new API release - 12/03/04

[onethumb]

Well, the short story is that there are all sorts of goodies for you all to play with. Let's get down to it:

Changes:
- The upload method and the Upload via POST w/XML-RPC response both have some new fields and functionality:
o "ByteCount" is optional, but strongly encouraged. Send along the # of bytes the file is, so we can see if we really received the whole thing.
o "MD5Sum" is optional, but strongly encouraged. Send along the md5sum hash of the file you're uploading, so we can see if we got all the bytes properly.
o "Version" is optional, but strongly encouraged. If it's properly set, you'll received the ImageID of the newly uploaded image upon success.

- loginAnonymously now works as advertised. This means non-logged in smugmug users can now browse smugmug using your apps. No login required, but of course, various features and information will be locked.

- createAlbum is fixed. It actually worked properly all along, but the documentation was all broken. It's been updated to be correct now, and more fields are exposed.


New stuff:

- You should be able to retrieve almost all useful information about images, image EXIF data, albums, etc. Creating a bulk downloader, backup tool, whatever should be insanely easy now.

- The early stages of modifying data and settings on smugmug is exposed now too. You can set various album details, image details, and do things like organizing, sorting, and moving images between galleries.

Everything has received minimal testing, at best, so beware the bugs. Post them on this thread, and I'll fight them as they crop up. In particular, I've tried to maintain 100% backwards compatibility, but it's possible something broke.

Please keep feature *requests* to another thread (or threads), and keep this one for comments, bugs, etc about this specific release.

Thanks,

Don

[Nikolai]

Now I have to redo everything...
Just kidding!
Thank you very much!:thumb
Cheers!:1drink

[Nikolai]

http://www.smugmug.com/hack/xmlrpc-changeImagePosition

On the page, the name of the method says "changeImageSettings" ..

[onethumb]

http://www.smugmug.com/hack/xmlrpc-changeImagePosition

On the page, the name of the method says "changeImageSettings" ..

Good catch. Just a typo, I'll fix it later. It is changeImagePosition.

Don

[Nikolai]

It works!!! :clap Thank you, thank you, thank you!:thumb So from now on having personal default settings would be no problem!
And it also works with subcategories!:lust


<HR>

One question, though: it takes int CommunityID parameter, but there is no current API to get those valid community IDs and names. It's absolutely no biggie, but I would appreciate the plans sharing: is it gonna be availavle any time soon?:dunno
I kinda don't feel like putting "Community Index" spin edit on the album settings dialog, I'd rather prefer combobox, just like you provide online. So if it's not gonna be availalble, I'd simply hide the whole community thing..
(As a side note - I still don't know what it does:scratch , so for me personally it's nothing;-)

Cheers!:1drink

[rutt]

The new API documentation documents neither the type of "version" nore its meaning for the upload function. I found this confusing. In fact, I think it's "boolean" and it controls whether an image ID is returned. The documentation should reflect this.

I had some totally different and more esoteric thing in mind, so it really is possible to misconstrue.

Other than that, this is very exciting. I'm about to make smumug.py conform and add new functionality. Yeah!

[Nikolai]

The new API documentation documents neither the type of "version" nore its meaning for the upload function. I found this confusing. In fact, I think it's "boolean" and it controls whether an image ID is returned. The documentation should reflect this....it says pretty clearly that Version is a string '1.0'.
hopefully somebody from the pitcrew kicks in, but in any case I'll most likely try it tomorrow and will share the results here.
Cheers!:1drink

P.S.
Back to the workbench, eh;-)? Me, too..

[rutt]

...it says pretty clearly that Version is a string '1.0'.
hopefully somebody from the pitcrew kicks in, but in any case I'll most likely try it tomorrow and will share the results here.

No, take a look here (http://www.smugmug.com/hack/xmlrpc-upload). I think you are confusing with the login method, here (http://www.smugmug.com/hack/xmlrpc-loginWithPassword).

[rutt]

No, take a look here (http://www.smugmug.com/hack/xmlrpc-upload). I think you are confusing with the login method, here (http://www.smugmug.com/hack/xmlrpc-loginWithPassword).
I guess we are both a little confused. The upload documentation definitly doesn't specify that version is a string. I suppose it should be "1.1" or something if we want to get the image ID? The login function is still documentated to take "1.0" as a version.

I imagined that the version given to login would control the API for the entire session. That way, if I log in with version 1.0, I won't get the image Id for upload and won't have to pass a version to it. I think this way of doing things enables easy hacking on Don's part and enables the clients to stay frozen and keep working. The way things are, perhaps the version flag will slowly creep into all the functions. I suppose this is OK, but since it is neceassarily an optional argument (for backward compatibility) it prevents new required arguments from being added. I think this will become a problem pretty quickly if there are a lot of changes. I know that Don thinks there won't be, but...

So before we all start hacking to the new version, I'd strongly suggest that Don rethink this.

[Nikolai]

Or the API is missing the categories names?
I'm still looking for a way to populate the "tree" quickly and efficiently, and this new guy definitely helps (I hope it returns even albums-less entries, haven't checked yet).
But - come on, why do I stil need TWO roundtrips:

getCategories (to get names and IDs)
getAllSubcategories (to get subcategories names and IDs)
after which I, of course, have to match one list with the other. Matching is not a big deal, but these kinds of requests take some valuable user's time and increase the traffic.

Is it possible to add Category's name to the returning struct? That would be totally sweet!
(However, I still would like to have a modified version of getAlbums with the suggested optional FullList parameter, as well as optional "filtering" category and subcategory IDs..)

Don, can we adress this issue? Please??:bow

[Nikolai]

And I defineitely agree that version sould be only mentioned during sign-up process. I think this was just a "kwik hack" on Don's part and it will be revamped as soon as he gets a bit more time to work on such fixes.

[rutt]

Or the API is missing the categories names?
I'm still looking for a way to populate the "tree" quickly and efficiently, and this new guy definitely helps (I hope it returns even albums-less entries, haven't checked yet).
But - come on, why do I stil need TWO roundtrips:


