[Foundation] JIGs and JEEPs
dwaite at jabber.com
Fri May 25 11:03:14 CDT 2001
Iain Shigeoka wrote:
> At 05:43 PM 5/24/2001 -0600, you wrote:
> >>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.
> It's starting to sound to me like too much administration overhead. As I
> understand it (and what I hope for) is that the Foundation is here to help
> in well focused "support" functionality and standards
> creation/maintenance/testing/enforcement. As such, it seems to me we
> really only need to worry about 3 things right now:
> Jabber standards (standards & protocols, performance metering, and
> compliance testing)
> Jabber PR (press releases, press relations, promotion, branding, and "legal
> enforcement" of standards through compliance testing and logo/branding)
> Jabber Biz (legal, helping businesses (other than Jabber.com) use/exploit
> Jabber, creating partnerships, negotiating on behalf of the Jabber
> community, $$$ to do fund raising, paying for conferences, scholarships)
I like these :-) Have Jabber Standards also be responsible for internal standards
(documentation format), and go ahead and add this general members list to the mix.
> >>>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.
> Yes. We need standards and tests for standards. But I'm not sure why we
> need a foundation to help people write clients. What benefits does the
> Foundation provide for an OSS jabber client writer beyond say a sourceforge
> project? Are we trying to standardize how people write clients? I was
> under the impression Jabber shouldn't care how the client is written as
> long as it meets the standards (and can therefore interoperate).
I could see UI recommendations and requirements; for instance, saying that a
particular case must be handled for a compliance rating, or just providing general
tips for how things should be represented. I'm hoping to have a draft of
conferencing ready for today, and it has a few UI interface guidelines interspersed
throughout; future drafts will be restructures so these have their own section.
More information about the Members