[JDEV] Connectivity and streaming.

[Scott Robinson]

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

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

<review>
The current Jabber system layout has three layers of network transportation:
between client and transport (C&T), between transport and router (C&B), and
between router and router (R&R). Each has their own connection requirements
and types of data being passed.
</review>

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

<important>
b) transport and router
Communications requirements between the transport and router are also
unknown. However, I believe we've made the mistake, since our only examples
have been jabbertransport and etherx, of making to many assumptions. The
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.

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>

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

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

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

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

Scott.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
URL: <https://www.jabber.org/jdev/attachments/19991012/d4a746e5/attachment-0002.pgp>