On 2010-05-05, Chris McDonough <chr...@plope.com> wrote:
> On Wed, 2010-05-05 at 15:10 +0000, Alex Clark wrote:
>> Hi all,
>> I am just going to blurt this out because I am thinking about it. At last
>> Python Meetup Tres mentioned something about their being various ways to use
>> BFG on GAE… which makes me wonder: what would it take to get GAE support
>> from the "top down"?
> I assume by "top down", you mean "the principals of BFG consider it a
> preferred deployment platform".
Right, really I just meant "implemented by the core devs" vs. "contributed"
but close enough. I hadn't even thought about whether BFG would have to
compromise its principals to run on GAE… and I assume that it wouldn't.
>> I'm sure I already know the answer (well, I'll guess anyway): there is
>> no immediate Agendaless (or any other big BFG shop) customer need for it,
>> so it's not going to happen until there is.
>> Fair enough (we all know/understand how that works).
>> Which brings me to an actual question: is "marketing" BFG on GAE even
>> desirable by the community? In other words, is making it work on
>> a platform that has wide-spread adoption like GAE (I assume it has
>> widespread adoption) something folks are interested in as a way to
>> spread the word and inject new developers/users into the project?
>> Or am I just blinded by shiny toys too much.
>> I suspect the latter ;-)
>> However I'll mention I see guys like philikon (http://i-luuv.appspot.com)
>> and davisagli (http://buildthreat.appspot.com/) building "cool apps" on GAE
>> and I can't help but wonder what it would be like if the BFG/GAE story was
>> complete and in place.
> I consider it useful for BFG to run on the widest variety of platforms
> possible. It should run within reason on an arbitrary system
> independent of Python version (2.4, 2.5, 2.6, 2.7.. although not 3.X
> yet), Python implementation (CPython/GAE/Jython... and untested but
> hopefully IronPython), and operating system (UNIX/Windows/GAE).
> This is both a practical and a marketing issue. On the practical side,
> being able to use the tool in many contexts is useful (e.g. alongside
> Plone 3 in a Python 2.4 deployment, or on GAE for a simple app). On the
> marketing side, we have spikes in interest and we gain new users
> whenever we put BFG into one of these contexts (e.g. a blog entry "BFG
> on Jython", or "BFG on GAE" etc).
> So to the extent that it helps market BFG, I'm all for better GAE
> support, and I would *love* to see people blog about putting BFG apps on
> GAE and other alternate platforms. There's only a single caveat: adding
> support for one platform cannot detract from the portability of BFG onto
> other platforms. Other than that, I'd love to see add-ons for BigTable
> bindings, authentication, etc that targeted GAE specifically, as well as
> IronPython, Jython, etc.
> Wrt GAE specifically, from a personal perspective, I like the idea of
> its easy deployment, but the kinds of work Agendaless does doesn't
> really lend itself to deployment on GAE due to limitations of the
> platform. So business-wise it will probably not become a preferred
> deployment platform for *Agendaless*. As a result, it will really need
> to be someone else who takes up the mantle of making BFG "better" on
> GAE. That said, this isn't an "I don't care", this is an "I care, but
> someone else is going to have to care more".
Right, this all makes sense, thanks.
As far as limitations of the platform goes, is this a "cloud computing"
vs. "traditional model" issue? Or is it a GAE-specific thing. I suspect
the latter because it seems any framework that runs on their (GAE's)
platform has to bend itself to fit.
Whereas something like Ian's Silver Lining (which also excites me)
might make a better "cloud deployment story" for BFG.
> - C
> Repoze-dev mailing list
Alex Clark · http://aclark.net
Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin
Repoze-dev mailing list