getCategories (to get names and IDs)
getAllSubcategories (to get subcategories names and IDs)



I thought about this and concluded that I should just cache categories and subcategories if I wanted to make this fast. After all what happens? The user specifies a category/subcategory. Either we already know the ids of both or not. Is so, fine. If not, then we can make the API calls to find them, then we should just save the info for future lookups. We don't have the API functions yet to crate categories and subcategories, so for now these have to be created by the user interacting with smugmug somehow. Fine, in the rare case when we have a cache and still don't understand the user's category or subcategory name, we can make the API calls and refresh the cache. Later on, we'll get the API calls to create the categories and subcategories. When that happens, we can add them to the cache when we create them.


Make sense?

[onethumb]

Or the API is missing the categories names?
I'm still looking for a way to populate the "tree" quickly and efficiently, and this new guy definitely helps (I hope it returns even albums-less entries, haven't checked yet).
But - come on, why do I stil need TWO roundtrips:

getCategories (to get names and IDs)
getAllSubcategories (to get subcategories names and IDs)
after which I, of course, have to match one list with the other. Matching is not a big deal, but these kinds of requests take some valuable user's time and increase the traffic.

Is it possible to add Category's name to the returning struct? That would be totally sweet!
(However, I still would like to have a modified version of getAlbums with the suggested optional FullList parameter, as well as optional "filtering" category and subcategory IDs..)

Don, can we adress this issue? Please??:bow


My architecture style for the API is much more inclined to a few small calls rather than big monolith calls that grows over time or has some unintended impact.

I don't think asking you to make two calls to get the entire "tree" is all that inappropriate, and it makes our life easier on the backend anyway (multiple calls = spread across our cluster. single call = one server is stuck doing it).

So, sorry, but you're stuck doing both. :)

Don

[onethumb]

I guess we are both a little confused. The upload documentation definitly doesn't specify that version is a string. I suppose it should be "1.1" or something if we want to get the image ID? The login function is still documentated to take "1.0" as a version.

I imagined that the version given to login would control the API for the entire session. That way, if I log in with version 1.0, I won't get the image Id for upload and won't have to pass a version to it. I think this way of doing things enables easy hacking on Don's part and enables the clients to stay frozen and keep working. The way things are, perhaps the version flag will slowly creep into all the functions. I suppose this is OK, but since it is neceassarily an optional argument (for backward compatibility) it prevents new required arguments from being added. I think this will become a problem pretty quickly if there are a lot of changes. I know that Don thinks there won't be, but...

So before we all start hacking to the new version, I'd strongly suggest that Don rethink this.

Without going into too much detail, I had to *also* version upload to make sure some older things that were using the API when it wasn't really an API don't break.

Version for the login details will, of course, get tied to the session for all future updates of all non-upload methods. I will probably make a cascade fallback for the upload method(s) at some point, but for now, please send it along with that call to enable the new features.

The current version is "1.0". Let's stick with a String, because I want the ability to go "1.0.1". For now, use "1.0" if you'd like all the nifty new features.

Don

[Nikolai]

My architecture style for the API is much more inclined to a few small calls rather than big monolith calls that grows over time or has some unintended impact.

I don't think asking you to make two calls to get the entire "tree" is all that inappropriate, and it makes our life easier on the backend anyway (multiple calls = spread across our cluster. single call = one server is stuck doing it).

So, sorry, but you're stuck doing both. :)

DonAt least now I know the reason - and I can see your point:-).
Also, I was plainning to cache data locally (rutt, I'm with you here, buddy, just don't have it yet, but I will purrrty soon:-), so in the end it should not be such big of a difference.

Thank you for the clarification!
Cheers!:1drink

[Nikolai]

I'm trying to use new upload API, and each time get a format error, code 4 for upload via post, and code 6 for base64 upload.
If I remove both ByteCount and MD5ASum, upload via post works just fine even though I provide Version '1.0' string.

