Older blog entries for niksilver (starting at number 32)

Much fun today as the Jtrix FAQ on JGuru spawns a minor argument. My apparently simple answer to "How does Jtrix differ from Jini" raised some shortcomings of Jini to which one reader took deep exception. Four of us sat round trying to understand the reader's objections until we realised that perhaps he had the wrong end of the stick. Anyway, posted a polite point-by-point rebuttal which will hopefully make him happy. I'd actually like him to mail back and say "Oh I get it", but more likely is that he'll stop, or come back with more objections. Well, we'll see.

Our recruitment drive continues, and the best avenue, as always, seems to be word of mouth. I've always thought the most interesting part of working in this industry (or any other) is the people.

Our Jtrix forum on the JGuru site spawned an interesting question: How will Jtrix gain mindshare? We're hoping for grassroots take-up which will be slower but more cost effective (we're not a large corporation) and more solid. The open source nature of our work is intended to build trust among developers.

One thing I didn't mention in my reply there was that we could spend time building a really pretty Jtrix app to attract attention, but this would take away from our core activities (producing dull-but-useful things like storage systems and bugfixing the main platform) and may not end up attracting the right people. It's a difficult call. I guess this one will run and run.

Hooray! Today CryoBob and and MartBrooks sent our new site live and all went well. Actually, it's very much like the old site, except for some very handy improvements and a much improved build process. It interesting that Java, as a more recent language than C, has tools such as Ant which are more in tune with current ways of doing things. Compare to C's Make. Or perhaps it's just more in tune with my own personal view of the world.

Spending more time working on the chapter explaining how to write a simple Jtrix service. It makes me feel much more confident giving people a good intro, since it helps answers nagging questions earlier and gets the user feeling they're a step closer to coding the things they want to code.

A few developers from the open source community who volunteered to take on simple, well-defined tasks with Jtrix have dropped from sight mid-way into their work (total task time approx 4-8 hrs each). Depressing and slightly perplexing. One of my colleagues had dinner recently with ESR (as you do ;-) who was saying that an open source project only really gets a good mass of developers, in his view, after it's mostly complete and useful, and people can make small changes, see the change in the next release, and feel they've contributed. Our system is a development platform, so it's not visually striking and to do anything with it you have to (gasp!) write some code.

Spent much of today adding to our documentation. This explains to people how to write a simple Jtrix service. It won't be an all-singing, all-dancing thing, but it will help people understand things a bit better, and it will do so earlier. This wasn't possible before, but an extension to jtrixmaker, which generates our XML documents, helps. The new documentation won't be ready for a couple of weekw though.

In other exciting news, our Web site will get updated this week with our new build process and many improvements. Thanks to CryoBob for this, who's learnt a lot about our systems in the process ;-) There are several nasty wrinkles to iron out after that. And then he can get on with the task of moving the site into a proper redundant Jtrix Web server. Much of the work here will involve ironing out bugs in Webtrix, the Jtrix Web server based on Tomcat.

A review of the GPL seems to make it pretty clear to me, and I have a new respect for it. My problem is as follows: Jtrix is an LGPL'd platform, so can I run GPL'd code on it as a Jtrix service?

To recap on definitions: a Jtrix service like a library-on-demand. Kind of like a Web Service, but you get local code plus remote access to bigger system (whereas Web services is just remote procedure calls).

If I want to write a GPL'd Jtrix service then the core code is GPL'd and the interface (giving the client access to it) is also GPL'd. A client has to include my interface in their code, and by the nature of the GPL their code also has to be GPL'd.

But I can release the interface under the LGPL, too, so the interface is covered by two licences. Then a client can include the interface in their code, without having to GPL their code.

This last case might sound silly, but it makes sense if my Jtrix service is really a stand-alone GPL'd application plus additional code to make it a Jtrix service. Also, the interface could be a front-end to other, proprietary, services which do the same thing. In fact, such an option would have to be available, because the client's program would have to work with non-GPL'd Jtrix services. If it didn't, then it would have to be distributed with the GPL'd service, and that would be a violation.

So in summary Jtrix really does run like an operating system (all the above is independent of Jtrix's licencing, in the same way that you can run a GPL'd program on a proprietary operating system) and the GPL continues to protect a program's author if they choose to apply it throughout their system, or just in the places where they want to be protected.

Phew!

We're looking for another developer to join our open source project, Jtrix! If you know of a great Java developer, then ask them to contact me at recruitment@jtrix.org with a plain text CV. There's a full ad on our site. An in-depth knowledge of Java (not J2EE, but the real Java J2SE and the JVM) is very important.

In other news, much of the work started before the holidays is coming together. And I need to ensure that it's okay to run a GPL'd program on Jtrix, which is LGPL'd. The idea is that Jtrix is an operating system, like Linux, so the licencing of the program you run on Jtrix should be irrelevant, just as you can run GPL'd, LGPL'd and proprietary applications on Linux.

Some discussion yesterday about documentation. All the usual things, but with a twist given by the open source nature of the work. The question is how should we document a sub-project or other piece of work in such a way that is reliable (doesn't get out of date) and leads new developers (or interested hackers) through how things work.

The answer we arrived at is to use the magic of wiki. The jtrix.org site uses devwiki to help contributors manage project pages. We'll use this to post rough plans of work *before* we embark on it. It's easy to access and easy to update as the work proceeds. Of course, there are other levels of granularity to. After a wiki design/overview doc comes Javadoc, and then comes reading the source itself (last resort!). But wiki is a good step from very broad concepts to Javadoc.

We'll try it out first with our hosting efficiency project.

Just started on a mini-project to get the hosting service, Hospitality, to scale up.

The hosting service allows a user to launch their code into a remote location --- the remote location runs the hosting service. Of course it's all secure and audited. You've got to have a right to run your code there, and it's all nicely sandboxed when it gets there.

The problem is that one hosting service may span several servers ("nodes"), and the more nodes, the longer it takes for them to communicate with each other. The efficiency gain we're aiming to introduce is to control one node's view of another, so not all the data comes down the line, and to have tools to select data segments by particular criteria.

The other advantage of this system is that we expect to apply it to other services, such as the Indexing Service. Should be done by end of Jan.

As always, the theory is right if you can apply it right. Our (well, Filippo's and Andy's) extremely fine-grained planning of the Mediator is proving to keep Filippo on track.

To summarise: the Mediator is a central part of a Jtrix node implementation. It prevents code sharing between two netlets which use each other's services, but still allows them to communicate as if unhindered. It's magic (almost). It is also fiercely complicated, having to ensure that one netlet's dodgy coding doesn't bring down the other, ensuring you can safely run untrusted code, and so on.

Filippo and Andy worked out a required rewrite to the half-day level of granularity. It took two days. But it's keeping Filippo on course. Contrast that with any other work in the same area which has gone over time by approximately three-fold. It's early days, but the moral of the story is that good planning, if you can bring yourself to do it, pays off.

Fingers crossed for the rest of Filippo's work.

Phew! Off to Devon (Southwest UK) to meet with the bosses. Jim, our CTO, had this rather nice idea of how to help open source people... the problem is that although people want to help, taking on a big task is daunting, especially when there are as many new concepts to learn as in Jtrix. Our roadmap contains lots of really excellent things, but they're quite big.

Jim suggested we write these things very roughly ourselves so they kind-of work, and where you can see what needs to be done very clearly. Then a developer can take this and improve it. Everyone like to design, but this is a great way to get started and still have plenty of creative input.

I wonder what other people think of this idea...?