[standards-jig] JEPs and Jabber Adoption
temas at box5.net
Sat Jun 28 22:17:02 UTC 2003
On Sat, 2003-06-28 at 16:23, Tijl Houtbeckers wrote:
> Rachel Blackman <rcb at ceruleanstudios.com> wrote on 28-6-2003 20:47:55:
> >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, and...
> >/me goes to find a bottle of Excedrin. Headaches, anyone? :)
> I guess it's a simple case of what's worse then. The whining we've had
> the past (and coming?) years for not having decent filetransfer
> support, or a period of whining because some clients don't support the
> eventual final protocol yet. (wich you'll have anyway, wether we have 1
> standard or 2).
> I suppose for client-writers the first solution is still bareable, but
> for people trying to convert others to Jabber, and people trying to
> promote Jabber in corporate enviroments I can imagine it's been a lot
The third option is the worst to me, it's the one where the maintainers
have to watch over many protocols because they've implemented them in
the wild. They'll have a few revisions with protocol a, a few with a &
b, some with a, b and c and the latest revision where they are working
to deprecate a,b,and c and move to the new "final solution" d. Having
many disparate systems out in the wild is not only a headache to the end
user it's a headache to the developer.
> Besides that, advancing a decent proposal to DRAFT more quickly won't
> necisarly lead the anarchy of protocols people are describing here. If
> there's a decent proposal that's well implemented and doesn't give any
> trouble, the second proposal would have to show some major advantages
> should it convince client-authors to reimplement this functionality.
> All we do now is compete on theoretical assumptions (like you said,
> experimental JEPs are not at all attractive to implement, let alone
> ship to your clients) for many many hours, and almost never on
> implementation and large scale testing of that implementation. It's
> also worth considering that protocols that are theoretical compromises
> aren't automatically the best (hello SIMPLE!).
Like I just stated in my other reply to you if we suddenly make draft
status a lot looser it becomes the same as experimental. It will also
be undesirable to implement in anything other than your testing branch.
> I think it's very unfortunate that when you have a good idea, and you
> write a good JEP for it, that's technically OK, you can't go ahead with
> it just because someone thinks your idea or solution should be more
> like theirs. Add to that there's hardly a way of objectivly finding out
> wich idea *is* the best, by just discussing it or letting a council
> look at it (esp. this type of council).
Who's stopping you? There are JEPs that are pretty stale now that are
in massive internal deployment, because the JEP authors haven't actively
pushed them through. They've been amazingly helpful in learning for
other systems we develop. Haven't we maintained that's the beauty of
Jabber? If your system is technically _solid_ use it, push the list
constantly, email it every day if you feel it's appropiate. The more
you make people look at something either they will see it to be
something amazing, or you are going to have even more bug hunters.
That's what this is all about.
Finally, I would like you to expand on "this type of council" this
comment is bothering me more every time I read this, but I want to make
sure we figure out what you mean. That way, the future councils won't
make similar mistakes, or we can fix the rules.
More information about the Standards