Add support for Rackspace CloudFiles about transit HOT 11 CLOSED

Can do! Will get on it when I have some free time.

from transit.

Also it would be helpful to store the container the image was uploaded to. CloudFiles only allows 500,000 objects in a container. My site is at about 450,000 objects and we will be switching to another container shortly. So once we switch the old images won't be on the new container and any delete requests will fail

from transit.

So I got this almost working, but the only thing I'm not sure of is what value to save in the database? Never used Rackspace CF before.

from transit.

So this is my code that I use to store the path to the file in my non-cake site.

$result = $container->getObject(basename($file));
$url = $result->getPublicUrl(OpenCloud\ObjectStore\Constants\UrlType::SSL);
$path = $url->getScheme() . '://' . $url->getHost() . $url->getPath();

And I also store the container that I uploaded the object too. But from my understanding this works if the container is CDN enabled by doing

$container->enableCdn();

Also the option to store either UrlType::SSL or UrlType:CDN as on my site I prefer to store the SSL path because my site is only available via SSL.

from transit.

Ok got it working: https://github.com/milesj/transit/blob/master/src/Transit/Transporter/Rackspace/CloudFilesTransporter.php

My tests are working locally, but not on Travis, but that might be a configuration issue. Test out the master and let me know how it works.

from transit.

Should also have an option to purge() the file but only optional during a delete

from transit.

How would that work exactly?

from transit.

Yeah good point, Oh and I will point out that during a deletion of 5 files the request could take up to 20 seconds to complete.

from transit.

Not sure there's anything I can do to speed that up :P

from transit.

Yeah I know, what I do is during the delete process create records in a table that has the file name and container and then delete them as a background process cause a 20s response time to a client is horrible

from transit.

Yeah that's a better approach, but more than what Transit is built to handle. However! I did update the delete to remove 1 of the round-about URL calls. Should be slightly faster.

from transit.