Here's an exmaple of a regular base64 upload xml I'm using (multipart upload is harder to log):
<?xml version="1.0"?>
<methodCall>
<methodName>upload</methodName>
<params>
<param><value>196aef96ce0ca69238c625b40bb88692</value></param>
<param><value><int>308578</int></value></param>
<param><value></value></param>
<param><value>sony-f828.jpg</value></param>
<param><value><base64>/9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABkAGQDASIAAhEBAxEB/8QAHAABAAEFAQEAAAAAAAAAAAAAAAYDBAUHCAIB/8QAOBAAAQMDAQUGBAQFBQAAAAAAAQACAwQFESEGEhMxQQcUUWFxgSIykbEkM0KhQ1KCwdFUcpKy4f/EABgBAQADAQAAAAAAAAAAAAAAAAABAgME/8QAIREBAAICAgICAwAAAAAAAAAAAAERAhIDISIxBBNBQlH/2gAMAwEAAhEDEQA/AN/oiICIiAiIgIiICIiAiIgIiICIiDxNMyCJ0shwxoyThRm4bbUNGWcOGeYOaXAtZ4DPLqNOijvaNtW2hrYrQ2ofA/dZNI5gzhpJHpnTTOhKglTfu8OfTxU0k8MQxBXOkLXvJGXOeDnqOrsADTCvGP8AVZyZ+s28r4auOHANbUuzEG1bHNIxnXGQ3Tnnktk2HaCKttUMlZNHHU6h7c6ZBPI8j6hct3PamGesbSUUQqIeIN98hO44nngH4sc9SVIrbcL1TxkQvqYojnDY3uGnlvEhTrE+kbU6dZLHK3eje1w8WnK9rnmzVN1pKxlZbOOGOdvl8027/wAt4+q21TbeWuV8UDi907wNIBxGk9cEKs40tE2liKDXftGitleYGWyeZjPzH53S0+mCq1u7TLHXP3H8eB+MkOjLgPcKKlKZovLXBwBBBBGQQvSgEREBERBpDtGbWjb2aS3zNhmZSR5JHzA5yD7LS+0tbXMrGx1LBGACN2N2GO8y0YGVu/bs42+rc/6WL7FaR20Obi30Wn6qfl52RtQu94Dp8cGAbxGNC4/KMexPstkT2C4UojqBTtk3wHNPFBJzk8sc8AnCjGylsvlLZJTHbWwRyO4jaiZhJd0Hw+X91dvi2nhcTBdn74OrBC1oHsOSnHqCe5Zunv8ATUMj6a7UEkenItIJx08eeFkBtA2BpidMZyHAiWB25+lp5txnnjX3WubtfLyyJ1LdC4B7w/fByHkAN19mj6Knaq+OGlklnmDWulwM9TgKbR2nNXJFPQSvpHStqM7wLn6AdR99SVZUUtbtMysdbC2nt1K3cFS8nfnd19Aq8FMaego6ippTNFVvxhkoBDAQMjnr116A9Ura6mstILdQM4UDHFwGeZOqHp0VZqqKss1HPC7ejfC3B9sH91fKDdlFS6q2MaXcmTvDfQ4P3JU5WMrwIiIkREQaT7QxI3b2oO6Rv00WD48woVDbaGpqDXgMeW8qmU4jb/tHXrr+6n/bdRwU8dtr4nOZW1b+5OIOhj+Yn1Go/qUDit8V1pmuLm8LvHdqeE/KwN0LsdTnPPkAt+ONulJhdPtnf96Wkr6Otl+YgPy77n7Kxdde7Ex1ED4Xw4e/BO6fMjUtzyy3TyX1tFmuMdM0jdPw45rJS0rblGY6qMithaeHICQSDzBwtsuHKMbhjHLjtqo3ehpbrZoqtu7PSTjDiBrE/ng+2oPVWtRs9aJaKhpqCFsRkaY5GuO8d/GpyfqP/Fh7PdJ6GWroS78LLgGLTDDkkY0/m/7FXdZce6GCdp+SRrufgQuf229LSgvNVRtqbUwEcOTLWO+Lh5yXAf1A/UrH1E8s1zp6Wm/G1MzmtaDnV59eePurVkpu21FY6OOR5ncQyOMZL3Hopq7YbaS0bTW09ybHJVxFsIjIcYz/ACZ6dSXHxS6KuadA7J2Y2DZykt7yHSxszK4fqedT/j2WbVGlbI2mibM4OlDAHkcicaqsslxERAREQar7c6GSTZWgubGucy31rJJsdGO+En9wtNRV77XeJ6XfJh43eID4tdgn+xXVt0t1LdrZU2+sjElPURmORp6grl7arZas2arWWa6hzGROJoLnjSRnRp8xyWnHnOM9KZRcL63XZsFw4zHB2TkFZmrrmSXKimH5sxIIA6Aan91AYqWvhmAdSPkx/Ege3DvY/wCVK6JraaNldXYi4bTuNc/ePqTjHLHIe56dn3+NOWPj+e0oZtDVdx2hrWM5cYfQ4cq9q2e2g22qHU1mo3TNhAMshcGsZ4anAz5KV7KdmFw28vD7vcOJR2h8hk3yPjmHQN8NBzK6Js1jt1htsdvtlMynpoxgMb18yeZPmVxTk69UL7N+zGl2OpxV1ZbUXSRurukQ8B4nxP0Ww90ZBwMjkV9xhfVS7WEREBERAREQFj7vZaC+0TqO5UsdRA7m1/TzB6LIIg1XUdiVC2Uutt3qKWInSJzS8D0+IK+t3ZDa4ZGvudXLX7pB4eNxhx46kn6rYyKdpRUKcMMcETYomNZGwYa1owAPAKoiKEiIiAiIgIiICIiAiIgIiICIiAiIgIiICIiD/9kg</base64></value></param>
<param><value><int>1887</int></value></param>
<param><value>FCE507E5A22A3342DDF31FE052AFADB9</value></param>
<param><value>1.0</value></param>
</params>
</methodCall>

