[jdev] Re: Proposal for a solution (to transport rosters)

[Nolan Eakins]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Remko Troncon wrote:
> I think this is one of the major problems with the way Jabber is going
> right now. If we do this 'the right way', it will take year(s) until it
> is actually approved, implemented, and active. And without better

Doing it the right way is always good, and it could take years if you wait
until the JEP is approved to start the implementation. The first
implementation or two of a JEP should be done alongside the writing of the
JEP. Sure you're implementing a spec that's changing, but isn't that how
the real world is where the customer can't decide between a blue or green
icon?

Doing the implementation while the JEP is still being worked on could yield
better code and a better JEP. The code would probably be more extensible
since you're expecting changes to be made, and the JEP would actually have
some real implementation notes like "If a s2s connection breaks, presence
turned out not to be reliable so we decided to cache it".

> Don't get me wrong, i also want to do this right the first time. I just
> lost my faith in the whole process of approving and getting protocols
> active in Jabber. Although it is a very extensible protocol, it always
> seems to me that it will still take years before Jabber is really active,
> and who knows, it might be leaping behind on other IM services by then.

Would the process be better if it were done like RFCs? With RFCs there needs
to be two interoperable implementations before the process is even started.
That may not be the best for JEPs, but an additional level above Final that
signifies that there are two completed implementations that work together.
"In Use" could be a good name for that level, and the goal of the JEP
process should be to reach that level in the shortest amount of time by
hammering out a JEP of the right thing and the code to along with it.
 

- - Nolan

- -- 
http://www.semanticgap.com/people/sneakin/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFBO/uBhuPszQVSPEARApF6AKCYLcHj23dwJ4f1e89y7j6x9IUEfACfQM+V
v7CUfiWCJreJ0U9GtNgS1yY=
=6/NK
-----END PGP SIGNATURE-----