[Foundation] JEPs

Rahul Dave rahul at reno.cis.upenn.edu
Fri Jun 29 10:21:12 CDT 2001


Hey Peter,
Great stuff on the DTD. I like it!

> On Fri, Jun 29, 2001 at 09:57:07AM -0500, Peter Saint-Andre wrote:
> > 
> > > - wouldn't it be useful to be able to identify what proposal type
> > >   a JEP is, by looking at its number? How about a prefix such as
> > >   'S', 'J' or 'I' for 'Standards Track', 'JIG' or 'Informational'
> > >   respectively.
> > 
> > Hmmm, well we were really just following the Python usage. But I suppose
> > we could have JEP-I0001 and JEP-J0001 and so on -- do you think that would
> > get confusing?
> 
> Well, I'm not aware to what extent the Pythonists get confused. I suppose
> with time, a prefix might not be necessary, but while it can help us get
> going without doing any harm, why not? Rahul, is there any reason why the
> Python PEP people keep to this 4-digit restriction?

I am guessing that this is bacause standards track PEP's outnumber
informational ones by a few times. This is likely to happen here too..

Consider, for example Web Services. There would likely be 1-2 JIG JEP's,
1 informational JEP (like the howto howto in linux with the index), and
many JEP's like xmlrpc over jabber, soap over jabber, jabber as SOAP, 
jabber as XMLRPC, jabber server discovery protocol, jabber transactional
extension, yada, yada..

Rahul
> 
> > >   STANDARDS TRACK: proposed|draft|final|deferred|rejected|obsolete
> > >   JIG PROPOSAL   : proposed|deferred|rejected|obsolete
> > >   INFORMATIONAL  : proposed|active|deferred|rejected|obsolete
> > > 
> > >   Is this correct?
> > 
> > Yes that's what I was thinking, I'll make that explicit in the doc.
> 
> Cool. I was just trying to imagine diagrams like this:
> 
>    +----------+         +----------+
>    | proposed | --+---> | draft    | ------> ...
>    +----------+   |     +----------+
>                   |
>                   |     +----------+
>                   +---> | rejected |
>                         +----------+
> 
> If you want me to do them, let me know. 
> 
> > > - reference implementation; I'm assuming this is in tune with the
> > >   proto/implementation decoupling initiative and could be in any
> > >   language? (/me goes off to learn Haskell or something equally
> > >   ridiculous)
> > 
> > Heehee. Well let's say you wanted to add some functionality that in the
> > current architecture required only a server-side component, I suppose you
> > could write it in some weird language as an external component. But I
> > think that the Jabelin server pretty much aims to be the (if not the only)
> > reference implementation -- not sure what a reference implementation would
> > be client-side, though.
> 
> Well, this is sort of the discussion I was attempting to bring up. On the
> one hand, component-style functionality can theoretically be in any 
> language as long as the code can talk jabber:component:* . On the other 
> hand, a ref impl.specific to, say, JSM, would suit being coded in JabberC. 
> 
> But (a) in a proposal, the focus might be more appropriate on what is being
> done, not in what language, and (b) I have heard that the next generation 
> (not necessarily Jabelin-sourced but possibly) might be in C++, which I 
> (i) do not know at all [1] and (ii) think is an abhorrent language from what
> I have seen :-)
> 
> [1] this didn't stop me learning C to read Jabber server source, though
> 
> Anyway, it was just a theoretical question[2] - I' sure these things will
> all come out in the wash. 
> 
> [2] is that a question that's only a question in theory, or a question *on*
> theory?
> 
> Forward ho!
> 
> dj
> _______________________________________________
> Members mailing list
> Members at jabber.org
> http://mailman.jabber.org/listinfo/members
> 




More information about the Members mailing list