You didn't discuss the STREAM_COMPLETION variable in your
"Revised PWG1394 CMD Set note, although I'm guessing it's
related to the question I raised (and my subsequent action
item) about whether there needs to be some negotiation over
strategies for pre-maturely completing stream-oriented ORBs.
(See page 8 of PWG 1394 Transport Command Set Proposal Rev.
0c: TO BE DETERMINED - When else should a target complete
this command? (e.g. "Flush" requested from target's
transport client; the target can no longer retain the data
The Store Data Command Response status block provides
a field called "residue". The Command Set Proposal
indicates that the meaning of "residue" depends upon
whether "message-based communication" is being used
or "stream-based communication" is being used between
host and device. As I understand it, "message-based
communication" implies that the initiator knows when
the target has data to send, but doesn't necessarily
know the length of the data. For the target, the
size of the data is reasonably predicable. "Stream-based
communication" allows more initiation on the part of
the target, so that the initiator must post a Store
Data ORB, to support the possibility that the target
will have data to transfer.
I think the question to be answered is whether there needs
to be negotiation between target and initiator (or maybe
just information from target to initiator) over when, under
stream-based comm., the target is allowed to complete the
Store Data Orb. As I thought about this, the only reasons
that I identified for termination were application
related. And the application (transport client in the
device) seemed to have it's own good reason.
So, what was the intent for the STREAM_COMPLETION
variable? Is there something I'm missing related
to the early completion of Store Data Commands
for stream-based communication?
-- Bob Morford (firstname.lastname@example.org) SIS Microelectronics, Inc. A Subsidiary of Aspec Technology, Inc. 1831 Lefthand Cir., Suite #E Longmont, CO 80501 303-776-1667 x226