[Seaside] rails niceties equivalents?

James Robertson jrobertson at cincom.com
Sat May 16 17:30:13 UTC 2009


Seaside as a framework isn't trying to solve the problems you're after  
below.  Vendors, on the other hand (as well as interested open source  
developers, I'm just less familiar with things like the work Ramon  
Leon has been doing) are solving them.

-- Cincom has been working on Web Velocity.  See the videos here:

http://www.cincomsmalltalk.com/userblogs/cincom/blogView?content=smalltalk_videos_web_velocity

If you're interested in having a look, the beta program is still  
open.  Just drop me an email

-- Gemstone has been working on GLASS.  I've only looked briefly at  
GLASS, but James Foster and Dale Henrichs have been pretty responsive  
over the last year or two on this.


James Robertson
Cincom Smalltalk Product Evangelist
http://www.cincomsmalltalk.com/blog/blogView
Talk Small and Carry a Big Class Library




On May 15, 2009, at 3:50 PM, Eagle Offshore wrote:

> 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.
>
> 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.
>
> 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.  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.
>
> 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.  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).
>
> Problem 2 - and this is huge.  No horizontal scalability pattern has  
> emerged.  Rails has Mongrel 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).  With all  
> application state stored in memcache storage, I can update and  
> bounce the rails apps at any time without hosing a single session.   
> 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.
>
> 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.
>
> -Todd Blanchard
>
> On May 15, 2009, at 12:16 PM, stephane ducasse wrote:
>
>> Hi Todd and others
>>
>> So why don't you offer code. Start small and step by step help.
>> Why this discussion comes from time to time?
>> You cannot ask lukas and julian to speed up, make seaside uses less
>> memory, clean and improve the Javascript and in addition offer  
>> database
>> supports.....
>> Something I have the impression that the seaside community is  
>> mainly people
>> complaining but not really offering support and new code.
>> Sorry to be harsh but this is not like that we will improve.
>>
>> Stef
>>
>>
>>> Yes, I know. That's why my last three projects have been done in  
>>> rails.
>>>
>>> Sometimes I wish seaside would copy more and "innovate" less.
>>>
>>> -Todd Blanchard
>>>
>>> On May 14, 2009, at 7:06 AM, Philippe Marschall wrote:
>>>>
>>>> Seaside is not Rails in Smalltalk.
>>>>
>>>> Cheers
>>>> Philippe
>>>> _______________________________________________
>>>> seaside mailing list
>>>> seaside at lists.squeakfoundation.org
>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>
>>> _______________________________________________
>>> seaside mailing list
>>> seaside at lists.squeakfoundation.org
>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>
>>
>> _______________________________________________
>> seaside mailing list
>> seaside at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>



More information about the seaside mailing list