rails niceties equivalents?

> -----Mensaje original-----
> De: [hidden email]
> [mailto:[hidden email]] En nombre
> de Eagle Offshore
> Enviado el: Friday, May 15, 2009 15:58
> Para: Seaside - general discussion
> Asunto: Re: [Seaside] rails niceties equivalents?
>
> 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
> > [hidden email]
> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> 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
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

> 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
>>> [hidden email]
>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>> _______________________________________________
>> seaside mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> 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.

>
>
> -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
>>>> [hidden email]
>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>
>>> _______________________________________________
>>> seaside mailing list
>>> [hidden email]
>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>
>>
>> _______________________________________________
>> seaside mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

> 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).

> -----Mensaje original-----
> De: [hidden email]
> [mailto:[hidden email]] En nombre
> de Julian Fitzell
> Enviado el: Friday, May 15, 2009 18:05
> Para: Seaside - general discussion
> Asunto: Re: [Seaside] rails niceties equivalents?
>
> On Fri, May 15, 2009 at 12:50 PM, Eagle Offshore
> <[hidden email]> 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.
>
> I agree. As others have pointed out, it's not for lack of desire, per
> se, on the core developers' parts. There's just only so much time and
> we choose to focus our time on the low-level stuff that others can not
> so easily tackle. If something can be "added on", we probably won't do
> it because somebody else could.
>
> > 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.
>
> We've tried hard in 2.9 to take a lot of the magic out or at least
> make it clearer (actually one of my biggest complaints about Rails is
> the "magic" :) ). I'm also working on design documentation that should
> help somewhat. If anyone wants to pay me to spend more time on a
> particular area of Seaside that is felt to be lacking, I'd be happy to
> consider it; otherwise I have to balance paid work, Seaside core
> hacking, and other activities.
>
> > 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.
>
> Glad to hear it and, as I hope you've observed, we're always quick to
> share pointers with anyone who is trying to contribute code.
>
> > 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).
>
> RESTful dispatching has always been possible but the framework never
> targeted it. 2.9 should make it somewhat clearer and in fact I'm
> currently intending to give an intermediate Seaside tutorial at ESUG,
> which will likely touch on at least one way to do this. Colin's
> Altitude experiment also played with this a bit. I've spent a little
> time in the past trying to think how you could map Rails' routing
> configuration into a Smalltalk world and just haven't come up with a
> great solution. This is not even remotely challenging at a *technical*
> level; it's just a matter of coming up with a good interface and I
> just don't know what it is yet.
>
> > 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.
>
> I think GLASS is our (the core developers') favourite option here but
> I think everyone agrees that the "all-around" experience in terms of
> deployment, configuration, and so on could do with improvement. I'm
> hoping that by facilitating and better documenting ways to use Seaside
> without Applications and Sessions, RESTful sites can be more easily
> created and scaled. For stateful applications, GLASS really is a good
> way to go but in any case we, as a community, need to come up with a
> better experience for getting from development to deployment.
> Contributions are hugely welcome here or, again, if anybody wants to
> pay me to work on it, that could be possible.
>
> > 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
>
> Oh, it's you, Todd. I thought I was replying to someone
> called Eagle. :)
>
> You said you wished Seaside would innovate less and I think we are
> getting there. Despite a huge amount of changed code, Seaside 2.9 is
> really all about refining and not about innovation. People haven't
> been clamouring for new features so we've really been focusing on
> cleaning up and clarifying the existing architecture, generalizing
> where possible, improving comments, standardizing categories, and
> breaking things up into packages. The packages reflect largely what
> the layer boundaries were always supposed to be but they have become
> muddied over the years without design docs. Hopefully the end result
> will be something that people can more easily extend and build upon
> (including copying other frameworks).
>
> So again, I hope we're moving to make the kind of copying you want
> easier and I think that's the best things for us to spend our time on.
> All of us are happy to point anyone who wants to extend the framework
> in the right direction (I'm happy to discuss possible architectures on
> Skype). And if anyone would rather pay me to scratch their own itch,
> let me know. :)
>
> Julian
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> 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.

