Hi Davey, You hit on a couple of issues here. First of all re: design and implementation. This is exactly why we have a proposal process. It is an opportunity for others in the community to provide valuable feedback like you are doing and work with the proposal leads to figure out whether it makes sense to tweak the proposals. Of course there will not always be agreement but it's the right process and I believe overall the results have been acceptable. Btw, make sure to also paste your comments to the Wiki because that's where the discussion gets recorded for reference.
Re: the direction of the "concrete" Web services. This has been one of the big goals of framework from day 1. While I agree most of them (if not all) can be done using other generic interfaces I believe there is a lot of value in delivering them. This is not real bloat as you don't have to load it and I am convinced we can generate a lot of interest from third party vendors who would contribute such connectors (I've already gotten a lot of interest in fact). I definitely plan on continuing to pursue this and I don't think it will significantly lessen the value of generic interfaces. Andi > -----Original Message----- > From: Davey Shafik [mailto:[EMAIL PROTECTED] > Sent: Monday, May 07, 2007 10:15 AM > To: Andi Gutmans > Cc: Stas Malyshev; James Andrews; Zend Framework > Subject: Re: [fw-general] New Proposal: Zend_S3 > > Andi, James, > > I'm very much NOT in agreement regarding these "concrete" web > services APIs goal. This is a great way to bloat the > framework unncessarily. For the most part, the generic web > service components will be enough. I used both the Flickr and > Technorati APIs for testing Zend_Rest_Client, and they were > just as easy to use as using Zend_Service_Flickr. Yes, > something like Amazon has value in being implemented, because > it's such a complex API, but there are a lot of simple, > popular webservices are just pointless. > > To that end, I must say that I do NOT agree with Zend_S3 (presumably, > Zend_Service_Amazon_S3 would the correct name) as it > currently stands. > However, in response, I have written a stream wrapper for S3, > this has a lot of merit IMO. > > It's not 100% implemented, nor is it 100% perfect, however > all the following works: > > file_exists("s3://bucketname"); // Check if a Bucket Exists > file_exists("s3://bucketname/filename"); // Check if a file > exists mkdir("s3://bucketname"); // Create a new bucket > rmdir("s3://bucketname"); // Delete a bucket > file_put_contents("s3://bucketname/file", $content); // Write > data to a file file_get_contents("s3://bucketname/file"); // > Retrieve a file > > This means also that the fopen/fread/fwrite/fgets methods > should all work too, but I haven't tested those yet. > > Also, I have decided that because S3 does not support > sub-directories, if you try to create or remove a bucket > (mkdir/rmdir) with sub-dir, it will just create the bucket > (first dir). However if you try to create a file using an > arbitrary filename including sub-dirs, it will convert those to .'s > > S3 provides enough facilities to make directory listing > possible (though not implemented yet in my code) with this. > rmdir() could be made smart enough that if you try to remove > a sub-directory like s3://bucketname/some/dir/ then it will > remove some.dir.* files. > > S3 auth is supported, and also access to public files, but > there are still bunches of things I don't support. Checking > of MD5 sums when sending files, setting access control, > requesting torrents and creating public key access. But all > of these things will be (just like auth) implemented using > stream contexts. > > I have no issues with add convenience methods to > Zend_Service_Amazon_S3 to allow OO calls to it directly, but > they will use the stream internally, but the stream is the > best way to do this. > > A great feature this allows for, is filters, so you can > attach an encryption filter if you want all your data encrypted. > Encryption/decryption would happen transparently and is > completely outside the wrapper itself. Or maybe compression > filters. Plenty of options :) > > You can find the code attached. > > - Davey > > Andi Gutmans wrote: > > Yep that's correct. In general though it's easier for us to push > > forward these "concrete" Web services APIs then more > generic framework > > components esp. during times like now where we are focusing > on getting > > a major version out of the door. The reason is that the Web > Services > > APIs are very self contained and tend not to be too hard > from a design > > point of view (and in most cases have few > inter-dependencies on other > > componentes). > > One of our goal is to have as many such "concrete" Web > services APIs > > in the framework as possible. I have also talked to some > companies who > > expose Web Services to have them engage and contribute such APIs. > > > > Andi > > > > > >> -----Original Message----- > >> From: Stanislav Malyshev [mailto:[EMAIL PROTECTED] > >> Sent: Saturday, April 28, 2007 11:25 PM > >> To: James Andrews > >> Cc: Zend Framework > >> Subject: Re: [fw-general] New Proposal: Zend_S3 > >> > >> > >>> How does the development process work for a "proposal" to > >>> > >> become part > >> > >>> of the "library"? > >>> > >> Usually it gets evaluated (as for "how useful it would be for > >> Framework users", "should we do it", etc.), discussed (as for "is > >> this the right way to do it") and then confirmed or not > confirmed, if > >> confirmed, then it can be put into the incubator and then > eventually > >> become part of the core Framework. Here is it described in detail > >> (with a nice picture too > >> :): > >> http://framework.zend.com/wiki/display/ZFPROP/Zend+Framework+P > >> roposal+Process+Detail > >> > >> Since right now 1.0 release is very close, I guess it might take a > >> bit more time until new proposals are reviewed, since people are > >> concentrating on getting 1.0 out. > >> > >> -- > >> Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] > >> http://www.zend.com/ > >> > >> > >> > >
