Recently, we received a lot of comments that we were using too many names for the various parts of the project. This induced confusion within users and developers. We had both historical and strategical reasons for having multiple names. However, the time to clean up the situation has now arrived.

We want to confirm that the framework will be called

KSS

as an acronym of

Kinetic Style Sheets.

This name, already used previously, represents the principal nature of the framework : our behavior stylesheet, which has syntax and semantics similar to CSS (Cascading StyleSheets - hence the similarity between KSS and CSS). The word kinetic insists on the idea that the framework adds dynamicity to existing pages. From now on, KSS will imply the whole system, the stylesheet syntax and the javascript stack.

There is nothing settled today for the pronounciation. Some like to pronounce KSS as it is spelled (Kay-es-es). Some like to say "KiSS" . And some prefer to imitate the "Kssssss Kssssss" sound that the friendly snake called Python likes to make after dinner...

Simultaneously, to simplify things, the following names are deprecated and wont be used anymore.

• Azax  was used to differentiate the Zope product from our client-side javascript library. "KSS for Zope" will be used instead of Azax, and "KSS for Plone" will be used instead of PloneAzax.
  

• Kukit is the original name of the client-side javascript library. It was used as the global project name but we dropped it because of its negative connotations in certain languages. Although it still appears in directory and variable names in our code, it will remain an internal detail.

Merge in Plone 3.0

• Products.azax will become kss.core (class names that have the word "azax" in them do not change for now, but will be gradually replaced in the future, with a proper deprecation policy). The namespace kss will be reserved to hold further packages for the development of the core framework.
  
• Products.PloneAzax will become plone.app.kss
• Products.ATAzax will become archetypes.kss
• Add-on products will go wherever they otherwise belong to. They do not have to go under any of the kss namespaces : each product can have its own kss stylesheets, command sets and javascript plugins that are activated from zcml and totally agnostic to their subdirectory locations. Those KSS addons are meant to be bundled with the product that uses them.
  

Since the external products will not need extensive import due to the newest enhancements, the change from azax to kss will not be painful and will affect few places in add-on products (in case there are some already ;-). In fact, there is a single interface that any product needs to import. The merge will happen in the next coming days. However, the package path changes will only affect the repository trunk versions: versions 1.0 and 1.1, working with Plone 2.1 and 2.5 will not  be affected at the moment.

The above information is still subject to small changes, until the merge will have been completed. If necessary, I will post further information to developers currently working on the code.

The Plone conference and sprint has finished in Seattle. Lot of people say it was the largest and most interesting conference so far. Well, it was also an important step for the development of KSS.

We gave an introductory tutorial about KSS. We were running at the same time than Philikon and had the same feeling as him that we spoke in front of a not so full room. After all, it was afternon of the last day and people might have grown tired.

Nevertheless, we received lots of positive feedback that reassures us that the initial goals are valid, and that we are moving into the right direction with the implementation. At the sprint following the conference, new developers started to work with and on KSS; once again, we could experience that, after a short introduction, they were able to contribute to the code.

Although the sprint lasted for two days only, we made good progress, especially in the following areas:

• Jan and Massimo have fixed most of the bugs that had crept in after the Louvain-la-Neuve sprint. (They were either the consequence that we are using the development trunk of Plone, or that we provide backports of the software to practically all Zope and Plone versions. - In other words, we have many branches to maintain and that gives a higher chance to dependency problems.)
  
• Balazs has refactored the way the plugins use the Zope3 component architecture : as a consequence, all our plugin components are now really independent of their import locations.
  
• Jan, with Aaron and Josten, went on with implementing the Plone 3.0 use cases. We can, now, for example,  quick-edit the data rendered in the event summary table.
  
• Last, but not least, we have a working version of a solution to the following problem : when some data on the server is modified by an Ajax request, the client should update all parts of the screen that are displaying the modified item. For instance, after quick-editing the title of a content item, not only must the title be updated in the content area, but the navigation portlet, the breadcrumbs, the recent items portlet have also to be updated. We can see how a generic solution is needed for this generic problem : custom portlets might also need to be updated. Jeroen (with Luca, Gotcha and Philikon), has built a Zope 3 event based solution that emits an event (IAzaxEvent) when some state is modified on the server. Handlers can be registered to automatically update all dependent parts of the screen.
  

There is still a lot to do in the future. Without being exhaustive, the following key points are foreseen:

• Move our code out of Products. Merge PloneAzax and ATAzax templates into the Plone core. This is now prepared and will happen asap.
• Tests, tests, tests. We are entering into a stage where testing becomes even more critical. We have to complete our coverage. We need to have Selenium tests for all the Plone UI functionality, and we are also planning to extend our client side framework to be able to load and test DOM content in an automated way.
• Improve the caching story. We want to be able to differentiate between cacheable and non-cacheable requests, and allow CacheFu to have fine-grained control just as with normal requests.
  
• Improve the client-side request queue manager to handle priority queues and the cancellation of requests. This will allow, for example, to have individual "loading" spinners and cancel buttons on each of the page elements whose refreshment is in progress.
• And most importantly: go on with the use cases for Plone, make a drag-and-drop component and extend the LiveSearch component to be used in a more generic way then before, for the filtering of very large result sets.

We wish to thank to everyone who joined us in our efforts. We believe that if we go on working like this (and of course we will), we are looking forward to a real exciting Plone 3.0 release. Thank you for making this happen.

And of course, as always, there is also a personal side of the story. It involves us Europeans, the trip to America was really amazing. Our private passtime activities like birdwatching, sealspotting in either Seattle or San Francisco, attending some cool Halloween parties (yes, nine were shot just a few blocks away from us) or chasing the Hollywood sign in LA (one of my favs) were truly fun.

Finally, although many have already told it on several occasions, we want to repeat it : big kudos to the conference organizers and to our more then friendly personal hosts.