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

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

Nikolai

Tiny description bug
http://www.smugmug.com/hack/xmlrpc-changeImagePosition

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

onethumb

Nikolai wrote:

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

Just finished first tests of new createAlbum!
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!

rutt

Small documentation bug
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

Unless I misread it..

rutt wrote:

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

rutt

Nikolai wrote:

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

rutt

rutt wrote:

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.

Nikolai

getAllSubCategories. Am I missing something?
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??

Nikolai

I agree, it's a bit confusing..
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

Nikolai wrote:

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)

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

Nikolai wrote:

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

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

rutt wrote:

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

OK, you're the boss:-)!

onethumb wrote:

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!

Nikolai

What am I doing wrong?
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]<?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>[/PHP]

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

Hmm, interesting..

rutt wrote:

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]
<?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>
[/PHP]

Don, can you please verify this?

Nikolai

Rutt, if you don't mind...
..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!

Nikolai

BUG: getAllSubCategories returns empty text
This old guy, getCategories, works fine:

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

The new guy,
[PHP]
<?xml version="1.0"?>
<methodCall>
<methodName>getAllSubCategories</methodName>
<params>
<param><value>75203105c43a6d2930d13b4c99ca779e</value></param>
</params>
</methodCall>
[/PHP]
while being almost identical with the exception of the method name, getAllSubCategories, returns nothing. Nada. Zero. Response is empty text.

Don, any clues?

rutt

Nikolai wrote:

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

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

Nikolai wrote:

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

Nikolai wrote:

This old guy, getCategories, works fine:

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

The new guy,
[PHP]
<?xml version="1.0"?>
<methodCall>
<methodName>getAllSubCategories</methodName>
<params>
<param><value>75203105c43a6d2930d13b4c99ca779e</value></param>
</params>
</methodCall>
[/PHP]
while being almost identical with the exception of the method name, getAllSubCategories, returns nothing. Nada. Zero. Response is empty text.<img src="https://us.v-cdn.net/6029383/emoji/deal.gif&quot; border="0" alt="" >

Don, any clues?

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

Don

Nikolai

I should've thought of that!!!

onethumb wrote:

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

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

Nikolai

Awesome! U Da Man!

onethumb wrote:

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

Don

Will test tonite, and, hopefully, get it working;-)
Thanks, Don!

Cheers!

Nikolai

50% there..

onethumb wrote:

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

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

• upload - works!
• upload via POST - still does not

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?

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

Nikolai

Not fixed as of 6:20 pm 06/12/2004..

onethumb wrote:

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

Don

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

rutt

Roundtrips with reSortAlbum and changeAlbumSettings
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
smugmug.py album_properties

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.

1. Have analogous calls for categories subcategories. All the albums in the given category/subcategory are resorted or have their properties changes..
2. 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 like it, but..
.. 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!

rutt

Nikolai wrote:

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

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

Nikolai wrote:

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

Fixes are up.

Don