[Foundation] JEPs

DJ Adams dj.adams at pobox.com
Fri Jun 29 10:06:59 CDT 2001

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?

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

Forward ho!


More information about the Members mailing list