Re: [lwip-devel] Extended udp_recv callback

[Jonathan Larmour]

Kieran Mansley wrote:
> I think a combination of the two approaches might be best:
>  - add an extra callback to the API, something like pcb->recv_ext() with
> an associated means of setting a handler for this callback. 
>  - have a pcb->flag that selects whether to use the normal recv callback
> or the extended recv callback.
>  - have a compile time EXTENDED_RECV_CALLBACK definition that can be
> used to compile the extended recv callback feature out if others don't
> want it.
>
> That way existing code doesn't need to be modified as the old callback
> remains the same.

I just noticed that you seemed to be saying this wouldn't just be a 
temporary measure. If it's not temporary, I don't believe it's such a good 
change because then you essentially have two mutually exclusive APIs for 
the same thing. Any well-written raw API code integrated with lwIP (other 
protocol stacks on top of lwIP, or applications, or services, etc.) will 
have to check whether EXTENDED_RECV_CALLBACK was set by the user, and 
provide support for both cases. I don't think that's a good thing in an API.

Jifl
--
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["The best things in life aren't things."]------      Opinions==mine