[jdev] Re: The State of Our Code-bases

[Tijl Houtbeckers]

On Sat, 28 Aug 2004 23:01:34 -0700, Rachel Blackman  
<rcb at ceruleanstudios.com> wrote:

>> Not to drench the end of this with gasoline. Yes, C is prone to memory
>> leaks
>> and bugs from misuse. That's why they made C++. :-)
>
> Since when did C++ fix the tendency towards memory leaks?  Even
> Objective C, which uses a Smalltalkish object model and has garbage
> collection, is not particularly immune to memory leaks. ;)

Or for that matter, since when is it impossible to leak memory to leak  
memory in Python? (even aside from the fact the main implementation has a  
reference couting garbage collector if I'm not mistaken!)

> As you say, no programming language will solve all your problems for
> you.  Interpreted languages like Python may make it easier to write
> code which does not leak, but they may not necessarily scale well for a
> server of multiple thousands of users.  (I admit I've never done
> scalability tests on Python code, so maybe it can in this case.)
> Similarly, native, compiled code may be able to do more in terms of
> integrating with a desktop OS environment (providing spellcheck
> services on OS X from system dictionary, providing system tray services
> on Windows, etc.) but you lose the easy cleanup and less-headachy
> memory management of an interpreted language.
>
> Like you said, there's no silver bullet.

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. 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.

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 ;)

So could the JSF bring any help to this situation? Well money can help.  
But limiting that to new projects in a specific language might not be the  
best way to spend it. 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?

> 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.  A 'client' which will connect to a
> server, try all kinds of things automatically and record the results,
> flagging abnormalities, making it easy to 'certify' a server as fully
> compliant.  A 'server' a client can connect to and do things, to make
> it easier to test the compliance for the client and get certification.
>
> Yeah, I know, I tried this once before, to push for various Jabber
> certification programs, for servers and clients and components, but I
> think really it would benefit us here.  As has been pointed out,
> real-world implementations often differ slightly from JEPs, and so
> sometimes various bits of software don't always agree on how to do the
> same thing on XMPP or Jabber.
>
> I really do still think being able to standardize, both on what
> features are supported for various levels of certification, and for how
> rigidly those implementations adhere to specification, would be of
> immense value.
>
> I'm sure everyone who is on standards-jig has gotten tired of me
> tossing two pennies in, but there's my $0.02 on this. ;)