> 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
>>>> [hidden email]
>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>
>>> _______________________________________________
>>> seaside mailing list
>>> [hidden email]
>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>
>>
>> _______________________________________________
>> seaside mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

> 2009/5/15 Eagle Offshore <[hidden email]>:
>> 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.

> On Sat, May 16, 2009 at 10:06 AM, Philippe Marschall
> <[hidden email]> wrote:
>> 2009/5/15 Eagle Offshore <[hidden email]>:
>>> 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.
>
> I don't think it's that simple and I don't think we should discourage
> people who want to work on this.

> Seaside has always been capable of supporting other paradigms, though
> this should be more obvious again with the reorganization in 2.9. At
> its core, Seaside is a request and response dispatching engine. So
> while you are right that Seaside is not *currently* a RESTful
> framework, it wouldn't take much effort to make it support both a
> Rails-type model and the existing Session model if only someone knew
> what they wanted a request handler for the former to look like. And I
> think being able to easily develop stateless rails-style apps with
> full REST URLs but using the Canvas API would be a huge win for many
> people.

> I don't think it's that simple and I don't think we should discourage
> people who want to work on this. It is true that nobody has come up
> with a good paradigm for doing non-Session REST stuff in Seaside and
> also true that we haven't even come close to figuring out a good way
> to blend the two but I would suggest that in a huge number of cases
> you don't need both within the same "application" anyway.
>
> Seaside has always been capable of supporting other paradigms, though
> this should be more obvious again with the reorganization in 2.9. At
> its core, Seaside is a request and response dispatching engine. So
> while you are right that Seaside is not *currently* a RESTful
> framework, it wouldn't take much effort to make it support both a
> Rails-type model and the existing Session model if only someone knew
> what they wanted a request handler for the former to look like. And I
> think being able to easily develop stateless rails-style apps with
> full REST URLs but using the Canvas API would be a huge win for many
> people.

> Seaside has always been capable of supporting other paradigms, though
> this should be more obvious again with the reorganization in 2.9. At
> its core, Seaside is a request and response dispatching engine. So
> while you are right that Seaside is not *currently* a RESTful
> framework, it wouldn't take much effort to make it support both a
> Rails-type model and the existing Session model if only someone knew
> what they wanted a request handler for the former to look like. And I
> think being able to easily develop stateless rails-style apps with
> full REST URLs but using the Canvas API would be a huge win for many
> people.
>

> On Sat, May 16, 2009 at 9:49 PM, Julian Fitzell <[hidden email]> wrote:
>> I don't think it's that simple and I don't think we should discourage
>> people who want to work on this. It is true that nobody has come up
>> with a good paradigm for doing non-Session REST stuff in Seaside and
>> also true that we haven't even come close to figuring out a good way
>> to blend the two but I would suggest that in a huge number of cases
>> you don't need both within the same "application" anyway.
>>
>> Seaside has always been capable of supporting other paradigms, though
>> this should be more obvious again with the reorganization in 2.9. At
>> its core, Seaside is a request and response dispatching engine. So
>> while you are right that Seaside is not *currently* a RESTful
>> framework, it wouldn't take much effort to make it support both a
>> Rails-type model and the existing Session model if only someone knew
>> what they wanted a request handler for the former to look like. And I
>> think being able to easily develop stateless rails-style apps with
>> full REST URLs but using the Canvas API would be a huge win for many
>> people.
>
> I for one like this idea a lot.  Generating HTML and XML with the
> Canvas is one of the big draws of Seaside for me, as well as the
> support for Prototype / Scriptaculous and the like.  I also like the
> idea of having RESTful and non-RESTful applications coexisting on the
> same Seaside server.
>
> Philippe: having active projects supporting the framework is a
> chicken-and-egg problem.  If it's difficult to do REST in Seaside,
> then users seeking to do REST projects will use Rails instead; if
> there's an option to do so, however primitive, some of them may stay
> and support the development.  I would think that the intersection of
> web developers interested in REST and those interested in Seaside is
> non-empty.