Subject: P1394> Re: SBP-2 vs. DPP 0.71 Cheat Sheet (?)

From: Kazuhiro HiRATA <[email-masked]>
Date: Mon, 23 Feb 98 20:59:07 +0900

Hi Greg,

[You wrote]
>What do you think?

I have question that which is your prefer to use for PC Printing.  So 
far, I thought you recommend to use SBP-2 for PC Printing.  However, I 
could not distinguish advantage to use SBP-2 for PC Printing in your 
comparison chart.

I feel that you are going to love THIN stack for PC Printing for keeping 
consistency with Peer-to-Peer devices.  Who does want to be fat for same 
function?

//[email-masked]'98

---

From: Greg Shue <[email-masked]>
Date: Mon, 23 Feb 1998 09:36:08 -0800 (PST)

> could not distinguish advantage to use SBP-2 for PC Printing in your 

I intentionally avoided stating preferences.  I wanted to present
an "equivalent concept" chart, and see where the discussion goes.

> consistency with Peer-to-Peer devices.  Who does want to be fat for same 

OK, here's my preference...

   "I am going to love using SBP-2 for peer-to-peer!

   (And, with a different SBP-2 command set, I'll love using it
   in a different way for PC printing!)"

Why?  Because:

  - Microsoft is supporting the SCSI model for scanning,
    so the standard scanning solution is built around SBP-2

  - Microsoft and Apple both prefer SBP-2 for printing,
    so I prefer an SBP-2 based printing protocol.

  - I want to support both PC printing and peer-to-peer
    interactions, so both protocols are going to exist.
    I don't see customers buying a printer which only
    supports peer-to-peer.

  As such, the SBP-2 based version only costs me the command set.
  I'm already paying for everything else (testing, ROM space, RAM
  space, tool support).  And, when I want to, I can easily build
  in access to other devices which use SBP-2 (e.g.  disk drives).

  No part of the Thin protocol comes for free.  And it may only
  work for the DPP protocol.

  To quote an interrested party:
     "Who does want to be fat for same function?"  :-)  :-)

  I am quite aware of product cost.  The "idea" of a $300 camera
  was mentioned as a cost-costrained device.  Let's not forget
  about the "idea" of a $500 MFP which prints, scans and faxes.
  They basically exist now...  I would guess that they are 
  equivalently constrained, and the MFP must support a greater
  variety of functionality (and protocols).

Also:

  I have no idea how the "30K +/- 10K" number fits into my
  environment.  There were:
  
    - no processors identified (CISC vs. RISC?),
    - no toolsets identified (C vs. C++? vendor A vs. vendor B),
    - no optimizations specified (none vs. compact vs. loop unrolling),
    - no design parameters identified (speed vs. space).
    
  (Hey, I might be able to do it in 10K!  Then again it might
  take 40K!)

  Those early numbers I shared really say that:

    sizeof(link driver) ~= sizeof(bus mgr) ~=
    sizeof(SBP-2 initiator) ~= sizeof(spb-2 target) ~=
    sizeof(IP1394 glue layer) ~= (1/3 -> 1/2) * sizeof(TCP/IP stack)

  Please don't get hung up on the absolute number of "30K".
  Besides, If you can't afford "30K" for the combined SBP-2
  layers, then you probably can't afford "30K" for the software
  to support a 1394 node, and you probably can't afford 1394 HW.

  (And, here is another reality check:  how big are ROMs these
  days?  Don't they come in practical package sizes of >= 0.5
  MBytes these days?  I have a hard time believing that anyone is
  considering putting 1394 in a product where they have less than
  7% headroom of one ROM package before they know what the
  technology really takes!)

-- 
Greg Shue
Hewlett-Packard Company
Office Products Division			[email-masked]
----------------------------------------------------------------

---

From: Atsushi_Nakamura <[email-masked]>
Date: Tue, 24 Feb 1998 10:06:37 +0900

At 02:36 98/02/24 +0900, Greg Shue wrote:

Has this been discussed with the "input" or "device-source" people ?

Peer to Peer is different from PC printing because we have to take 

requirements and restrictions of the input devices in to consideration,

whereas the PC has pratically no restrictions (PC can do anything.)  

No matter how much we, the printer guys may like SBP-2, peer to peer

can only be achieved if the image source support the (appropriate

functions of) same protocol.

Now, my question is : 

Q)Has anyone actually discussed with the input people about implementing

   BOTH initiator and target SBP-2 in input devices for peer to peer ?

Q)The scanner may prefer a SCSI-like solution , especially because of it's 

   origin as a PC peripheral, but how about digital cameras?,DV camcorders?

Toru Ueda wrote:

> We are developing DPP and THIN protocol. The biggest priority for THIN

> protocol is  the size and simplicity. I cannot explain the reason we

> need two logins for simple print task to our product engineers. Also I

> cannot explain the reason we need 20 or 30KB for print protocol, while

> the file transfer protocol using IR(Infra-Red) communication (called Ir

> TranP) needs only several Kilo bytes.

People like Ueda-san and others of the PWG-C HAS been discussing 

these issues with input people from not just the office products area, 

but the consumer market people as well, and we should consider the THIN

protocol as the outcome of these discussions.  

I would also agree this may be a good reasoning from the 

PC printing point of view. 

-Differnt reasoning for differnt solutions....Both reasonable.

>    supports peer-to-peer.

This is also VERY true. It's the manufacturer's responsibility 

to avoid end-user confusion.

If $300 digital cameras don't support SBP-2 but support DPP,  it's

our responsiblity to support it. Same opposite-wise.

My personal choice  

"I may not love it, but I will use BOTH situation by situation!"

 (I may have to implement AVC if that becomes necessary.)

That's why we proposed FDS right ?, 

(Whatever protocol, we know where the printer is...)

-----------------------------------------

<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):[email-masked]

email(2):[email-masked]

-----------------------------------------