Web 2.0 is about the machine using us…
No…
Web 2.0 is about the machine being us…
This video will explain all.
Archive for April, 2007
It’s not that often I get to do some real, exploratory hacking anymore. It’s a shame, I love just playing with new stuff, but other responsibilities keep me away from it much of the time. However, recently I had a play with the Eclipse Rich Ajax Platform (RAP) project (currently in the validation phase of the Eclipse incubation process), boy is it cool.
RAP provides a wide range of of GUI widgets for creating web applications with a very rich user interface (using AJAX for those who care). So what? There are plenty of AJAX libraries around, what is special about this one?
There are a number of things that make RAP interesting. One of the key issues, the one I focus on here, is that the API of the RAP widgets is drawn from the Eclipse Standard Widget Toolkit and the JFace User Interface framework. Couple this with the excellent OSGI framework and you have a delivery platform that allows you to deploy your application as a desktop or a web application with the drop in replacement of the user interface plugin.
If you have already developed a desktop application using the Eclipse Rich Client Platform then you will be comfortable with RAP almost immediately.
Add to this mix the Eclipse Embedded Client Platform (eRCP) and the same application can be quickly deployed on mobil phones or PDAs.
The Rich Ajax Platform is not the best choice for every application. It scales reasonably well, but if you are looking at 100,000+ simultaneous users it’s not really for you due to the heavy server load, but for apps that you want to deploy in many different guises it could be the answer.
I’m looking forward to having a proper play with this as the application framework for the forthcoming OSS Watch project, Simal (more on that soon).
As most readers will know by now the GPLv3 third discussion draft is available.
For me it contains one very big surprise, this is discussed on page 33 of the rationale document for the third draft which contains the following words:
We regret that we will not achieve compatibility of the Apache License, Version 2.0, with GPLv3, despite what we had previously promised.
Why is this such a surprise (not to mention disappointment) ? Well the clue is in the quote above, specifically:
despite what we had previously promised
I was originally very excited to hear that one of the goals of the FSF with respect to the GPLv3 was to achieve compatibility with the Apache License (see the transcript of Richard Stallman speaking at the 5th international GPLv3 conference). I was very distressed to discover that this had not been possible in the third draft.
Allison Randal is a member of the board of the Perl Foundation, she is one of the first high profile experts within open source brave enough to comment on this issue. Remember, Perl is dual licensed under GPL and the Artistic License, so one would assume she is not overtly biased towards the Apache License, therefore, I reproduce her conclusion below. I strongly suggest that readers visit her full blog entry since it provides much more detail.
Is the FSF saying that when a downstream company takes on the legal burden to indemnify a piece of GPL software, they expect the developers to also take on that legal burden? Or, in the case where the FSF is the copyright holder, that they intend to take the legal burden of indemnification themselves? Somehow that seems unlikely, but they claim that the GPLv3 differs from the Apache License on exactly this point.
I give them the benefit of the doubt, but it sounds to me like the FSF really had to stretch to find some terms that might make the Apache License incompatible.
The good news is, this is not the end of the line. There is another draft to come from the FSF, the ASF are working hard to see if there is anything that can be done on their side of things, and, as you would expect dialogue also continues between the FSF and ASF.
