[exprla-devel] RE: [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:
Thanks Kurt, for clearing this up;  I appreciate it!  I clearly was 
making
an error in terms of what sync and async really mean.  So now that 
that
issue is clearer in my mind, the next question is:  what is the 
terminology
and process of accessing data non-sequentially called, and would this 
be
handled by the transfer protocol itself, or be handled by XPL 
processes?  Or
can it even work the way I was thinking in the first place?

In any case, the revised requirement/design goal should read:

  a.. XPL will stream 0 or more streams of heterogeneous data, 
including XML
and/or non-XML media types.
(Please feel free to rephrase this to sound better and be more 
concise - I
don't like using "stream ... streams" in the same sentence fragment.)

We will keep this open for discussion and vote using the Poll feature 
of
egroups, if and when necessary.  Once consensus is reached concerning 
this
and other requirement/design goal issues, focus on implementation 
will fall
into the hands of the most knowledgeable in this area.

Richard Anthony Hein

  -----Original Message-----
  From: Kurt Cagle [mailto:cagle@o...]
  Sent: July 5, 2000 1:26 PM
  To: xpl@e...
  Subject: Re: [XPL] Issue: XPL will stream XML data ... (was Re: a 
domain
name for XPL)


  Richard,

  Typically, asynchronous is not the same as non-sequential.  A 
synchronous
stream is one in which the processing thread effectively locks any 
other
threads until the stream has completely loaded, while an asynchronous 
stream
is one in which the processing thread relinquishes control to other 
threads
and works in the background. The upshot of this is that a synchronous 
stream
can be loaded through a single call, but it means that NOTHING else 
happens
until the stream completely loads:

  myDoc.async=false
  myDoc.load "mySource.xml"
  write myDoc.xml

  The code in the above case will work automatically, but there will 
be a
(potentially lengthy) delay until the file loads before the write 
statement
executes.  On the other hand:

  myDoc.async=true
  myDoc.load "mySource.xml"
  write myDoc.xml

  will likely generate an error (or at the very least display 
nothing) since
the document may not have finished loading before the write call is 
made. An
asynchronous stream usually relies on some kind of even binding 
mechanism.
For example:

  function outputDoc()
      if readyState="complete" then
          write myDoc.xml
      end if
  end function

  myDoc.async=true
  myDoc.load "mySource.xml"
  myDoc.onreadyStateChange=outputDoc

  (this is pseudo code here, but the idea holds) will call the 
function
outputDoc any time the ready state of the XML document changes, and 
will
output the contents when the document has completely loaded. 
Asynchronous
programming is more complicated to write, but it makes for more 
responsive
code.

  -- Kurt

  ----- Original Message -----
    From: Richard Anthony Hein
    To: xpl@e...
    Sent: Wednesday, July 05, 2000 10:12 AM
    Subject: [XPL] Issue: XPL will stream XML data ... (was Re: a 
domain
name for XPL)


    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. :-)



    To unsubscribe from this group, send an email to:
    xpl-unsubscribe@o...




----------------------------------------------------------------------
------
--



----------------------------------------------------------------------
------
--
  To unsubscribe from this group, send an email to:
  xpl-unsubscribe@o...
--- End forwarded message ---