Comments for "Services_urlTea"

» Submit Your Comment
Comments are only accepted during the "Proposal" phase. This proposal is currently in the "Finished" phase.
» Comments
  • Chuck Burgess  [2007-10-09 01:10 UTC]

    Looks clear enough... another good simple service tackled :)

    I'm curious though, contrasting this with _TinyURL... could this be the start of many small URL Shortener services that could all start following a top-level interface, where the specific implementations (TinyURL, urlTea) become almost "drivers" ?

    Just a thought to consider going forward. If say you built a top-level interface that all these new provider-specific implementations all followed, I could further picture them being used in combination with each other as backups for each other. Meaning, if I built an app that used your URL Shortener package(s), I could program my code just against your interface, with config options set to utilize X number of your provider implementations (round-robin, or 1stChoice-2ndChoice-etc) and all those providers could implicitly back each other up if any are unreachable or down.
  • Joe Stump  [2007-10-09 04:43 UTC]

    This was a thought I had about 20 minutes after proposing the package. It'd be fairly trivial to roll them up into a single package, but I think that packages for individual services should remain stand-alone mainly for marketing reasons. I'm open to a package sitting on top of them though.
  • Till Klampaeckel  [2007-10-09 14:32 UTC]

    Looks good to me!

    I am not in favour of "hub classes" and the like. I think those service classes should stay as small and flexible as possible. Maybe a common naming scheme (Services_Url_TinyUrl, Services_Url_urlTea, ...) would be more appropriate than adding class dependencies and object factories.

    The reason why I am not in favour of a driver-style architecture here is because I am not so sure if they really offer the same feature set. Basically, they all shorten URLs, but do they all have a preview feature like TinyURL (btw, is that API-acessable?), etc..

    And my second argument would be K.I.S.S. (not the band ;-))! :)