[Foundation] JIGs and JEEPs
dwaite at jabber.com
Thu May 24 17:54:24 CDT 2001
Peter Saint-Andre wrote:
> Some ramblings....
> I like the idea of borrowing ideas from other successful projects, and
> Python is certainly one of them. However, Jabber is a little different
> from Python (and Apache etc.) because it has two aspects: protocol and
> code (and, it could be argued, architecture). So I'm struggling a bit
> in trying to map Python's SIGs and PEPs over to Jabber's JIGs and
> JEEPs (gotta work on that acronym, though -- maybe it stands for
> Jabber Enhancement/Extension Proposal? :).
How is that?
The Jabber Foundation does not produce code, or at least that is what I
thought - that was the purpose of creating Jabelin. Also, other than the
server2server and client2server protocols, the foundation doesn't
dictate a particular architecture. Sure, both existing implementations
I've seen have a very similar architecture, and I can seem some
informational notes pushed through to help compatibility for external
components between implementations. However, as long as I support the
'standard' c2s and s2s protocols, an alternate implementation should be
able created with any architecture desired, even if it means some of the
existing code written for components will not work with it.
> Jabber currently has 22 mailing lists, many of which are
> platform-specific (e.g., mac-dev), language-specific (e.g.,
> python-dev) or project-specific (e.g., server-dev, wcs-dev). Some are
> more general (e.g., the security list), but really only two (jdev and
> jadmin) get a significant amount of traffic. Furthermore, the JADMIN
> list is (mostly) specific to the server that will soon be known as
> Jabelin. JDEV also sees a lot of questions that are specific to the
> current codebase.
> With Jabelin splitting off into its own project, it seems to me that
> JIGs will focus on topics that are general -- i.e., not specific to
> Jabelin or to any particular platform or language. (However, I still
> think there might be value in having forums for the latter, so that
> all the Perl fans or Mac-heads can get together and compare notes etc.
> -- would those not be hosted through the Jabber Foundation?)
I don't see why there would need to be platform/language forums within
the Jabber Foundation. I do see these being useful on Jabelin.
> That said, the list of JIGs that we came up with in yesterday's
> meeting and after seems pretty good to me, with the addition of a
> docs-jig and perhaps a little re-jiggering here and there (mainly in
> my mind to align with some of the thinking behind the recent Jabber
> Progress Report, see http://jabber.org/?oid=1406). Taking the best
> from all materials I can find, here is how I understand the JIGs:
> 1. meta-jig (General Foundation Stuff) -- includes management of and
> policies for all other JIGs. (Is this different from the "Executive
> Committee" mentioned in the proposed articles of incorporation at
> http://foundation.jabber.org/bylaws-draft.html ?)
> 2. infra-jig (Foundation Infrastructure) -- jabber.org website,
> mailing lists, development tools, CVS, etc. Could this be rolled into
> the meta-jig as a sub-team? That makes sense to me.
Does the Jabber Foundation need development tools or CVS? :-)
> 3. docs-jig (Documentation) -- kinda speaks for itself. Lots of work
> to be done here. :) May develop JEEPs related to documentation
> standards, and will definitely work with the other JEEP-creating JIGs.
What would the goal for this JIG be? To document incomplete/ poorly
understood ("legacy") protocol, to exist as a resource for all other
JIGs in maintaining documentation, maintain all the documents produced
by the foundation, and/or to propose the rules on how documentation
should be written and what is required for a formalized proposal and
> 4. biz-jig (Standards Conformance, Business Relations) -- evaluates
> projects and products for conformance/compliance with standards of
> "Jabber purity" and such (but it seems to me that those standards
> actually are developed by other JIGs). Perhaps markets or evangelizes
> Jabber. Also in Dave Rahul's definition handles financial matters,
> legal issues, and general management of the foundation. However, I'm
> wondering if the management functions are better off handled by the
> Board of Directors, that's what we're paying them the big bucks for! :)
> 5. security-jig (Security) -- develops security standards, completes
> security audits, creates JEEPs related to security, authentication,
> privacy, and the like.
> 6. client-jig (Client Development) -- creates standards and guidelines
> (including JEEPs) for Jabber client functionality. Delivers those
> standards to the biz-jig. Sub-projects here might include text
> formatting, file transfer, and web intergration.
> 7. server-jig (Server Development) -- creates standards and guidelines
> for Jabber servers (core XML routing, probably Jabber-as-middleware)
> in whatever language. Delivers those standards to the biz-jig. Might
> work together with client-jig and component-jig to develop JEEPs
> related to "cross-functional" protocol like browsing, presence
> management, and message filtering.
Which of these last two jigs would define a specification as a whole?
Say for instance, I want to start projects up to create a new
conferencing standard, solidify browsing and introspection
functionality, and revise how presence works. All three of these require
protocol, all require functionality implemented within the server, and
all require functionality in the client. In addition, client
user-interface issues, i18n issues both come to play, and we may
eventually also standardize other access protocols (such as a
nonpersistant connection protocol for wireless clients).. in which case
we would also need to create different guidelines and potentially a
different protocol for interaction.
In the end though, the goals are specifications on conferencing,
browsing/introspection and presence. It doesn't seem like either one of
these two base groups can
be responsible for the entire process there. All three projects would
need to be started on both lists, which would be a nightmare for those
participating, and even worse for those not ;-)
Also, what is this about delivering standards to the biz-jig? It seems
like the membership as a whole should decide what gets made into an
official recommendation, and those members should also decide what
features get rolled into the 'required' protocol for certification.
> 8. component-jig (Component Development) -- creates standards and
> guidelines (including JEEPs) related to the development of internal
> and external server components. Delivers those standards to the
> biz-jig. Sub-projects here might include conferencing, database
> integration, whiteboarding, and transports.
The differentiation between something as a server and separate
components is a strong architectural distinction. I may want one big
monolithic server, or I may use a separate component model than other
existing implementations to spread things out. Neither of these could
ever be anything more than an informational note. Thats not to say that
defining a database integration and schema standard, several internal
component standards, xmlstream-based external component protocol
standards, transport standards, etc. is not a *huge* job and one that
needs to be done, but this could even be an informal Jabelin effort,
with that project submitting these notes to the Jabber Foundation as
> As to the organization of JIGs, I would prefer (especially after a
> chat with Ryan Eatmon yesterday) to have a small "ruling council" for
> each JIG rather than one head person. Ryan suggested having 5 people
> on each council, but I think that 3 people on the council might be
> better (mainly so I can call it a triumvirate, but also because I
> think it might be hard to find 5 people for some of these JIGs --
> hopefully I'm wrong about that :). However, 5 people would give us
> more input and different perspectives, which would probably be
> valuable. Each council member would serve a defined period of time (6
> months?) and then would need to be re-appointed / re-elected. I'm not
> sure how council members would gain their positions, perhaps they
> volunteer and are approved by the meta-jig?
What does IETF do here? I would say that a formalized JIG should only
decide technical decisions in official meetings, and outside fo those
meetings this triumvirate would pretty much be doing list administration
and recommendations. I don't see any reason if I was the head person or
a member of the triumvirate that the standards produced should be any
more heavily influenced by myself, other than that I was interested
enough in establishing a standard to want to lead the group.
> Those are my thoughts so far, hopefully you've found them useful.
More information about the Members