Topic caption tells my desire :.)
keep in mind that making a nice, clean API for CAN is difficult. some people want CanOPEN, master, slave, some people want/need their own CAN protocol.
Thank you for the post.
I am in despirate search of practical CAN usage.
So far, only mbed with lpc1768 is the solution.
Try to think of this situation in an amusing way; there is an advertised feature (let it be wifi) but it is not in use yet:-)
I think that the Spark API should provide a simple API for setting baud rates, getting error states, and receiving/sending messages (11 & 29 bit IDs).
Once you have that capability higher level protocols can always be added such as J1939, or CANopen.
If the higher level protocols are placed into the Spark API, the code size will explode and people will be limited.
Of course the higher level protocols can always be added if people need it later.
My 2 cents.