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 ;-))! :)
|
