Re: PHP 6.0 Wishlist
| From: | Marc Richards | Date: | Sun, 14 Aug 2005 20:59:07 +0000 |
| Subject: | Re: PHP 6.0 Wishlist | ||
| References: | 1 2 3 4 5 6 7 8 9 10 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-18078@lists.php.net to get a copy of this message | ||
Marc Richards wrote:
Rasmus Lerdorf wrote:Oops. Hit send a little early. Just to clarify, the value of adding this extra layer of complexity would be that developers could write apps that persitently store and retrieve data at an application level without worrying about portability. It would then be up to the server admin to choose the appropriate backend based on their own requirements such as speed, platform, security, or multi-server configuration. I would envision it working in a manner very similar to how sessions work now, including the use of a user-configurable an APPLICATION_ID to prevent colisions. MarcJani Taskinen wrote:How about an implementation with multiple possible backends ala session.save_handler? It could use "files" or "apc" by default, or optionally use something like "mm", "msession" or "mysql" depending on the user's needs. MarcOn Sun, 14 Aug 2005, Ilia Alshanetsky wrote:I am confused. What are you proposing here? That we write a multi-server memory-based datastore? That's a project in itself and quite beyond the scope of PHP. It would seem to me like a replicated database setup with decent query caching solves this problem nicely. -RasmusIf apc comes bundled then it includes apc_store() and apc_fetch() this is pretty much $_MEMORY with a few tweaks.Yes, but that is restricted to one server installations. I need such a 'global session' that is available with multiple front-end servers..ie. using DB as session storage.