It's nice to see that we are in synch on many aspects, Alfonso. Almost all those ideas are already in my mind. We need in effect to put them on paper to effectively make them reality.
We'll use the docs to better describe each API feature, but just to give you some feedback on your suggestions, and to explicitly list them:
Selection: we definitely need to have better support for it in the API. The current FCKSelection object is not that clear.
DOM Manipulation: it includes attributes, but not only. Actually I have named your idea as "DOM Abstraction" in the docs. Basically, nothing in the code will ever work with real DOM objects (except the DOM abstraction classes). It impacts on the performance of some DOM operations (low impact), but the benefits of it compensate: consistent, full featured and simple API and zero memory leak. More details of it to come.
Extensions/Tools Plugin: a must have. It makes it possible to leave the core clean, giving powerful features for plugin developers. It could also be a set a plugins, instead of a big one (for example Selection Extensions Plugin). In any case, as the core itself will be strongly plugin based, many of the basic features will be available out of the box. It's still unclear what we should have here though, but I'm sure it will get its lines during and mainly after the V3 release.
Documentation: the base for the success of it. Not everybody is able to (or interested on) looking at the code to understand how things work. This time the API should get well documented.
It's nice to have some quick briefs like the above ones right now, so we can consider all those things during the development. So, let's continue throwing our thoughts here in the forums.
Re: Defining the API
We'll use the docs to better describe each API feature, but just to give you some feedback on your suggestions, and to explicitly list them:
Selection: we definitely need to have better support for it in the API. The current FCKSelection object is not that clear.
DOM Manipulation: it includes attributes, but not only. Actually I have named your idea as "DOM Abstraction" in the docs. Basically, nothing in the code will ever work with real DOM objects (except the DOM abstraction classes). It impacts on the performance of some DOM operations (low impact), but the benefits of it compensate: consistent, full featured and simple API and zero memory leak. More details of it to come.
Extensions/Tools Plugin: a must have. It makes it possible to leave the core clean, giving powerful features for plugin developers. It could also be a set a plugins, instead of a big one (for example Selection Extensions Plugin). In any case, as the core itself will be strongly plugin based, many of the basic features will be available out of the box. It's still unclear what we should have here though, but I'm sure it will get its lines during and mainly after the V3 release.
Documentation: the base for the success of it. Not everybody is able to (or interested on) looking at the code to understand how things work. This time the API should get well documented.
It's nice to have some quick briefs like the above ones right now, so we can consider all those things during the development. So, let's continue throwing our thoughts here in the forums.
Frederico Knabben
CKEditor Project Lead and CKSource Owner
--
Follow us on: Twitter | Facebook | Google+ | LinkedIn