At this time we're testing Cassandra to properly understand how it works and make sure we can use it the way we're thinking we want to use it. This works. See libQtCassandra

Next we want to implement a simple test to check cTemplate and see that we can (1) create a simple layout with variables and fill in the fields; (2) extract the fields to generate the dependencies. We changed our plans on this one we'll be using XML and XSLT to transform the XML to whatever output the user is interested in (HTML, PDF, Text, RDF, etc.)

As we're working with Cassandra, make sure we can get it to talk to another node via an SSH tunnel.

Start getting a basic app. that take a page data from Cassandra and generates the output with the layout selected for that page and cTemplate. This works for files for which the output is not XML. For example, robots.txt feature works. We also have a XML Sitemap feature (which is XML but not in the sense meant by the standard HTML or XHTML output.)

Once this works well, we have a "static" (non-editable) website capability that we can test through a browser so we want to implement the two layers of our application: very small snap.cgi which connects to the snapwebsites server. The server needs to be able to return the compiled page(s) to the CGI. We have that already. The snap.cgi and Snap website server are communicating as expected and the server is already capable of sending data back to Apache including real HTML pages, CSS, JavaScript, images. The Editor feature [core] is even capable of saving inline images as Attachment feature [core] and returning them through an <img src="..."/> tag.

At this point we want to implement the necessary elements to generate the HTML output of a page of content. This requires many elements and thus requires a little bit of thinking. See Content Object in Cassandra (Content Tree) for all sorts of details. This works already although we are looking into including branchs, revisions, and secret data support early on because we are actually thinking that it will be easier to implement now rather than later.

• Links between content types (node type, tags, author, permissions, etc.) -- this is part of the Lists implementation because we want to implement all the Links as sets even if only one link is used (see Lists and List feature [core]) This is actually not part of the lists because lists (1) make use of another table and (2) want their data sorted. We have a links plugin instead (see Links between rows).
• The theme that defines the look of the page in HTML -- there is a plan in regard to having our own XML definitions instead of HTML, however, that would dramatically complicate any editor we'd be able to use to let users edit their content; so at this point we assume that most of the input data is [X]HTML. This is part of the XSLT translation mechanism. However, the theme must define a certain number of properties to enable handling of data that we can attach to it. (TBD) (See Output Format feature [core]) This is done. We use XSLT for the theme and the data is XML. The output is currently only HTML (although we are able to generate PDF files from simplified HTML documents and text emails from HTML pages), but we'll later have layouts that can spit out text. This means the user can edit his pages with standard inline editors.
• The layout of the content (this is confusing at this point because the Layout feature talks about both things... what we want is an easy way for users to change the page content layout between a single or double columns, a layout with an image at the top-right with proper margins and shadow...) -- the layout is different from a theme because the layout is only applied to that bit of content, whereas a theme is applied to all the bits and pieces being generated in this page (see Layout feature [core]) In general, the layout does not define any CSS that changes the font, colors, etc. that the theme defined.
• Content tree: root type, types, content types, content. We could have permissions fairly quickly to test that a page can easily be forbidden (401/403). Content tree manager (see Page feature [core]) and Permissions feature [core] are done.
• Boxes support -- these are bits and pieces of other content that are displayed around the main content of the page (menus, user log-in form, recent posts, last comments, etc.) Support is already available. It has not been tested much yet but it looks like the base is there and working good.

This presents a simplified view of the handling of a
Page to it's Output.

The following shows how the data flows from the Internet to Snap! and back out. The Snap! server and Cassandra can each be on different computers than Apache, although at this time we plan to have the Snap CGI talk to the Snap! server via a Unix socket to make it as fast as possible (this is implemented and working with a full TCP/IP socket.)

Note: our first Snap! C++ version will not include external caches to simplify our implementation. (i.e. the only cache is Cassandra's memory cache at this point.)