Greg Stein <gstein_at_gmail.com> writes:
> Hmm. I saw it more as private subsystems, or sharing data between
> client and server bits.
>
> The readme is kinda hard to argue with... Hmm. I'll take a look. It
> just seems that if a library needs functionality from another, then we
> should tweak the public api cuz somebody else may need it.
Making an API public is a commitment to maintaining it, including doing
the deprecation dance whenever we change it.
Meanwhile, when it comes to consuming Subversion APIs, Subversion's own
libraries are a special case. We know this from experience -- that's
exactly why we made the include/private/ headers in the first place.
There were things we wanted to use that it just seemed unlikely anyone
else would want. (And if people do want it, then the answer is easy: we
just promote it out of private/ and maintain it like any other public
API from then on.)
I mean, this wasn't something that got developed just for kicks. It
solved a real problem: that there was no level of accessibility between
library-internal and fully-public, even though we found we kept needing
that intermediate level of accessibility.
Now would be the time to come up with some concrete example, and I'm too
lazy (read: swamped) to do that :-). But if I haven't convinced you,
maybe I can dig around and find one...
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-20 23:14:44 CEST