I got a nice 512 Mo iPOD shuffle for my birthday. Thank you guys ! :)

It took me 5 minutes to make it work under a FC3 Linux box.

At first it though it would act as a normal usb storage and then did this :

$ mount -t vfat /dev/sda1 /media/IPOD -o sync

At this point, everything was ok. I could transfert whatever files on
the storage as it was a normal USB key thus I put couple of MP3''s to
give a try.  At my surprise the lights were switching from red to
green on the iPOD shuffle telling me there's an error. (Ok too easy
maybe... )

I found then the GNUpod package :

http://www.gnu.org/software/gnupod/gnupod.html

And after this everything worked well :)

Actually, the iPOD uses a database that needs to be initialized.( I'm
not gonna go in details in here about this. Go and read the manual !)

Basic examples :

Initialize the iPOD :
$ gnupod_INIT.pl -m /media/IPOD

Transfert songs :
$ gnupod_addsong.pl -m /media/IPOD/COX/Essential_Mix_03.05.00_live_from_golden-south_beach.mp3

Search Songs :
$ gnupod_search.pl -m /media/IPOD -a cox

Remove selected songs :
$ gnupod_search.pl -m /media/IPOD -a cox --delete

Synchronize
$ mktunes.pl -m /media/IPOD/

Unmount device
$ umount /media/IPOD

And that's it !

The manual explains how to do cool stuffs such as rating your songs,
edit playlists etc...

So no worry, if you are running a Linux box you can steal an iPOD it will work :)

CPSPortlets and CPSSkins are now shipped as a default environment with a CPSDefault Site.

See for installation / upgrade and status notes there :

http://lists.nuxeo.com/pipermail/cps-devel/2005-April/001364.html

It's a major step toward CPS-3.4 release and a enormous improvement in term of user interface and development process for the future.

A CPSDefault Site provides now a portlets environment inspired by the JSR 168 specifications managed by a WYSIWYG theme editor 'out of the box'.

I believe, this will be an enormous advantage for CPS for the following reasons :

• because until now the former box system was too hostile for non-technical people and was probably discouraging them to go further and adopt CPS to build small publication portal.
  

•  because CPSSkins offers a really powerful but simple environment to customize TTW most of what you need to customize usually.
  

•  No need to write CSS !!!! (Who likes to write css ?? ;) )
  

•  because it permits to get rid of the default 3 columns / header / footer, etc... without typing a single line of code and thus it means less restrictions in term of look and feel. (check this : http://tibosoulcie.net/. Would you have guess it's a CPS instance ?)
  

•  because integrators will be even more productive than before :

• packaging is easier since CPSSkins provides XML export / import of theme and portlets configuration (No need to write any Python !)
  

• because the learning curve of CPS will decrease. Only one concept   to learn now for integration -> CPSSchemas.

•    less regressions while updating because less skins and macro libs to write. CPSSkins will act as a glue on top of the framework.
  

•  because it was what was missing to CPS on top of its powerful

           framework probably hidden by the green and blue basic colors of the
           CPSDefault Site :)

• RAM Cache integrated to portlets to increase performances.
  

• because Zope is not php and won't ever be thus the main_template aprroach is not suitable on Zope servers. (definitely too heavy)
  

• because it will be easier for Plone sites using CPSSkins to migrate to CPS ;)

This projects started during the Paris sprint last year.

And I'm really really really happy to see it where it is now :) Thank you Jean-Marc for your great work. in between.

Issue :

We recently realized on a CPS instance while plugging an external catalog (ZSQLCatalog actually) that a *lot* of reindexations (something like 10) occured at creation time. Same behavior for content modifications and still the same with workflow transition excecutions.

Usually, the problem is not visible but as soon as you get big catalog (for instance 600 K entries) then the creation or workflow transition execution had a tendency to be slow down.

First step : object repository objects

Historically, the object repostiory objects within CPS3 were indexed. It wasn't necesarly anymore since CPS branch 3.1.x and the new rearch mecanism that basically aggregates the repository object attributs on the proxy itself with the help of dedicated proxy indexes. (Ben did a great work at this time and the search speed of CPS grew up big time after this).

Thus, the first step was to avoid repository object indexations.

Direct benefits :

• Half of the indexations avoided
• Lighter catalog and thus more efficient ones when they become really big.

Second step : getting only one reindexation per-object and per-transaction no matter what appends to the objects during the transaction.

First, I've been trying to figure out where to call my reindexObject() method within the CPS architecture. It's definitely not mangeable especially when you got during the same transitions : object reindexation, object security reindexation and workflow transition executed with the object involved. The CMF is definitely not optimized at all on this point.

Then, we started to discuss with Florent about a possible post-publishing hook on the Zope publisher. No existing hooks were available for this and no way to patch properly the framework for our extensions.

We discussed about the problem on zope-dev and zodb-dev (thanks to the people over there for the answers)

The problem we were faced to was that the ZODB-3.2 (the one Zope-2.7.x is using) doesn't provide good ways to hook just *before* the first commit phase of the transaction.

There's a way to register a hook executed at the beginning of the first commit phase implementing this interface :

    http://cvs.nuxeo.org/cgi-bin/viewcvs.cgi/CPS3/CPSCore/interfaces/IZODBTransactionHook.py?rev=1.1&view=auto

and registering the object implementing this interface like this  :

>>> get_transaction().register(hookInstance)

The problem is that this hook is called too late in the commit process (during phase1) and the objects are already frozen at this time. It's thus not possible to deal with Persistent Objects and thus no way to cope with our Indexation problems.

We discovered that Zope-3.3.x would have provide a way to do the job with the Synchronizers and the beforeCompletions() API :

See the discussion there :

http://mail.zope.org/pipermail/zope-dev/2005-April/024566.html

I finally decided to extend the ZODB-3.2 transactions to make them support pre-commit hooks with a subscriber mecanism that I may use for an Indexation manager subscriber.

A pre transaction commit hook has been added to the ZODB Transaction supporting subscribers registration. Each subscriber has a commit() method called just *before* the first commit phase that contains the actual code to execute and an abort() method called at the beginning of the abort() method of the transaction class. :

Pre-commit hook definition with subscribers :

http://cvs.nuxeo.org/cgi-bin/viewcvs.cgi/CPS3/CPSCore/PatchZODB.py

Subscriber definition :

http://cvs.nuxeo.org/cgi-bin/viewcvs.cgi/CPS3/CPSCore/TransactionCommitSubscribers.py?rev=1.1&view=auto

Subscriber interface :

http://cvs.nuxeo.org/cgi-bin/viewcvs.cgi/CPS3/CPSCore/interfaces/ITransactionCommitSubscriber.py?rev=1.1&view=auto

You may register your own subscribers by implementing the interface

above and register them to the list of pre-commit transaction subscribers.

This is checked in and available in the HEAD of CPSCore.

Note that the extensions currently defined within CPSCore will disapear.

The threads are still running talking about an implementation for ZODB-3.4 of a simple before transaction commit hook :

• http://mail.zope.org/pipermail/zope-dev/2005-April/024566.html
• http://mail.zope.org/pipermail/zodb-dev/2005-April/008661.html
• http://mail.zope.org/pipermail/zodb-dev/2005-April/008667.html
  

   J.