I still believe this is the way to go. I'd like to clarify one
point and then ask a question:
Symmetry: You are all correct that the peer-to-peer nature of
1394 favors symmetry. For example, we'd like to have a scanner
send an image straight to a printer (less work for us OS folks!).
SBP-2 is not symmetric - it is an initiator/target model. What
I would like to clarify is that this is not automatically a
problem. In any particular session, we can define roles of
initiator and target, even between devices that are peers. I
would suggest that generally whatever device has initiated the
operation is the initiator (simple, huh?). In the scanner-printer
case, probably we pressed a button on the scanner to cause it to
print the image. So the scanner is the initiator in this case.
By the way, Apple does plan to support SBP-2 target functions in
Mac OS. We see SBP-2 as a good way for two computers on 1394 to
talk to each other. We also want to emulate a 1394 printer so
that the 1394 scanner can print to a legacy device (through us).
Now the question: I understand that printing is not a purely
one-way communication. The printer may need to communicate various
information back to the iniator during a print job. This need led
to much of the 1284.4-over-SBP-2 work, as far as I can tell. But
I have never seen a careful explanation of exactly what need exists.
If reverse-flow communication is used only rarely, then we can use
a slow, awkward mechanism for it, as long as we don't slow down the
primary forward-flow data communicatin. If reverse-flow
communication is used a lot, then maybe we need a more symmetric
transport. But my guess is that reverse-flow communication is much
smaller and less frequent than forward-flow communication. So
adding all the overhead of the 1284.4 credit-based transfer does
not pay off, because we don't need that for the forward-flow data.
So, when do we need printer-initiated data flow back to the host?
Error conditions are one obvious case. But errors are rare. Job
setup is the other obvious case. We might negotiate a bit with
the printer before we start printing. But that happens only once
at the start of a job, not during active data transfer. Is there
any other reverse dataflow that matters? If we can limit the
reverse data flow to error reporting, light status reporting, and
setup, then perhaps it's OK to use SBP-2 in a clumsy way for this,
leaving the normal dataflow to happen quickly and efficiently (in
SBP-2).
> 4) DPP over 1394.
>
> Sounds good. I have not seen enough of the detailed mechanism to
determine
> if it delivers (I need to learn more about DPP). Did receive some
comments
> at the TA about totally inventing a new mechanism instead of reusing
> existing protocols, though it could be the right answer.
As Greg wrote, my view of DPP is that it is almost as complex as
SBP-2, but less well documented, and it has holes such as flow
control. When these things are all fixed, we essentially have
another SBP-2 (an incompatible one). Also DPP was very expensive
on the host side, with lots of CPU-driven polling and transmission,
rather than the passive SBP-2 model where the printer just reads
data out of our memory.
> 5) TCP/IP over 1394.
>
> I think this is a given. (IP happens). This could give us printing
similar
> to the way it works today, as well as all the new internet possibilities.
> Address administration and configuration, (DNS and DHCP and others as
> Michael points out), make a full implementation larger than some devices
> might like. Not sure of the use model?
I also agree that IP-1394 will happen. However, this is a low-
performance solution, because a lot of host software work is
required to send and receive IP, and the flow control does
not map well to printing and 1394. Furthermore, this does nothing
for isochronous printing. The value of IP-1394 is in compatibility,
not performance. The shared-memory services of 1394 are lost with
IP, as far as I can tell.
> Conclusions?
>
> Alan