[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:
Okay, then that clears that up for me.  I think, if I can find some 
time, I
will take a look at that TCP/IP book have laying around somewhere, 
but never
read, so I can talk somewhat intelligently about it!
So you mean to say that whole design goal point ("XML will 
stream ...") is
not necessary, or just what I asked about handling non-sequential 
data?

Thanks again,

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


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




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



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