[Foundation] JIGs and JEEPs
stpeter at jabber.org
Thu May 24 18:43:10 CDT 2001
David Waite wrote:
> How is that? ... The Jabber Foundation does not produce code,
No, the Jabber Foundation does not produce code. But the Jabber
community does. Notice I said Jabber, not the Jabber Foundation.
Certainly Jabber as it is commonly understood right now is more than
> 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.
True. Right now, however, we have identified a need for some
standards/guidelines regarding clients, servers, and components (if for
no reason other than our standards-conformance activities), so I would
see those JIGs working on that. Perhaps we need to emulate Python and
make sure that every JIG has a start-date and an end-date, because
perhaps these architecture-specific JIGs will wither away like the
> 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.
Well, Jabelin is just C. That's why I'm struggling to find the right
place for these community forums.
> Does the Jabber Foundation need development tools or CVS? :-)
Yes, if it provides organizational assistance to the projects within the
Jabber community, which is part of the purpose of the Jabber Foundation
as I understand it. Plus it might be good to have those JEEPs under
version control. :)
>> 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
> final specification?
That all sounds good. :P
>> 6. client-jig (Client Development) -- creates standards and guidelines
>> 7. server-jig (Server Development) -- creates standards and guidelines
> Which of these last two jigs would define a specification as a whole?
That's a good question. I think we need perhaps something more general.
So, as hinted above, the client-jig and server-jig might develop these
conformance standards, but perhaps we need an over-arching protocol-jig.
> 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 ;-)
Good points all. I notice that client-server architecture creeping in
again, though. :) Seriously, I see what you're saying: perhaps the JIGs
would be more effective if directed to specific protocol/functionality
areas (e.g., conferencing, file transfer, presence management) than
something as generic as clients or servers.
Time to bike home, I guess I'll look at the rest tomorrow. :)
stpeter at jabber.org
More information about the Members