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

Now I have to redo everything...
Just kidding!
Thank you very much!
Cheers!

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

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

Originally Posted by Nikolai 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

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


<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?
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 , so for me personally it's nothing;-)

Cheers!

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!

Originally Posted by 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.

...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!

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

Originally Posted by Nikolai ...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. I think you are confusing with the login method, here.

Originally Posted by rutt No, take a look here. I think you are confusing with the login method, here.

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.

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:

1. getCategories (to get names and IDs)
2. 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??

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.

Originally Posted by 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)

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?

Originally Posted by 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??

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

Originally Posted by rutt 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

Originally Posted by onethumb 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

At 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!

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):

PHP Code:

<?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!

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.

Originally Posted by 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.

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:

PHP Code:

<?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?

..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 . 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!

This old guy, getCategories, works fine:

PHP Code:

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

The new guy,

PHP Code:

<?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.

Don, any clues?