To All,
>At this point in time we have apparently narrowed our potential solutions
>to the following:
>A- 1284.4 with SBP-2
>B- New SBP-2 command set with SBP-2
chosen to be THE transport for PC printing, and we will work the "glue"
for it. Has it ?
This is a very important decision, and I have not heard anything
"official" about it. (Did I miss something in one of the meetings ?
I apologize if I did.)
IP over1394 ?, thin protocol(DPP)?, AVC? ...
Nothing negative about SBP-2, I just want to take I thing at a time.
On the other hand, if we decide to use 1284.4, the natural way of thinking
technically is to come up with a "glue" ( or SBP-2 subset, which was once
proposed but turned down) between 1284.4 and 1394, since 1284.4
and SBP-2 has overlapping functionality.
I don't think anyone is planning on doing that.
I would like to consider supporting B, IF we have decided to use
SBP-2 for PC printing.
Eric' s note about Taigate and native-bridge was very convincing,
and I also think the same kind of situationt applies fro the printing world.
The HPT proposal, along with Alan's January proposal are 2 details
of the "B" work, which is similar to the direction the strorage protocol
went from Tailgate to native-bridge, which I think is the natural way of
thinking purely technically.
Ats Nakamura
At 22:33 98/02/09 -0800, Eric Anderson wrote:
>
> Recently, the 1394 community had the opportunity to define a
> storage protocol for 1394. The first solution, Tailgate, gave
> us essentially an ATA interface bridged over 1394. Both the
> target and the initiator had to operate as if traditional ATA
> was the interconnect. Sure, SBP-2 was present, but only as a
> transport, and much of it's potential was wasted. Tailgate
> was supposed to be quick an easy and lead to rapid market
> adoption. What actually happened was quite different.
>
> Microsoft and others realized that adopting this model would
> "lock in" ATA for a long time, including long after ATA itself
> was dead. Emulating a dead technology with new technology may
> yield short-term savings in implementation, but at the expense of
> long-term losses in performance. Amazingly, reason prevailed,
> and Tailgate was abandoned in favor of a pure SBP-2 protocol
> for disk drives. As it turned out, Tailgate vendors quickly
> switched to Native Bridge, which still allowed today's drives
> to act like 1394 drives, by making them look (from a 1394
> point of view) like fully native devices. As far as I can tell
> this switch was not too painful, and now we aren't stuck with
> ATA. Everyone won.
>
> Now we have a similar situation with printers. 1284.4 is a
> very well established technology. Compared to 1394, I think it
> would be fair to say that 1284.4 is also a very slow and clumsy
> technology (nothing personal!). Surprise, surprise - the idea
> comes up to bundle 1284.4 in SBP-2 because some purported savings
> can be had, in the short term. From what I have seen of how this
> works, it is quite inefficient, with lots of unsolicited status
> requests and in general lots of hand-holding by the CPU on the
> initiator. This is not what SBP-2 was designed for.
>
-----------------------------------------
<bigger>Atsushi Nakamura
</bigger>-----------------------------------------
BJ Technology Develpoment 22,
Canon Inc.
53 Imai Kami-cho
Nakahara-Ku, Kawasaki-shi
postal no. 211
tel:+81-3-44-733-6111(ext.5593)
+81-3-44-739-6634(direct)
fax:+81-3-44-739-6756
email(1):Atsushi_Nakamura at cbj.canon.co.jp
email(2):atsnaka at bsd.canon.co.jp
-----------------------------------------