[standards-jig] JEPs and Jabber Adoption

Rachel Blackman rcb at ceruleanstudios.com
Sat Jun 28 18:47:55 UTC 2003

Hash: SHA1

> I like the process, except for one key part:  The utter lack of
> community support!  I'm completely serious about this.  How many people
> say absolutely nothing when a new JEP comes out?  How many people reply
> to a new revision?  How many people even answer simple questions by the
> authors?  Damn near no one!  Look at every major discussion on s-jig. 
> It hasn't happened until a JEP was right about to go last call.  People
> need to be more active throughout the development of JEPs, and the
> authors need to be more out in the open with their development.  I think
> there are way more than enough people around for us to quickly get
> something together and through the door if everyone is actively
> involved.

I think this is partly because there's a bit of an issue as to when to
speak up.  Worse still, I know that I really only can make what I feel are
authoritative comments on a JEP after I've implemented it and seen how it
works.  Yet, there's a lot of discouragement from implementing experimental
JEPs; witness the avatar kerfluffle of only recently.  

So I as a client author face a choice.  Do I try to implement an
experimental feature (therefore adding support for it, and therefore
causing an expectation that the feature will work and continue to work and
interoperate, among my client userbase), or do I wait until it's gone
draft?  If the first, I gain a lot of practical experience that I can bring
to the table when discussing the JEP... but then it's one more client
implementing an experimental feature.  If the second, it means there's no
worries about experimental things becoming 'active' simply through
extensive use (witness how people are unhappy with the idea of removing the
old avatar support since so many clients /do/ already use it).

> I think letting through multiple versions of similar protocols is an
> extreme waste of time.  I think the council needs to be more active in
> getting all the parties interested in a topic together (that's what I
> tried to do with FT) and working hard to find a solutino that is
> generally agreeable.  The council can not be a backburner group waiting
> for the vote, it needs to be fully proactive in protocol growth.  Couple
> this with my previously mentioned help from everyone on s-jig and we can
> get a system together quickly.

+128, and quite vehemently

While I agree that it's really not great that we're blocked on this and are
still lacking a file transfer protocol more functional than Yahoo's (which
is basically the same as iq:oob), I think we ask for more problems than we
solve if we allow multiple versions of the same solution.  If we have
multiple methods of file transfer, I either have to implement /all/ of
them, or deal with whining from my users as to why they can send to /some/
users, but not others, and those users claim /they/ have file transfer too,

/me goes to find a bottle of Excedrin.  Headaches, anyone? :)

- -- 
Rachel Blackman <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillian.cc/
Version: GnuPG v1.2.1 (MingW32)


More information about the Standards mailing list