[standards-jig] Stream Contexts

Thomas Muldowney temas at box5.net
Thu Jun 26 16:05:49 UTC 2003


You know what, your on again off again attitude with SI has been severly
hindering the process we've been trying to work through.  In the
protocol gathering you were largely alright with the decisions made
there.  Yet it seems within the week after a gathering you raise some
other "issue" or revise REL to be exactly like what exists.  This is
tiresome and boring.  Now about the specific REL revision.

As I read it now, you've basically created double duty for clients.  REL
forces the client to use many back and forths during the actual
negotiation (seperation of usage and stream negotiation) and even worse
the stream itself now has double duty.  Because of the CID transmission
you now have to hook up a REL parser, and then change that out for the
actual stream usage.  Sure it might look easy on paper since it's just
the id<cr> and then data, but in reality you can't know how big a read
is so you are mangling buffers to ensure no data loss along the way.  In
my opinion, streams should be kept clear of anything but the data or
negotiated protocol.  We've gone down this road of discussion before and
it hasn't been fruitful.

I don't know what else to say at this point.  Others can chime in or
not, but I'm getting close to finding someone to motion SI to last call
and we can debate the fine points, before vote, then.

--temas


On Thu, 2003-06-26 at 06:47, Justin Karneges wrote:
> I have updated JEP-0041 (REL) to reflect this context issue.  Until stpeter 
> makes it available, you can find it here:
> 
>   http://www.affinix.com/~justin/jep-0041.html
> 
> No longer does REL require inheritance or for the stream JEPs to be modified.  
> Now the context id is sent over the datastream, and so the stream JEPs 
> themselves are left context-free, just like a TCP socket.
> 
> I went ahead and plugged all the holes in the JEP that I could think of, added 
> stream requirements and state information, and otherwise fleshed it out 
> (disco, extra sections, schema).  It is now actually clear and presentable.  
> If something in the JEP looks like it makes bad assumptions, or is otherwise 
> dodgy, let me know.  In the past, the problem I've had with all of these 
> stream negotiation JEPs (including my own) is that there was always something 
> dodgy going on.
> 
> REL looks a bit more like Jidlink this time around, with its own separate iq 
> exchange to determine the stream method.  This was intentional, as I cannot 
> think of another way to allow multiple method attempts for one context, short 
> of requiring modification of the streams themselves (which the previous 
> version of REL depended on).
> 
> temas, you may like this version of REL better now that I've described the 
> stream requirements and states.  Or maybe not.
> 
> linuxwolf, I'm not here to be "belligerent", but only to try and show how 
> things can be made better.  REL gets critiqued, certainly I can critique SI?
> 
> I don't mind if JEP-95 ends-up superceding JEP-41.  There was a similar 
> situation in the past with JEP-65 superceding my JEP-46.  Once JEP-65 reached 
> the capability I desired, I sided with it.
> 
> At this point, I can't side with JEP-95.  I'm trying to, but I just can't 
> figure out how to get it in the condition I want.  I can, however, get JEP-41 
> into shape, and I hope it can either be accepted or used as a model to 
> further JEP-95.  Either way is fine with me, so as long as we have a good 
> result.
> 
> And anyway, majority rules, right?  Can't some others besides the 3 of us 
> speak up here too?
> 
> -Justin
> 
> On Wednesday 25 June 2003 12:56 pm, Justin Karneges wrote:
> > By 'context' I speak of the link between stream and whatever uses it.  This
> > is briefly covered in JEP-95, Section 4.2 and in JEP-41, Section 2.2,
> > however these solutions are not optimal in my opinion.
> >
> > -Justin
> >
> > On Wednesday 25 June 2003 08:44 am, Thomas Muldowney wrote:
> > > I'm sorry, but what is the SI JEP doing?  Or is "context", which you
> > > never fully explain, something magically different?
> > >
> > > --temas
> > >
> > > On Wed, 2003-06-25 at 06:42, Justin Karneges wrote:
> > > > Hi all,
> > > >
> > > > I had a brainstorm last night (morning?) and I have concluded that one
> > > > annoying problem with this stream negotiation stuff is that we don't
> > > > have a clear way of passing context.
> > > >
> > > > Context is required to use a stream (S5B,IBB,anything else that
> > > > arises). There is never a time when you would not have context.  Maybe
> > > > you don't want SI or REL, but you will surely want context.  It's the
> > > > one thing we should all be able to agree on.
> > > >
> > > > I can see two possible ways to pass context to a stream:
> > > >
> > > > 1) Pass it inside of the datastream itself.
> > > >  or
> > > > 2) Pass it via the XML handshake of the stream.
> > > >
> > > > #1 is like TCP.  Think of HTTP GET.  However, since Jabber streams have
> > > > much fancier handshakes, we can easily accommodate context inside of
> > > > the XML exchange, so I'd prefer #2.  Unfortunately, without a standard
> > > > provision for this, the only acceptable way to pass context with
> > > > S5B/IBB currently is via the datastream.
> > > >
> > > > I propose to author a JEP to describe stream context.  It will be the
> > > > world's simplest JEP, with the following requirements:
> > > >
> > > > * Contexts are simply opaque strings
> > > > * Contexts must be unique for all streams
> > > > * Streams must have a provision for passing along the context
> > > >
> > > > Example of S5B using a possible standard context:
> > > >
> > > >   <iq
> > > >       type='set'
> > > >       from='initiator at host1/foo'
> > > >       to='target at host2/bar'
> > > >       id='initiate'>
> > > >     <query
> > > >       xmlns='http://www.jabber.org/protocol/bytestream'
> > > >       sid='mySID'
> > > >       xmlns:context='http://jabber.org/protocol/streamcontext'
> > > >       context:id='myCID'>
> > > >       <streamhost
> > > >           jid='initiator at host1/foo'
> > > >           host='192.168.4.1'
> > > >           port='5086'/>
> > > >     </query>
> > > >   </iq>
> > > >
> > > > Thoughts?
> > > >
> > > > -Justin
> > > > _______________________________________________
> > > > Standards-JIG mailing list
> > > > Standards-JIG at jabber.org
> > > > http://mailman.jabber.org/listinfo/standards-jig
> > >
> > > _______________________________________________
> > > Standards-JIG mailing list
> > > Standards-JIG at jabber.org
> > > http://mailman.jabber.org/listinfo/standards-jig
> >
> > _______________________________________________
> > Standards-JIG mailing list
> > Standards-JIG at jabber.org
> > http://mailman.jabber.org/listinfo/standards-jig
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig




More information about the Standards mailing list