Zope3 on Google AppEngine
Hi, Next week Lovely will be sprinting in New York/San Francisco to get the Zope3 framework and the first applications running on Google AppEngine. You’re welcome to join us. Google AppEngine is a perfect match to the transition we at Lovely Systems made during the last 12 month in “stealth mode”. We’re using heavily WSGI and are replacing ZODB within most of our applications. Tomorrow we’re leaving to New York visiting our friend reco. dobee and I will be working on getting the component architecture running on AppEngine. Later next week we’ll fly to San Francisco to attend Google I/O and get even more insight to the technology. We’re open to release lovely.nozodb and the related components in near future, as usual - just some polishing missing… Please drop me a note (jodok@lovelysystems.com, batlogg on skype/AIM) or give me a call (+43 664 9636963) if you want to join us. jodok -- Lovely Systems, Partner phone: +43 5572 908060, fax: +43 5572 908060-77 Schmelzhütterstraße 26a, 6850 Dornbirn, Austria
Hi Jodok. Sounds interesting. Curious what you are replacing ZODB with. Are you using its interfaces to Relstorage / other ZODB backend, an ORM to map direct to rdb, or other database. Many thanks. Regards, David Jodok Batlogg wrote:
Hi,
Next week Lovely will be sprinting in New York/San Francisco to get the Zope3 framework and the first applications running on Google AppEngine. You’re welcome to join us. Google AppEngine is a perfect match to the transition we at Lovely Systems made during the last 12 month in “stealth mode”. We’re using heavily WSGI and are replacing ZODB within most of our applications. Tomorrow we’re leaving to New York visiting our friend reco. dobee and I will be working on getting the component architecture running on AppEngine. Later next week we’ll fly to San Francisco to attend Google I/O and get even more insight to the technology. We’re open to release lovely.nozodb and the related components in near future, as usual - just some polishing missing… Please drop me a note (jodok@lovelysystems.com, batlogg on skype/AIM) or give me a call (+43 664 9636963) if you want to join us.
jodok -- Lovely Systems, Partner
phone: +43 5572 908060, fax: +43 5572 908060-77 Schmelzhütterstraße 26a, 6850 Dornbirn, Austria
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists -http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
On Thu, May 22, 2008 at 4:53 PM, David Pratt <fairwinds@eastlink.ca> wrote:
Hi Jodok. Sounds interesting. Curious what you are replacing ZODB with. Are you using its interfaces to Relstorage / other ZODB backend, an ORM to map direct to rdb, or other database. Many thanks.
right now we're using storm. for the application we plan to port first it seems like bigtable fits perfect. during the next week we won't focus on the storage layer, but more on getting the C-based things running. the other part - lovely.nozodb (zope3 without zodb, utility registrations,...) is almost done and just needs some polishing. jodok
Regards, David
Jodok Batlogg wrote:
Hi,
Next week Lovely will be sprinting in New York/San Francisco to get the Zope3 framework and the first applications running on Google AppEngine. You're welcome to join us. Google AppEngine is a perfect match to the transition we at Lovely Systems made during the last 12 month in "stealth mode". We're using heavily WSGI and are replacing ZODB within most of our applications. Tomorrow we're leaving to New York visiting our friend reco. dobee and I will be working on getting the component architecture running on AppEngine. Later next week we'll fly to San Francisco to attend Google I/O and get even more insight to the technology. We're open to release lovely.nozodb and the related components in near future, as usual - just some polishing missing… Please drop me a note (jodok@lovelysystems.com, batlogg on skype/AIM) or give me a call (+43 664 9636963) if you want to join us.
jodok -- Lovely Systems, Partner
phone: +43 5572 908060, fax: +43 5572 908060-77 Schmelzhütterstraße 26a, 6850 Dornbirn, Austria
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists -http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Hello Jodok, Please contact Georgy Berdyshev (codingmaster at gmail.com) who has "Zope on Jython" as a GSOC project. I think your interests about the C modules could be quite close. Thursday, May 22, 2008, 10:53:33 PM, you wrote: JB> On Thu, May 22, 2008 at 4:53 PM, David Pratt <fairwinds@eastlink.ca> wrote:
Hi Jodok. Sounds interesting. Curious what you are replacing ZODB with. Are you using its interfaces to Relstorage / other ZODB backend, an ORM to map direct to rdb, or other database. Many thanks.
JB> right now we're using storm. JB> for the application we plan to port first it seems like bigtable fits perfect. JB> during the next week we won't focus on the storage layer, but more on JB> getting the C-based things running. JB> the other part - lovely.nozodb (zope3 without zodb, utility JB> registrations,...) is almost done and just needs some polishing. JB> jodok
Regards, David
Jodok Batlogg wrote:
Hi,
Next week Lovely will be sprinting in New York/San Francisco to get the Zope3 framework and the first applications running on Google AppEngine. You're welcome to join us. Google AppEngine is a perfect match to the transition we at Lovely Systems made during the last 12 month in "stealth mode". We're using heavily WSGI and are replacing ZODB within most of our applications. Tomorrow we're leaving to New York visiting our friend reco. dobee and I will be working on getting the component architecture running on AppEngine. Later next week we'll fly to San Francisco to attend Google I/O and get even more insight to the technology. We're open to release lovely.nozodb and the related components in near future, as usual - just some polishing missing… Please drop me a note (jodok@lovelysystems.com, batlogg on skype/AIM) or give me a call (+43 664 9636963) if you want to join us.
jodok -- Lovely Systems, Partner
phone: +43 5572 908060, fax: +43 5572 908060-77 Schmelzhütterstraße 26a, 6850 Dornbirn, Austria
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists -http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
-- Best regards, Adam GROSZER mailto:agroszer@gmail.com -- Quote of the day: Designed with your mind in mind by people who have in mind what you should have in mind.
Hi Jodok. I had looked at storm a while back but the zope integration seemed to lack any relationship with zope schemas. I guess it is possible to define a zope schema that is not persisted and create the tables from it. It did not seem to me a good way of using CA. How are you managing this part of things. I Haven't worked with bigtable yet myself but assume the transactional semantics would be a challenge since I am not sure how quickly the data gets to the storage. This is interesting stuff in any case. Regards, David Jodok Batlogg wrote:
On Thu, May 22, 2008 at 4:53 PM, David Pratt <fairwinds@eastlink.ca> wrote:
Hi Jodok. Sounds interesting. Curious what you are replacing ZODB with. Are you using its interfaces to Relstorage / other ZODB backend, an ORM to map direct to rdb, or other database. Many thanks.
right now we're using storm. for the application we plan to port first it seems like bigtable fits perfect. during the next week we won't focus on the storage layer, but more on getting the C-based things running. the other part - lovely.nozodb (zope3 without zodb, utility registrations,...) is almost done and just needs some polishing.
jodok
Regards, David
Jodok Batlogg wrote:
Hi,
Next week Lovely will be sprinting in New York/San Francisco to get the Zope3 framework and the first applications running on Google AppEngine. You're welcome to join us. Google AppEngine is a perfect match to the transition we at Lovely Systems made during the last 12 month in "stealth mode". We're using heavily WSGI and are replacing ZODB within most of our applications. Tomorrow we're leaving to New York visiting our friend reco. dobee and I will be working on getting the component architecture running on AppEngine. Later next week we'll fly to San Francisco to attend Google I/O and get even more insight to the technology. We're open to release lovely.nozodb and the related components in near future, as usual - just some polishing missing… Please drop me a note (jodok@lovelysystems.com, batlogg on skype/AIM) or give me a call (+43 664 9636963) if you want to join us.
jodok -- Lovely Systems, Partner
phone: +43 5572 908060, fax: +43 5572 908060-77 Schmelzhütterstraße 26a, 6850 Dornbirn, Austria
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists -http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
David Pratt wrote:
Hi Jodok. I had looked at storm a while back but the zope integration seemed to lack any relationship with zope schemas. I guess it is possible to define a zope schema that is not persisted and create the tables from it. It did not seem to me a good way of using CA. How are you managing this part of things.
fwiw, ore.alchemist and now z3c.dobbin integrates zope.interface and zope.schema with sqlalchemy, each taking a quite different approach. \malthe
Hi Malthe. z3c.dobbin looks quite good and transparent. In my opinion, this is much closer to what integration ought to look like for CA. BTW, I noticed that z3c.dobbin is zpl but ore.alchemist that it depends on is gpl. I think all the other zope flavors of sqlalchemy are under zpl. I believe there was a recent effort to bring the sqlalchemy flavors together under a single package. Not sure what progress has been made. In any case, this direction looks like a good one. It would be interesting if dobbin could map for storm but it appears to rely heavily upon ore.alchemist. I believe storms advantage is that it is faster than sqlalchemy since it doesn't have to worry about pooling connections, mappers, and more. I'd be interesting to see a similar approach with storm. Good job on this. Regards, David Malthe Borch wrote:
David Pratt wrote:
Hi Jodok. I had looked at storm a while back but the zope integration seemed to lack any relationship with zope schemas. I guess it is possible to define a zope schema that is not persisted and create the tables from it. It did not seem to me a good way of using CA. How are you managing this part of things.
fwiw, ore.alchemist and now z3c.dobbin integrates zope.interface and zope.schema with sqlalchemy, each taking a quite different approach.
\malthe
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
David Pratt wrote:
Hi Malthe. z3c.dobbin looks quite good and transparent. In my opinion, this is much closer to what integration ought to look like for CA. BTW, I noticed that z3c.dobbin is zpl but ore.alchemist that it depends on is gpl. I think all the other zope flavors of sqlalchemy are under zpl. I believe there was a recent effort to bring the sqlalchemy flavors together under a single package. Not sure what progress has been made.
It's progressing, but we've also talked to Kapil about relicensing ore.alchemist to LGPL or ZPL, whichever is enough.
In any case, this direction looks like a good one. It would be interesting if dobbin could map for storm but it appears to rely heavily upon ore.alchemist.
I think it's more accurate to say that both rely heavily on SQLAlchemy. We're actually not using the table reflection functionality of ore.alchemist because we've taken a different approach to it (joining on minimal interfaces rather than mapping classes to tables). What we are using is some of the zope.schema to sqlalchemy.Column mappings and the database session environment.
I believe storms advantage is that it is faster than sqlalchemy since it doesn't have to worry about pooling connections, mappers, and more. I'd be interesting to see a similar approach with storm. Good job on this.
Thanks, I think we might've found a good approach. Currently we're test-driving it in the Vudo project. So far so good. I don't know much about storm; at this point I must say that I care more about ease of use, mindshare and stability than just speed; we feel that SQLAlchemy gives us that. Add to it that their community is absolutely great. \malthe
Hi Malthe. Perhaps I am wrong about the licensing situation. I guess its a bit confusing since pypi indicates GPL and package ZPL. I guess I should contact Kapil for clarification if I am interested in experimenting here. Many thanks. Regards, David name="ore.alchemist", version="0.5.1", url="http://code.google.com/p/zope-alchemist", install_requires=['setuptools', 'transaction'], packages=find_packages('src', exclude=["*.tests"]), package_dir= {'':'src'}, namespace_packages=['ore'], package_data = { '': ['*.txt', '*.zcml', '*.pt'], }, zip_safe=False, author='Kapil Thangavelu', author_email='kapil.foss@gmail.com', description="""\ ore.alchemist contains an integration of sqlalchemy into the Zope App server environment. It can be used with Zope2, Zope3 or standalone. """, license='ZPL', keywords="zope zope3", ) Malthe Borch wrote:
David Pratt wrote:
Hi Malthe. z3c.dobbin looks quite good and transparent. In my opinion, this is much closer to what integration ought to look like for CA. BTW, I noticed that z3c.dobbin is zpl but ore.alchemist that it depends on is gpl. I think all the other zope flavors of sqlalchemy are under zpl. I believe there was a recent effort to bring the sqlalchemy flavors together under a single package. Not sure what progress has been made.
It's progressing, but we've also talked to Kapil about relicensing ore.alchemist to LGPL or ZPL, whichever is enough.
In any case, this direction looks like a good one. It would be interesting if dobbin could map for storm but it appears to rely heavily upon ore.alchemist.
I think it's more accurate to say that both rely heavily on SQLAlchemy. We're actually not using the table reflection functionality of ore.alchemist because we've taken a different approach to it (joining on minimal interfaces rather than mapping classes to tables). What we are using is some of the zope.schema to sqlalchemy.Column mappings and the database session environment.
I believe storms advantage is that it is faster than sqlalchemy since it doesn't have to worry about pooling connections, mappers, and more. I'd be interesting to see a similar approach with storm. Good job on this.
Thanks, I think we might've found a good approach. Currently we're test-driving it in the Vudo project. So far so good.
I don't know much about storm; at this point I must say that I care more about ease of use, mindshare and stability than just speed; we feel that SQLAlchemy gives us that. Add to it that their community is absolutely great.
\malthe
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Hi Malthe. Kapil has confirmed the licensing is ZPL with a version bump to 0.5.2 with a change in the headers, etc. I am anxious to experiment with dobbin since it looks so straight forward and nice. I guess I see traversal and containers as possible issues but will be interested in potential solutions. Trails for grok is one possible solution for traversal but will be curious to see approaches for replacing containers. Regards David David Pratt wrote:
Hi Malthe. Perhaps I am wrong about the licensing situation. I guess its a bit confusing since pypi indicates GPL and package ZPL. I guess I should contact Kapil for clarification if I am interested in experimenting here. Many thanks.
Regards, David
name="ore.alchemist", version="0.5.1", url="http://code.google.com/p/zope-alchemist", install_requires=['setuptools', 'transaction'], packages=find_packages('src', exclude=["*.tests"]), package_dir= {'':'src'}, namespace_packages=['ore'], package_data = { '': ['*.txt', '*.zcml', '*.pt'], }, zip_safe=False, author='Kapil Thangavelu', author_email='kapil.foss@gmail.com', description="""\ ore.alchemist contains an integration of sqlalchemy into the Zope App server environment. It can be used with Zope2, Zope3 or standalone. """, license='ZPL', keywords="zope zope3", )
Malthe Borch wrote:
David Pratt wrote:
Hi Malthe. z3c.dobbin looks quite good and transparent. In my opinion, this is much closer to what integration ought to look like for CA. BTW, I noticed that z3c.dobbin is zpl but ore.alchemist that it depends on is gpl. I think all the other zope flavors of sqlalchemy are under zpl. I believe there was a recent effort to bring the sqlalchemy flavors together under a single package. Not sure what progress has been made.
It's progressing, but we've also talked to Kapil about relicensing ore.alchemist to LGPL or ZPL, whichever is enough.
In any case, this direction looks like a good one. It would be interesting if dobbin could map for storm but it appears to rely heavily upon ore.alchemist.
I think it's more accurate to say that both rely heavily on SQLAlchemy. We're actually not using the table reflection functionality of ore.alchemist because we've taken a different approach to it (joining on minimal interfaces rather than mapping classes to tables). What we are using is some of the zope.schema to sqlalchemy.Column mappings and the database session environment.
I believe storms advantage is that it is faster than sqlalchemy since it doesn't have to worry about pooling connections, mappers, and more. I'd be interesting to see a similar approach with storm. Good job on this.
Thanks, I think we might've found a good approach. Currently we're test-driving it in the Vudo project. So far so good.
I don't know much about storm; at this point I must say that I care more about ease of use, mindshare and stability than just speed; we feel that SQLAlchemy gives us that. Add to it that their community is absolutely great.
\malthe
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
David Pratt wrote:
Hi Malthe. Kapil has confirmed the licensing is ZPL with a version bump to 0.5.2 with a change in the headers, etc. I am anxious to experiment with dobbin since it looks so straight forward and nice. I guess I see traversal and containers as possible issues but will be interested in potential solutions. Trails for grok is one possible solution for traversal but will be curious to see approaches for replacing containers.
You're right on the mark here. We haven't yet experimented with traversing, and although it's reasonably trivial to implement it naïvely, thought could be put into coming up with a more efficient solution. Zope's traversing model is attractive, especially since inheritance plays such an important role. In a relational database, it's expensive, but if extensive traversing can be avoided, perhaps it's still reasonable. We're trying to put this matter a bit in the background right now, as there are other, more important tasks to look at first; but it's certainly something we need to decide on. At any rate, adding container-support to dobbin would be a great start. I had the idea of using the ``contains`` pragma from zope.app.publisher to spell out containment behavior. I think this fits well with the general declarative machinery in Zope. \malthe
Am Freitag, 23. Mai 2008 18:19 schrieb David Pratt:
Hi Jodok. I had looked at storm a while back but the zope integration seemed to lack any relationship with zope schemas. I guess it is possible to define a zope schema that is not persisted and create the tables from it. It did not seem to me a good way of using CA. How are you managing this part of things.
I Haven't worked with bigtable yet myself but assume the transactional semantics would be a challenge since I am not sure how quickly the data gets to the storage. This is interesting stuff in any case.
Very interesting, indeed. Does this mean that one can basically create classes that inherit from some class like persistent.Persistent and data is then simply stored in a RDB instead of ZODB? What I'm curious is how transactions are managed; I currently use SQLAlchemy, but it seems that transactions are managed on the RDB-level only, which means that the object state is not in the transaction scope. Another issue is data migration, which requires changes in the database model (altering tables etc.), so this might be also quite challenging. Best Regards, Hermann -- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
--On 24. Mai 2008 15:44:01 +0200 Hermann Himmelbauer <dusty@qwer.tk> wrote:
I currently use SQLAlchemy, but it seems that transactions are managed on the RDB-level only, which means that the object state is not in the transaction scope.
Huh? If you use one of the integration framework for sqlalchemy-within-zope then SQLAlchemy is fully integrated with the Zope transaction system. Andreas
Am Sonntag, 25. Mai 2008 13:32 schrieb Andreas Jung:
--On 24. Mai 2008 15:44:01 +0200 Hermann Himmelbauer <dusty@qwer.tk> wrote:
I currently use SQLAlchemy, but it seems that transactions are managed on the RDB-level only, which means that the object state is not in the transaction scope.
Huh? If you use one of the integration framework for sqlalchemy-within-zope then SQLAlchemy is fully integrated with the Zope transaction system.
In my application, I use zope.sqlalchemy and I load my objects from the database via SA. These objects have interfaces and are related to SA tables via mappers. If I now change such an SA object and do a transaction.abort(), a database rollback is issued, however, SA does not restore the object state. For common cases, this is no problem, as in my application, a transaction correlates with a HTTP request/response span, and if objects at the end of the operation are restored or not is of no interest (as data is stored in the database and the objects are discarded); what counts is that the database holds the right data. Nevertheless I have cases (e.g. in testing scenarios) where it makes sense to manually issue a transaction.abort(). In this case I have to reload the objects from the database in order to be consistent with the database. But maybe there's some magic class from an additional z3c package I can inherit my classes from, which solves this issue? Best Regards, Hermann -- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
Hermann Himmelbauer wrote:
Am Sonntag, 25. Mai 2008 13:32 schrieb Andreas Jung:
--On 24. Mai 2008 15:44:01 +0200 Hermann Himmelbauer <dusty@qwer.tk> wrote:
I currently use SQLAlchemy, but it seems that transactions are managed on the RDB-level only, which means that the object state is not in the transaction scope. Huh? If you use one of the integration framework for sqlalchemy-within-zope then SQLAlchemy is fully integrated with the Zope transaction system.
In my application, I use zope.sqlalchemy and I load my objects from the database via SA. These objects have interfaces and are related to SA tables via mappers. If I now change such an SA object and do a transaction.abort(), a database rollback is issued, however, SA does not restore the object state.
For common cases, this is no problem, as in my application, a transaction correlates with a HTTP request/response span, and if objects at the end of the operation are restored or not is of no interest (as data is stored in the database and the objects are discarded); what counts is that the database holds the right data.
Nevertheless I have cases (e.g. in testing scenarios) where it makes sense to manually issue a transaction.abort(). In this case I have to reload the objects from the database in order to be consistent with the database.
But maybe there's some magic class from an additional z3c package I can inherit my classes from, which solves this issue?
SQLAlchemy 0.5 has autoexpire support for this use case. It should mean that zope.sqlalchemy no longer has to do session.clear() on a savepoint rollback. Laurence
Hi jodok
Betreff: [Zope-dev] Zope3 on Google AppEngine
Hi,
Next week Lovely will be sprinting in New York/San Francisco to get the Zope3 framework and the first applications running on Google AppEngine. Youre welcome to join us. Google AppEngine is a perfect match to the transition we at Lovely Systems made during the last 12 month in stealth mode. Were using heavily WSGI and are replacing ZODB within most of our applications. Tomorrow were leaving to New York visiting our friend reco. dobee and I will be working on getting the component architecture running on AppEngine. Later next week well fly to San Francisco to attend Google I/O and get even more insight to the technology. Were open to release lovely.nozodb and the related components in near future, as usual - just some polishing missing Please drop me a note (jodok@lovelysystems.com, batlogg on skype/AIM) or give me a call (+43 664 9636963) if you want to join us.
Sounds very interesting. But take care, not every customer likes to have his data on such a share. Think about what could happen if google get a negative touch in the future. Probably you must be able to switch very fast from google to a none shared DB if customers become a bad feeling about it. But I guess that's another topic. Anyway, sounds really great! Regards Roger Ineichen
jodok -- Lovely Systems, Partner
phone: +43 5572 908060, fax: +43 5572 908060-77 Schmelzhütterstraße 26a, 6850 Dornbirn, Austria
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
On Thu, May 22, 2008 at 6:34 PM, Roger Ineichen <dev@projekt01.ch> wrote:
Hi jodok
Betreff: [Zope-dev] Zope3 on Google AppEngine
Hi,
Next week Lovely will be sprinting in New York/San Francisco to get the Zope3 framework and the first applications running on Google AppEngine. You're welcome to join us. Google AppEngine is a perfect match to the transition we at Lovely Systems made during the last 12 month in "stealth mode". We're using heavily WSGI and are replacing ZODB within most of our applications. Tomorrow we're leaving to New York visiting our friend reco. dobee and I will be working on getting the component architecture running on AppEngine. Later next week we'll fly to San Francisco to attend Google I/O and get even more insight to the technology. We're open to release lovely.nozodb and the related components in near future, as usual - just some polishing missing… Please drop me a note (jodok@lovelysystems.com, batlogg on skype/AIM) or give me a call (+43 664 9636963) if you want to join us.
Sounds very interesting. But take care, not every customer likes to have his data on such a share. Think about what could happen if google get a negative touch in the future. Probably you must be able to switch very fast from google to a none shared DB if customers become a bad feeling about it.
yes, you're right. i don't think any of our customers feels comfortable running his portal on AppEngine. But as our applications are utilizing multiple webservices (e.g. commenting, authentication,...) these webservices could be run on appengine. and yes again. unfortunately there is no open source / non-google DB application implementation so far. we keep this in mind. jodok
But I guess that's another topic. Anyway, sounds really great!
Regards Roger Ineichen
jodok -- Lovely Systems, Partner
phone: +43 5572 908060, fax: +43 5572 908060-77 Schmelzhütterstraße 26a, 6850 Dornbirn, Austria
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Jodok Batlogg wrote:
and yes again. unfortunately there is no open source / non-google DB application implementation so far. we keep this in mind.
There is http://hypertable.org, but of course that's not an application engine. \malthe
perhaps too late to help with the sprints, but i got zope3 running on app engine last week http://zope3.appspot.com and http://zope3.appspot.com/tests, and blogged about to http://blog.kapilt.com most of zope.app isn't useable due to persistence or containment and security proxies, but page templates and the publisher work. some fairly minor but pervasive changes (removing some deprecations/bbb code) were needed, and to have space (1000 file limit) to actually develop an application requires stripping the eggs of text and tests. i ended up using the publisher support in zope.publisher (3.5.1+) instead of ore.wsgiapp or lovely.nozodb as it presents a much more minimal dependency set. i'd like to see if i can get some form machinery going underneat the 1000 file limit, and publish a starter tarball for folks interested. i'm uncertain long term what's viable, as their were a number of changes needed, and how best to maintain them. if their suitable for upstream into the zope repository, or just done again for separate releases as gae variant of z3. cheers, kapil On 5/22/08, Jodok Batlogg <jodok@lovelysystems.com> wrote:
Hi,
Next week Lovely will be sprinting in New York/San Francisco to get the Zope3 framework and the first applications running on Google AppEngine. You're welcome to join us. Google AppEngine is a perfect match to the transition we at Lovely Systems made during the last 12 month in "stealth mode". We're using heavily WSGI and are replacing ZODB within most of our applications. Tomorrow we're leaving to New York visiting our friend reco. dobee and I will be working on getting the component architecture running on AppEngine. Later next week we'll fly to San Francisco to attend Google I/O and get even more insight to the technology. We're open to release lovely.nozodb and the related components in near future, as usual - just some polishing missing… Please drop me a note (jodok@lovelysystems.com, batlogg on skype/AIM) or give me a call (+43 664 9636963) if you want to join us.
jodok -- Lovely Systems, Partner
phone: +43 5572 908060, fax: +43 5572 908060-77 Schmelzhütterstraße 26a, 6850 Dornbirn, Austria _
Interesting post. I am still not sure to what level I'll look to Google for app infrastructure. Seems to me there are too many restrictions on what you'd really be able to deploy and then you're stuck with married to what they've got for better or worse. On the other hand, Stripping zope to the minimum has certainly been an eye opener and certainly beneficial to get to a bare bones idea of what you could run with (with or without Google) though. Many thanks for sharing your efforts on this. Regards, David Kapil Thangavelu wrote:
perhaps too late to help with the sprints, but i got zope3 running on app engine last week http://zope3.appspot.com and http://zope3.appspot.com/tests, and blogged about to http://blog.kapilt.com
most of zope.app isn't useable due to persistence or containment and security proxies, but page templates and the publisher work. some fairly minor but pervasive changes (removing some deprecations/bbb code) were needed, and to have space (1000 file limit) to actually develop an application requires stripping the eggs of text and tests. i ended up using the publisher support in zope.publisher (3.5.1+) instead of ore.wsgiapp or lovely.nozodb as it presents a much more minimal dependency set.
i'd like to see if i can get some form machinery going underneat the 1000 file limit, and publish a starter tarball for folks interested.
i'm uncertain long term what's viable, as their were a number of changes needed, and how best to maintain them. if their suitable for upstream into the zope repository, or just done again for separate releases as gae variant of z3.
cheers,
kapil
On 5/22/08, Jodok Batlogg <jodok@lovelysystems.com> wrote:
Hi,
Next week Lovely will be sprinting in New York/San Francisco to get the Zope3 framework and the first applications running on Google AppEngine. You're welcome to join us. Google AppEngine is a perfect match to the transition we at Lovely Systems made during the last 12 month in "stealth mode". We're using heavily WSGI and are replacing ZODB within most of our applications. Tomorrow we're leaving to New York visiting our friend reco. dobee and I will be working on getting the component architecture running on AppEngine. Later next week we'll fly to San Francisco to attend Google I/O and get even more insight to the technology. We're open to release lovely.nozodb and the related components in near future, as usual - just some polishing missing… Please drop me a note (jodok@lovelysystems.com, batlogg on skype/AIM) or give me a call (+43 664 9636963) if you want to join us.
jodok -- Lovely Systems, Partner
phone: +43 5572 908060, fax: +43 5572 908060-77 Schmelzhütterstraße 26a, 6850 Dornbirn, Austria _
Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
participants (9)
-
Adam GROSZER -
Andreas Jung -
David Pratt -
Hermann Himmelbauer -
Jodok Batlogg -
Kapil Thangavelu -
Laurence Rowe -
Malthe Borch -
Roger Ineichen