[Seaside] rails niceties equivalents?

[Philippe Marschall]

2009/5/15 Eagle Offshore <eagleoffshore at mac.com>:
> First, the point of my rather cranky reply was to point out how the other
> remark was not only not helpful, but off-putting.  This is how seaside
> community gets labelled "unfriendly" and "arrogant".  There's a lot of nice
> ideas in rails.  Many are worth stealing.

Rails solves a different problem, really. If you like rails, just
continue using it. If you want a copy of rails, do one.

> Seaside is a deep magical framework (the session state management magic and
> continuations) make it really hard to contribute anything at the core level
> unless they've studied and studied it.  We can't all devote that much time
> to mastering all that magic.

Noone expects or asks you do contribute, change or understand anything
at the core level.

> OK, here's a couple of things I wish were solved and have take a bit of time
> to look at and keep hitting the wall on.  At some point fairly soon, I
> promise I'll take at least one of them on and try to do something about it
> if I get a little help pointing me in the right direction.
>
> I do periodically download the seaside image, and have also tried to get
> started with glass a time or two.  In the end I keep running into time
> constraints and bugs that I can't seem to get around, tools are in a state
> of flux, etc.... and I conclude its just not stable enough yet.  But I keep
> checking back.
>
> The one thing that is consistently requested (and I definitely need) is ways
> to do RESTful dispatching.

Seaside is not a RESTful framework. If you need that look somewhere
else. There are certain ways to emulate certain things but that's
about it.

> The usual reply is that it is done in Pier and I
> could download Pier and look at that.  I've done this and browsed code for a
> few hours, and still come up empty about how to do this in generic Seaside.
>  I think the core maintainers have to do this - only they have the
> knowledge.

The usual reply is look at #initialRequest: #updateUrl: and
#addToPath: they actually have comments. Look at WABrowser for
concrete example.

> In general, tracking down how URLs get built and routed in Seaside is HARD
> (at least it was in the previous versions - I haven't looked at the latest
> one).  Rails has a really GREAT convention of making urls a standard REST
> format of scheme://server/controller/action/id and a "routes" file for
> customizing this.  This is a great idea.  I love it.  I now miss it
> everywhere else I work.

Great, use an MVC style web framework. Really, these things work fine
for MVC style web frameworks but will end up in pain for component
based frameworks. If that is what you need and works really well for
you then Seaside isn't well suited for your problem unless you just
want to use WARequestHandler, WARequest and WAResponse.

> It has to be easier to customize URL generation in
> seaside in a centralized way.  Maybe I'm too stupid for this, but every time
> I set out to do this, I get lost, deadlines loom, and I fall back on what I
> know will work (rails or django).

If they work well then that means they're well suited for the problem
and Seaside is not. No point in tying to use Seaside or making it fit
the problem.

> Problem 2 - and this is huge.  No horizontal scalability pattern has
> emerged.

That's a Smalltalk (image) problem, talk to your vendor.

> Rails has Mongrel

That was yesterday, today is phusion passenger.

> and some really slick sharing via memcached
> (which actually, if I were to do something for seaside - adding a memcached
> client would be a giant win).

http://www.squeaksource.com/memcached.html
Needs users, testers, contributors, bugfixing, documentation, the usual stuff.

> With all application state stored in memcache
> storage, I can update and bounce the rails apps at any time without hosing a
> single session.

Yeah, as long as your whole session state is just a couple of strings
everything is fine. As soon as your session state is arbitrary objects
including blocks and continuations you enter a world of pain.
memcached is only really useful if you can't preserve state across
requests (PHP).

> GLASS looks like it may well solve this problem - except my
> hosting providers don't provide 64 bit machines and I get lost every time I
> try to get started with GLASS because I hit some half baked tool problem and
> give up.

Complain at GemStone.

> OK, actually, since I agree that code talks - tell me if anyone is doing a
> memcache client, and if not, I'll try to do one and see about applying it to
> shared session storage - because state in the image sucks for production and
> reliability.  I want any image in a pool to be able to fail at any time and
> not have a single user notice.  Until it does this, I can't consider it for
> real work.

See above.

Cheers
Philippe