Free Seaside/Pier/GLASS for Amazon EC2

Nick Ager just published the instructions (and a screencast) for creating a free Micro EC2 instance for Seaside, Pier, and GLASS:

Amazon’s offer of a free micro instance for a year grabbed my attention:

To help new AWS customers get started in the cloud, AWS is introducing a new free usage tier. Beginning November 1, new AWS customers will be able to run a free Amazon EC2 Micro Instance for a year…

But would a micro instance be sufficient to allow a Seaside application to run within Gemstone — my deployment method of choice?

[Updated: 1/4/2010] If you are interested, you should also check out the discussion on the Seaside list.

Photo by http://www.flickr.com/photos/chechipe/3821497127/ / CC BY NC ND 2.0

Pier 1.2.1.4 ready for release

Pier version 1.2.1.4 fixes a couple of GemStone portability issues.

To install or upgrade in GLASS 1.0-beta.8 evaluate the following expression in a GemTools workspace:

MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [
	[	Gofer project load: 'Seaside28' version: '2.8.4.6'.
		Gofer project load: 'Magritte' version: '1.2.1.4'.
		Gofer project load: 'Pier' version: '1.2.1.4' ]
	on: Warning
	do: [:ex |
		Transcript cr; show: ex description.
		ex resume ]].

I recommend that you specify explicit versions when you load, because the default version of intermediate projects may not be exactly what you expect. By explicitly loading a version you will have fewer surprises.

Note also that I’ve wrapped the standard Gofer project load messages with a handler for Warnings that dumps the  warning message to the Transcript and then resumes execution. The #commitOnAlmostOutOfMemoryDuring: method will do just that … it creates and enables an AmostOutOfMemory signal handler that performs a commit when you are almost out of memory – quite convenient for any operation that might run out of memory on you.

Photo by http://www.flickr.com/photos/mateus27_24-25/2168015333/ / CC BY-NC 2.0

Bootstrapping GLASS 1.0-beta.0

[1]

Not long after shipping the SOAP update for GLASS, I started working on Metacello. With the SOAP update, it became obvious that the GLASS ‘umbrella’ package was going to have to be replaced, and soon. Well, 7 months later I am reaching the point were I am finally ready to replace the GLASS package with a Metacello configuration .

I’m going to phase in the use of Metacello with GLASS. With the initial release, we’ll use Metacello for bootstrapping GLASS into a virgin extent. This way folks starting a greenfield project can use Seaside 2.8.4 or Pier 1.2 right away. Other releases that are in the pipeline:

• GemStone/S 64 2.4.x with partial continuations for Seaside3.0.
• Metacello configuration for bootstrapping Seaside 3.0 (ConfigurationOfSeaside30). A Squeak/Pharo version of this configuration is available now.
• final release of GLASS.230 package that will boot Metacello into an existing GLASS installation and allow for upgrading to GLASS 1.0-beta.0 and beyond.

GLASS 1.0-beta.0

ConfigurationOfGLASS version 1.0-beta.0 is based upon GLASS.230-dkh.231, with the following additions:

• Seaside 2.8.4
• Pier 1.2
• Metacello support
• VB-Regex loaded as part of ‘core’
• Scriptaculous updates from Ken Treis
• GemTools updates from Gerhard Obermann
  • optional auto abort performed before commands
  • add remove method (without any checks) renamed “remove method …” to “safe remove method …”
  • add command “browse class history”
  • add class history index to class browser title
• browse changes fixed … reversed comparison direction so that ”Install” will install repository version. the strike-out text is what is in current image.
• supports bootstrapping of code into virgin extent (see Bootstrapping Instructions).

Read the following sections to gain an understanding of the 1.0-beta configuration structure. If you are impatient and just want to load and go, then you can skip to the Bootstrapping Instructions.

1.0-beta Configuration Structure

With release 1.0-beta.0 there are 9 different loadable configurations defined in ConfigurationOfGLASS. If you read the code in the method ConfigurationOfGlass>>baseline10beta00:, you can see the Metacello specification summarized in the following sections.

Primary GLASS Projects

Any one (or combination) of the following projects and groups may be used as a load configuration for bootstrapping

Each of these projects is managed by it’s own ConfigurationOfxxx class.

• Core project. ConfigurationOfGsCore manages the Core, Base-Bootstrap, Bootstrap, GemStone-Exceptions (2.x only), GemStone-Indexing-Extensions, GsRandom, Sport, Squeak and VB-Regex packages. The Core packages are fundamental to the operation of GLASS and is always loaded.
• FastCGI project. ConfigurationOfGsFastCGI manages the FastCGIPool and FastCGI packages. The FastCGI packages are optional and are used to support FastCGI packages for Seaside2.8 and Seaside3.0.
• Hyper project. ConfigurationOfGsHyper manages the OpenSkills and Hyper packages. The Hyper packages are optional and are used to support the Hyper packages for Seaside2.8 and Seaside3.0.
• Magritte project. ConfigurationOfGsMagritte manages the Magritte-Model, Magritte-Tests and Magritte-Seaside packages. The Magritte packages are optional and represent the GemStone/S port of Magritte. By default only Magritte-Model and Magritte-Tests packages are loaded. To load Magritte-Seaside, it must be explicitly referenced.
• Metacello project. ConfigurationOfMetacello manages the Metacello packages and is imported from the Metacello project. By default the Metacello-Core, Metacello-MC and Metacello-Platform packages are loaded. The Metacello packages are fundamental to the operation of GLASS.
• Misc project. ConfigurationOfGsMisc manages the MockGemStone, SMTPMail, Utf8Encoding, Announcements, XML-Parser, SIXX, SmaCC, System-Digital-Signatures, and GemStone-Release-Support packages. The Misc packages are represent useful pieces of functionality that are contained in a single package and depend only upon the Core project. The Misc project is rarely loaded in it’s entirety. Typically individual packages are loaded from the project.
• Monticello project. ConfigurationOfGsMonticello manages the Change-Notification, PackageInfo-Base, and Monticello packages. The Monticello packages are fundamental to the operation of GLASS.
• OB project. ConfigurationOfGsOB manages the OmniBrower, OB-GemStone-Platfrom, OB-Monticello, OB-SUnitIntegration, OB-SUnitGUI, OB-Stanadard, OB-Tools and JadeServer packages. The OB packages are optional and provide the implementation for the GemTools.
• Pier project. ConfigurationOfGSPier manages the Pier-Model, Pier-Blog, Pier-DesignChooser, Pier-Design, Pier-Documents, Pier-EditorEnh, Pier-Google, Pier-Links, Pier-Randomizer, Pier-Slideshow, Pier-TagCloud, and Pier-Twitter packages. The Pier packages are optional and represent the GemStone/S port of Pier.
• Scaffolding project. ConfigurationOfGsScaffolding manages the GemStone-Scaffolding package. The Scaffolding packages are optional and representing the implementation of Scaffolding for GemStone. Even though this project consists of a single primary package, the fact that it depends upon Magritte and Scriptaculous warrants the creation of separate Metacello configuration.
• Seaside2.8 project. ConfigurationOfGsSeaside28 manages the Seaside2.8, SeasideAsync, Scriptaculous, RSRSS2, CallDemo, CheckboxExample, CSSDock, ErrorHandler, HelloWorld, ImageDemo, LogoutDemo, MarqueeDemo, menuDemo, ScreenResolution, Store, GemStone-Store, GemStone-Examples, FastCGISeaside and HyperSeaside packages. The Seaside2.8 packages are optional and represent the GemStone/S port of Seaside. By default only the Seaside2.8 pacakge is loaded. All of the other packages must be explicitly referenced.
• Seaside2.8 Testing project. ConfigurationOfGsSeasideTesting28 manages the SeasideTesting and PierTesting packages.
• SOAP project. ConfigurationOfGsSoap manages the SoXML, SOAP-CORE, SOAP-Client SOAP-Server, SOAP-Example and SOAP-TestCases packages. The SOAP packages are optional and represent the GemStone/S port of SoapCore.

Convenience GLASS Projects

• FastCGISeaside is a project based on a specialization of ConfigurationOfGsSeaside28 and references the FastCGISeaside package.
• HyperSeaside is a project based on a specialization of ConfigurationOfGsSeaside28 and references the HyperSeaside package.
• Metacello Tools is a project based on a specialization of ConfigurationOfMetacello and references the OB-Metacello package.
• Release Support is a project based on a specialization of ConfigurationOfGsMisc and references the GemStone-Release-Support package.
• Pier Testing is a project based on a specialization of ConfigurationOfGsPier and references the PierTesting package.

Groups

The following groups have been defined for the common load configurations.

