Are Web Services coming?

3rdPlanetPhotography3rdPlanetPhotography Banned Posts: 920 Major grins
Hello Smugmug,

Love the service and the ability to interface. I'm a .NET developer and would love to see consumable web services from SmugMug. Any chance this technology is in the future?

Thanks
kc7dji

Comments

  • AndyAndy Registered Users Posts: 50,016 Major grins
    edited November 25, 2005
    Can you elaborate some more? ear.gif
  • 3rdPlanetPhotography3rdPlanetPhotography Banned Posts: 920 Major grins
    edited November 25, 2005
    Thanks Andy, Sure.

    I didn't go very far because I don't know what's behind the scenes at Smugmug. Web Services are available in many environments, however, I'm a Microsoft Certified programmer so I'm only familiar with the Microsoft end of the spectrum. Web Services are sorta like the API interface but with much more ease and flexibility.

    With the API's my application must set the stage, send to smugmug, recieve the response then un-chunk the data from the xml format. I have been able to write a couple of generic classes that will interface with Smugmug with ease, however, moving foward the use of Web Services would make our 3rd party development much faster and more dependable (my opinion).

    With Web Services basically I tell my programming environment about the Smugmug service(s) then from code I utilize that service just as it was a local class. This is awesome technology.

    Thanks
    kc7dji
  • luke_churchluke_church Registered Users Posts: 507 Major grins
    edited November 26, 2005
    Hi kc7dji,

    So I'm not from Smugmug, but have been hacking around with it for quite a while, writing generic wrappers and the like. I'm also primarily a .NET and Java developer.

    Let me see if I can give you some unoffical context.

    But first, from your post:
    kc7dji wrote:
    Web Services are sorta like the API interface but with much more ease and flexibility. [/kc7dji]

    Ease yes, certainly, especially from heavy-weight systems like .NET and Java, but flexibility, not really. XML-RPC is just as expressive as SOAP isn't it?

    (Unless you're considering all the WS-* protocol descriptions. But thankfully for our sanity, they're probably not relevant with Smugmug)
    With the API's my application must set the stage, send to smugmug, recieve the response then un-chunk the data from the xml format.
    Or use a library to do it? You'll have to do all this and more with WSDL+SOAP, it's just that .NET does it all for you :-) (And very nice it is to)
    With Web Services basically I tell my programming environment about the Smugmug service(s) then from code I utilize that service just as it was a local class. This is awesome technology.
    Yes and no, it's basically just a more complex standard with some tool support.

    Anyhow, I was thinking the same thing, back in the day, as I dislike writing tedious boilerplate code, which one is currently forced to do.

    However, OneThumb (chief techy at Smugmug) seems to be inclined to the hacker perspective, as opposed to the heavy-weight deverloper perspective.

    SOAP can be a real pain to talk from a hacker style language, if I remember correctly (and it's over a year since I read the specs) it's more finickity about where you put the data, the structuring etc. Whereas XML-RPC is a very simple specification making it much easier to just throw the data around without worrying quite so much about semantic allignment.

    If you're in doubt as to the relative complexity, compare the length of the specs. I believe XML-RPC is a couple of pages!

    His opinion was expressed here: http://www.dgrin.com/showthread.php?t=9030&page=3&pp=10

    OK, so that's the bad news, if OneThumb doesn't like SOAP I guess there isn't a great deal of chance for WSDL + SOAP...

    This is a shame for us people who talk from heavy-weight languages, but I'd rather see Smugmug get a small interface right and close to complete than a larger more complex interface that's riddled with SOAP semantics violations. (This being another point, have you ever tried to debug the result of what happens if you get .NET's magic SOAP proxy trying to talk to a partially SOAP compliant server? I hope for your general sanity that the answer is no....) :):

    The Good News is that if you can hand on a few more weeks longer I have an API that wraps the whole of the Smugmug API into a .NET framework envelope coming out that will save you a whole lot of very tedious coding...

    (About 7000 lines, including tedious error handling and 'method contains bugs, you can't use it' demarkations...)

    So yes, I share your pain, but you may not have to suffer for much longer...

    Hope this helps,

    Luke
  • 3rdPlanetPhotography3rdPlanetPhotography Banned Posts: 920 Major grins
    edited November 26, 2005
    Luke,


    Thanks for the long reply :) Yea I've been doing this stuff for 13 years and coming from the VB world I've seen the changes and watched our programming environments morph into something great. I've lived the pain of SOAP as you and all the rest have.

    I've mangaged to write some pretty nice classes in C# that wrap some of the API calls into simple usable classes for my program. I really should (before it gets much larger) break some of that away and put it into a library. Maybe that will be the task this weekend :)

    I was just thinking how nice it would be to be able to consume a smugmug webservice and utilize it directly. I work in a large heavy environment and we have many webservices that serve our needs.... they sure are nice.

    Thanks again for the reply and maybe we can swap notes.

    I'm on MSN messenger: kc7dji@hotmail.com

    Scott
    kc7dji
  • luke_churchluke_church Registered Users Posts: 507 Major grins
    edited November 27, 2005
    Thanks again for the reply and maybe we can swap notes.
    Sure. Unfortunately I can't use instant messaging software (I have to be somewhat careful with typing, the plauge of RSI), so email is much better for me.

    If you click on my profile you'll find an email address.

    Cheers,

    Luke
Sign In or Register to comment.