Sorry this is getting long [EMAIL PROTECTED] schrieb: > Hi Werner and Mike! > > > I don't understand your last posting... > What do you have submitted now to the rep? > > And wouldn't it be possible to update Kupu with a new license? >
Good question.. I was talking with Martin one of the core people this problem yesterday. The Kupu license was derived from another BSDish project which used obviously a relicensed Kupu codebase. Maybe this project has a new version of the lib (which could be or not), this will be investigated soon, but in the long run I do not see any sense in going with kupu. The main problem is, relicensing is somewhat complicated, basically if it is under GPL or LGPL everyone who has donated code must agree to the relicensing, being able to relicense the stuff to my knowledge. So one day one of the kupu people might say now and then, wham ... a forked huge codebase. > Or which editor you mentioned (Xinha, TinyMCE usw.) would be best to > integrate in JSF? > Xinha looks very good functionalitywise, so it definitely is an option. It also has the correct license, AFAIR. TinyMCE to my knowledge has licensing issues regarding licensing compatibility with the Apache2 license (we are limited in what we can add or not, GPL and LGPL definitely are not possible BSDish stuff is, the CDDL from Sun is an issue which seems to be discussed in the Apache Board of directors forever, no clearance of this issue yet ;-) ) Anyway I think in the long run going with a well maintained javascript library (which we do not have to maintain but is maintained by the project people themselves) with lots of committers and build upon their infrastructure is the way to go. We tried to move towards prototype, in this area, but there are too many problems related with it so it is very likely that it will be phased out for the non sandbox components in the future. The key is to try to keep the javascript related lines of code from us or from different sources as low as possible. As replacement for the prototype lib I added the less problematic and more extensive dojo library to the javascript foundations we have, and will keep it up to date in the future. I had a look at it, although the code is rough in some edges (lots of old code commented out), those people know how to handle all the non documented browser issues. And they try to keep the code as less intrusive into javascript as possible (although they do tag intrusion, but that is way less problematic due to being an entirely different area), unlike the also excellent prototype library which basically does a javascript foundation rewrite (and hence causes problems sometimes) The dojo lib has a working rich edit control infrastructure in it, so going with that one might be the way to go, as Mike suggested (I was planning to add dojo anyway because I am working on a dojo based component tag and had a need for its infrastructure for another component which soon will be committed (This component has several dojo backports which I needed to fix things, which I need to get out to avoid code forks, and the ajax codebase currently is non dojo but in the long run will be replaced by dojo). Mikes decision to try Dojo as the base for the html edit just pushed things forward earlier than I had planned. Nobody has any problem with it if someone wants to move forward with Kupu or tries to integrate Xinha to the mix (after all we are happy about every donation and helping hand). Having added the dojo codebase was more a personal issue I and Martin had with the existing javascript codebase and having Mike wanting to build a component or a renderer on top of it pushed things forward earlier than expected. Anyway the dojo foundation is in there, currently a tad rough (therefore sandboxed), but I will keep it up to date with the latest versions, in the codebase, so that others can build upon it.
