Sorry, hard to respond inline.
Yes, i've already assumed it is incumbent on me to suggest any change.
The current arrangement makes sense, tho it makes me a but
uncomfortable. It's on me, so don't waste ur time.
Cheers,
-g
On Sep 20, 2008, at 17:14, Karl Fogel <kfogel_at_red-bean.com> wrote:
> 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-21 02:40:52 CEST