[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:
This shouldn't be an issue. In general, the resposibility of the 
TCP/IP protocol is to assure that messages are reassembled in the 
correct order after coming through in non-cardinal order, or to 
request a retransmit if the message did not arrive completely. Unless 
you're writing a lot of socket packet switching code, you should 
generally not need to worry about whether the data arrives in the 
correct order; that's what TCP/IP is for. Note that both HTTP and 
BXXP are transport protocols, not transport control protocols -- they 
sit on top of TCP/IP and leverages the services that TCP/IP provides. 

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


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




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



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