Your opinion persuade me 95%,… I like your opinion.
However I could not agree these points.
Greg Shue wrote:
<<
If “best” is thought of in terms of developers and development effort,
then there is no significant difference between providing the SBP-2 only
solution or the SBP-2 portion of a combined solution. There will be
additional effort for a combined solution if a 1284.4 driver needs to be
developed.
If “best” is thought of in terms of (availability of) OS support,
then the SBP-2 only solution is preferred because a greater portion
of the total solution already is provided by or is committed to
by OS vendors.
>>
If we choose 1284.4 as transport layer in PC printing architecture,
we can use same transport layer to cover USB, 1394 and conventional
parallel port. And if we adopt socket API on 1284.4 service, then we
can use same interface for any local devices and for any network
devices.
This feature greatly decrease development efforts to make protocol
stack in PC printing area. And it would provide better usability even
for end users.
If we choose new transport for SBP-2/1394 stack, then we need to
develop different middle device driver to cover rest of other I/O(s).
How do you think this point?
--------------------------------------------
-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111, Fax +81 268 25 4627
E-mail to nagasaka.fumio@exc.epson.co.jp
-----Original Message-----
From: Greg Shue [SMTP:gregs@sdd.hp.com]
Sent: Wednesday, February 11, 1998 12:21 PM
To: Larry Stein
Cc: p1394@pwg.org; P1284_3@lexmark.com
Subject: Re: P1394> 1284.4 over SBP-2
> I await your responses.
OK, here we go...
Larry Stein wrote:
> 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
>
> As many of you are aware, I'm primarily in support of
option A as the
> preferred solution. I'd like to take this opportunity
to provide some of
> my reasoning and get feedback from you.
>
> My support for this solution is not necessarily a
technical reason, but a
> market reason. As Greg Shue et al pointed out at the
Maui meeting, it is
> possible to provide the required functionality by
defining a new Command
> Set for SBP-2. This would provide a transport
solution for 1394 that is
> based solely on the SBP-2 protocol. Technically, this
is probably a better
> solution than option A.
>
> My question is "Is this really the best solution for
the market today?".
> Many of us have expended great effort in developing
the IEEE P1284.4
> standard. One of the purposes and goals of the
development was to create
> a datalink independent transport standard that could
be used over the
> parallel port and other physical interfaces.
>
> The intent here was to create a standard that would
allow a peripheral to
> operate over various interfaces without requiring
major architectural
> changes to the product. In other words, a modular
approach to the
> peripheral design. A printer or MFP device could be
developed to work with
> 1284.4 over parallel today, and 'easily' adapted to
work over 1394
> tomorrow. The host application interface may not even
know the difference.
>
As I understood it, the ability for 'a peripheral to
operate over
various interfaces without requiring major architectural
changes
to the product' is provided by meeting the specified
transport
service requirements. As long as the transport
requirements are
met, no architectural changes are required of the
product. Thus,
the transport layers are all modular with respect to the
product.
(I think this is also why the PWG has not tried to
eliminate a
TCP/IP printing solution. :-)
The main difference between options A and B is whether
multiple
services are made available through a 1284.4 MUX layer,
or
through a combination of Unit Directories and Logical
Unit
Numbers. The command set features needed for a combined
1284.4/SBP-2 solution are essentially identical as for
an
SBP-2 only solution (as shown below).
In order to provide a combined SBP-2/1284.4 solution,
an
SBP-2 command set must be provided which meets the
Data Link
requirements spelled out for 1284.4. These are:
R1) Register/Unregister transport layer with the
Data Link layer
R2) Packet Data Transfer - error free, in order, as
a whole
R3) Asynchronous Operation - no polling shall be
required.
In order to map this within SBP-2, then the command
set must
provide (at least) the following features:
F1) Transient link interruption support
(to support R2 and R3)
F2) Non-transient link loss indication (to support
F1)
F3) Extended SBP-2 Access Control to the transport
interface (to support F1)
F4) SBP-2 ORB execution model for packet transfers
(to support R2 and R3)
F5) Encapsulating of 1284.4 packets into ORBs
(to support R2)
F6) Policy to determine maximum DL packet size
(to support R2 and F1)
F7) Policy for how 1284.4 dialogue maps into SBP-2
access
control (to support R2, R3, and F1)
F8) Standard mechanism for indicating existence of
1284.4
peer (to support R1)
So, any of these features which are common with an
SBP-2 only
solution are outside the scope of concern here.
(For the
unfamiliar, they all are provided in the (very
rough) SBP-2
only proposal presented at the January PWG 1394
meeting.)
These features are also those required for an SBP-2 only
solution.
Since these are in common, they _don't_ affect the
choice of option A
vs. option B.
I can't give an answer to Larry's question directly,
because "best"
is rather subjective. What's "best" for a customer
might not be
"best" for a developer, and that might not be "best" for
a
technology, which are all indirectly related to what is
"best"
for the market. I tried to identify above what are not
areas of
tradeoffs between the two options so that we can look at
what are.
If "best" is thought of in terms of market, then (I
suppose)
supportability and deployment of the solution(s) matter
the most,
because the 'market' has almost no history. There
really is no
legacy issue which makes either choice A or choice B
preferred,
even though there are "legacy" printing solutions which
will need
to be supported (i.e. AVC, IP1394). So, each of the
following
areas become signficant:
If "best" is thought of in terms of providing the
transport
services outlined by the requirements, then there is no
signficant difference between the SBP-2 only solution or
the
combined solution.
If "best" is thought of in terms of developers and
development
effort, then there is no significant difference between
providing
the SBP-2 only solution or the SBP-2 portion of a
combined
solution. There will be additional effort for a
combined
solution if a 1284.4 driver needs to be developed.
If "best" is thought of in terms of (availability of) OS
support,
then the SBP-2 only solution is preferred because a
greater portion
of the total solution already is provided by or is
committed to
by OS vendors.
If "best" is thought of in terms of product cost, then
the SBP-2
only solution is preferred because it has fewer layers.
If "best" is thought of in terms of performance, then
the SBP-2
only solution is preferred because it isn't limited to
64-KByte
packets.
If "best" is thought of in terms of 1394 bus usage, then
the
SBP-2 only solution is preferred because it doesn't have
the CBT
crediting traffic of 1284.4.
If "best" is thought of in terms of compliance
testability, then
the SBP-2 only solution is preferred because it is
simpler and
has fewer layers.
If "best" is thought of in terms of availability
customer
solutions, then the SBP-2 only solution is preferred
because of
it's smaller footprint (which makes it more attractive
to
integrate into more devices) and it's spreading use for
varying
types of services on 1394.
> I think that this is the primary reasons for choosing
option A. It sends a
> clear statement to peripheral and OS vendors that
1284.4 is the preferred
> transport interface for printer and MFP peripherals.
We back this up by
> providing solutions for parallel (1284.3) and for
1394. This is not a
> stagnant industry and certainly new interfaces will
appear in the future.
> I think it would be a great service that we provide a
clear migration path
> between interfaces that do not require redesign of the
entire system.
Unfortunately, that message of 1284.4 being "the
preferred
transport interface for printers" has been lost in the
shuffle.
There are (currently) four transport protocols being
defined on
1394 for printing. These are:
+ AVC (for video snapshot)
+ DPP (for non-PC device-to-device)
+ PWG 1394 solution(s) (being discussed)
+ IP1394
I also haven't seen it get embraced for standardization
on USB,
where hardware limitations and lack of a multiplexing
transport
protocol solution identify a hole which 1284.4 can fill.
When this is added to (Apple's) Eric Anderson's thoughts
of:
- Emulating a dead technology with new technology may
yield
short-term savings in implementation, but at the
expense of
long-term losses in performance. (philisophical)
- Amazingly, reason prevailed, and Tailgate was
abandoned in
favor of a pure SBP-2 protocol for disk drives.
(historical)
- From what I have seen of how this (1284.4 over
SBP-2) 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.
(perceptual)
- Used properly, SBP-2 allows huge data transfers that
can proceed
at the pace of the consumer (printer), with no
hand-holding by
the host (computer)... SBP-2 and OpenHCI make this
possible - but
only if protocols are designed with care to avoid
needless
interruption of the host. (practical)
- 1394 is far more "future friendly" and scalable than
other
interconnects were at their introductions... The
more inefficient
the protocol we choose, the more demand there will
be for
ever-faster interconnects. A well-designed,
efficient protocol
can last a very long time, and serve everyone's
needs better during
that time. (consequential)
- To conclude, I want to ask a simple question: Has
anyone run
this idea past Microsoft? Microsoft killed off
Tailgate, and
my guess is that they may have similar feelings
about printing.
Market reality is that we'll all follow whatever
they decide,
so it really makes sense to get them involved.
(REALISTIC!!)
And (from a previous posting of Eric's):
- Microsoft says that their treatment of printers will
be
different. They will only login to printers and
other shared
devices when they actually want to use the printer.
So a printer
with only one login could be shared by several
Windows systems.
Apple plans to do the same thing for printers using
SBP-2.
And the most quotable quote from the January 98 PWG 1394
meeting:
"Every protocol looks light until it's implemented."
Given all of this, I am compelled to support option B.
--
Greg Shue
Hewlett-Packard Company
Office Products
Division gregs@sdd.hp.com
----------------------------------------------------------------