I intentionally avoided stating preferences. I wanted to present
an "equivalent concept" chart, and see where the discussion goes.
> 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?
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 gregs@sdd.hp.com ----------------------------------------------------------------