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

[Nolan Eakins]

Rachel Blackman wrote:
> 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. ;)

It's all in how you use it. I'm still trying to grapple Qt's object model.
 
> 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.

That's actually a really good idea. Something that an automated script could
do in say Python. You would need a compliant library, but it could be done.
The list of tests would have to be enumerated. Registering, logging out,
logging in, breaking the connection, sending a message, receiving a
message, deleting the account, etc. The list will be quite long, and don't
forget s2s too.

If all that needs to be done is run a script giving it a jabber server to
use, and it spits out a test report (50% compliant, these tests failed,
etc.). I don't see why that wouldn't be a good thing for the community.
Community involvement will have to be necessary to ensure any possible test
case gets added to the main suite.

Testing client compliance would be a little trickier. It would have to be
tested against a compliant server with some way of checking what it sends.

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

Server certifications could be automated like I suggested above. Components
probably can be too. It might be possible with clients. Client libraries
will probably already have their own tests, but clients meant for human use
probably would need some human interaction to be certified. Realistically
server certification could be realized first. Client certifications would
require some money. Certifying clients could prove to be a decent income
stream for someone. The JSF would benefit too since the Jabber trademark
would most likely want to be licensed.

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

JEP-0073 and JEP-0117 already define a couple of levels. They would be a
start.

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

Add in my 2 cents. Total: $0.04


- Nolan

-- 
http://www.semanticgap.com/people/sneakin/