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. ;)
_______________________________________________ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