Any clues? Don, rutt?
TIA!

[rutt]

smugmug.py worked this am passing a bytecount via the POST method. I don't pass the version parameter nor check the result for the image id, but this didn't seem to matter. The image appeared if and only if the whole image arrived.

So maybe you should take a look at it. There isn't much to it.

[Nikolai]

smugmug.py worked this am passing a bytecount via the POST method. I don't pass the version parameter nor check the result for the image id, but this didn't seem to matter. The image appeared if and only if the whole image arrived.

So maybe you should take a look at it. There isn't much to it.
Rutt, thanks, I tried your advice - regular, base64 upload witht he byte count - and it worked.
It also works without the byte count. Adding the rest seem to screw things up.

Here's working xml with bytecount:

<?xml version="1.0"?>
<methodCall>
<methodName>upload</methodName>
<params>
<param><value>99cddc9e83212b3e9297b5adaca0809e</value></param>
<param><value><int>308578</int></value></param>
<param><value></value></param>
<param><value>sony-f828.jpg</value></param>
<param><value><base64>/9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABkAGQDASIAAhEBAxEB/8QAHAABAAEFAQEAAAAAAAAAAAAAAAYDBAUHCAIB/8QAOBAAAQMDAQUGBAQFBQAAAAAAAQACAwQFESEGEhMxQQcUUWFxgSIykbEkM0KhQ1KCwdFUcpKy4f/EABgBAQADAQAAAAAAAAAAAAAAAAABAgME/8QAIREBAAICAgICAwAAAAAAAAAAAAERAhIDISIxBBNBQlH/2gAMAwEAAhEDEQA/AN/oiICIiAiIgIiICIiAiIgIiICIiDxNMyCJ0shwxoyThRm4bbUNGWcOGeYOaXAtZ4DPLqNOijvaNtW2hrYrQ2ofA/dZNI5gzhpJHpnTTOhKglTfu8OfTxU0k8MQxBXOkLXvJGXOeDnqOrsADTCvGP8AVZyZ+s28r4auOHANbUuzEG1bHNIxnXGQ3Tnnktk2HaCKttUMlZNHHU6h7c6ZBPI8j6hct3PamGesbSUUQqIeIN98hO44nngH4sc9SVIrbcL1TxkQvqYojnDY3uGnlvEhTrE+kbU6dZLHK3eje1w8WnK9rnmzVN1pKxlZbOOGOdvl8027/wAt4+q21TbeWuV8UDi907wNIBxGk9cEKs40tE2liKDXftGitleYGWyeZjPzH53S0+mCq1u7TLHXP3H8eB+MkOjLgPcKKlKZovLXBwBBBBGQQvSgEREBERBpDtGbWjb2aS3zNhmZSR5JHzA5yD7LS+0tbXMrGx1LBGACN2N2GO8y0YGVu/bs42+rc/6WL7FaR20Obi30Wn6qfl52RtQu94Dp8cGAbxGNC4/KMexPstkT2C4UojqBTtk3wHNPFBJzk8sc8AnCjGylsvlLZJTHbWwRyO4jaiZhJd0Hw+X91dvi2nhcTBdn74OrBC1oHsOSnHqCe5Zunv8ATUMj6a7UEkenItIJx08eeFkBtA2BpidMZyHAiWB25+lp5txnnjX3WubtfLyyJ1LdC4B7w/fByHkAN19mj6Knaq+OGlklnmDWulwM9TgKbR2nNXJFPQSvpHStqM7wLn6AdR99SVZUUtbtMysdbC2nt1K3cFS8nfnd19Aq8FMaego6ippTNFVvxhkoBDAQMjnr116A9Ura6mstILdQM4UDHFwGeZOqHp0VZqqKss1HPC7ejfC3B9sH91fKDdlFS6q2MaXcmTvDfQ4P3JU5WMrwIiIkREQaT7QxI3b2oO6Rv00WD48woVDbaGpqDXgMeW8qmU4jb/tHXrr+6n/bdRwU8dtr4nOZW1b+5OIOhj+Yn1Go/qUDit8V1pmuLm8LvHdqeE/KwN0LsdTnPPkAt+ONulJhdPtnf96Wkr6Otl+YgPy77n7Kxdde7Ex1ED4Xw4e/BO6fMjUtzyy3TyX1tFmuMdM0jdPw45rJS0rblGY6qMithaeHICQSDzBwtsuHKMbhjHLjtqo3ehpbrZoqtu7PSTjDiBrE/ng+2oPVWtRs9aJaKhpqCFsRkaY5GuO8d/GpyfqP/Fh7PdJ6GWroS78LLgGLTDDkkY0/m/7FXdZce6GCdp+SRrufgQuf229LSgvNVRtqbUwEcOTLWO+Lh5yXAf1A/UrH1E8s1zp6Wm/G1MzmtaDnV59eePurVkpu21FY6OOR5ncQyOMZL3Hopq7YbaS0bTW09ybHJVxFsIjIcYz/ACZ6dSXHxS6KuadA7J2Y2DZykt7yHSxszK4fqedT/j2WbVGlbI2mibM4OlDAHkcicaqsslxERAREQar7c6GSTZWgubGucy31rJJsdGO+En9wtNRV77XeJ6XfJh43eID4tdgn+xXVt0t1LdrZU2+sjElPURmORp6grl7arZas2arWWa6hzGROJoLnjSRnRp8xyWnHnOM9KZRcL63XZsFw4zHB2TkFZmrrmSXKimH5sxIIA6Aan91AYqWvhmAdSPkx/Ege3DvY/wCVK6JraaNldXYi4bTuNc/ePqTjHLHIe56dn3+NOWPj+e0oZtDVdx2hrWM5cYfQ4cq9q2e2g22qHU1mo3TNhAMshcGsZ4anAz5KV7KdmFw28vD7vcOJR2h8hk3yPjmHQN8NBzK6Js1jt1htsdvtlMynpoxgMb18yeZPmVxTk69UL7N+zGl2OpxV1ZbUXSRurukQ8B4nxP0Ww90ZBwMjkV9xhfVS7WEREBERAREQFj7vZaC+0TqO5UsdRA7m1/TzB6LIIg1XUdiVC2Uutt3qKWInSJzS8D0+IK+t3ZDa4ZGvudXLX7pB4eNxhx46kn6rYyKdpRUKcMMcETYomNZGwYa1owAPAKoiKEiIiAiIgIiICIiAiIgIiICIiAiIgIiICIiD/9kg</base64></value></param>
<param><value><int>1887</int></value></param>
</params>
</methodCall>


