I want to change the http interface

[Mark Canonical Ramm-Christensen]

On Tue, Oct 15, 2013 at 5:29 AM, William Reade
<william.reade at canonical.com>wrote:

> On Thu, Oct 10, 2013 at 6:31 AM, David Cheney <david.cheney at canonical.com>wrote:
>
>> Thoughts ? And while we're at it, why isn't there a schema for
>> interfaces as there is for the configuration of a provider ?
>>
>
> * I'm definitely not keen on creating a new interface to handle this
> situation -- if there's a compelling case for a "super-http" interface,
> then there's little reason for a charm author to implement "http" as
> well... except that their charm won't work with others that require plain
> old "http".
>


I know that this is less than optimal, but I'm not sure it's that much of a
problem.  Having multiple API's with the same name is painful, and
enforcing name-to-api uniqueness seems reasonable to me.  On the other
hand, there is a fixed, flat namespace for interfaces, and if we lose the
name http to an old deprecated interface, and have to tell everybody to use
the new multi-proxy interface instead, that hurts as the namespace is now
polluted.   Ultimately 20 year down the line we could end up like  httplib,
httplib2, and urllib, and urllib2 all in the python standard library,
creating confusion.

Fortunately though, I'm not seeing large scale pressures to change
interfaces, so I don't know that this is a huge problem. The scope of a
charm interface as an API is somewhat limited, and there aren't huge
numbers of cases where *lots* of charms all implement an interface that
we'd like to change in some way.  And even with the "horror case" of
python, it took 20 years to get there, and it clearly has not impeded the
success of the language overall.


> But I'd rather not encourage a profusion of almost-identical interfaces --
> it's good for charms to be "sticky", but it's unrealistic to expect that
> they all be, uh, multiply-sticky(?) -- I want authors to be able to provide
> *one* interface for a single purpose, lest the ecosystem become irreparably
> balkanised.
>

I agree, though I think there is a case for limiting this "extension" to
the ability to extend interfaces in backwards compatible ways, and possibly
version them to allow depreciation of old versions over time.

--Mark Ramm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20131015/5414fd11/attachment.html>