[JDEV] Connectivity and streaming.

[Thomas Charron]

Quoting Scott Robinson <quad at jabber.org>:
> <disclaimer>
> This post is being originated from the fact that there are many able coders
> on this list, but none can become involved because Jer leaves many details
> for later. The coding architecture of Jabber is still very centralized. The
> recent message-level routing discussion has given me much faith in The
> Jabber Team, and I believe that we can work from what we currently have
> into
> developing a full v0.7 protocol spec.
> </disclaimer>

  I agree, in part.  Anyone is welcome to join libs-dev and start chatting, but 
I have seen '0' traffic on that list..  Nadda, zlich, zip.  I guess I don't 
understand your complaint here?  It it that you think Jer is idea hording?

> <summary>
> Currently, on docs.jabber.org, Jer has posted a very sketchy example of an
> XML streaming system. While this works for many systems, and it especially
> flows well with our "coherent XML document" paradigm, I would like to place
> the following on the table: we cannot assume we'll be running on a reliable
> socket medium.
> </summary>

  This I CAN agree with.  I truely wish we had a more solid document on exactly 
what the XML Streams will look like, etc..

> <completeness>
> a) client and transport
> Between the client and transport, the connection requirements are unknown
> as well as the data. This is exactly what the Jabber paradigm is in that we
> want to create transports which can connect to ANY IM-esque protocol in
> existance as well as ones to come. This means we cannot place any
> requirements upon the data coming into our transports.
> </completeness>

  Err, I don't think there are any limitations.  Heck, the 
transport<=>Etherx<=>transport protocol encapsulates everything inside of a 
CDATA segment.  To be honest, I'm RELYING on the way etherx encapsulates the 
data to handle NON Jabber traffic..
 
> <important>
> b) transport and router
<SNIP>
> general thought (as well as what I've seen in the documentation) is we'll
> have a reliable (TCP) connection between the transport and router. We
> cannot
> assume this! This is only available on a TCP/IP network, which by the
> design
> of Jabber we cannot have network-level assumptions of this sort. New forms
> of intra-level communication will appear. Example: direct router access as
> seen in the new direct jabbertransport access and direct etherx access via
> IPC/shared memory.

  Ok, confusal here.  I *THINK* I grasp what your saying here, but technically 
speaking, there is no reason why there HAS to be a persistent connection 
between the router and the transport.  Who ever said that?  Granted, THERE HAS 
TO BE A CONNECTION LONG ENOUGH to transfer the data, and we cannot 'split' it, 
but it does nOT have to be persistant.  Shared memory I'm not getting.  Shared 
memory doesn't work anything like a socket connection.  Please, explain more 
regarding what you mean?

> c) router and router
> We've also made the assumption communications between routers will be
> TCP/IP
> only. The XML streams recommended implementation has given direct support
> for this. A router on a unreliable network would be forced to understand
> (or
> parse) the contents of a "properly" implemented Jabbertransport. As it is
> also stated in the plans for our routing system, in general, we cannot have
> this.
> </improtant>

  (*BANG*)  That was my remaining brain cell exploding.  No one has stepped 
forward and implemented any other protocols beside's TCP/IP.  There is NO 
REASON why someone could not add that capability.  I bet technically it 
wouldn't be all that hard to rig in something like IPX..  (Ok, I'm gonna say 
it, but EEEEEWWWWWWWw!!!!)

> <solution>
> Rather than force network requirements upon our communications layers, we
> should reduce the needs of our REFERENCE transport and router. XML
> streaming, as an example, should have recommendations for short/burst
> connections and streams. In that, jabbertransport would need to communicate
> with etherx in much shorter (hopefully, a single message per connection)
> squeals.

  Again, there is nothing saying that the transport needs to stay connected.  
Etherx should be able to spool messages when the transport is not connected, 
not a problem.  Actually, one of the reasons when we where looking at the route 
tag that I mentioned archived, simply becouse this is what etherx would do when 
it can't send the message, and basically spools it offline to ensure the 
message persists..

> <silver lining>
> There is hope though! I can see an improved T&R (JabberBox) protocol which
> allows for route-checking, and more importantly a way of querying the MTS
> (maximum transmission size) and whether a connection is "reliable." This,
> unfortunately, would only be on a transport-to-transport basis. However,
> remember we want all the processing in the transports and not the routers
> (or clients to a level).
> </silver lining>
> </solution>

  Yes, we want the processing of the XML messages within the transports, but 
I'd suppose that we could setup the XML streams to allow fragmented XML 
streams, allowing The streams to be split up..  (Oh dear god, what do we do 
with the routing data when it goes two different ways..).  Heck, we could send 
the XML streams as larger sized UDP packets..  That's as unreliable as you can 
get..

> <alternatives>
> I can imagine posts of "well, then we can the unreliable systems be FORCED
> to code a reliable protocol underneath Jabber." However, I, as a developer,
> would not appreciate network transport requirements to come bundled into
> this new "universal" communications system. It might even give me reason to
> move to a project which didn't require even MORE coding on my part.

  This is all at the stream layer, IMHO.  The Jabber protocol that most people 
have been using/looking at is a TCP/IP based protocol, no questions asked.  
That's what Jabbertransport is currently IS.  I would like to see, for the 
reasons you stated, that etherx itself support fragmentation, etc of messages, 
and perhaps even tag the streams with 'Packet ID's'.  This can all be done with 
what we have now.  I don;t think we've been veering AWAY from a non TCP/IP 
oriented situation, I just don;t think we've headed twards it either.

  To that point, I'd also like to say we've been gearing it twards person to 
person IM.  This fits in your example, as when I want to send/recieve SMS 
messages via cellphone/pager.  The data transfered may not be someone saying 
'Hello, how was your day..' type of messages..  It could easily be something 
like log file entries, public key transfers, etc..  etc..

  Now, that's not to say we've geared AWAY from this, we just haven't focused 
on it.

> We want to take over the world, let's give the world a reason to take us
> with open arms.

  Good way to put it.  I get what your trying to say, I just perhaps don't 
agree with the idea that we're straying away from anything BUT TCP/IP..

--- 
Thomas Charron
<< Wanted: One decent sig >>
<< Preferably litle used  >>
<< and stored in garage.  ?>>