API hack examples
WTL
Registered Users Posts: 2 Beginner grinner
Hi all.
Been thinking about doing my own Smugmug API hack - just a basic one to pull an album, but I'm not much of a programmer and my language of choice (CF) isn't available to me...so it's all a big learning curve :rofl
Anyway - it'd be good to compile a list of what other people have already done. Early days I know, but bear this thread in mind if & when you want to share your hacking genius with fellow SmugMuggers!
Will
[who's off to learn XML-RPC and PHP]
Been thinking about doing my own Smugmug API hack - just a basic one to pull an album, but I'm not much of a programmer and my language of choice (CF) isn't available to me...so it's all a big learning curve :rofl
Anyway - it'd be good to compile a list of what other people have already done. Early days I know, but bear this thread in mind if & when you want to share your hacking genius with fellow SmugMuggers!
Will
[who's off to learn XML-RPC and PHP]
0
Comments
It's not ready yet, but verrrry close to alpha on phase 1.;-)
It's gonna use all the available SmugmugAPI - on windows (2000/XP) only, though...
Rutt already created a nice Python script - it might be a good starting point in you're into scripting.
Cheers!
Will
I'm developing a Smugmug backend to allow automatic communication of images as a library. I'm writing primarily in C#, but also using Java and C++.
Primary use is for some imaging software that I'm developing:
- Automatic image processing for things like auto-stacking, auto-allignment etc.
- Easy communication of outputs from a research genetic imaging system
However it should also be useful as a general communications add-on and image management system. It should also allow such facilities as auto-backuping/mirroring, statistical analysis of viewing overtime, trend analysis etc. All the general stuff that you want from a management and statistical analysis point of view.
All projects that I'm currently working on have been delayed by a period of RSI enforced break [3 months and counting ], consequently such systems are in research/Rapid Prototype phase and I'm currently mainly concentrating on software development systems that can be used without keyboard or mouse(!).
However I would envisage an extensible architecture were components can be swapped over to XML-RPC as more functionality becomes available.
I have the statistics about analyser acquiring data now, and much of the high-performance imaging code is ready and the interfaces are designed, much of the work is now just pending some code 'hacking'
Keep in touch with how it goes,
Luke
SmugSoftware: www.smugtools.com
Nikolai,
Which version of Delphi are you using?
If the newer versions, are you targetting native x86 or .NET MSIL?
Luke
SmugSoftware: www.smugtools.com
Would be totally sweet to have all this..
However, for now, it would be REALLY great to have just a little bit more control on data retrieval and upload.
From all my extensive playing with the existing API during the last few days (and I mean EXTENSIVE:-), the only things we can reliably do now are:
- login/logout
- get list of albums (along with relevant categories and subcategories)
- get list of categories
- get subcategories for one (ONE!) category. Attempt to create the whole category/subcategory tree takes about a minute over a decent DSL connection (get the list of categories; enumerate them all, for each caetgory issue a request for the list of subcategories - you know the drill:-)
- create an album (with the smugmug default settings - none of the API-mentioned gallery-related parameters works:-()
- upload an image to an existing album - Base64 encoded or not (about 20%-30% performance difference, purely because of the xfer size)
- that's all folks:-)!
Things I would really appreciate to have asap:- fix createAlbum
- add API for getting list of all existing subcategories with the categories, so we don't have to issue dozens/hundreds of getSubCategories statements
The rest can wait:-)Thanks again for the insight, I truly appreciate it!
The reason I didn't start the whole .NET with this pet project was because of the smugmug API size. I am kinda new to .Net, and it would take me a long time just to get the basics. In win32, however, I'm a king:-). And the whole RPC-XML thingie took me only about a day to "wrap" into nice OO framework:-)
I'm definitely looking forward towards .NET, but so far i would not feel comfortable to switch. At work we still are stuck with D5 for the 60% of our codebase, if you can believe it;-)
Besides, Delphi 2005 is so darn expensive, and so far company does not make any intention to upgrade. We're lucky to have one copy of D7..;-(
Did I answer your question?
Nikolai,
Sure that makes sense. There are issues with the way Smugmug uses RPC-XML that cause compliance difficulties with the standard implementation that I've looked at. The communications channel that I've seen couldn't do error interception and exception cascading, so it was effectively having return type polymorphism difficulties. This was what I meant when I said that my current approach wasn't working, I'll have to re-wrap the APIs I think...
There is a learning curve with .NET but I have found it to be easier than Win32 generally once you've got used to it. The Framework libraries are also relatively good.
:-( Bad luck
I was very disappointed to see their Delphi 2005 was only targeted at.net 1.1. I think this pretty much invalidates Borland's arguments about getting there quicker than Microsoft. I don't know great deal about Delphi the language, but I see the big deal with 2005 being generics and managed languages, both Sun and Microsoft will have offerings out, I'm somewhat disappointed if Borland will not be amongst them, especially at the price they are asking.
Ah well with got a while before Longhorn comes out of makes manage code essential...
Yup, thanks.
SmugSoftware: www.smugtools.com