Smoking toooooo much PHP
Tuesday 27 May 2008
Well, things are ticking away on the ExtJS forking project - There will be a official web site soon (I'm promised) - in the meantime head over to #roojs on freenode to see what's going on. On the global plan, this is what I've been looking at - I have found a copy of yui-ext 0.33, which was released under a BSD style licence, and includes all the CSS and Images. I've not got round to merging and testing it with the 1.1.1 code, but I can't see any major issues, as from my recollection 1.0 evolved from this.
- I got about halfway through adding all the javascript files (v1.1.1) to my subversion repo, along with modifying the headers to remove the licence link reference which is now irrelivant. The code can sit there until a shared repo becomes available.
- Made a dependancy list for the files (so that building specialized bundles should be easier)
- started testing a few javascript bundling tools (that work better than my simple tokenizer tool)
- Started looking at docs
The doc's turned out to be an interesting little intellectual challange, as I was not too impressed with jsdoc (the perl thing) Apart from being written in a "Write-only" language, it did not spit out anything resembling usefull docs from the extjs code. So I started looking at jsdoc toolkit (on google code) - It's dependancies are a bit annoying (java + mozilla js engine AFAIR) - but the thing is written in javascript - (very well designed) and looks like a better bet. My idea was to take this code, and use my dmdscript fork to run it and generate documentation without that java dependancy. My little dmdscript fork has a few benefits that make it very suited to this task - Built in File access, a built in tokenizer to start. And it's piss easy to extend. However it turned out to be a bit more complex than that. One of the major problems turned out to be that dmdscript uses digital mars's D's regex engine, which unfortunatly is seriously feature flawed. To the point that most regex's that you give it fall over badly. I did manage to hack in forgetfull matching (?:.....) but when I started finding quite a few more oddities, ([\s\S]+\s)? the whole task of trying to fix the code became to much, and I came to the conclusion that just ripping it out would be simpler. In it's place I've used the excellent pcre library by Phil Hazel (who also wrote one of the best MTA's out there.) The binding code for the pcre library was already available in dsource, hidden away in the dwin project, so after understanding the API for that, I've almost got to the point where a semi modified version of jsdoctookit can parse the Code. I still need to do some more fixes to the regex engein so it can render the templates. -But it's getting there.
Sunday 11 May 2008
I've started looking at forking ExtJS, after some considerable thought, I'm pretty close to the concluding that forking ExtJS is really option left, to retain the investment I've already made in it..
So, as I have a Zip file of 1.1.1 and it explicitly says that the Javascript code is Licensed under LGPL, (not ifs/ no but's) - I'm slowly putting the code into my subversion repo under www.akkbkhome.com/svn/extjs1 (*I'm looking at extjs1.1.1 as I have been using it and tend to prefer it, but there is nothing in the discusion below that precludes anyone helping/leadingwith the last extjs2 version that was released)
Now if this actually becomes a full fork (most forks fail BTW), It will need a bit of work, so If anyone is interested in helping out. I've no idea where this could go. But this fork ain't changing the license no-more...
The plan
I think there's quite a few things to do here... so Ideas or contributions.. -- feel free to email me, or just comment on this post. - At worst, it could form the brainstorming for anyone else actually doing this. (If you want to comment on if/should this be done - do it on my previous post, otherwise I will delete the comment)
The Code
- Tidy up Ext Js's source - see if it can be stored in one file per class, and have a simple classname->filename mapping... (eg. Ext.Dom in Ext/Dom.js) ** started..
- Sort out the CSS
- If Jack ever released any old CSS/images under a open licence (ext-yui source?) see if that can be used.?
- or Go through the classes and see what their requirements are for CSS
- Probably in batches - write a short document listing the required classes needed by the batch, enabling someone to contribute a CSS file that works.
- Posibly create enough CSS to make enough of it useable (probably with no images)
- Document image requirements (see above), then see if other open projects already have images that can be used? - otherwise see if someone want's to contribute themes..
- Break up Source into managable packages - Distribute ownership! - GIT or multiple SVN repos??
The Project
- Build infrastructure
- Create a command line tool that can compress then merge all the required components (and allows end users to do this)
- Allows source to be taken from multiple sources (so you can create builds with extensions / or without stuff you don't need)
- Forums
- Set up a mailing list! (and archived, with a search feature!) - Anyone know a good hosted one available? - or should I just go off and set the infrastructure here..
- No more 'premium' ... users! - equal, like open source is supposed to be!
- Manual
- Work out how to build a manual from the source!-- While Ext's manual is not bad, take the opportunitythis time do it right, and have a bug reporting / user comments on it....
- A name??/ - May need some thought...
The reasoning.
I have to admitafter some reflection to being pretty pissed at this change, ExtJs was useful in a number of ways, other than being a reasonably well written, the forums where search-able, so you occasionally found fixes to issues that you where having. The doc's where not to bad. etc.
But basically I've committed 1000's of hours of time to learning, and writing huge codebases that depend on ExtJS, under the basic premise that it was availably for Free, with the only Caveat that If I modified ExtJS, then I would have to give back those changes. "Quid Quo-pro" as they say.
The Change to GPL has altered that equation in such a radical way that If this was not a 'software' product, and was something physical. you would be down at the consumer council, and filing a class action against Jack for things like Breach of trust, financial gain by deception etc.And filing claims for the loss of your time, and the cost of replacing his library..
I have seen postings that appear to claim Jack plan's to 'send notice' to people using a fork, but as far as I can see, he released the Javascript code as LGPL, and from every reading I've seen of that, I have the absolute right to distribute the Javascript code, along with any modifications. - This is the purpose of the license!!! - so by claiming otherwise he is not honoring his own license, not a good omen for the future of ExtJs even under GPL!
I'm floating this, as a plan... - shout if you are interested/ have some ideas..?? - (or you can find real technical flaws - not FUD flaws please).
Wednesday 7 May 2008
I think that basically sums up my reaction to Jack's GPLv3'ing a library. For those who are not aware, As I was not, when I visited the extjs web site a few days ago to grab a copy of the old 1.1 version and found all references to download it had disappeared. Digging a bit deeper on the site, I started spotting a few comments about the new licensing.
While I can say that Jack as the author (of I presume most of extjs?) has the right to change the license to whatever he likes, I think he has probably just destroyed the project. I could not commit to writing new code with a "Library" that is GPL, unless I was working on a GPL project (which is unlikely at present - got bills to pay). And for commercial or spec projects, that are not turning revenues yet, I can't really justify my time in committing to develop stuff that may, or may-not be able to fund today's and whatever Jack feels like charging in the future for the non-commercial license.
I've seen too many people burned by this closed source dependencies that they build their businesses around, only to have the effective rental for their office yanked through the roof, and no other option than a huge effort moving to another library or software causing chaos.
All that said, I'm not sure if v2.0 and v2.1 are really worth bothering with anyway, I've tried them on 2 projects so far, and the general sense I get, is that compared to v1.1 they are a little finicky, and tend to produce slightly unpredictable results. Which is tempting me to stick with 1.1..
The problem I see though is that the community that has built up around extjs has been supported by quite a few handy tools, the wiki, the doc's and the rather nasty forum (which is a good way to waste time finding answers to issues). So I guess someone setting up a openext? (I saw something on the net about it) should probably sort out those issues first, then start solving the technical issues about how to replace all the images and css in extjs which where not previouslylicensed under LGPL.
I would hate to have to go looking at the alternatives again, So sticking with v1.1+ hacks may be the best long term plan for me anyway.
|
