[jdev] Jabber Certification Program
rcb at ceruleanstudios.com
Fri Jun 18 09:39:24 CDT 2004
> Rachel was suggesting that the certification program might want to
> experimental JEPs, and I'm just trying to explain that this is a bad
Again, even if this has been the mindset in the past, it's not
necessarily such now.
> I can't imagine the JSF have a certification program involving
> JEPs, when you consider the nice red warning text that is currently at
> top of all of them. Left hand, meet right hand?
I think part of the point of all this -- at least over in the jdev
chatroom, and in off-channel discussions -- is that the 'oh,
experimental, bad don't touch it, it will bring plague upon your
project aaaaugh' mindset is itself a bad thing and that maybe that
language is a little too strong and too discouraging. It might be
better to have something like:
"WARNING: This Standards-Track JEP is currently classified as
Experimental, and may be subject to change or replacement in the
future; the publication of this JEP does not imply acceptance or
approval of this proposal by the Jabber Software Foundation as part of
the official Jabber specification. Developers who implement this
extension MUST be prepared to change or replace their implementation as
the status of this JEP."
Basically... no, you shouldn't implement every experimental JEP. And
if you /do/ implement an experimental JEP, you should be prepared that
it might still change and thus you might need to change your code;
don't go in assuming that the protocol for an experimental JEP is set
in stone, but don't assume it's a biohazard you must not touch, either.
In certifications, an Experimental JEP would only be able to be a
'recommended' feature, not a required one, and the majority of features
would ideally not be 'experimental' ones anyway, but it would be a way
to encourage focus on certain JEPs.
To bring this thread back a little more on topic while still focusing
on your issue: a certification level would never /require/ an
experimental JEP. That would be silly. But there would be some
experimental JEPs which you look at and go, huh, that looks like
something we would have be required for this certification level /if/
it were draft... so we'll put it into the 'recommended' feature set.
Then authors who are going for that certification can also see a
preview of what might well be requirements for the certification the
following year; if they choose to start implementing the experimental
JEP (and following any changes to it), then if or when the JEP goes to
draft status (and thus potentially becomes part of the next
certification set), they've already got that feature in place.
I do not think this process would force client authors to adopt new
methods of development. If you do not want to implement experimental
JEPs, as you apparently do not, you do not have to; no one is going to
force you to do so, and no certification level would require
experimental JEPs. You could still get a certification without writing
the experimental JEPs.
Let's say XHTML-IM (which is Experimental) is a recommendation one year
for one particular certification; you do not need to implement it, but
you know that it is something which will likely become a requirement
once it is draft. If you choose to implement it, yay, you get in ahead
of the game, have the structures to support it in place, and you help
explore implementation of the JEP. If you do not choose to implement
it, there's no penalty. But then let's say XHTML-IM advances to Draft
status. So the same certification for the next year now has XHTML-IM
as a requirement. Those who did not implement the recommended
experimental JEP from the previous year now have to implement it in
Draft form; this is no different than your 'wait until its Draft'
philosophy. But those who implemented it when it was recommended,
rather than required, have XHTML already in their clients, and
(presumably) have followed the JEP and accounted for any changes, so
voila, they already /have/ that feature which is now a requirement.
Does that help clarify? Or has this become more an issue about
experimental JEPs in general rather than specifically experimental JEPs
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 186 bytes
Desc: This is a digitally signed message part
More information about the JDev