[standards-jig] Core Tool Protocols
theo at theoretic.com
Wed Aug 7 16:45:21 UTC 2002
Iain Shigeoka wrote:
> Sorry Adam. I think to start talking about JNG needs to address other
> issues first. So I'll put them inline and see what you think. :)
Yes, please, I relish the feedback.
mmm... relish. /me goes off to fix a hot dog real quick.
/me is back.
I have not thought that a smooth transition would be possible. I should
have clarified that. I am not after a smooth transition since I, too,
realize those two items must be done in order to do Jabber 2.0/JNG, and
they will break the current protocol and codebase no matter how we do
it. I do plan for Jabber 2.0/JNG to be seperated into 3 tiers: Routing,
Core Tools, and Environments, each building off the one underneath it.
But I realize that trying to do it all at once would be asking for
trouble, and would result in a protocol designed by committee (here's
your que, rynok...).
So, instead I've decided to create a "transition protocol" off the
current protocol, starting with making the Core Tools for the current
protocol. When the Core Tools are mature and robust in a year's time or
so, then we can start looking into breaking the routing layer off from
the application layer, and have the Core Tools ready and waiting for
people to start using.
It seems our ideas are along the same lines after all. What do you think
of the Core Tools concept as it relates to the current protocol? See
anything amiss? I'm looking to turn this transition plan into a JEP
soon, so I'm wanting to get as much feedback as possible.
And thanks for the pointers, Iain!
>>I had planned to carefully build them as the start to Jabber 2.0, but
>>after some good advice from dizzyd, I have realized that Jabber 2.0
>>should not be a hard break from the current protocols. It should instead
>>be a gradual, evolutionary progress that results in a whole new
>>generation for the Jabber protocol.
> I hear this a lot. My problem with the smooth evolution theory is this:
> We (er, well at least "I") want to make two fundamental changes to Jabber to
> enable next generation features:
> 1) Transport independence - free the Jabber protocols from the underlying
> network transport. (raw persistent TCP/IP, HTTP, SMS, etc).
> 2) Framing - it is pretty widely accepted that the current lack of framing
> makes designing and implementing the protocol difficult. Each packet
> (chunk) should be a separate and complete XML documents. This helps to
> handle the network traffic (routing), parsing, namespaces, etc.
> I still don't see how you could make a smooth transition between what we
> have now and a JNG based around these two major changes. Perhaps a smooth
> transition isn't as important as a compatible transition. JNG should be
> able to run in parallel with Jabber in the same server and messages should
> be able to be passed between clients using JNG and Jabber (and servers
> should be able to S2S with Jabber and JNG implementations).
> Sort of like HTML --> XHTML (transitional) --> XML + CSS
> Perhaps we should be thinking more of:
> J1.0 --> Jtransition --> JNG
> With J1.0 and JNG being necessarily incompatible... I think it is also
> significant that the order of development of the standards was: HTML, XML,
> XHTML. They made an incompatible new protocol then created a transitional
> bridge to move from the old to the new...
/\ Adam Theo, Age 23, Tallahassee FL USA
//\\ Email & Jabber: theo at theoretic.com
// \\ Pager: (850) 709 7738
// || \\ Theoretic Solutions: http://www.theoretic.com
|| "Building Ideas by Bringing them Together"
|| Jabber Protocol: http://www.jabber.org
|| "The Next Generation Communications Protocol"
|| "A Free-Market Socialist Patriotic American Buddhist"
More information about the Standards