I think everyone would agree to this as an "ideal" solution.
Unfortunately. the reality (at least now) is that the PWG and PWG-C
have requirements that are "similar", but not the "same".
The difference may be small, but seem to be crutial to both sides.
It may be the "level",or depth of each requirement items, or
priority of requirement items (for example, "light", symmetrical VS,
existing
protocol use, OS support)
If we can come up with a PWG solutionthat can cover the difference, that
would be great. On the other hand, if the DPP thin transport can be used fro
PWG printing, that would be good too, and will be the ideal solution.
>, but it just seems that we have accepted a
>transport (SBP-2) that isn't symmetrical and we are calling it good.
I think so too. It's one of the reasons why I asked the whether we
ever officially decide to go with SBP-2...
There was still discussion in Maui whether symmetrical (and/or
bi-directional)
was necessary or not for PWG printing. (must or want ?)
This is one of the questions we need to get consensus first , as well as
prioritizing the requirements. For example, if existing protocol use is much
more important for PWG printing than symmetric, SBP-2 may be good
after all.
-----Original Message-----
差出人 : Stephen Holmstead <stephen@hpb16977.boi.hp.com>
宛先 : 'Toru Ueda' <ueda@slab.tnr.sharp.co.jp>; Turner, Randy
<rturner@sharplabs.com>
CC : 'Stephen Holmstead' <stephen@hpb16977.boi.hp.com>; 'Brian Batchelder'
<brianb@vcd.hp.com>; p1394@pwg.org <p1394@pwg.org>
日時 : 1998年2月14日 13:00
件名 : RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes
>I agree with Toru that we NEED a symmetrical transport. I really don't
>care which option (A or B) is used, as long as we can provide a
>symmetrical connection. In fact, that was one of the PWG transport
>requirements from that start, but it just seems that we have accepted a
>transport (SBP-2) that isn't symmetrical and we are calling it good.
>The PWG-C also needs a symmetrical transport. I would love to have the
>same transport for the PWG and PWG-C (since they both have the same
>requirements). I would HATE to have to make a printer that implemented
>two different transports for PWG and PWG-C printing. I think most
>printer manufacturers would agree.
>
>Greg Shue said that he made a proposal to the January PWG that would
>extend SBP-2 so that it was symmetrical (at least that is what I
>understand--I may be way off here). If so, that would be great. I have
>not been able to find any minutes from the PWG since Dec 97 (anyone got
>some?).
>
>1394 could really use a commonly accepted symmetrical transport layer.
>If that's 1284.4, great. If that's a modified SBP-2, great. If that's
>TCP/IP, great. If that's DPP's Thin Protocol, great.
>
>Personally, I am biased towards IP or 1284.4 (if you couldn't tell).
>
>Stephen Holmstead
>
>> -----Original Message-----
>> From: Toru Ueda [SMTP:ueda@slab.tnr.sharp.co.jp]
>> Sent: Friday, February 13, 1998 5:45 AM
>> To: Turner, Randy
>> Cc: 'Stephen Holmstead'; 'Brian Batchelder'; p1394@pwg.org
>> Subject: Re[2]: P1394> Rough SBP-2 & IP1394 core component ROM
>> sizes
>>
>>
>> I don't want to make any confusion about PC printing protocol. This is
>> only for your information.
>>
>> >From consumer device point of view, "symmetrical" is the essential
>> feature of the protocol.
>> For example, a digital still camera wants to send its image data to
>> printers. Also the same camera wants to receive image data from the
>> other still cameras. We want to use the same protocol for both use.
>>
>> These are three essential features for consumer device.
>>
>> 1) Bi-directional
>> Each side can send and receive data.
>> SBP2 supports bi-directional feature.
>>
>> 2) "True" bi-directional
>> Each side can send and receive data at any time.
>> Alan's architecture supports "true" bi-directional feature by using
>> transmit buffer, receive buffer and unsolicited status.
>>
>> 3) Symmetrical
>> Each side has the same architecture.
>> This is completely different from bi-directional issue.
>>
>> Consumer device needs these three features and the protocol must be
>> simple.
>>
>> If SBP2 implementation needs 30K for initiator and target, it might be
>> difficult to use it for consumer device.
>>
>> Toru Ueda
>> Software labs.
>> Sharp Corp.
>>
>> On Wed, 11 Feb 1998 08:35:10 -0800
>> "Turner, Randy" <rturner@sharplabs.com> wrote:
>>
>> >
>> >
>> > I didn't know chip sets offered "explicit" support for SBP-2. OHCI
>> > maybe, but I hadn't seen the chip set feature in the brochure for
>> > "chip-level SBP-2 support".
>> >
>> > Also, since 1394 is a peer-to-peer interface, anyone developing a
>> > peer-to-peer device (like the majority of the Japanese electronics
>> > industry), would have to essentially duplicate the functionality of
>> > SBP-2 initiator and target, whether they actually use SBP-2 to do
>> this,
>> > or some other (potentially proprietary) method for implementing
>> > peer-to-peer functionality.
>> >
>> > Randy
>> >
>> >
>> >
>> > -----Original Message-----
>> > From: Stephen Homestead [SMTP:stephen@hpb16977.boi.hp.com]
>> > Sent: Wednesday, February 11, 1998 8:30 AM
>> > To: 'Turner, Randy'; 'Brian Batchelder'; p1394@pwg.org
>> > Subject: RE: P1394> Rough SBP-2 & IP1394 core component
>> > ROM sizes
>> >
>> > My experiences in the past is that combining target AND
>> > initiator
>> > functions into a single device is VERY difficult. The
>> > complexity of the
>> > state tables and ambiguities that can arise make it very
>> > difficult.
>> > Also, I don't believe any of the chip manufacturers support
>> > SBP-2 for
>> > both target and initiator. In my opinion, it's NOT just a
>> > matter of
>> > adding the 15K for the target and 15K for the initiator. The
>> > target and
>> > initiator have vastly different functions. Designing a model
>> > that did
>> > both (well) would be a challenge. It was problems like this
>> > that fueled
>> > many of the AEN (asynchronous event notification) debates.
>> >
>> > Stephen
>> >
>> > > -----Original Message-----
>> > > From: Turner, Randy [SMTP:rturner@sharplabs.com]
>> > > Sent: Monday, February 09, 1998 1:03 PM
>> > > To: 'Brian Batchelder'; p1394@pwg.org
>> > > Subject: RE: P1394> Rough SBP-2 & IP1394 core component
>> > ROM sizes
>> > >
>> > >
>> > > I am very interested in the combined target/initiator
>> > footprint as
>> > > well.
>> > >
>> > > Thx
>> > >
>> > > Randy
>> > >
>> > >
>> > > -----Original Message-----
>> > > From: Brian Batchelder [SMTP:brianb@vcd.hp.com]
>> > > Sent: Monday, February 09, 1998 9:37 AM
>> > > To: p1394@pwg.org
>> > > Subject: Re: P1394> Rough SBP-2 & IP1394 core
>> > component
>> > > ROM sizes
>> > >
>> > > At 02:04 PM 2/6/98 -0800, Greg Shue wrote:
>> > >
>> > > [snip]
>> > >
>> > > >I approached them about sharing some rough estimates of
>> > code
>> > > size
>> > > >for the IP1394 glue, SBP-2 target and initiator, and
>> > 1394 bus
>> > > >manager modules to get a feel for how "heavy" the
>> > protocol
>> > > >implementations really are. They graciously shared the
>> > flowing
>> > > >estimates with us, and certainly deserve our thanks.
>> > Since the
>> > > >technology is still being developed, these
>> > implementations are
>> > > >certainly going to be tuned and the numbers will change
>> > a
>> > > little
>> > > >bit.
>> > > >
>> > > > Component Rough ROM size (KBytes)
>> > > > --------- -----------------------
>> > > > SBP-2 initiator core 15 +/- 5
>> > > > SBP-2 target core 15 +/- 5 (incl. Mgmt+Fetch
>> > agent,
>> > > no exec agent)
>> > >
>> > > Any idea how big a combined SBP-2 target/initiator would
>> > be?
>> > > 15-30K? ;-)
>> > >
>> > > [snip]
>> > >
>> > > Brian
>> > >
>> > >
>> >
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> > > ~
>> > > Brian Batchelder | Hewlett-Packard |
>> > > mailto:brianb@vcd.hp.com
>> > > Connectivity Futurist | 1115 SE 164th Ave. | Phone:
>> > (360)
>> > > 212-4107
>> > > DeskJet Printers | Vancouver, WA 98684 | Fax:
>> > (360)
>> > > 212-4227
>> >
>