[Foundation] JIGs and JEEPs

[Peter Saint-Andre]

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 
mere protocol.


> 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 
Marxist state.


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

<snip>

Time to bike home, I guess I'll look at the rest tomorrow. :)

Peter

-- 
Peter Saint-Andre
stpeter at jabber.org