The
Aida 6
web framework is rather different in objectives than
Seaside 3 as a Smalltalk application server. My specific interest was to determine to what extent the services for web applications were orthogonal to any given web markup. Both default to HTML but I am looking at frameworks suitable for emitting declarative Curl markup using the Curl web content language (originally MIT and now Sumisho.)
Both frameworks loaded fine into Pharo as Metacello configured packages and both had gotchas which required some experience in Smalltalk - unlike the Gofer and Metacello tools themselves.
What was distinctive in Aida was the need to make changes across many framework classes - and in Pharo Smalltalk, I can see no way to move new methods for base classes into my packages other than the *extensions mechanism.
The worst problem was an >>
initialize method which started with
super initialize and then failed to call a private method - the one mechanism that permits a subclass to override
initialize properly ( I will submit my change as a fix.)
A serious problem was the lack of critical cleanup and reset methods ( I only needed to add one to Seaside for WAKom.) I will submit these to the Aida team.
You will not want to try to prototype anything in Aida without using the process browser tool and without running a set of >>allInstances sanity-check mthods.
The proliferation of objects comes from inadequate cleanup - but in a Version 6 of Aida may reflect the reliance on loading packages into base images. This is terrific for PITL but Smalltalk was always great for prototyping and that almost means maintaining a 'working' image - which is one way to spot objects that hang around.
In the early days of Seaside my rule was to discard any image in which Seaside had launched. For anything other than prototyping, Aida would mean working from a close-to core base image. That's just my take on what I saw after running two subclasses of SwazooSite in the same image, stopping, saving, quitting, launching ST.
And all bets are off until I have seen what a production image looks like - in the old days this was a matter of "stripping" images down - but we should now be in the age of building core images up.
I say that with a clear awareness of just how tiny servers can be in other alternative languages - such as Rebol - aside from any issues of code getting reused, code being understood and code being maintainable.
In the positive column: Aida has achieved a dialect for composing web pages which I think is on a par with Seaside. But Rebol is also great at dialecting ... so dialecting is not enough.
In secure corporate environments where Curl shines, I remain concerned with the use of a
pharo.st file at startup. On the other side of that coin, the Aida tag method looks as if it should be reading from a resource file as adding a new tag should not always be a matter of changing framework level code.
At this time I have more of Curl running under Seaside but neither have the equivalent of 'halos' in Curl yet - so the jury is still out on a Smalltalk web framework for Curl markup.
Curl has great prospects in Asia, the subcontinent and Africa (most professional Curl developers are in India and Japan) wherever security is paramount.
My current work has moved from "eyes-only" document browsing* to "dark documents" on analogy with "dark matter": shedding light on a file directory or a DB table does not reveal them. The key is to make "dark documents" run light in collaborative environments. Both Smalltalk and Curl come with such excellent programmer facilities that they make a terrific match for prototyping a dark objects source and viewers. And Curl has an exisiting inheritance mechanism near to Traits and no barrier to evolution away from classic OOP (having been designed and implemented by MIT Lisp and Scheme experts at
curl.com)
More to follow ...
* a early prototype for which there are links at
logiquewerks.com and at
aule-browser.com - both required the Curl runtime for the browser or the Curl REPL with scripted variants.