Don, can you please verify this?

[Nikolai]

..my asking, what other new/extended methods did you already try?

So far I spent most of my time encapsulating new settings for the new createAlbum, and this guys seem to work fine now, all by the book:thumb . I still have no idea what to do with the CommunityID, but I surfaced it anyway. Also it took time to take care of the subscription level differences, but it was mainly UI work.

I'm in the process of trying of getAllSubCategories, but haven't completed any tests yet.

Thanks!

[Nikolai]

This old guy, getCategories, works fine:

<?xml version="1.0"?>
<methodCall>
<methodName>getCategories</methodName>
<params>
<param><value>75203105c43a6d2930d13b4c99ca779e</value></param>
</params>
</methodCall>

The new guy,

<?xml version="1.0"?>
<methodCall>
<methodName>getAllSubCategories</methodName>
<params>
<param><value>75203105c43a6d2930d13b4c99ca779e</value></param>
</params>
</methodCall>

while being almost identical with the exception of the method name, getAllSubCategories, returns nothing. Nada. Zero. Response is empty text.:deal

Don, any clues?

[rutt]

..my asking, what other new/extended methods did you already try?

So far I spent most of my time encapsulating new settings for the new createAlbum, and this guys seem to work fine now, all by the book:thumb . I still have no idea what to do with the CommunityID, but I surfaced it anyway. Also it took time to take care of the subscription level differences, but it was mainly UI work.

I'm in the process of trying of getAllSubCategories, but haven't completed any tests yet.

Thanks!
I'm sort of in the same place as you are. I'm planning to add stuff for contolling/resetting the album options in fairly fancy ways. The idea of my script is to be able to use it from a batch job to mirror a directory structure onto smugmug and keep it up to date with a minimal amount of manual intervention. So I'm planning to have option overrides be able to reside in each directory in the tree and subdirectories inherit from them.

[onethumb]

I'm trying to use new upload API, and each time get a format error, code 4 for upload via post, and code 6 for base64 upload.
If I remove both ByteCount and MD5ASum, upload via post works just fine even though I provide Version '1.0' string.


Any clues? Don, rutt?
TIA!

Luckily, this one was pretty easy. I'm expecting a standard MD5 hash in lower-case format, but you're providing upper-case. No big deal, I just auto-lower case your MD5 hash now. (Well, on my test server. The fix will go live at some point soon, hopefully today).

Don

[onethumb]

This old guy, getCategories, works fine:

<?xml version="1.0"?>
<methodCall>
<methodName>getCategories</methodName>
<params>
<param><value>75203105c43a6d2930d13b4c99ca779e</value></param>
</params>
</methodCall>