• Dev group is made up of the Core, Monticello, Metacello, Release Support, OB and Metacello Tools projects.
• Magritte Dev group is made up of the Dev and Magritte projects.
• SOAP Dev group is made up of the Dev and SOAP projects.
• Seaside Dev group is made up of the Dev, Seaside2.8, FastCGISeaside and HyperSeaside projects.
• Seaside Testing Dev group is made up of the Seaside Dev, Seaside2.8 Testing projects.
• Scaffolding Dev group is made up of the Dev, Scaffolding, FastCGISeaside and HyperSeaside projects.
• Pier Dev group is made up of the Dev, Pier,  FastCGISeaside and HyperSeaside projects.
• Pier Testing Dev group is made up of the Pier Dev and Pier Testing projects.
• ALL group is made up of all of the projects defined in ConfigurationOfGLASS.

As you become familiar with Metacello and the GLASS configurations, you can define your load configuration. although you probably want to become more familiar with Metacello first.

Bootstrapping Instructions

Please comment to this post or send mail to the GLASS Beta Mailing List if you have trouble or the instrcutions are not clear. The bootstrap should work for the appliance or any version of GemStone/S 2.3 or greater.

1. Start a stone using a virgin extent copied from $GEMSTONE/bin/extent0.dbf into $GEMSTONE/seaside/data. Don’t forget to shut the stone down before copying extents around and don’t forget to make the extent writable using ‘chmod +w extent0.dbf’.
2. Download and unzip bootstrap_1.0-beta.0.zip.
3. cd to the bootstrap_1.0-beta.0 directory
4. Edit the .topazini file to match your stone.
5. Launch topaz: ‘topaz -l -T50000’
6. ‘login’ and ‘input installMaster.topaz’
7. Exit topaz. The ‘installMaster.topaz’ script installs the Dev Group which includes the GemTools.
8. Launch a GemTools Client 1.0-beta.1 image and login.
9. [Updated: later that day] Due to some bugs discovered in 1.0-beta.0, it is recommended that you update to 1.0-beta.1 by executing the following expression:

   ConfigurationOfGLASS project updateProject.
   (ConfigurationOfGLASS project version: '1.0-beta.1')
       load: 'Dev'.
   System commitTransaction.

10. Choose a configuration to load by executing one of the following expressions:

    (ConfigurationOfGLASS project version: '1.0-beta.1')
        load: 'Magritte Dev'.
    (ConfigurationOfGLASS project version: '1.0-beta.1')
        load: 'SOAP Dev'.
    (ConfigurationOfGLASS project version: '1.0-beta.1')
        load: 'Seaside Dev'.
    (ConfigurationOfGLASS project version: '1.0-beta.1')
        load: 'Seaside Testing Dev'.
    (ConfigurationOfGLASS project version: '1.0-beta.1')
        load: 'Scaffolding Dev'.
    (ConfigurationOfGLASS project version: '1.0-beta.1')
        load: 'Pier Dev'.
    (ConfigurationOfGLASS project version: '1.0-beta.1')
        load: 'Pier Testing Dev'.
    (ConfigurationOfGLASS project version: '1.0-beta.1')
        load: 'ALL'.

11. Make a backup and have fun!

—–
[1]http://www.flickr.com/photos/dawilson/ / CC BY-NC-ND 2.0

GLASS Beta Update: Cooking with GLASS (Preview)

[1]

In the last month, Gerhard Obermann and I have been pretty busy. Between us we’ve made over 80 updates to the GemTools package and over 20 updates to the GLASS package.

At this point in time, I think that the GemTools Launcher (GemStone-dkh.441) and the OmniBrowser tools are stable enough that you no longer need to be Brave and/or Curious to take the new tools and GLASS.230-dkh.209 for a spin. In fact the tools are probably in better shape now than they’ve ever been (I haven’t seen the MNU storms that would periodically appear in the old client for quite awhile). If you’re reluctant to upgrade, check out the new Backup/Restore commands. Being able to backup/restore your repository from the GemTools Client should ease your mind.

I still have between 50 and 100 issues that I want to address (mainly on the server-side) before the next beta release. In the mean time, I am all but done with the UI changes and I would like feedback from folks on the new commands. If you haven’t already, join the beta mailing list and send mail with your comments and suggestions.

If you run into (gasp!) a bug, use the new Bug Report commands to report the bug. Honestly, I would rather have people report 100 duplicate bugs than miss 1 valid bug report – don’t assume that I know about the problem!

