Re: uploadprogress extension

> The tricky part here isn't really the extension part that catches the > hooks, but the server-side storage tie-in. You already mentioned > possible support for memcached, and I added support for shared memory > storage to APC a while back. The question then becomes whether each > storage extension gets their own rfc1867 hooks, or we have a single mega > extension that knows how to talk to every storage mechanism? That is, > would pecl/uploadprogress eventually speak memcached, mysql, oci8, > pgsql, mssql, firebird, frontbase, informix, odbc, ingres, etc? Yeah, I thought about that too and making an uber-extension is certainly the wrong way to go :) I didn't think very thoroughly about that, I wanted to track that down when I start with the memcached stuff :) But if anyone has a decent idea right now, go ahead. And your approach with exposing a known interface to the datastore extensions seem a good way too me. chregu > > That seems like a nightmare to me. But by the same token, having each > of these extensions implement their own hooks which may not be > compatible would also be a mess. I think we need a single way to > trigger the upload, and we need a consistent dataset we store in the > backend so these things will be interchangeable. > > Have a look at: > > > http://cvs.php.net/viewvc.cgi/pecl/apc/apc_rfc1867.c?revision=HEAD&view=markup > > > And > > http://progphp.com/progress.php > http://progphp.com/progress.phps > > for a working implementation. > > Perhaps what we need is a combination. A single extension that catches > the hooks, but then the actual datastore part is handled by the > individual datastore extensions by exposing some known interface > specifically for doing this? > > -Rasmus -- christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich phone +41 44 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71 http://www.bitflux.ch | christian.stocker@bitflux.ch | GPG 0x5CE1DECB