[Seaside] Newbie questions about Squeak and Seaside

William Harford seaside at harford.org
Thu Aug 24 19:03:30 UTC 2006

I looked at it. And there are a couple things that did not work for me.

It does not support MySQL. Thats a show stopper for me.

It's centered around the idea that the Database comes first where  
REServe uses the approach that the objects come first.

REServe will also do some other things like storing any sub instance  
of REServe in a ivar.

I am not trying to fill in the space the GLORP already fills. I am  
making a different compromise between the object model and the  
relational one and trying to make a relational database as much like  
an Object Oriented database as possible while still keeping some of  
the advantages of a relational database.


On Aug 24, 2006, at 2:48 PM, Todd Blanchard wrote:

> Rather than writing new OR mappers, you might look into GLORP.  The  
> community has been unusually active lately and lots of good  
> improvements have been made.
> On Thursday, August 24, 2006, at 11:30AM, William Harford  
> <seaside at harford.org> wrote:
>> On Aug 24, 2006, at 1:05 PM, stephane ducasse wrote:
>>>> We use Squeak/Seaside in a commercial setting and the speed is
>>>> adequate.
>>> Can you tell us more?
>> Sure.
>> The page loads are around one second. My goal is to half that by the
>> end of the year but there are a lot of hurtles to overcome before I
>> can do that.
>> The slowest part of the application is data access. I currently use a
>> OR mapping library that was written in a hurry (by me) and
>> unfortunately it suffers from poor design and kludgy code. You are
>> welcome to take a look at it but I ask that you don't hold it against
>> me :-) http://squeaksource.com/IOSPersistent.html .
>> I have written another OR library, called REServe, that takes some of
>> the concepts I liked from IOSPersistent and implements them in a
>> much, much, much nicer fashion. Giving the developer better control
>> over how things are stored, cleaner code, the database is abstracted,
>> Smalltalk enumeration of the database,  PostgreSQL is supported, and
>> much more. I am convinced that the new library has a future and will
>> be releasing it to the public in the next couple weeks.
>> If you are interested in having a look at REServe let me know. The
>> main reason for not releasing it yet it incomplete documentation and
>> tests.
>> The current MySQL drivers for Squeak do not use Unix domain sockets.
>> I have not looked into Squeak support for Unix sockets on squeak but
>> if the MySQL drivers could be modified to access the server via Unix
>> sockets that would give our application a speed boost. Any
>> volunteers :-)
>> WeakArray ; What can I say that has not already been said. I fear
>> that the implementation details of WeakReferences are currently over
>> my head and I would need a bit of education before I attempted making
>> finalization faster. I would really like to see this improved because
>> I currently have to work around the problem.
>> I changed SeasidePlatformSupport #weakDictionaryOfSize: to read
>>    ^ IdentityDictionary new: aNumber
>> This means that our sessions grow until they are ended. It's not
>> ideal but it works.
>> Instead of triggering the cleanup of expired sessions every n new
>> session/requests (I can't remember which) I run a reaper process that
>> checks every so often and cleans things up.
>> We run a document management application and as such we create a lot
>> of WADocumentHandlers for thumbnails. WADocumentHandlers where not
>> getting cleaned up until we cleared all Seaside caches and for our
>> situation that was not reasonable. I changed WADocumentHandler so be
>> a sub instance of WAExpiringHandler and have it expire after a couple
>> hours (except for css files) and that seamed to keep our image size
>> down.
>> Our image will get up to about 300MB. It runs on a server with 4G of
>> ram so for us thats acceptable.
>> Our usage might not be typical. During the day we have 3-12 people
>> working in the application doing data entry as fast as the
>> application will go. Touching all parts of the application.
>> Another thing we did that greatly improved speed pair down some of
>> the component creation.
>> Because components are not cleared after they are no longer
>> referenced because of the above changes creating > 12 components on
>> each page view was to much. To work around it I ask each model
>> #canRender. If #canRender answers true I send the model
>> #renderContentOn: html caller: parentComponet. The model can then
>> render it's self with out registering a component. While this is not
>> ideal it gets the job done.
>> There are other things but thats all I can remember for now.
>>> Is the application visible on the web?
>> The application is not public. If you are in the Toronto, ON or
>> Orlando, FL area I will be more than happy to demo the application
>> for you.
>>>> At one point I did port my application to VisualWorks and the
>>>> speed was much improved but the price we were quoted was
>>>> unacceptable ($130,000/year).
>>> Indeed you were making money apparently or the sales were doing
>>> something wrong.
>>> you have also dolphin smalltalk :)
>> We run on Linux and it's essential to our operations. I don't see
>> that changing anytime soon so unfortunately Dolphin is out of the
>> question.
>> The VW sales person quoted me on number of expected users. She offer
>> no other quote even after I pressed for it. In fact she seemed almost
>> uninterested in our business. The price was 135 and that was that.
>> Personally I would like to see Squeak become an industrial strength
>> platform. There is a lot of work to be done but there is also a
>> growing interest. I might be biased but the future looks bright for
>> Squeak to me.
>> Enough of my rambling.
>> Will
>> _______________________________________________
>> Seaside mailing list
>> Seaside at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

More information about the Seaside mailing list