Hi all, Sorry for joining in late. I had participated in GSoC last year with TurboGears and I am interesting the having another fun filled learning experience with the TurboGears team once again. I had a discussion on GSoC 2009 project with Chris Perkins already. He have me some ideas for this years GSoC. I have done a little research on them. Here are short outlines of the proposals I have come up with. Detailed proposals with milestones and timelines will be posted after deciding on the project.
TG2 / Pylons CouchDB Backend ================== The idea is to create a new backend to support storing and retrieval of documents in CouchDB. This would basically involve adding extra configuration parameters for couchdb in development.ini / deployment.ini and setting up the server / db instances in tg.configuration.py. These server / db instances would be made available to the project.model.__init__.py for use in the couchdb model classes. Christopher Lenz's python-couchdb library could be used. One issue with couchdb ATM is that authentication is not supported. So SA should be included in all apps that require authentication till the time other repoze.who authentication backends are made available. Also, including SA would help in storing non-document oriented / traditional objects in a relational db. CouchDB has a RestFul web interface so it could very well be used on the client side (in-browser javascript) only, where all requests for document retrieval and manipulation are made directly to the database. But integrating it with a web framework may have certain advantages such as, integration with the auth & auth system provided by the framework, making use of other WSGI middleware along with the documents (possibly filtering / modifying them on the way), using it in conjunction with other relational objects stored in an RDBMS, etc. There is already some work going on in using couchdb to store geospatial data (http://vmx.cx/cgi-bin/blog/index.cgi/category/CouchDB). tgext.geo could also be enhanced to support couchdb. python-couchdb already has decent coverage. More unittests would be added as required in the form of patches. The glue code in tg2 / pylons codebase would be covered 100% by unittests. The detailed proposal with milestones and timeline would be prepared and posted to socghop app if the idea is accepted. Improving tgext.geo ============ The tgext.geo project was developed as part of GSoC 2008 Toscawidgets project. As of now tgext.geo integrates Mapfish server and Tilecache into tg2. Mapfish is used for providing a restful web interface to geospatial data stored in a PostGIS backend and Tilecache is used to cache and serve map tiles. While these two applications could address a large number of geographic applications, there are areas where tgext.geo needs to improve to compete with other mainstream geospatial web frameworks like geodjango. Geodgango extends the django ORM to support geospatial data objects. ATM SQLAlchemy does not support geospatial databases like PostGIS, SQLiteSpatial or MysqlSpatial. A separate project could extend SQLAlchemy to add support for these spatial databases. FeatureServer is another interesting python application meant for serving geographic objects. Featureserver could be integrated with tg2 as a wsgi app. FeatureServer uses the FeatureServer.DataSource module for storing geospatial objects. The various supported DataSources are PostGIS, SQLite, WFS, OGR, etc. A DataSource for SQLAlchemy GIS Extension could be added so that the backend database could be integrated with the TG2 framework cleanly. By integrating FeatureServer with the tg2 we could have a geospatial web framework with all the goodies provided by TG2 like auth & auth, transactions, multiple databases, toscawidgets and indeed all the other wsgi middleware components. Care will be taken to have 100% unittest coverage of the SA GIS Extension. TG2 Featureserver integration would also be tested using functional tests. Documentation would be delivered as tutorials and api docs. Documentation on getting up and running with gis infrastructure (e.g. setting up postgis, getting sample gis data, etc.) would be delivered. Improving Sprox ========== Sprox, a model based automated widget generation framework is a much improved reincarnation of DBSprockets. It would be a nice project to work on enhancing Sprox's capabilities. Sprox already supports plain html and dojo based widget generation. It could be improved by including many more dojo based widgets. This could include various formfields (e.g. Textfields, Autocomplete Fields, Combo Box Fields, Rich Text Editor Fields, Single and Multiple Select fields, date and time selector fields, number spinner etc.) based on hints provided by the config. A major part of the work will also go into developing toscawidgets for these widget types under tw.dojo. Sprox already has 100% coverage. All new code added will also have unittests for 100% coverage. The already excellent documentation of Sprox will be improved with api docs and tutorials for all new features added. What do others think about these ideas? Should I add them to the ideas page so that others may propose on them too? regards Sanjiv --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~----------~----~----~----~------~----~------~--~---
