Hello all, I already send some infromations about my plans of using a IoC container for GData Server which adds some features to the whole system and removes some testing and development pain. Here comes a list of new implementations and refactorings:
1. Adding binary webservice support I did implement a generic solution for the hessian webservice protocol to enable users to expose almost every interface which exist inside the server as a webservice. this aims also to replication of stateful data like login tokens within a cluster or administration features like adding feeds or accounts. The current REST approach like Solr uses will remain but be refactored (see below). 2. Dependency Injection for the core classes Currently there is a Registry holding references to the "modules" and their services configured in the server config. These services are created at server startup and can be looked up by other parts of the application. This creates a strong dependency on the Registry overall the classes and causes some pain in tests. So I wanna remove this registry completely and create dependencies via setter methods controlled by the IoC container. The default container will be apache hivemind but using pico, spring or whatever is still possible. (little metadata overhead ;) I guess I have to touch a lot of classes so there will be a lot of commits due to that. 3. Default stable persistence layer I have to work on the persitence layer an will remove the lucene based persistence which is not a database as we all know. I suffer from performance problems due to the extensive io. This is not what lucene has to deal with in my eyes. Currently there is a DB4O impl. which is more or less a hack due to the short amount of time I had within SoC, so this will be refactored by creating a clean DAO layer behind the storage facade.Other persistence layers can still be implemented. 4. Refactoring of the REST admin func. Currently there is a mix of patterns used for handling the requests wich is not a good idea so I will pick up the solr approach of different render classes creating the output and little requesthandlers talking to the API and the storage. calling a renderer to create the output. Providing this functionality only via webservices is not a good idea as you always have problems with different languages. If someone wants to expose a admin interface via WS it is just a single line in the hivemind descriptor. 5. Admin application as soon as all these stuff is done (that could take a while as I have to study) I will create the admin application either as a extra webapp or included in the server. In the second case this will be plugable. No deeper thoughts about that so far. Any suggestions and / or ideas are highly appreciated. best regards Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
