Re: [Repoze-dev] BFG and GAE

2010-05-06 Thread Fernando Correa Neto
Hey

On Thu, May 6, 2010 at 9:43 AM, Tres Seaver tsea...@palladion.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Chris McDonough wrote:
  On Thu, 2010-05-06 at 08:30 -0400, Tres Seaver wrote:
 
  To ask for another $AU .25:  can somebody point to the currently-best
  docs on doing BFG on GAE?  There are a number of somewhat-contractictory
  writeups out in the wild, which leads to some confusion when folks want
  to try it out:  I talked to a user at the D.C. ZPUG the other night who
  was intereested in evaluating it, but couldn't figure out what was
  supposed to work, and how.
 
  AFAIK, this is 100% correct:
 
 
 http://docs.repoze.org/bfg/1.2/tutorials/gae/index.html#appengine-tutorial


 That procedure might work, but it relies on appengine-monkey, which was
 a big fat warning plastered across its homepage[1]:


It may work 100% correct on the first time only though.
While playing with it, I tried to create another bfg on gae project and
for my surprise it didn't work because appengine-monkey patched my system's
python distutils putting a hardcoded value for [install] in my distutils.cfg
(which happens to be installed in my $HOME/bin).

With that said, I believe appengine-monkey is not the best way to get BFG on
GAE and it would be better if people that have a sane process of achieving
this tried to document and hopefully advertise that approach.

Cheers,
-Fernando
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev


Re: [Repoze-dev] BFG and GAE

2010-05-06 Thread Chris McDonough
On Thu, 2010-05-06 at 11:08 -0300, Fernando Correa Neto wrote:

 It may work 100% correct on the first time only though.
 While playing with it, I tried to create another bfg on gae project
 and for my surprise it didn't work because appengine-monkey patched my
 system's python distutils putting a hardcoded value for [install] in
 my distutils.cfg (which happens to be installed in my $HOME/bin).
 
 
 With that said, I believe appengine-monkey is not the best way to get
 BFG on GAE and it would be better if people that have a sane process
 of achieving this tried to document and hopefully advertise that
 approach.

No disagreement here.  When I say it's the best way, I mean it's a way
that is documented and that is known to work.  If there's another better
way that is also documented and works, we should use that.  Would you be
willing to take on the task of figuring out what that is and documenting
it ala the existing tutorial.

- C




___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev


Re: [Repoze-dev] BFG and GAE

2010-05-06 Thread Alex Clark
On 2010-05-05, Charlie Clark charlie.cl...@clark-consulting.eu wrote:
 Am 05.05.2010, 17:10 Uhr, schrieb Alex Clark acl...@aclark.net:

 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.

 Please forgive the ignorance but is actually cool about those two sites?

Heh, just that you can knock together scalable toy apps for fun. In the
case of philikon's http://i-luuv.appspot.com/ he used WebOb and some
HTML5 IIRC, and davisagli appears to have used straight Python:
http://pypi.python.org/pypi/buildout.threatlevel

 Charlie

-- 
Alex Clark · http://aclark.net
Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev


[Repoze-dev] BFG and GAE

2010-05-05 Thread Alex Clark
Hi all,

I am just going to blurt this out because I am thinking about it. At last 
night's
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'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.

2cents,

Thanks for reading,

Alex

-- 
Alex Clark · http://aclark.net
Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev


Re: [Repoze-dev] BFG and GAE

2010-05-05 Thread Chris McDonough
On Wed, 2010-05-05 at 15:10 +, Alex Clark wrote:
 Hi all,
 
 I am just going to blurt this out because I am thinking about it. At last 
 night's
 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.

 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.

- C


___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev


Re: [Repoze-dev] BFG and GAE

2010-05-05 Thread Alex Clark
On 2010-05-05, Chris McDonough chr...@plope.com wrote:
 On Wed, 2010-05-05 at 15:10 +, Alex Clark wrote:
 Hi all,
 
 I am just going to blurt this out because I am thinking about it. At last 
 night's
 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.

Alex


 - C


 ___
 Repoze-dev mailing list
 Repoze-dev@lists.repoze.org
 http://lists.repoze.org/listinfo/repoze-dev


-- 
Alex Clark · http://aclark.net
Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev


Re: [Repoze-dev] BFG and GAE

2010-05-05 Thread Charlie Clark
Am 05.05.2010, 17:10 Uhr, schrieb Alex Clark acl...@aclark.net:

 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.

Please forgive the ignorance but is actually cool about those two sites?

Charlie
-- 
Charlie Clark
Managing Director
Clark Consulting  Research
German Office
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev


Re: [Repoze-dev] BFG and GAE

2010-05-05 Thread Tim Hoffman
Hi All

We (KT Studio), have a fairly significant site based on BFG (pre 1.1)
running on app engine very successfully. (www.polytechnic.wa.edu.au).
(We have other bfg based app engine apps in the pipeline). (Also about
to go live with a bobo, repoze.what and zope.component/zope.interface,
formish based app as an alternate stack)

Much of what Chris has said is spot on the mark, (though there are
emerging tools like TyphoonAE which provide
an alternate deployment to google for the app engine api).  In fact
appengine should really be thought of as an API and collection of
services that you build your application too.

We see a huge advantage in app engine if you can deal with the
restrictions of the platform because it
does remove a major area of support requirements (namely the OS,
scaling, failover and the app stack (web server, rdbms etc)).

The main things I find I have to do when building is removing things
we don't use, (paste scripts don't help much, therefor no ini files
etc.., ) , Which really means just hooking  bfg up with the wsgi
handler.

I personally think bfg offers some big advantages over Django on
appengine, though you probably have to do a little more work in some
areas, but there seems to be a bit of an impedance mis-match between
Django its ORM and App Engine.

Where as bfg just gets out of the way, but does what it does well.
Also not tying forms directly to the model is a good thing.
I really have not found myself trying to work around things in
appengine.  (Especially now we can do configuration directly in
python).

Just my 2c ;-)

T



On Thu, May 6, 2010 at 1:13 AM, Charlie Clark
charlie.cl...@clark-consulting.eu wrote:
 Am 05.05.2010, 17:10 Uhr, schrieb Alex Clark acl...@aclark.net:

 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.

 Please forgive the ignorance but is actually cool about those two sites?

 Charlie
 --
 Charlie Clark
 Managing Director
 Clark Consulting  Research
 German Office
 Helmholtzstr. 20
 Düsseldorf
 D- 40215
 Tel: +49-211-600-3657
 Mobile: +49-178-782-6226
 ___
 Repoze-dev mailing list
 Repoze-dev@lists.repoze.org
 http://lists.repoze.org/listinfo/repoze-dev

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev