After the feature set was clarified, the challenge team started in on the design of the weblog server.

As a start, the challenge team was given a 'typical' data structure layout that a weblog server uses: SBlog Data Structures.

The team divided the task up into the major functional areas:

Web UI

CSS Interface

Data Model

Data Persistence

Output

RSS Feed

First priority: Write the model. Here's some of the lightly edited transcript from the discussion logs. The purpose of displaying the transcript is to give some insight on how experienced programmers who program in Smalltalk 'think' about implementing an application.

<avi> so what are we modelling...
<avi> let's look at the diagram... SBlog Data Structures
<avi> not all of the ivars there seem necessary to me at first
<avi> Author, I'd say we need username, pass, blogs
<avi> Blog, we need name, posts, categories
<avi> not sure about author, since it seems to me that's a many->many relationship
<avi> entry, we want...
<avi> author, timestamp, description, title, category[ies], comments
<avi> comment, we want author and text
<avi> at least to begin with
<avi> and category we want name
<avi> what do y'all think?
<avi> what else should be there?
<markschwenk> what about link of some kind in entry?
<avi> link or permalink? like, to the blog or out of it?
<blaineb> I think we should have a user object with a BlogAuthor role and a CommentAuthor role
<avi> well, do we want people to log in to post comments or no?
<blaineb> but then again, I think comment author is going to have less info
<markschwenk> I was just thinking some unique identifier or url into the blog entry.
<blaineb> I think logging in to post a comment is a little much isn't it?
<avi> yes
<blaineb> I think we should be the basic info we need into a user object and put the rest of the information in the separate roles
<blaineb> and we use the roles around the system to make things clear
<avi> markschwenk: it does need that, although I'm not clear that it should be an ivar... really we should be talking about interface not structure
<blaineb> I think blog should have a UID and not a URL inside of it
<avi> blaineb: to take a slightly different tack on what you're saying, it might be nice to use a capabilities model here
<avi> so in a capabilities model, an Author would hold any number of BlogEntryPoster objects
<blaineb> avi: explain capabilities model...I think I know where you are going but want to be clear
<avi> these are what are actually able to add entries to blogs
<avi> a "guest" user would be able to access a Blog,
<markschwenk> avi: so you were thinking of the UID being where?
<avi> but there would be no API for modifying it
<blaineb> avi: OK, I can agree with that...=)
<avi> markschwenk: well, clearly BlogEntry should respond to #id or something
<avi> but it may be something like
<avi> ^ self blog idForEntry: self
<avi> idForEntry: anEntry ^ entryIndex keyForObject: anEntry
* avi shrugs
<blaineb> avi: have you got the ivars yet?
<avi> no, was just about to start roughing in some methods,
<avi> but others can do this too... :)
<markschwenk> i'd really like the policies to be able to be defined by the blog host admin, so that some blogs could require commenters to log in or not, readers login or not, etc.
<avi> markschwenk: in a capabilities system, you would achieve that by the admin adding BlogReader, BlogWriter objects etc to a guest object

There are a couple of things to notice at this point. First, notice the practice of decomposition; the problem is broken down as much as possible into the constituent parts, each part is 'stripped' down to the core values. Somebody once said that programming in Smalltalk is like farming, you plant the seeds and then cultivate the resultant crop. The important part is to pick the right seeds :-) Another interesting point: because of the extensible nature of Smalltalk, it's easy to come back later and build incrementally during the development cycle. That's why it's OK to 'prune' data structures; they can easily be 'grown' when actually needed. The important part at this point is to understand the relationship of different objects and understand each objects' role within the application.

In Smalltalk, we talk a lot about 'late binding'. There are a lot of advantages of deferring implementation too.

At this point, the group started sketching some of the objects: SBlog-avi.mcz (Monticello format). If you look through the code, you'll notice that several classes have been defined. Open a browser, and browse the category SBlog-Model. You'll notice that some new classes have been defined:

Blog

BlogAuthor

BlogCategory

BlogComment

BlogEntry

There are a couple of interesting points here that I'll point out. First, notice that none of the classes have instance variables; this is an implementation detail which will be handled later during the coding phase. Second, notice that a few methods are defined. These methods are 'known' entities, functionality that must be provided by the class, but are not actually specified on how it should be implemented. As an example:

The interesting part here is that the implementation has been deferred; it's not important at this point to define the password as an instance variable (ivar) or an object property. However, also note that this is not as formal as precisely defining an entire 'API' before implentation. Instead, the designers are trying to just sketch out some of the known factors, the details will be filled in later.

Some Other Choices
The team chose to use the Seaside as their web development framework. Seaside is interesting from a variety of standpoints. Look here for the 5 minute elevator spiel, look here for the big picture. Seaside has been developed in Squeak by Avi Bryant and Julian Fitzell of Beta4 Productions.

Seaside is an interesting selection for the challenge. Even though one would think that the UI would be nearly elementary for a weblog server, there are many points for user interaction. Seaside helps with that interaction at a very fundamental level; it makes it easy to layout the interaction flow and implementation.

Persistence (Data Store)
Another choice that the team made was to use Ominbase for persist storage of the data objects. Ominibase is an object oriented database management system (OODBMS).OmniBase is a production-strength object database. Cees de Groot has ported it to Squeak, details can be found on the OmniBase Swiki.