Hi guys, I wanted to get some feedback on an idea I've been toying with regarding the Cache & SessionStorage. I've been working on prototyping the changes and while it's only partially complete I thought it best to get feedback now, since I missed the API freeze for 1.3. There's some overlap between the Cache & SessionStorage which means currently it's not a DRY as it could or should be and there's a new templating engine coming that would benefit from using many of the backend providers that currently exist in some form under the Cache & SessionStorage wrappers. As more interesting providers become available - we have a MongoDB provider in the pipe from gregoire, I have a couchDB, memcached, XMLStorage, gearman, cloudFiles providers - it would be handy to expose these to the SF framework for general use. The generic interface for the providers would be simple but strightforward - essentially crud and would allow access to the underlying provider (ie you would be able to obtain a reference to the memcache instance) but specific providers would extend the interface with relevant methods. It would also be an opportune time to harmonize the options used to configure each of StorageEngines to lend a little more consistency to how they are setup. Additionally with the proposed approach it would allow a simpler yml interface - allowing you to define a bunch of storage engines and use these configured instances accordingly on the cache or session in the config. This would also allow some of the existing SessionStorage providers to be collapsed down to a simpler implementation (there's some overlap between the database providers that can be simplified). Proposed Solution: Extract storage engines from both Cache & SessionStorage. Move SessionStorage into Sessions and use Storage for StorageEngines/Providers. Harmonize the config options to achieve a consistent config Update both Cache and Sessions to use the StorageEngines/Providers Collapse down the various database providers into one SessionStorage Update autoloader & FactoryConfigHandler with the changes Potential Issues: BC - there might be some issues with backwards compatibility. Mostly around the config options - generally code will be loaded via the autoloader rather than people accessing the folder/class Performance - the approach will introduce extra function calls which could impact performance Thanks for reading - take a moment to read it through again - and I look forward to hearing your thoughts, Regards, David |
- [symfony-devs] propel behaviors - question about 'symfon... arri...@gmail.com
- [symfony-devs] Re: propel behaviors - question abou... arri...@gmail.com
- [symfony-devs] Re: propel behaviors - question ... arri...@gmail.com
- [symfony-devs] Cache, Sessions and storage david