Re: [lwip-devel] Extended udp_recv callback

[Kieran Mansley]

On Tue, 2009-01-13 at 22:21 +0000, Jonathan Larmour wrote:
> 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.

It would only have to provide support for the extended part of the API
if it set the flag that activated that path.  i.e. If it didn't know
about the extended API everything would continue to work as it does now,
even if the extended API code were compiled in.

Kieran