Older blog entries for niksilver (starting at number 37)

More javadoc, which really is not fantastically exciting, but it does mean there's going to be a lot fewer people scratching their heads over our storage system thinking "Eh? That's dumb". Andy really does have a fetish for inner classes. Which are all very good in their place, but it can get silly at times. I cannot see the point of most inner interfaces. I pine for the simple things in life. I remember BBC Basic. Now *that* was a programming language...

Phew, long day continuing Javadoc, and tidying up some interfaces. At least I think it's tidying up... we'll see what happens when real programmers get to them. This is for Storix, our distributed transactional file system. Actually, it's probably a good thing for several people to run over the code. It provides a sanity check.

Spoke to CyroBob at the end of the day regarding Beatrix and his understanding of it. Looks like there are lots of gaps in my documentation. Not all that surprising since that's the least roadtested.

Spent the morning making a few corrections to How to write netlets after CryoBob went through it on Friday. It was good to see that his comments were thoughtful and well-directed, as that means he has a good understanding of the issues. Or at least as far as the document allows.

Today he's looking at Beatrix, our application framework. Some comments have already come my way, and it's certainly more complicated. Mind you, it allows you to do much more. We'll see.

Will spend the rest of today making sure our javadoc compiles without problems. A painful, but I think helpful, business.

CryoBob is now starting work on writing Jtrix netlets. Let's see how he gets on. In the past people found it difficult, but currently it's generally more streamlined and much easier to do simple things. Of course, it's more complicated to do more complicated things, but then it would be, wouldn't it?

Observed that experienced people try fiddle around with things to learn them better. CryoBob did this: "I tried to change X just to see what happened, and it broke. And I figured I think I know why...".

Site experienced a small surge after posting a "developers wanted" ad on sourceforge, for our redundant file system, Storix. Meanwhile still looking to fill our full time Java job here in the London office.

Trundling on with documenting the latest changes to the Beatrix framework, which makes it easy to write large-scale services. This is more important now because we have a design for our redundant storage system, Storix, which will be built in this framework, and developers will need decent documentation.

Also on the agenda is continuing the design of the One Node Wonder (is there a better name?). This is a simplified version of the Jtrix node, optimised for a one-user PC rather than a server cluster. Current problems include how to represent resources (disk, sockets, etc) which appear in multiple locations (i.e. multiple PCs).

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!