Hi everyone,
I have images uploaded to the blobstore using filesystem API. The files
have been uploaded successfully and I can see the blobs in the respective
directory.
But then, how do I decode these files such that when sent back to the
client or retrieved using the blobstore API, I'm able to
Look at the documentation for the images service. There is a method that
gives you a serving url directly to the CDN.
Warning: This method has a surprising amount of latency, you probably want
to cache the value in memcache for a reasonable duration.
Jeff
On Thu, Mar 1, 2012 at 7:42 AM, Kayode
On Thu, Mar 1, 2012 at 3:03 PM, Jeff Schnitzer wrote:
> Look at the documentation for the images service. There is a method that
> gives you a serving url directly to the CDN.
>
> Warning: This method has a surprising amount of latency, you probably
> want to cache the value in memcache for a r
I serve blobstore images via getServingUrl() all the time, including image
blobs that I have created with the files API. On the dev server.
I don't know your particular problem, but the first step in getting help
would be to post a full stacktrace.
Jeff
On Thu, Mar 1, 2012 at 12:19 PM, Kayode O
Hello Odeyemi,
If I got your problem right, yes, you can use the Files API to create an
image blob, then use the ImageService to create a dedicated URL to serve
that image as Jeff said. You can safely cache the generated URL, it will be
available as long as you don't delete de blob.
Double che
2012/3/1 Ronoaldo José de Lana Pereira
> Hello Odeyemi,
>
> If I got your problem right, yes, you can use the Files API to create an
> image blob, then use the ImageService to create a dedicated URL to serve
> that image as Jeff said. You can safely cache the generated URL, it will be
> available
What are you trying to do?
Jeff
On Thu, Mar 1, 2012 at 2:29 PM, Kayode Odeyemi wrote:
> 2012/3/1 Ronoaldo José de Lana Pereira
>
>> Hello Odeyemi,
>>
>> If I got your problem right, yes, you can use the Files API to create an
>> image blob, then use the ImageService to create a dedicated URL t
To store upload images as blob using the filesystem api. Then be able
to access the raw image files via a file/url resource path when
wrapped around wrote:
> What are you trying to do?
>
> Jeff
>
> On Thu, Mar 1, 2012 at 2:29 PM, Kayode Odeyemi wrote:
>
>> 2012/3/1 Ronoaldo José de Lana Pereira
On Thu, Mar 1, 2012 at 3:34 PM, Kayode Odeyemi wrote:
> To store upload images as blob using the filesystem api. Then be able
> to access the raw image files via a file/url resource path when
> wrapped around
Forget file paths. The only thing that matters is 1) getting your blob
into the blobs
On Thu, Mar 1, 2012 at 11:25 PM, Jeff Schnitzer wrote:
> On Thu, Mar 1, 2012 at 3:34 PM, Kayode Odeyemi wrote:
>
>> To store upload images as blob using the filesystem api. Then be able
>> to access the raw image files via a file/url resource path when
>> wrapped around >
>
> Forget file paths.
Jeff,
Yes, the URL its unique for the life spam of the image. We should better
document this on our side though.
Best,
Jose
On Thursday, March 1, 2012 11:29:38 AM UTC-8, Jeff Schnitzer wrote:
>
> 2012/3/1 Ronoaldo José de Lana Pereira
>
>> Hello Odeyemi,
>>
>> If I got your problem right, yes,
Jeff is right, I was actually assuming this behavior by reading this info
from javadoc: "If you wish to stop serving the URL, delete the underlying
blob key. This takes up to 24 hours to take effect. ". But this don't
explicitly states that they will be available forever. Anyway, we are using
t
2012/3/5 Ronoaldo José de Lana Pereira
>
> Just for curiosity, if you call the getServingUrl() twice for the same
> blob key, I was expecting that they would generate the same URL. Jeff, did
> you got different URL's?
>
>
I never looked at them closely enough, but I wouldn't have trusted my own
s
2012/3/5 Ronoaldo José de Lana Pereira
> Jeff is right, I was actually assuming this behavior by reading this info
> from javadoc: "If you wish to stop serving the URL, delete the underlying
> blob key. This takes up to 24 hours to take effect. ". But this don't
> explicitly states that they will
On Mon, Mar 5, 2012 at 12:20 PM, Kayode Odeyemi wrote:
>
> In my use case, I just needed the files to be stored temporarily using the
> filesystem api (just for UI purposes). To permanently save the uploaded
> file, I implemented the blobstore api. This way I don't have to worry about
> whether t
On Mon, Mar 5, 2012 at 5:28 PM, Jeff Schnitzer wrote:
> On Mon, Mar 5, 2012 at 12:20 PM, Kayode Odeyemi wrote:
>
>>
>> In my use case, I just needed the files to be stored temporarily using
>> the filesystem api (just for UI purposes). To permanently save the uploaded
>> file, I implemented the
On Mon, Mar 5, 2012 at 12:34 PM, Kayode Odeyemi wrote:
>
> So whether the files are written using the Files API or directly uploaded
> to the blobstore, the blobstore still reside on disk?
>
The Files API is an interface to the Blobstore and Google Cloud Storage.
The data lives in one or the ot
17 matches
Mail list logo
