Services/Sync/Server/DesignNotes: Difference between revisions

Jump to navigation Jump to search
no edit summary
(Created page with '= Overview of used tools = * Apache * mod_wsgi 3.2 * Python 2.6.x * Paste 1.7.4 * PasteScript 1.7.3 * PasteDeploy 1.3.3 * SQLAlchemy 0.6.2 * MySQL-Python 1.2.3c1 * python-ldap 2…')
 
No edit summary
 
Line 99: Line 99:
]
]


=== Work in progress ===
* abstract layer : http://bitbucket.org/tarek/python-weave-server/src/tip/weave/server/storage/__init__.py
* sql backend : http://bitbucket.org/tarek/python-weave-server/src/tip/weave/server/storage/sql.py


== Server : apache + mod_wsgi ==
== Server : apache + mod_wsgi ==
Line 141: Line 137:


[I think we can make an abstract interface similar to the data store, something that fetches/stores user information, with ldap as one implementation of that abstraction -- Ian]
[I think we can make an abstract interface similar to the data store, something that fetches/stores user information, with ldap as one implementation of that abstraction -- Ian]
= Roadmap =
# create a Distutils-based Paster-based application. [ian]
# get an production-like-ish environment to play with in a VM [tarek]
# create an abstract storage + sql backend [tarek]
# implement the storage API w/ webob + routes [tarek]
# ...
= Open Questions =
== Release process ==
How do we release/deploy the python server ? Since RHEL
is used in production one option could be to generate
a RPM from the Python project.
[I think an RPM for the application itself isn't a particularly good workflow.  For instance, we might want to do an upgrade by putting the new code into place and touching the .wsgi file or sending a signal to Apache, at which point it would switch over to the new code without interruption.  That requires multiple versions of the application to be installed at one time (in different directories).  -- Ian]
[I'll launch a thread with Zandr and Jeff Balogh. It'll be good to discuss this. zc.buildout could also be a way to deploy things -- Tarek ]
== Sharing ==
Do we want to add at some point sharing capabilities, and
how this will impact with the current architecture ?
In any case, I think the best approach would be to implement
a Python version that works exactly like the current PHP
version in a first step, then make it evolve.
Confirmed users
927

edits

Navigation menu