[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..., "Kurt Cagle" <cagle@o...> wrote:
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...
--- End forwarded message ---