>Jet Send's code size is not worth for comparing or discussing transport
layer.
>"Consumer" product is very sensitive to cost of code size, but it also
depends
>on the benefit of "consumer". In my experience, the first EOS system
had 64kB
>total ROM 10 years ago, but it was successful in the market for the
reason of
>integration of automatic and manual tuning capability with simple user
>interface. JetSend might lead successful product in consumer market
regardless
>of its code size. But this is not the discussiong point in PWG-C.
I think I need to clarify the position of JetSend. JetSend is NOT a
transport layer protocol (in the OSI model). JetSend fits ABOVE the
transport layer and provides the session, presentation, and part of the
application layers. JetSend is transport independent, but it does need
a transport layer to sit on. JetSend doesn't care what transport layer
that is (e.g. 1284.4, DPP's Thin Protocol, IP/1394, etc.), but it does
need a transport layer that is symmetrical (just like DPP). That's why
I (as one of the JetSend architects) am so interested in this current
discussion.
It sounds like there is some support to work with PWG-C to define a
standard transport layer for 1394. I think this is excellent. I would
strongly support and help such an effort.
Stephen Holmstead
Hewlett Packard Information Appliance Operation