On Mon, Feb 15, 2010 at 11:03:09AM +0100, Oliver Hartkopp wrote: > Kurt Van Dijck wrote: > > On Sat, Feb 13, 2010 at 05:32:52PM +0100, Oliver Hartkopp wrote: > > >> Generally the address structure should only contain information that's > >> really > >> needed to allow a usual communication requirement. Other things (like your > >> isoname that should not be relevant here anyway) or special settings that > >> differ from communication defaults could be set with sockopts. > >> > >> What do you think? > >> > >> Can you map your requirements to this reduced j1939 structure, or do you > >> feel > >> there's something missing? > > No, I feel there's a lot missing. > > And talking without the real implementation known is bit weird. > > It took quite a long time to create the socket programming interface for the > CAN Transportprotocols i implemented so far (ISO-TP, and the stuff described > in the doc on www.llcf.de). I don't question that. > > It's not the thing about the implementation. It's a matter of correct > abstraction and what parameters are better placed into socketoptions. > > If you look into > > Bloch, J. How to Design a Good API and Why it Matters. Oct. 2005. > http://lcsd05.cs.tamu.edu/slides/keynote.pdf I will read. > > you'll find these major points: > > • Easy to learn > • Easy to use, even without documentation > • Hard to misuse > • Easy to read and maintain code that uses it > • Sufficiently powerful to satisfy requirements > • Easy to extend > • Appropriate to audience > > Especially it has to be minimal in layout. And i'm sorry ... i find your 'less is more', and 'perfection is achieved when there is nothing left to strip'. I agree. > current suggestion for a j1939 address structure at least redundant in some > parts. Mmmh. > > Regards, > Oliver I'll come back on these in 2 weeks or so.
Kurt _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
