I'm currently on parental leave till September. During that time, I will not read any e-mail or blog comments.
Until I'm back, please read through my archives, take a look at my code/applications and check out my pictures.
Have a great summer, and a splendid winter to you aussies and kiwis! 
I’ve had some people worrying about the GPL license I’ve used for DOMAssistant, and it being too strict so they can’t use it in their commercial project.
Therefore, DOMAssistant has now changed to a MIT License, which basically means you can pretty much do anything with it!
Enjoy!
Fredrik Frodlund
It’s been a while since I read the GPL, but I can’t seem to remember there being any restrictions about using GPL:ed code in commercial projects. You just need to provide the source code, which, in the case of Javascript, you do per default.
Robert Nyman - author
Fredrik,
As I’ve understood, there might be issues where some of your other code will need to be open source as well, which isn’t always desirable in commercial projects.
Besides, most other major JavaScript libraries use an MIT License, so it felt like a good idea to be on par with them.
Martin Odhelius
If using GPL on libraries and similar code, LGPL is almost always to prefer. With that license no other code has to be open source, the only code that has to be open under such license is the library itself, which will result in that modifications of your code also have to be open. With a MIT license people can use it and modify it as they want to without keeping it open source. Whats the most preferable is of course up to the author 
Robert Nyman - author
Martin,
Hmm, I see. To me it’s a delicate balance between offering what the other library makers do, while at the same time trying to make sure that DOMAssistant is respected.
Maybe LGPL is better if it means that it can be used anywhere, and if you tweak DOMAssistant itself, only that certain part has to be open. Preferably, given that I offer it openly, naturally I don’t want it to be closed in with anothe environment.
Do you see any scenario where a LGPL would hold any web developers/product back?
As a side note: the license reference in the DOMAssistant code refers to the DOMAssistant Google Code site, so I can change it without re-releasing the source code. Therefore, I want to try what suits everyone best without comprimising the integrity of DOMAssistant.
Pelle
LGPL forces changes to DOMAssistant to be released opensource while MIT leaves it up to the modifier to decide whether the changes should be released back to the community or not. If I had understood the licenses correctly that is…
A modified version of DOMAssistant that isn’t released as open source can still indirectly be of contribution to the project because it can lead to contributions in the future from either the modifier himself or from someone else who has been inspired by the success of the closed modifidied library.
I think that DOMAssistant can benefit from having people contributing to the project according to their own possibilities rather than by a license. In other words - I would prefer MIT, but I don’t see anything wrong with LGPL…
Erik
Excellent!!
Robert Nyman - author
Pelle,
Thanks, good point. I wouldn’t want it to be forced for them to re-release their changes, although my (maybe somewhat naive) hope is that they will be interested in giving something back.
I think it will be a MIT License for now, and then we’ll see.
Erik,
Good!
Andy
Robert, I see you’ve been releasing fixes with a couple of days interval and I would suggest that the library should undergo a short beta period before “officially” releasing the code to prevent these sort of things. As for the license, I think you should thoroughly go through the candidates rather than going for what the mainstream does. Perhaps even setting up a poll to see what the community wants.
Another thing that crossed my mind is that ElmsBy* methods might be superfluous due to the introduction of CSS selectors. The only gain I could see of having them is that they’re possibly faster than the CSS Selector method. This should of course be benchmarked to see if there’s any significant gain of actually keeping them.
Perhaps create a forum to discuss future additions to the codebase? I believe that every addition should be put through careful consideration before adding. As John Resig said during the “Best Practices in Javascript Library Design” presentation:
You should fear adding new items into your API. You need to keep it as small as possible because every single method that you add, you are going to have to support.
Wherever possible, if you can get away with not adding a method, you should.
…Just thought I’d give you some friendly advice.
Robert Nyman - author
Andy,
Thank you for the advice, which are very good!
Regarding the recent releases, in hindsight a beta period would definitely have been nice. It was such a small addition, and I underestimated the impact it would have, and it got a bit unfortunate. But it’s also about needing people who are interested in helping out with testing, and it’s not that easy to find people interested in that.
With the license I think it’s important to see what the community wants as well as looking at the competitors, to offer something which can match what they offer. The community communication idea is to have this blog post (instead of a poll) to gather inoput and ideas, as well as balancing it with what I’ve learned about the licenses.
MIT License seems to be the best for end users, basically putting no constraints on them (or me) in whatever project DOMAssistant will be interesting to use.
The different elmsBy* methods are used internally in DOMAssistant for code separation, so offering it publicly is only about offering something which is in there anyway. Besides, if you have a certain element reference (DOM reference), it’s easier to use them directly on that element then, with the added benefit of utilizing XPath when it’s available. For example: $(document).elmsByClass("news", "a").
Another reason that they’re available for everyone’s usage is backwards compatibility, and at the same time offering a more “programmatic” approcah for those not into CSS slectors. For example, these two samples do the same thing:
$("container").elmsByClass("print", "a");
$("#container a.print");
I completely agree with John’s suggestions, and that’s my approach to, and the reason I’m very wary about adding new methods. replaceClass and especially post for AJAX calls were inevitable, so I felt it was better adding them sooner than later.
There’s also a Wiki page with Feature Sggestions on the code site, where everyone can express what they feel suited for DOMAssistant, where I will consider and comment on those.
Robert Nyman - author
Andy,
I should also add that if you’re in any way interested in helping out with the work, be it beta testing, sample code or anything similar, just let me know!
Andy
Robert,
I am very much interested in helping out. I am available on MSN, mail & GTalk on the email address provided.
All the proceeds from ad clicks will go to charity. However, if you like to give something directly to charity yourself, I recommend choosing from the listed ones below.
