Newbie Atmos Questions

Adam,

I need to get some specific answers to some of your questions, but here are answers to a few:

Some application developers may consider storing the objectID while others may not.  Many Content Management applications, for example, don't rely on the filename to read and write objects because it's not important to the users.  The metadata elements are often more significant to the actual end-users than the filename, so they use they store only the objectID.

The objectID is indeed returned in the response header when creating files via namespace in the form of a URI.

Raj

Thanks Raj. That makes sense. Since we're a file system, the Object IDs aren't all that important, but since we actually already have a place to store them, we may anyway.  The API says (on the ListObjects function) that Object IDs are 44 chars long. I'd like to know whether that will be standard.

I doubt the 44 character objectID will change, but I want to verify.

By the way, the request headers themselves can be in any order when making the request, but as you indicated the headers need to be sorted alphabetically when computing the hash.

Adam,

The 44 character objectID will not change.

The total namespace field is unlimited per the HTTP spec, but the individual parts of the namespace URI (ie directory and filename) are limited to 255 characters.

Raj

Thanks Raj, thats great.

Adam,

You can use "x-emc-limit: 50" with ListObjects to essentially paginate results.  When you send in x-emc-limit, Atmos will return x-emc-token so that you can request the next 50 objects.

Is that what you're looking for?

Raj

EDIT: Sorry I figured out what I was doing wrong.

Raj, saw your reply after I edited this post. And yes that was the problem; the dashes.  The PDF wasn't zoomed to 100% so I didn't realize there were equal signs there.

One more question for you if you don't mind....

With x-emc-tags and ListObjects specifying multiple tags, it will only return an object if that object is tagged by all of those tags (basically an AND operation.)  There is no way currently to specify an OR operation?

Correct.  It's currently an AND operation.  No way at the moment to specify OR without making multiple requests.

Raj, can you tell me if the following is expected behavior?

If I search for a listable tag that never existed on any object, I get the following response:

HTTP Code: 404, with message body:

        1003
        The requested object was not found.

If I search for a listable tag that existed on a given object, but of which I have deleted all those objects, I get the following response:

HTTP Code: 200, with message body:

I have another question. ReadObject says "If the Range header is specified, data from offset until offset+size is read and returned to the user. The default value of size=0 and a non-default value of offset returns the data from offset until size." I don't understand what the second sentence is trying to say. The range header specifies only beginning and ending offsets, there is no size parameter that I can see.

Is the range header one or zero based?

Edit: The reason I ask is because I'm getting a 206:Partial Content with the following request:

GET /rest/objects/4980cdb2a610105404980d99e8b23b04a82fdc116ed5 HTTP/1.1
Host: accesspoint.emccis.com
Accept: */*
content-type: application/octet-stream
date: Wed, 12 Aug 2009 19:11:00 GMT
range: Bytes=2097152-2097183
x-emc-uid: [my UID]
x-emc-signature: [my signature]

Response:

HTTP/1.1 206 Partial Content
Date: Wed, 12 Aug 2009 19:11:00 GMT
Server: Apache
x-emc-policy: default
Content-Length: 32
Content-Range: bytes 2097152-2097183/2097184

I don't understand why a 206 would come up.  This is assuming byte 0 is a valid first byte. So I get bytes 0-2097151 in 65KB chunks (just for testing) and then the last 32 bytes I for and yet get partial content.

Adam,

This is expected behavior --- I'll find out why, but I would be the first to admit that it's not exactly intuitive.

Raj

Range header is zero based.