mikelin at MIT.EDU
Tue Feb 19 19:13:24 UTC 2002
Firstly, I would like to say that I am very satisfied and very grateful
with how the discussion over JEP-0017 has evolved. Some serious problems
that I hadn't thought of were pointed out, and I like to think that it
has started the intellectual ball rolling on framing in JNG, which was
definitely a goal from the start.
That stated, I still believe JEP-0017 framing will be useful in the near
term (within the next year) since it is unlikely that JNG will be
substantially deployed within that time period.
In the face of the misframe propagation problem that was pointed out by
David Waite, Diz, and others, I'll withdraw all predictions of how the
framing will "obviously" improve performance. However, I can confidently
predict that it can perform at least as well as can be done currently.
The code simplicity reason why JEP-0017 adds "real value" that I've been
referring to time and again is quite subtle and is most clear if you
have the experience of having actually implemented a Jabber XML stream
processor. In the worst case, the framing data makes no difference to
the stream processor; in the best case, it makes the processor's task
vastly simpler and less error-prone (depending on variables like the XML
parsing suite used, asynchronous I/O capabilities of the system,
willingess to reimplement portions of processor code, and so on).
In the end, I would like to see JEP-0017 or some derivative thereof as
an active informational JEP so that the option is at least legitimately
available to new implementations. I think this is a case where the line
between informational and standards is somewhat blurred.
I've updated JEP-0017 to reflect this new thinking. I hope we can build
a test implementation and move JEP-0017 to draft stage in the near
On Wed, 2002-02-06 at 22:35, Iain Shigeoka wrote:
> On 2/6/02 10:01 AM, "Dave Smith" <dizzyd at jabber.org> wrote:
> > On Mon, Feb 04, 2002 at 04:49:03PM -0500, Mike Lin wrote:
> >>> Yes. Hence, I have moved the discussion of JNG to another thread. With
> >>> regard to JEP 0017, I think our original discussion still stands: there are
> >>> difficult problems here and it may just not be worth addressing without a
> >>> willingness to consider alternatives to Jabber's "pure XML" approach...
> >>> Will a stopgap XML framing effort pay off and be adopted?
> >> There are real benefits to new implementations (such as Jabber.NET and
> >> Jabber for embedded devices) from having JEP-0017-style framing
> >> information available, since it makes XML Stream interpretation much
> >> easier.
> > After a considerable amount of contemplation, I'm going to just go ahead
> > and concede the point. While I don't agree with the approach, that
> > doesn't make the approach _wrong_.
> Thanks for saying that. I'll have to add my vote to this as well. I don't
> like the approach of framing being taken as it seems too much of a hack to
> add real value, but my primary complaints have been mainly driven by my
> aesthetic dislike for the approach and not how well it fills the limited
> role stated.
> > *Dizzy eats his hat*
> Well, I wouldn't go that far. :) Even though something isn't wrong doesn't
> mean it's necessarily right. Sometimes these aesthetic objections are due
> to something about the approach that should be examined and in doing so, may
> result in a better spec. That's the whole point of the JEP review process
> and the JEP author (Mike) has been very good about taking this criticism
> constructively and defending the proposal without being defensive. As long
> as the objections are addressed or at least noted in the JEP, I think it was
> well worth it. Sometimes the reasons behind the standards are just as
> valuable as the standards themselves.
> > The most important thing is that no matter what the framing protocol,
> > everything is interoperable. Jabber can (and should) move beyond a
> > single implementation and mindset (as Iain pointed out).
> > Mike, my apologies for "dissing" an idea before giving it a chance.
> If any of my objections came across as "dissing" I too apologize. I don't
> think we devolved to that though did we?
> > Now, I don't think I would like to see this JEP reach a "standard"
> > status -- it seems more fitting to term it as "informational" or
> > something. There will certainly be other framing approaches, and it
> > might be in our best interest to not necessarily push one or the other,
> > but instead just document them all and ensure that they can interoperate.
> I'm unsure of the value of making it informational. At least as I
> understand it, this JEP addresses the current Jabber protocols without
> really intending to extend beyond that. I'm not sure that we'll be looking
> at many more framing protocols for the existing Jabber model. From our
> other discussions on the subject, it seems that any other significant
> framing effort will probably require significant Jabber changes and hence,
> probably fall into JNG territory. So whether it is a standard or
> informational JEP seems unimportant in the scheme of things. My very casual
> opinion. :)
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
> Standards-JIG mailing list
> Standards-JIG at jabber.org
More information about the Standards