GemStone-dkh.441

There have been a significant number of changes to the GemTools Client since the last preview release, so many that I decided to update the old Terse Guide to the GLASS Tools with a new post: Terse Guide to the (new) GLASS Tools. All of the menu items for the GemTools Launcher are documented.

If you haven’t already created a new GemTools client smalltalk image, then follow these instructions.

If you’ve already updated to a preview release, then you’ve already got a new Squeak/Pharo image and all you need to do is to update to the latest version of the GemTools Client, using these instructions.

Take a look at the GemTools change log for a complete history of the changes made between GemStone-dkh.355 and GemStone-dkh.441.

GLASS.230-dkh.209

In addition to the support needed for the GemTools Launcher a number of bugs were fixed:

• Bug39820 – packages dirtied unnecessarily when recompiling subclasses
• Bug38105 – HTTPSocketError not correctly loaded
• Bug38794 – Subclass creation method leaves instance creation disabled
• Bug39838 – ExceptionA class>>hasFixFor39741 breaks some things
• Bug38146 – unload class and remove method should clean up undeclared sybmols
• Bug39798 – UndefinedSymbols is not maintained correctly
• Bug39850 – MCPackageBrowser doesn’t update when package dirtied
• Bug39345 – ‘Squeak browser tools need move-to-category button’
• Bug39578 – ‘”revert to version” in “Versions of” method browser does not autocommit’
• Bug39303 – sorting of change list in Monticello brower is strange
• Bug39823 – missing OSkSocketReadStream>>upToEnd
• Bug39800 – SeasideTesting has probably decayed…
• Bug39777 – Cannot ‘browse’ ProtoObject without a walkbalk
• Bug39772 – Class>>allSubInstancesDo: always fails
• Bug39582 – lots of key-not-found errors using Vocabulary browser
• Bug38140 – ‘highlight inspect’ feature for debugger
• Bug38274 – need visual separation between ancestors in MCWorkingCopy>>summary
• Bug38304 – CTL-i on a String or Smallinteger ends up with Squeak inspector
• Bug39662 – Inspecting a float in GLASS results in a ‘Float out of Range’ error in Squeak
• Bug39827 – missing base method for GLASS
• Bug39795 – MAPriorityContainer>>remove: fails unexpectedly

Other highlights include:

• A belated update to Seaside2.8.3.
• Update to Pier 1.1.1.
• Improved Debugger, Inspector, and Chasing Inspector.

The following packages have bee removed from the GLASS package:

• MonticelloConfigurations
• Pier-LightBox
• Pier-Twitter
• SqueakSource
• TinyWiki

These packages are not automatically removed by the update process. If you aren’t using them, then you should manually unload them using the Monitcello Browser. If you don’t remove them you may see test failures for the UndefinedSymbolsTest and SentButNotImplementedTest. After removing the above packages the tests should run clean (4182 run, 4182 passed, 0 failed, 0 errors).

Once you’ve updated to the latest version of the GemTools Client, follow these instructions to update the GLASS server software to GLASS.230-dkh.209.

Take a look at the  GLASS change log for a complete history of the changes made between GLASS.230-dkh.187 and GLASS.230-dkh.209.

—–

[1] Photo by placbo (Creative Commons).

Pier Programming

[1]

This is the second post where I’m recording my experiences using Pier and GLASS for wife’s website. In the first post, I got GLASS and Pier installed on Slicehost using lighttpd as the web server.

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,

Code Updates

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:

1. 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.
2. Using scp, I copy the extent to my sandbox system (a 64 bit laptop running a copy of the appliance).
3. 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.
4. 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.

Repository Cleanup

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 Miguel Cobá, then files are served out of ‘/var/www’.

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.

——
[1] Photo: 2007-08-12, Uploaded by sayzey on August 16, 2007.

GemStone 101: #allInstances, #become: and friends

[1]

Intro

Last week Dario Trussardi submitted a bug report to the GLASS Beta mailing list (subscription required, but feel free to subscribe if you’re interested). The bug involved Magritte auto accessors – a feature whereby new instance variables (and accessor methods) are dynamically added to a class on demand. Dario was triggering the new instance variable creation during the rendering phase of a Seaside component and getting an Internal Server Error from Seaside:

InterpreterError 2403: Cannot commit, <‘a previous commit attempt failed with an error, this transaction must be aborted’>

