Over the last week I didn’t have a lot of time to do very much with the Pier installation other than set things up so that Seaside would be safe on the open internet:
- Remove all of the default Seaside apps, except the object log.
- Add authorization to the object log. The object log is too useful to remove, but since you can get easy access to the inspector via the object log, it has to be sealed off.
- Using the config editor for the object log, add WAAuthConfiguration as an Ancestor, then set the Login and Password.
- Set deploymentMode to true for pier, config and object log.
- Change all of the passwords (pier, config and object log).
My wife enjoyed herself writing articles and uploading pictures. We don’t have a domain name yet and we turn off lighttpd when we’re not actively using the site.
Today I finally found some time to play with Pier and take a chunk out of my todo list:
- Update to the latest GLASS package (GLASS.230-dkh.176 – still waiting for feedback from Dario, but I thought I’d go ahead and load it on my wife’s site)
- Fix a bug my wife found in the Pier-Blog package.
- Do a bit of repository cleanup.
- Convert the instances of MAMemoryFileModel to MAExternalFileModel,
The first thing I want to mention is that with a production site, it is a real good idea to have a sandbox where you can do development without worrying about impacting production users. Our web site won’t have a lot of traffic, but my wife puts in a fair amount of effort working on content and I don’t want to lose her work, so I take a couple of simple precautions:
- Before making any significant changes, I make a backup of the extent file (/opt/gemstone/product/seaside/data/extent0.dbf). I shut down the stone before copying the file, but you can also use the runBackup script, which safely copies the extent file while the system is running.
- Using scp, I copy the extent to my sandbox system (a 64 bit laptop running a copy of the appliance).
- After shutting down the stone on my sandbox, I copy the extent file to the data directory and restart the stone. The copy is useful in case you do something regrettable.
- After validating the upgrade/update steps using the sandbox, I perform them on the production system.
When all was said and done, I ended up committing a new version of the GLASS package (GLASS.230-dkh.177) and creating two web-site specific packages (Pier-Model-dkh.241 and Pier-Seaside) that I saved in a directory-based repository.
Looking at the object log, I had seen that the repository had grown from 100M to 160M since we’d started, and I was interested in seeing what I could do to reduce the amount of space used:
- There were a couple of continuations stored in the object log that I could get rid of now that the bug that my wife ran into was fixed.
- I knew that the all of the Monticello packages are saved in the repository in the Monticello cache, so I was interested to see what could be gained by flushing the cache.
- While working out the details of converting from MAMemoryFileModel to MAExternalFileModel I noticed that we had some 500 entries in the PRHistoryPersistency. Each one of history entries hangs onto a WASession along with other things, so I figured that cutting the size of the history list to 250 (from 1024) wouldn’t hurt.
In the sandbox, I gained about 20M by doing the above cleanup steps, but some of the Monticello operations took noticeably longer (the cache had to be refilled), so I don’t think that flushing the Monticello cache is worth it.
Convert from MAMemoryFileModel to MAExternalFileModel
GemStone/S extent files get moved around a lot between the time that the Seaside extent is created on one of our build machines and the time an appliance is fired up or GLASS is installed on a Linux or MAC machine. This movement makes it extremely impractical to do anything that depends upon a fixed directory path and lead to my decision to make MAMemoryFileModel the default mechanism used by Magritte and Pier to manage it’s files for GLASS.
Once a system is installed in a production environment it is desirable to start using MAExternalFileModel, because you can arrange for your web server to serve up the files.
In our case, my wife had already uploaded a number of images as instances of MAMemoryFileModel, so I needed to convert the existing instances as well as change Pier to start using MAExternalFileModel.
The first thing to do is to edit PRFile class>>descriptionFile to replace MAMemoryFileModel with MAExternalFileModel.
Then you need to decide where you want the files to be stored. If you are using the appliance, then Apache serves files out of ‘/opt/gemstone/apache/htdocs’. If you are using lighttpd as set up by
The script below, illustrates the choices made for an appliance. The rest of the script grabs all PRFile instances and swaps in an equivalent instance of MAExternalFileModel. The final statement in the script flushes the MADescriptBuilder cache, otherwise you’ll continue using MAMemoryFileModel:
| pf fm xfm | MAExternalFileModel baseDirectory: (ServerFileDirectory on: '/opt/gemstone/apache/htdocs/files'). MAExternalFileModel baseUrl: '/files'. System commitTransaction ifFalse: [ nil error: 'Commit failed' ]. (PRFile allInstances select: [:each | each file isKindOf: MAMemoryFileModel ]) do: [:pf | fm := pf file. xfm := MAExternalFileModel new filename: fm filename; mimetype: fm mimetype; contents: fm contents asByteArray; yourself. pf file: xfm]. MADescriptionBuilder default flush.
This pretty much takes care of the major items on the todo list for my wife’s website.
I am playing with some code that generates real clean URLs for Pier (unfortunately, there are some gotchas for the moment). My wife has seen some java script effects on other sites that she’d like to be able to do on her site so I’ll there’s some java script in my future. When my wife is happy with the way things look, we’ll get that domain name we’ve had our eyes on:) and set up the google analytics.
I have to say that I’m real pleased with the Pier is working out for both me and my wife.