[jdev] Re: The State of Our Code-bases
Peter Saint-Andre
stpeter at jabber.org
Mon Aug 30 14:14:16 CDT 2004
In article <opsdhv28gbqj7son at smtp.chello.nl>,
"Tijl Houtbeckers" <thoutbeckers at splendo.com> wrote:
> Exactly. There's something I don't understand from these discussions about
> the "reference" implementations. People say they want the "Apache" or
> "Mozilla" or Jabber, and in the next sentence say you really can't use C
> or C++. Ofcourse you can do an implementation in those languages, just
> like you can do it Python.
Wikipedia defines reference implementation in part as follows:
"a software example of a standard for use in helping others
implement their own versions of the standard"
I suggested Python because it easier to read and understand than C or
C++, thus helping others write their own versions of the protocols.
> If you ask me a reference client in
> Python+wxWidgets (ofcourse there are alternatives to that combination in
> Python, this happens to be the example from PSA's blog) will probably be
> more the Amaya of Jabber than the Mozilla, which is why you won't find me
> working on that project. But if there are people willing to prove me wrong
> on that.. I could be very wrong and we'd end up with a very good client
> perhaps.
Well, the OSAF people (http://www.osafoundation.org) are using Python
and wxWidgets to write Chandler. At least it is being used. Python + Qt
is another possibility if we can work out the licensing issues.
> That's what you need for a succesfull project, developers, people willing
> to write docs, and it doesn't hurt to gain a nice community around all
> that after a while. And those developers will choose for themselves which
> language they want to use ofcourse. So if someone wants to start a Python
> client project and see right here on JDEV how much intrest from others
> there is to join him/her in that, it's fine by me. But it's not so strange
> that others will look on it as yet another new client project, rather than
> the saviour of the jabber community. That's why to me it would seem so
> strange to complain "too many clients already" and then start a new one ;)
I'm not claiming that a reference implementation would be the saviour of
the Jabber community. However, it might help quite a bit.
> So could the JSF bring any help to this situation? Well money can help.
Money is a possibility if the JSF gets involved (the JSF is not rich
either, but could work to raise money specifically for a project of this
kind). Someone could raise money for such a project outside the context
of the JSF, but I think the JSF would find it easier to raise money
since it is a known entity.
> But limiting that to new projects in a specific language might not be the
> best way to spend it.
I think that focusing on one language (at first) is the best way to go.
That doesn't stop anyone from writing code in other languages, and an
effort to write a reference implementation would be undertaken as a way
to limit anyone else's work.
> Like the starter of this thread pointed out, there's
> good quality code already out there. But you can also look at other good
> idea's like the one below by Rachel, or usability testing, documentation
> etc. What I'm wondering by now is; does the JSF have any position on this
> yet?
I plan to publish a proposal soon, which will be discussed at length by
JSF members (and on this list), I'm sure, before the JSF has a settled
and official position.
> > Rather than see us all going over what should be done to produce one
> > 'reference implementation,' (or what language would be best to write it
> > in,) I would rather see a process and set of tools for testing how well
> > a given thing adheres to spec.
Personally I think that certification would be good, but that we need
more than certification. In particular, the IETF requires at least two
interoperable implementations in order for an RFC to advance from
Proposed to Draft, and if one of those implementations is not fully
open-source and well-documented then I think we're doing ourselves and
the Internet community a disservice.
But as mentioned I hope to publish a proposal about all this soon.
/psa
More information about the JDev
mailing list