[exprla-devel] [XPL] Issue: XPL will stream XML data ... (was Re: a domain name for XPL)

[reid_spencer <ras...@re...>]

--- In xpl-dev@y..., "Richard Anthony Hein" <935551@i...> wrote:
I made a new thread for this topic, and encourage people to make new 
threads
for specific issues so we can have some order when discussing them, 
as they
respond to individual points.  Here I will discuss and open for Q&A 
the
issue of XPL streaming data.
  -----Original Message-----
  From: me@m... [mailto:me@m...]On
Behalf Of Jonathan Burns
  Sent: July 5, 2000 9:15 AM
  To: xpl@e...
  Subject: Re: [XPL] Re: a domain name for XPL


  Richard Anthony Hein wrote:

      a.. XPL will stream XML data, in an asynchronous and/or 
synchronous
format, and support multiple streams of heterogeneous data, including
non-XML media types.

  I support this as a requirement, except that I'm not sure what
"synchronous" and "asynchronous"
  mean in context here.

  From my simple hardware background, "synchronous" means: multiple
processes are going on;
  their outputs must be combined, and delivered in a correct order; to
ensure this, processes are
  constrained to open for input or output only on logical conditions, 
which
are dependent on a
  global counter or timestamping system.
  [RAH]
I will try to explain what I had in mind.  As I understand it, data 
can be
input synchronously or asynchronously.  Synchronous would be 
according to
your definition, and async means that streams of data can arrive
out-of-order and processed independently where possible.  So for 
example, if
you have streaming video the frames themselves may not arrive in 
order, and
they may even be decoded out of order.  The only point in which they 
are
assembled occurs after processing of the data, then it's sent to the 
player
for output.  In a peer-to-peer network, this should mean it's 
possible to
get frame 1 from one location and frame 2 from another, out of 
sequence,
choosing where to download from based on transfer speed, decode each 
one of
them when they arrive, independently, and then assemble them.  
Perhaps this
isn't an XPL issue per se, but a transfer protocol issue.

In a synchronous method, the frames must be downloaded in order 
(correct me
if I am wrong).  So I would have to wait for frame 1 to be finished
downloading before I can retrieve frame 2, decode frame 1 first, then 
2, and
finally assemble them.  Each step could really be either async or 
sync,
depending on the application and data.  XPL should have the ability to
stream data in either fashion, I think.  For example, I can set async
download and decoding for the first 30 frames that make up 1 second of
video, but get the sets of 30 frames in order (sync.).  So each 
second is
downloaded, decoded and sent to the player in order, but the frames 
that
make up the second are downloaded in arbitrary order.

I don't really know if this is simply a protocol issue, but I am 
pretty sure
that we have to make XPL to be able to recognize the difference, to 
be able
to tell processes what to do with the data, and a way to "mark" parts 
of a
data stream in a way that makes it easy to know where each piece 
belongs.
However, I don't know much about it, so I differ to the better 
judgement of
my peers, especially Lucas on this one, since he has been working on
protocol issues at a low level.  I think this is his place, not mine, 
to say
and correct.
  Is this the sense of things for Web protocols?  Lucas? Kurt?
  [RAH]

 Yes, let the protocol people focus on this; I think I'll step away 
on this
one, and let them work on it.

More to come on the other topics - after lunch!

Richard Anthony Hein

(I got a new job today!  Actually, it's not great, but I need a 
temporary
job to fill in the gaps.  It's not even programming, but at least 
it'll pay
the bills, and I get to go out to all kinds of summer events.  Plus 
it's for
the Ontario Provincial Police, so I am hoping I can slip in there 
with some
XML apps for collecting and processing data in the field using PDAs - 
they
have TONS of paperwork. :-)
--- End forwarded message ---