An UnitDir is assumed as the entity of a function, a function (ex.
a printer, or a scanner, ) may have several services, for example
job control, printing, status monitoring and finisher control.
A "Function" is an abstracted software entity of a real device.
A "Service" is an abstracted software model of an executable
UnitDir == Function (printer) -----|
We've discussed three ideas listed below;
(1) an initiator logins to the function.
(2) an initiator logins to each service.
(3) hybrid solution of (1) and (2).
If we choose (2), naturally each service shall be associated
with a LUN and the initiator shall specify the selected LUN in
parameter of "login".
If we choose (1), a function shall be assumed as one LUN.
The initiator shall specify this LUN at login, and this LUN
shall provide multiplexing to support several services.
I have no urge to describe (3). This idea seems to be too
complicated for me.
Second idea is neat. And current profile (0.52) is applicable
for this model. However I am not sure whether existing PC OS
is supporting PnP of this architecture.
UnitDir ---|-- LUN
Also I don't think current PC OS is supporting dynamic adding
of LUNs. Thus it is difficult to add service entity on demand.
The first idea is not neat, but may be supported even under
existing PC OS.
UnitDir ----- LUN
UnitDir ----- LUN
However, each service requires a multiplexed connection and
each connection requires flow control and send/receive queues.
My proposal suggested in the last meeting was describing
multiplexing, but it does not have description for flow control
of each logical channels. So my question is, shall we choose
second idea? or does anyone have better idea for (3) option?
Or is there new idea??
--- -------------------------------------------- Fumio Nagasaka Epson Software Development Laboratory Inc. Tel +81 268 25 4111, Fax +81 268 25 4627 E-mail to <mailto:email@example.com> firstname.lastname@example.org. co.jp