<<I believe the problem I am seeing is the easy determination of what type of
devices are out there. For example in current os's a generic monitor driver
can be loaded just by knowing an unknown device is a monitor. For a printer
or other generic device ( like a camera complying with the sony desktop
camera specification ) could be loaded. In the case of a low-end digital
camera, the camera would like to be able to assess that a printer is out
there that would support the "Digital Still Image" protocol with very little
overhead.>>
I'm still uncertain as to whether or not you and the PWG believe there is a
difficulty.
I read what you've written above and say to myself, "Ya, sure...that's the
way it works."
Is there agreement that it is a Unit Directory that identifies the presence
of any particular 1394 device? If we are, the searcher (the digital camera in
your example) needs to read configuration ROM of the other nodes on the bus.
OK. No there's the question of the order in which you determine a) protocol
and b) device type. At the moment the presumed order is protocol first,
device type second. This is because there is no universal registration
authority to assign device class ID numbers---it is left to the specifier of
the protocol to assign numeric values to device class ID's. The SCSI family
of commands is one illustration: you have to know that the device is a SCSI
device, first, before you can discover that device type 0x02 means a printer.
Could you be more specific as to where you think the problems, if any, lie?
Regards,
Peter Johansson
Congruent Software, Inc.
3998 Whittle Avenue
Oakland, CA 94602
(510) 531-5472
(510) 531-2942 FAX
pjohansson@aol.com