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.
Cheers,
-g
On Sep 20, 2008, at 11:18, Blair Zajac <blair_at_orcaware.com> wrote:
> Greg Stein wrote:
>> On Fri, Sep 19, 2008 at 11:09 PM, Blair Zajac <blair_at_orcaware.com>
>> wrote:
>>> Greg Stein wrote:
>>> Presumably being in include/private means it can be used across
>>> lib's.
>> This isn't right... Our libraries should not have privileged access
>> to
>> certain APIs that other users cannot reach. IOW, all 38 lines must
>> change :-P
>
> That's the purpose of all the headers in private:
>
> $ cat subversion/include/private/README
> Header files in this private/ directory are for internal APIs shared
> across Subversion's implementation. They are not part of the public
> API, nor are they ever copied into or under the include/ directory
> (e.g. by the installation process).
>
> You're effectively suggesting removing the entire include/private
> directory and promoting all the functions to public. Why would we
> want to do that? There may be APIs that we only want to support
> internally and not have the maintain in a public API.
>
> The only case I see for changing this is if we were to allow our
> libraries to be versioned independently so if you chance a private
> API without versioning it you can break the ABI, but we don't do
> that, so if we change a private API, it'll still be internally
> consistent across all the libs.
>
> I don't feel that strongly about it, as long as I can use the
> functions I need to make my coding easier :)
>
> Blair
---------------------------------------------------------------------
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 18:43:39 CEST