Options
[RESOLVED] smugmug.images.getStats does not work
Nikolai
Registered Users Posts: 19,035 Major grins
Mod Edit: Logged as SmugBug
I was trying in the morning and just now: image getStats method does not work:-(
Albums stats return correct info. Image stats always return invalid user.
Don, any ideas? I do need this method..
What am I doing wrong?
Thank you!
I was trying in the morning and just now: image getStats method does not work:-(
Albums stats return correct info. Image stats always return invalid user.
Don, any ideas? I do need this method..
// I inserted spaces after "<" and before ">" to avoid vBulletin problems
Post to [URL="http://api.smugmug.com/hack/xmlrpc/"]http://api.smugmug.com/hack/xmlrpc/[/URL]
< ?xml version="1.0"? >
< methodCall >
< methodName >smugmug.images.getStats< /methodName >
< params >
< param >< value > session id here< /value >< /param >
< param >< value >< int > image id here < /int >< /value >< /param >
< param >< value >< int >4< /int >< /value >< /param >
< /params >
< /methodCall >
Response
< ?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 >
What am I doing wrong?
Thank you!
"May the f/stop be with you!"
0
Comments
Can I provide more info to help you to resolve this?
I kinda took "the leap of faith" with this particular API and the fact that it does not work as described hurts..:cry
Guys,
smugmug.images.getStats still does not work.
SM techsupport (Toni) says they have do not support API issues and I shall use this forum.
However, there is no single response here...
I would appreciate at least some reply, you know..
If you say it's not important enough for you to look at it and as such it's not gonna work in the nearest future - fine, I'll bite the bullet and do the "creative browsing" approach.
But I hate to be in a situation when the declared - i.e. promised by SM - functionality is just around the corner, while I'd have to take a 500 miles detour to get there otherwise. I already went that route with category management. It was a nice exercise, but I'd much rather spent that time doing more useful features, not reinventing the wheel..
Don, Baldy, JT?
Thanks..
I haven't been round much lately, been very busy..so development on my SmugBrowser has ground to a halt
I share ur frustration on timing...i am kinda glad that I am busy or I would be tearing my hair out as well.
Go the creative approach
Cheers,
David
SmugMug API Developer
My Photos
Thank you for the compassion:-) Actually, I'm particularly grateful to you for your advices on how to do that in a 'creative' way
Still wating for the "official" SM response....
Only Don can but he can't offer the few-hour turnaround we can to regular questions. He was at the MySQL conference the last three days immersed in talking to the MySQL engineers about scaling, etc. It would have been hard to yank him from his sessions, have him debug, get the testing team working on it, and push out a change and head back to the conference.
I didn't realize you were thinking about same-day turnaround for API bug fixes.
I'm sorry I don't have a better answer for you.
Doh, I hate to read posts like this.
Somewhere, some wires must have gotten crossed. Let me quote our hack section:
"Like a lab, things aren't perfect. Everything in these sections should be regarded as highly experimental and prone to change."
and
"This API is in the "work in progress" stage, as you can tell by it's presence in our hacks section"
I'll try to update the docs to be more specific about what we do and we don't support, but here's the breakdown:
I am the sole API developer and it's been a pet project of mine within the company. I love working on it, I love what Nik, Rutt, Omar, Ayush and everyone else have done with it, and I think the future is very bright.
I spend spare minutes of time on it, but remember, I'm the CEO, and I also have tens of thousands of other customers who have never used API (let alone know it exists) to think about. I don't have a lot of spare minutes.
The API is completely beta, completely unsupported, and completely as-is. There are NO promises of any kind, and I'm sorry if it appeared otherwise somehow. I'm confident all of that will change as it matures and becomes more widespread, but the fact of the matter is, it's currently a money-losing proposition, not a money-maker. I believe with all my heart that it WILL become a vital part of smugmug and will clearly become a money-maker - but we're not there yet.
I'm happy to work on bugs, fix things, and enhance the API. But I'm afraid you'll have to be patient with my time constraints - I was away from the office all week, and thus, had less time even than my normal time constraints allow. But asking Baldy, JT, or our wonderful customer support for assistance isn't gonna help - all the API goodness is in my lap.
Having said that, we have a few neat things in the works you should hear about soon. I think you'll like them.
I'll play with smugmug.image.getStats tomorrow. I doubt it's anything serious, so you should see a fix soon. Out of curiosity, is this REST or XML-RPC or both? (From now on, that info is vital).
Don
I wouldn't say that we are looking for same day turn around on bugs.
I understand that you guys are busy just like anyone else, for most part you guys are great with response times. However, there is the occasional problem that seems to drag on or issue that seems to get no (or very late/little) acknowledgement, and leaves the developer wondering if he is wasting his time.
Cheers,
David
SmugMug API Developer
My Photos
On one hand, I certainly appreciate the functionality the current API offers. But on the other, I don't think it's right to use statements like "it's beta - no promises" to justify a level of support far below the smugmug "standard". An API is not simply a feature that either works or doesn't, it's a tool that people will spend hours upon hours trying to use in ways that ultimately benefit smugmug! By providing inadequate support, it seems like smugmug is taking the good will and determination of others for granted. Surely you guys at smugmug have worked through enough of your own technical problems to know how unbelievably frustrating it is to encounter roadblocks and have to sit and wait for fixes and/or answers from a vendor that may never come.
I don't mean to complain too loudly here... like I said, I really appreciate the current API. And frankly, the support for it is at least not the worst I've ever seen. But I take smugmug's request for honest feedback at face value, so there it is. Please take it as constructive criticism.
Paul
Chris, thank you for your relpy!
It's the silence and uncertainty that delivers the most frustration..
Now that I know that the only person who can take care of that is
1) aware of situation
2) currently at the conference
I can set my expectations properly and switch to doing something else..
Cheers!
First of all, thank you very much for your time and your answer!
I know how busy it can get at the conference (and at work, too), so I really appreciate your response. Frankly, if I knew that you're away that would explain the "no-reply" thingie automatically and you would not have to hate reading my post that much:-)
As a professional developer I understand "betas", "priorities", etc.
I also understand that APIs not making money for SM directly yet.
However, come think of it, you have all us 3d party guys working our asses off to improve YOUR customers satisfaction and bringing more customers to YOU (just last week you got another Pro who signed up *solemnly* due to the API fact - here's your extra $100/yr right here and now). In essence, you have a whole team of senior developers working for you, and they are all self-managed and don't cost you a penny in salary. Most of us (if not all) are willing to work late hours, help you with testing (just ask!), etc...
And all we ask in return is a reliable communication channel. Not the fixes/improvements, mind you (although they would be nice to have sometimes:-) - just the feedback... And if the answer is "no" - that's fair, too. But the lack of the answer at all - that's what kills the spirit..
I'm excited to hear that
As you can see from my original post, it's an RPC-XML.
Just for the record, I built my engine on top of original RPC-XML functionality and bringing the REST just for kicks does not make a whole lot of business sense.
However, that all depends on their support. Originally you've said that they both will be supported in a same way. I got a feeling from this messages of yours that this may no longer hold true. Then I would use whatever method works.
I would prefer to stay within the same protocol, but if this is not possible for whatever reason - I'm fine, too.
Once again, thank you for your time, and I really hope to hear good news from you soon!
Cheers!
Very well said, Paul!
My feelings exactly!
No, you're not way out of line, because you don't have inside knowledge of how the company works. But I do, and I'm happy to share. Buckle up, here's the brutal facts.
The technical staff consists of two people: me and JT. JT does all the awesome UI elements you see on our pages, and I do everything else. Every new feature you see every week, I build with his help. There is no other developer who can work on the API because there are no other developers.
JT's the best in the business at what he does, but that's not hardcore development. Likewise, I totally suck at what he does, but I seem to be alright at building and maintaining complex websites.
To reiterate: There isn't anyone but me who can support this stuff. Also to reiterate what I said above, the API is a money-losing proposition currently. So I can't just go out an hire someone to handle the API, at least partially due to money constraints. We love you guys, but we are a business. I'm not going to risk my company's profitability (we are profitable) on an unknown gamble like this API.
Nikolai mentioned that he got a Pro to sign up because of the API. That's awesome, but let's face facts: $100 is $100. Any developer I would consider worthy to work on anything at smugmug, especially my API baby, is going to cost $100K+ per year in salary alone, let alone benefits, stock options, and other related costs. Figure $250K per year all told. Since that $100 isn't pure profit, we'd probably have to be *sure* of at least 5000 - 10000 Pro-level accounts signing up for the API per year to justify someone spending their entire time on the API. You mention 25% of their time, so assuming I had stuff for them to do the other 75% (which is a big if), we're still talking 1000-2500 Pro-level accounts per year at the very least.
We're just not there yet. I want to be there. Believe me, I do. But I have a responsibility to keep the service on it's track, running well, profitable and in no danger of closing. If I started to throw $250K around on extra developers, I wouldn't be keeping my duty to my customers and employees in mind.
Again, in the interests of good communication, I'm going to be brutally honest here. Given our time (and thus, budget) constraints, there are really only two options:
1 - Provide the API in a "beta, as-is" state and try to nurture and help our external developers as much as possible in my limited free time.
2 - Don't provide an API at all.
I hate to break it down like this, but the business reality (at this very moment) is just that. I chose #1, and I think it's the right choice, because I truly believe that some day in the (not-so-distant?) future, we'll have a full staff developing and supporting the API. Who knows, maybe we'll have smugmug Developer Conferences!
But today, there's just not enough time and budget. I leave it in your hands - Door #1 or Door #2?
This approach isn't rare, BTW. Flickr's API clearly states:
"Flickr services are experimental and are currently offered to outside developers on an ad hoc basis with no guarantee of uptime or availability of continued service. We reserve the right to disable access to external applications at any time."
Google's apps are in BETA stages for years, with zero support. I'm not saying either approach justifies what we're forced to do, but there is precedent. I'd like to be better than Flickr and Google about our APIs, but I'm afraid you have to give us time to build our core business first.
We are NOT taking the good will and effort of our developers for granted. I'm terribly sorry if it feels that way, and it's probably a communication problem on our end. There isn't any official support for the API at all, and it sounds like we didn't set expectations well enough for that. Someday, I'm sure there will be, but I've already elaborated enough, I think, on why there isn't today.
We value the honest, frank feedback we get immensely. It's key to our success, both present and future. Thank you!
Don
Thank you for the great post!
You said it yourself several times: API is your baby, and as such, cannot bring any food to the table now.
And, as it was mentioned before, the main problem is not the bugs, but the communication (or lack of thereof).
I hear you clearly that you can't afford another developer.
However it seems that you underestimate the resources you already have and not use - us.
Let's take consider a nominal case: you got some spare time and decided to roll out another API, smugmug.do.whatever. Why not post a message here (or shoot an email to us) that you're planning to do this, the parameters are such-and-such, response is so-and-so, ETA is 1..6..24..72 hours from now.
You know what would happen? By the time you're done you'll have 2-3 guys with that method wrapped up in whatever framework we use and ready to go.
You give us a go - and we jump on it, test it, provide you with a feedback - and in no time this particualr API will be tested and ready to use by everybody else. I cannot speak for everybody, but in my case wrapping up one method to a "testable" shape takes 30 minutes or less.
Unfortunately thus far the situation was a bit different.
Out of the clear blue sky you present us with the whole bunch of methods, and quite high percentage of them simply does not work - and we have no way to know which is which. Wrapping them all up may take days. We can too make mistakes - as far as we all have our day jobs, by the time we get to our SM projects we're pretty much running on fumes. One method works, another doesn't - whose problem is it - mine, yours? There is no way to tell..
And on top of that, you've just spent so much time writing them all that you simply MUST go back to you CEO/backoffice needs and take care of business. And that happens exactly during the time when we need you most..
I think a simple change to delivery practice can make a huge difference.
API is your baby - let's take "baby steps" approach. I much rather have 1 working api per week, than 20 non-working ones in one day.
And let us help you to take care of that baby!
Cheers!
Thank you for the honest answers. I had figured that you and JT were the only developers, but didn't want to "accuse" you of that. Obviously you guys are doing a great job for just two people (or four, or six!) but it would be great if there were more of you. Of course I don't expect you to lay out all of your financials, but if you say the business just isn't at that point, I'll believe you. I just think the API and budding developer network should be viewed as a way to leverage and strengthen the smugmug platform and provide features and functionality you don't have the time or resources to do yourself instead of as a money-losing proposition.
I have lots of other thoughts, but I'll just say thanks, and keep up the good work. Oh, and please don't sell your souls to the VC devil to get to the next level.
For what it's worth, your API support is better than Amazon's, and they don't have any excuses.
Something would have to go absolutely horribly wrong for us to sell our souls to a VC. They bang on our doors all day, and some of them we actually like a lot, but we're profitable and growing. No need to share.
I happen to think our API support is a lot better than most other online businesses. I know, since I've tried to integrate smugmug stuff with quite a few others. Bad docs (we're mildly guilty of this from time to time), nonexistent support, many don't even have informal forums like this one.
We'll keep improving, though. Being the best isn't good enough...
Don
Just wanted to tell you - please don't waste any of your time on this particular API, at least on my account.
It was pretty silly of me to request support for this API, since the "creative browsing" approach
1) works (got it working in less than two hours)
2) works about 100x faster than API-based one due to the lack of call-per-image overhead..
Sorry for the distraction, should not happen again.
The difference is that the HTML stats page changes periodically, which will completely break your "creative browsing" approach.
The albums page changed a lot just this week, for example.
Don
...but it does not look like I have any other option, does it...
Last night I got some first results on statistics download that I would like to share with you guys.
I downloaded statistical info on my own site for the last 12 months.
273 albums, about 9,000 individual images, all over my not very fast home Adelphia cable modem and 802.11g Wi-Fi.
I used API to get album stats and "creative browsing" for image stats.
It took almost exactly two hours to get the job done.
This makes one month about 10 min on average.
One album/one month come out with about 2 second on average (1 sec to get album summary, 1 sec to get images stats).
Since each API call constistently shows a turnaround rate of about 1 second, using smugmug.images.getStats API (provided it's fixed) to get individual images stats for this kind of task seems very unreasonable.
In my case 1 sec per image would mean 9,000 extra seconds per month = 2.5 hours per month = 30 hours for the year...:-(
I understand that this normally would be a one-time deal (initial sweep), after which people might use one-two month request only.
I also hear and understand Don's dislike for what he calls "monolithic" methods.
However, it seems to me that in this case one-image-stats-per-call instead of array-of-images-stats-per-call is an overkill.
Come think of it, album stats pages are served by SM servers on a regular basis (WITH the thumbnails!) and they don't seem to hurt anybody.
Similar API request - WITHOUT thumbnails! - should make a fraction of that load, let alone the fact nobody's going to use it very often..
Comments and questions are welcome:-)
Cheers!
That, and I'm still waiting for comments to be accessed throught the API.
-Mitch
We are starting to put more effort into the API now, but unfortunately I have been short on bandwidth right now. Over the next couple of weeks, I will be trying to determined the outstanding defects and make a push to get them fixed.
It would be a great help if you could raise the defect here.
Cheers,
David
SmugMug API Developer
My Photos
It said I didn't have permission to creat a child something or another. So, if figured i'd post here.
After this, I hope we'll see an ability to post/read comments for photos too. :-) :ivar
-Mitch
These days, I'm fixing API bugs as fast as I can. But I have to know about them.
I'll dig into this one, but your best bet is to open a SmugBug on it so we can find it, track it, and fix it easily instead of on some message forum thread that gets lost in the noise.
That goes for feature requests, too.
Don
Thanks,
Mark
http://smugmug.jot.com/WikiHome/WikiAccount
Portfolio • Workshops • Facebook • Twitter
SmugMug API Developer
My Photos