The new guy,

<?xml version="1.0"?>
<methodCall>
<methodName>getAllSubCategories</methodName>
<params>
<param><value>75203105c43a6d2930d13b4c99ca779e</value></param>
</params>
</methodCall>

while being almost identical with the exception of the method name, getAllSubCategories, returns nothing. Nada. Zero. Response is empty text.:deal

Don, any clues?

Woops. My bug. Fixed on my test server, live release will be soon.

Don

[Nikolai]

Luckily, this one was pretty easy. I'm expecting a standard MD5 hash in lower-case format, but you're providing upper-case. No big deal, I just auto-lower case your MD5 hash now. (Well, on my test server. The fix will go live at some point soon, hopefully today).

Donyou guys are all unix/linux/whatever case-sensitive types... gr-r-r-r

I guess I 'll fix it tonite on my end, too - along with your password-less entry suggestion..;-)

Thanks alot for the clarification!
Cheers!:1drink

[Nikolai]

Woops. My bug. Fixed on my test server, live release will be soon.

DonWill test tonite, and, hopefully, get it working;-) :thumb
Thanks, Don!

Cheers!:1drink

[Nikolai]

Luckily, this one was pretty easy. I'm expecting a standard MD5 hash in lower-case format, but you're providing upper-case. No big deal, I just auto-lower case your MD5 hash now. (Well, on my test server. The fix will go live at some point soon, hopefully today).

DonJust came back from work and started testing.
Changed MD5 to lowercase.

upload - works!:thumb
upload via POST - still does not:scratch
Agian, I can't provide complete log of HTTP traffic for the multipart post, as far as components "hide" it from me. But here are the data I provide (in this exact order):

URL: 'http://upload.smugmug.com/photos/xmladd.mg'
--
FileField: 'Image'
FileName: 'C:\Documents and Settings\user\My Documents\My Pictures\sony-f828.jpg'
--
Fields: ('AlbumID', 'SessionID', 'Caption', 'ByteCount', 'MD5Sum', 'Version')
Values: ('308578', '628b784e2c1bce0723ca5093cee6fc6b', 'some nice caption', '1887', 'fce507e5a22a3342ddf31fe052afadb9', '1.0')

As you can see, md5 digest is now lowercase.
Note, that if I omit "advanced" fields (with or without the version) and do the following:

URL: 'http://upload.smugmug.com/photos/xmladd.mg'
--
FileField: 'Image'
FileName: 'C:\Documents and Settings\user\My Documents\My Pictures\sony-f828.jpg'
--
Fields: ('AlbumID', 'SessionID', 'Caption', 'Version')
Values: ('308578', '628b784e2c1bce0723ca5093cee6fc6b', 'some nice caption', '1.0')

then this method works also.

Can you (or anybody) spot anything wrong?:deal

Still confused.. Oh wel, on to removing password storing in the mean time..

[Nikolai]

Woops. My bug. Fixed on my test server, live release will be soon.

DonI'm standing by for your command, mylord..:snore

[rutt]

I want to add some functionality to smugmug.py that will surface these API calls. In particular, I was thinking along the lines of:

smugmug.py resort [--recursive]
smugmug.py album_properties [--recursive]

In either case, the idea is to act on either the album represented by the current directory or on the entire subtree of the current directory. Probably, I'll also allow a directory list as well. (Remember I am keeping a local directory<->album mapping.)

OK, I think there is no problem if I only make one of these calls. But what if I want to resort all my albums and I have hundreds of the them? Or want to make all the filenames in all my old albums visible? Doing that will take much longer than it has to. And it's not like the getCategories/subCategories thing. Local smarts can't fix.

Here are a few suggestions for dealing with this.

Have analogous calls for categories subcategories. All the albums in the given category/subcategory are resorted or have their properties changes..
Take a vector (list, array, whatever) of albumids in the call and apply to all the elements. You can even make this backward compatible with the current calls; just test the type of the albumId argument.

[Nikolai]

