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). 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 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 current suggestion for a j1939 address structure at least redundant in some parts. Regards, Oliver _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
