Proposal for Web Services::Services_urlTea

Joe Stump (http://pear.php.net/u
ser/jstump) proposes Web Services::Services_urlTea.

You can find more detailed information here:
 http://pear.php.net/pepr/pepr-proposal-show.php?id=511


-- 
Sent by PEPr, the automatic proposal system at http://pear.php.net

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Joe Stump (http://pear.php.net/u
ser/jstump) has edited the proposal for Web
Services::Services_urlTea.

Change comment:

Change the license to the BSD Style License (New BSD to be
specific).

Please review the proposal:
http://pear.php.net/pepr/pepr-proposal-show.php?id=511


-- 
Sent by PEPr, the automatic proposal system at http://pear.php.net

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Chuck Burgess (http://pear.php.net/
user/ashnazg) has commented on the proposal for Web
Services::Services_urlTea.

Comment:

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.

Proposal information:
http://pear.php.net/pepr/pepr-proposal-show.php?id=511


-- 
Sent by PEPr, the automatic proposal system at http://pear.php.net

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Joe Stump (http://pear.php.net/u
ser/jstump) has commented on the proposal for Web
Services::Services_urlTea.

Comment:

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.

Proposal information:
http://pear.php.net/pepr/pepr-proposal-show.php?id=511


-- 
Sent by PEPr, the automatic proposal system at http://pear.php.net

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Hey Joe,

If they have similar fingerprint for the methods it should
be fairly
easy for a user to swap them out if needed.

-Philippe


Joe Stump wrote:
> Joe Stump (http://pear.php.net/u
ser/jstump) has commented on the proposal for Web
Services::Services_urlTea.
> 
> Comment:
> 
> 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.
> 
> Proposal information:
> http://pear.php.net/pepr/pepr-proposal-show.php?id=511


-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

On Tue, Oct 09, 2007 at 12:52:12AM -0400, Philippe Jausions
wrote:
> Hey Joe,
> 
> If they have similar fingerprint for the methods it
should be fairly
> easy for a user to swap them out if needed.
> 
> -Philippe
> 
> 
> Joe Stump wrote:
> > Joe Stump (http://pear.php.net/u
ser/jstump) has commented on the proposal for Web
Services::Services_urlTea.
> > 
> > Comment:
> > 
> > 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.
> > 

If they have a similar fingerprint, as Philippe is
suggesting, it would be
simple enough to devise a 'meta' package that utilises them
as drivers as per
your own comments.

Then you have yet another package to market...

k.

-- 
Ken Guest
Mobile: +353 86 8252 141    http://blogs.linux.ie
/kenguest/
Irish PHP Users Group       http://www.php.ie

On 10/9/07, Ken Guest <kenlinux.ie> wrote:
>
> If they have a similar fingerprint, as Philippe is
suggesting, it would be
> simple enough to devise a 'meta' package that utilises
them as drivers as
> per your own comments.
>

Exactly what I was getting it by have a "Services"
level interface, and I do
mean "interface" rather than "class".  I
was trying to describe it that way,
guess I blew it :P

Services - interface to certain set of methods
-                - all methods can remain static...
-                - final optional arg to each method could
be a marker to
-                      denote "use service X", but
defaults to "use any
available service"
-                           - create() - defaults to using
any available
service, or optional arg can specifiy service to use
-                           - lookup() - can determine based
on $url which
service to lookup against

Services_TinyURL - implement Service interface's methods
Services_urlTea    - implement Service interface's methods
Services_NextOne - ...
Services_AndAnotherOne - ...

-- 
CRB

Let me introduce you to my very own DMCA-protected
encryption key:
BC 1B 64 4A 8D DE 49 E8 C3 7D CC EE 1A AD EE F5
(compliments of Freedom-to-Tinker http://www.f
reedom-to-tinker.com/?p=1155)

Chuck Burgess wrote:
> On 10/9/07, Ken Guest <kenlinux.ie> wrote:
>> If they have a similar fingerprint, as Philippe is
suggesting, it would be
>> simple enough to devise a 'meta' package that
utilises them as drivers as
>> per your own comments.
>>
> 
> Exactly what I was getting it by have a
"Services" level interface, and I do
> mean "interface" rather than
"class".  I was trying to describe it that way,
> guess I blew it :P

That can be a another step. Experience shows that trying to
design 
top-level first does not work that well 

-- 
Arnaud.

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

On 10/9/07, Arnaud Limbourg <arnaudlimbourg.com> wrote:
>
> That can be a another step. Experience shows that
trying to design
> top-level first does not work that well 
>

True ;)

I was just broaching the subject to be sure Joe had it in
mind going
forward.  He's built two Service implementations now, and
usually I'll start
looking at a potential interface when I've built a second or
third
implementation of something similar (I'm doing that now with
a file transfer
interface, with SCP and SFTP implementations to start
with).

If each of his next implementations (you are making more,
right Joe ;)
intentionally uses the same API calls by proactive design,
then it will be
easier to later wrap an interface around them all. 
Otherwise, it would mean
BC breaks in the API just to build the interface.

I wasn't meaning do the interface now :P   That would slow
down getting this
second implementation accepted.--
CRB

Let me introduce you to my very own DMCA-protected
encryption key:
BC 1B 64 4A 8D DE 49 E8 C3 7D CC EE 1A AD EE F5
(compliments of Freedom-to-Tinker http://www.f
reedom-to-tinker.com/?p=1155)

Chuck Burgess wrote:
> On 10/9/07, Arnaud Limbourg <arnaudlimbourg.com> wrote:
>> That can be a another step. Experience shows that
trying to design
>> top-level first does not work that well 
>>
> 
> True ;)
> 
> I was just broaching the subject to be sure Joe had it
in mind going
> forward.  He's built two Service implementations now,
and usually I'll start
> looking at a potential interface when I've built a
second or third
> implementation of something similar (I'm doing that now
with a file transfer
> interface, with SCP and SFTP implementations to start
with).
> 
> If each of his next implementations (you are making
more, right Joe ;)
> intentionally uses the same API calls by proactive
design, then it will be
> easier to later wrap an interface around them all. 
Otherwise, it would mean
> BC breaks in the API just to build the interface.
> 
> I wasn't meaning do the interface now :P   That would
slow down getting this
> second implementation accepted.

Indeed, discussing that beforehand cannot hurt 


-- 
Arnaud.

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php