Hi all - 

I would like to announce the first version of the Bicephale project:

   <http://software.auf.net/bicephale/Bicephale3-mist.1.mcz>

The goal of Bicephale is to change Seaside to make it handle elegantly the display of static, long-lived objects. 

As it stands, Seaside is very powerful at handling sessions - sequences of pages that represent a dynamic operation and for whom bookmarkability and long-term persistence is not an issue. Seaside is however somewhat clunky at displaying simple, unchanging pages with stable and bookmarkable urls. Since most applications with sessions also need such stable pages to display the objects they are editing, Seaside suffers from this even on its home turf.

To take an example, if you view a blog entry with Smallblog - the Seaside blog application - you get a different url every time you view the entry. This creates several problems: (i) such pages cannot be easily bookmarked although they should be (Smallblog resorts to a workaround for this); (ii) they cannot be indexed although one would want them to; (iii) such pages 'expire' after a while, and clicking on a link after expiration has unexpected effects, confusing the user. Almost every Seaside application suffers from this, whether it is a store, a ticketing application or an academic article repository.

There are currently workarounds for these issues, but Bicephale aims at solving the problem at its root, in an elegant and principled way. It does that by introducing static, long-lived callbacks (following up on these two February 2005 posts on the Seaside list by Avi and myself:

	<http://lists.squeakfoundation.org/pipermail/seaside/2005-February/004400.html>
	<http://lists.squeakfoundation.org/pipermail/seaside/2005-February/004436.html> )

These lasting callbacks are rendered by a new type of components (WAStaticComponent) that live outside of sessions but within the application. Apart from having stable urls, these components behave just like session components:

	i. they use standard Seaside rendering methods - e.g. they render with the usual #renderContentOn: and link to another object with 'html anchor: anObject text: aString'.

	ii. they can #call: traditional dynamic components (WAComponent) and receive an #answer: from them. A static component can for instance include a (stable) link to edit the object currently displayed. That link will trigger a standard seaside login dialogue and based on the answer, it initiates a traditional Seaside editing session.

	iii. the handling of urls is largely transparent to the developper. Much of Seaside's appeal is the ability to concentrate on the logic of the application and have the framework automatically handle the details of the underlying http transaction, including the urls used. This is the same with static components.

A Bicephale application (WABicephale) has therefore two root components: the usual session root component and the new root static component (hence the Bicephale name). By default the application renders the static component, and sessions are used only when a #call: is issued.

This first version implements all of the above, but in a preliminary and experimental way. This means that it is now almost trivial to display static object with automatically generated fixed urls and have them call/answer dynamic components. At the same time, I am still experimenting with various implementations, and looking for the right abstractions -- particularly in the handling of urls/component composition. Since almost every design decision is still open to drastic revision, I would appreciate feedback!

Finally, there is currently no UI or documentation. I will however post a sample application, and if there is interest, I will provide some basic documentation.

Michal

ps. there are no modification to base Seaside classes in this package - it only adds new classes. It should hence be harmless to install it into your Seaside image, but this being an early prototype, caveat emptor.