This error doesn’t have the most intuitive explanantion and the stack dumped into the object log was rooted in the standard commit that occurs right before the HTTP response is returned to the browser – not much help.

I had tangled with the auto accessors before, in the Magritte unit tests, but Dario’s scenario wasn’t covered there. Dario provided a simple test case and I was off to the races. In the end I was able to fix the problem in Dario’s test case (at this writing I’m waiting for confirmation from Dario – when I get it I’ll publish a Beta Update), but I thought that it would be instructive to cover the issues involved in case anyone else wanders into this territory.

If you’re using Magritte auto accessors or are seeing 2403 errors or want to geek out on GemStone for a bit or have already settled down with a cup of coffee to “read another long post of mine” (yes I’m talking about you, Gera:), then by all means read on.

1. #addInstVarName
2. #allInstances
3. #become:
4. #readUsing: and #writeObject:using:
5. Magritte auto accessor and Seaside
6. SafelyPerformBlockRequiringAbort
7. Summary

Pier and GLASS on Slicehost

Last week while I was on vacation, I got my wife interested in using Pier for her Saluki website. I used the latest appliance with Pier 1.0.17. We made some changes to Pier like setting up the menu, changing the color scheme and removing some of the features included in the default Pier setup (post ticker on every page). My wife spent the bulk of the week playing with Pier – adding content and pictures.

By the end of the week she was very pleased with the potential – she’s been thinking of putting together a website bragging about our current and past Salukis. Pier is pretty easy for her to use and has just about everything she wants in her website and for the missing features and some of the nitty gritty details, she’s got me. I’m pleased because I’m sorta familiar with GLASS and if anything isn’t working right I have a reasonable chance of fixing it – I’d much rather be fixing things in Smalltalk:)

Last night while keeping an eye on the drubbing that the Patriots were putting on the Broncos, I installed GemStone/S 64 2.3 on Slicehost, following James’ instructions for GemStone/S and Miguel Cobá’s instructions for lighttpd. By the time the game highlights were being shown on ESPN, I had copied the extent0.dbf file from the appliance to the Slicehost instance and I had given my wife the basic instructions for starting and stopping lighttpd – we’ll not turn the site on full-time until my wife has finished building the site.

So far I haven’t deviated from the standard Seaside installation, but I know that I will be doing a few Pier-specific things like setting up PRFile to use MAExternalFileModel (scheduled for tonight) and possibly one or two other things which I’ll document as I go along.

Pier 1.0.17 on GLASS

[1]

On Tuesday, Tudor Girba announced the release of Pier 1.0.17 and the creation of a new Pier website. Today (Thursday), I am pleased to announce that Pier 1.0.17 is available on GLASS. I suggest that you keep an eye on the Pier blog for ongoing developments.

If you don’t already have GLASS installed, go on over to the GLASS downloads page for options and instructions. Then follow the instructions here to install the code that includes Pier 1.0.17.

When the final release of GemStone/S 64 version 2.3 is available ([updated 10-06-2008]real soon now) Pier 1.0.17 will be pre-installed. When the appliance based on the final release is made available ([updated 10-21-2008]probably version 1.0 beta 11), it will make a very nice little Pier-in-a-box with built-in persistence and a ready-to-run Pier instance.

Developer Details

When I ported Pier to GLASS I only made one (intentional) change in the feature set (changing PRFile to use MAMemoryFileModel instead of MAExternalFileModel). I didn’t port the package Pier-Squeak-Persistency either for obvious reasons.

By default PRFiles are created using MAExternalFileModel, however, for GLASS, I changed PRFile class>>descriptionFile to use MAMemoryFileModel instead. The rationale is that the GLASS repository is created and initialized on a build machine here at GemStone and any directory structures created during Pier initialization will not be propogated to the final installation. By using MAMemoryFileModel all of the PRFile data is stored in the repository (which happens to be on disk in the final analysis). When you get around to deploying Pier, you will most likely want to use MAExternalFileModel so that you can use Apache or Lighttpd to serve the static files, so you will need to change PRFile class>>descriptionFile to use MAExternalFileModel when you are ready to deploy.

Note – This was my first post using the ‘Blog It!’ feature on Flickr, so some of you may have seen a premature feed in your RSS reader.

——
[1] Photo: Pier Glass Studio, Uploaded by artfull281 on 19 Aug 07, 5.43AM PDT.