.. I don't think we'll get it...:-(

As Don explained earlier, he's not in favor of the huge, massive calls, as fas as it keeps the one server busy for a long time. He prefers a - possibly very long - list of separate small calls, even coming all at the same time, so he can do load balancing.

Again, I would love to save on the roundtrips myself whenever posiible, but it looks like he have to comply with the house rules..

Just MHO..

Cheers!:1drink

[rutt]

.. I don't think we'll get it...:-(

As Don explained earlier, he's not in favor of the huge, massive calls, as fas as it keeps the one server busy for a long time. He prefers a - possibly very long - list of separate small calls, even coming all at the same time, so he can do load balancing.

Again, I would love to save on the roundtrips myself whenever posiible, but it looks like he have to comply with the house rules..

Just MHO..

Cheers!:1drink
Yes, we'll see. I think the argument in this case is sounder than the argument for a monolithic getCategories/subcategories call. And there is an obvious "embarrassingly parallel" implementation so Don can do his own load balancing in these cases, perhaps even more intelligently than the routers would. With the getCategories thing, all the work had to result in a single list so syncronization would be required. In this case the sorts (probably the most expensive possible thing one could do with this) are all independent (or at least should be) and so can be deligated. There is no reason for either of these calls even to wait for completion, although even that would be a relatively small amount of syncronization.

[onethumb]

I'm standing by for your command, mylord..:snore

Fixes are up.

Don

[onethumb]

Yes, we'll see. I think the argument in this case is sounder than the argument for a monolithic getCategories/subcategories call. And there is an obvious "embarrassingly parallel" implementation so Don can do his own load balancing in these cases, perhaps even more intelligently than the routers would. With the getCategories thing, all the work had to result in a single list so syncronization would be required. In this case the sorts (probably the most expensive possible thing one could do with this) are all independent (or at least should be) and so can be deligated. There is no reason for either of these calls even to wait for completion, although even that would be a relatively small amount of syncronization.

Those operations are definitely "embarrassingly parallel", but the other component that makes it worth my while is "frequency of use". Since I don't anticipate calls like these would be used all that frequently, I probably won't (at this time) invest the effort to make them load-balance themselves on our backend. I'd just let you submit and send a reply when complete.

Having said that, it makes sense to have these be options, so I'll see what I can do. And if I'm wrong about the frequency, I can always parallelize them on our backend at a later date with no API change. I like that. :)

Don

[Nikolai]

Fixes are up.

DonJust tested:

getAllSubCategories work!:thumb
upload via POST still does not...:scratch
Thank you for the categories fix!
Cheers!:1drink

[Nikolai]

Just tested:

getAllSubCategories work!:thumb
upload via POST still does not...:scratch
Thank you for the categories fix!
Cheers!:1drink
I finally got home and got my hands into the programm. Well, getAllSubCategories now returns somthing, but result is unusable.

Instead of providing Category ID, Subcategory ID and Subcategory Title, it uses subcategory id twice, thus making each id equal and the whole thing totally useless :-(

Here is a log excerpt:
First goes call for all caetgories:


<?xml version="1.0"?>
<methodCall>
<methodName>getCategories</methodName>
<params>
<param><value>3ff8d655e92b68728fe54e8408228861</value></param>
</params>
</methodCall>
.......................................
<?xml version="1.0" encoding="iso-8859-1"?>
<methodResponse>
<params>
<param>
<value>
<array>
<data>
<value>
<struct>
<member>
<name>CategoryID</name>
<value>
<int>0</int>
</value>
</member>
<member>
<name>Title</name>
<value>
<string>Other</string>
</value>
</member>
</struct>
</value>


the rest is skipped. OK, Other does have id=0.
Now, the new method. I have a Test subcategory within Other:

<?xml version="1.0"?>
<methodCall>
<methodName>getAllSubCategories</methodName>
<params>
<param><value>3ff8d655e92b68728fe54e8408228861</value></param>
</params>
</methodCall>
.......
12/7/2004 7:24:31 PM: Post results
<?xml version="1.0" encoding="iso-8859-1"?>
<methodResponse>
<params>
<param>
<value>
<array>
<data>
<value>
<struct>
<member>
<name>CategoryID</name>
<value>
<int>48284</int>
</value>
</member>
<member>
<name>SubCategoryID</name>
<value>
<int>48284</int>
</value>
</member>
<member>
<name>Title</name>
<value>
<string>test</string>
</value>
</member>
</struct>
</value>
...............

Parsing this shows this line:

12/7/2004 7:24:31 PM: Finished Getting all sub categories for PhotoSoCal (0:00:01)
12/7/2004 7:24:31 PM: CategoryID=48284, SubCategoryID=48284, Title=test
....


So, instead of 0 we have first item 28284.

Don, it seems like an easy fix.. If you please?

Thanks!

[Nikolai]

Parsing this shows this line:

12/7/2004 7:24:31 PM: Finished Getting all sub categories for PhotoSoCal (0:00:01)
12/7/2004 7:24:31 PM: CategoryID=48284, SubCategoryID=48284, Title=test
....


So, instead of 0 we have first item 28284.

Don, it seems like an easy fix.. If you please?

Thanks!
The red line should read:
So, instead of 0 we have first item 48284.

[Nikolai]

In this branch I'm gonna post separate messages for each API I personally verified. Everybody is welcome to follow, so we can share the load:-).

[Nikolai]

works :thumb

[Nikolai]

works:thumb

[Nikolai]

works:thumb

[Nikolai]

works:thumb (Duh!:-)

[Nikolai]

works:thumb

[Nikolai]

works:thumb

[Nikolai]

works:thumb

[Nikolai]

works:thumb

[Nikolai]

works - both with extra info (version '1.0'):thumb and without it (versionless):thumb

[Nikolai]

works in versionless mode:thumb
adding ByteCount and/or MD5Sum digest (upper or lower case) result to "format error", code 4. :noob

[onethumb]

works in versionless mode:thumb
adding ByteCount and/or MD5Sum digest (upper or lower case) result to "format error", code 4. :noob


Hmm, well, I just uploaded a bunch of photos fine with both ByteCount and MD5Sum.

Can you send me your POST output or something? I think you must be doing something wrong.

Don

[Nikolai]

Confirmed:thumb

[Nikolai]

I finally got home and got my hands into the programm. Well, getAllSubCategories now returns somthing, but result is unusable.

Instead of providing Category ID, Subcategory ID and Subcategory Title, it uses subcategory id twice, thus making each id equal and the whole thing totally useless :-(

...skipped..
Don, it seems like an easy fix.. If you please?


Thanks!

[Nikolai]

- loginAnonymously now works as advertised. This means non-logged in smugmug users can now browse smugmug using your apps. No login required, but of course, various features and information will be locked.
I tested this tonite. I can login anonymousle, get the session ID - and then cannot do anything. Any method I tried returns "invalid user" error.
Methods I tried:

getAlbums
getCategories
Logout
I can understand the first two, but Logout ...

I have logs to prove my point, in case you need them...

Absolutely not a rush, but eventually would be nice to have this fixed..;-):deal

TIA

[Nikolai]

.. but I REALLY need getAllSubCategories to work...
Again, it simply uses the wrong id, looks like a typical copy-paste error..
I just tested it again - same thing...
Please? :bow

[onethumb]

.. but I REALLY need getAllSubCategories to work...
Again, it simply uses the wrong id, looks like a typical copy-paste error..
I just tested it again - same thing...
Please? :bow

Try it now.

Don

[Nikolai]

Try it now.

DonI works!!! :clap
Thank you very much!:thumb

Cheers!:1drink

[Nikolai]

Works!:thumb

[Nikolai]

If I try to enter more than one line, it returns a fornat error. I understand the reason (chars #13, #10 in the Description), but have no clue how to encode that properly. For now I'm gonnal just make it all one line, but eventually I' d like to see this resolved.
Don? maybe use base64? or some &.. stuff?
TIA

[onethumb]

If I try to enter more than one line, it returns a fornat error. I understand the reason (chars #13, #10 in the Description), but have no clue how to encode that properly. For now I'm gonnal just make it all one line, but eventually I' d like to see this resolved.
Don? maybe use base64? or some &.. stuff?
TIA

As long as you're sending properly form-encoded data, it should be fine. You can, for example, add multiline descriptions/captions in the HTML interface, which is an incredibly basic form POST.

Don

[Nikolai]

As long as you're sending properly form-encoded data, it should be fine. You can, for example, add multiline descriptions/captions in the HTML interface, which is an incredibly basic form POST.

DonThank you! I guess, my components do not take proper care of the stuff, even though I use proper ''multipart/form-data'' content type. But now I know where to look:-). I though I should use some kind of URI/URL/MIME/etc encoding...
I'll figure it out now..

Thanks!:thumb

[Nikolai]

At least for the albums.. Maybe it's different on different machines. Need to check it from home tonite..

[Nikolai]

At least for the albums.. Maybe it's different on different machines. Need to check it from home tonite..

Multiline album description (createAlbum) - works:thumb
Multiline image description - multipart upload (upload via POST) - works:thumb
Multiline image description - standard base64 upload (upload) - returns format error! :deal
Don, at this time I have only one question:

is this something which is easy to fix and gonna be fixed some time soon (say, this year:-),
or
you simply discourage everybody from using this method and we can forget about the whole problem
I personally have no issues with the latter:-), I can totally desurface it from UI and don't even leave it as an option.. I only want to know..

Thank you!

[Nikolai]

It lets me in, returns a session, but aftewards I don't seem to be able to do much. Here is an example of attempt to getAlbums (it should return list of public albums, right?):


Post to https://upload.smugmug.com/xmlrpc/

<?xml version="1.0"?>
<methodCall>
<methodName>loginAnonymously</methodName>
<params>
<param><value>1.0</value></param>
</params>
</methodCall>

Post results

<?xml version="1.0" encoding="iso-8859-1"?>
<methodResponse>
<params>
<param>
<value>
<struct>
<member>
<name>SessionID</name>
<value>
<string>265a4f4786718c8668db41464606db16</string>
</value>
</member>
</struct>
</value>
</param>
</params>
</methodResponse>

Logged in: Session: 265a4f4786718c8668db41464606db16; User: ; Hash:
Started Gettings list of albums

Post to http://upload.smugmug.com/xmlrpc/

<?xml version="1.0"?>
<methodCall>
<methodName>getAlbums</methodName>
<params>
<param><value>265a4f4786718c8668db41464606db16</value></param>
</params>
</methodCall>

Post results

<?xml version="1.0" encoding="iso-8859-1"?>
<methodResponse>
<fault>
<value>
<struct>
<member>
<name>faultCode</name>
<value>
<int>4</int>
</value>
</member>
<member>
<name>faultString</name>
<value>
<string>invalid user</string>
</value>
</member>
</struct>
</value>
</fault>
</methodResponse>



Am I missing something, or is this a bug?
Thanks

[Nikolai]

There was an interim problem with two new sort parameters, but it looks like it's been fixed.
Cheers!:1drink