[Seaside] rails niceties equivalents?

Fri May 15 22:16:52 UTC 2009

I was confident but this clarifications adds the sense of hope for the project.
It's perfectly natural for a grown project to have people available to push
things.
I mean, you can contract Thomas Fuchs in the very scriptaculous page.
What stop us to see what seaside ninjas (Julian et al.) we can contract if we
need to in the seaside very page?
sebastian

> -----Mensaje original-----
> De: seaside-bounces at lists.squeakfoundation.org 
> [mailto:seaside-bounces at lists.squeakfoundation.org] 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 
> <eagleoffshore at mac.com> 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
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside