You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Daniel Shahaf <da...@elego.de> on 2012/04/24 16:08:49 UTC
Re: svn commit: r1329015 - in /subversion/trunk/subversion:
include/private/svn_ra_private.h libsvn_ra/editor.c
libsvn_ra/ra_loader.c libsvn_ra/ra_loader.h
Greg Stein wrote on Mon, Apr 23, 2012 at 22:47:43 -0400:
> On Apr 23, 2012 7:20 PM, "Hyrum K Wright" <hy...@wandisco.com> wrote:
> >
> > On Mon, Apr 23, 2012 at 4:55 PM, Greg Stein <gs...@gmail.com> wrote:
> > > On Mon, Apr 23, 2012 at 16:21, Hyrum K Wright <hy...@wandisco.com>
> wrote:
> > >> On Mon, Apr 23, 2012 at 12:52 PM, Greg Stein <gs...@gmail.com> wrote:
> > >>...
> > >>> Alright. It sounds like svn_ra.h has two purposes: stuff for
> libsvn_client,
> > >>> and stuff for all RA layers to use internally. Ugh.
> > >>
> > >> But the capability strings are part of the public API.
> > >
> > > Says who? Not server Ev2 support. The RA layer can isolate that, so it
> > > should not be "part of the public API".
> > >
> > > Mergeinfo support? Sure. But Ev2? Nah.
> >
> > The entire RA interface is part of the public API. The wire protocols
> > are the public interface to the server, particularly for those who
> > want to write their own clients and server. These strings are part of
> > that definition.
>
> Ah. There we go. That clinches it.
>
> It's too bad we don't have svn_wire.h. Right now, svn_ra serves both
> purposes, so yah... I guess it makes sense to leave it there, unless we'd
> like to start migrating appropriate pieces to a new header. Thoughts?
Haven't followed the thread, but we generally declared only the C API to
be public, while the wire API was considered "internal". (i.e., we'll
have to make it compatible to respect our 1.x-client/1.y-server promise,
but we don't officially support people writing their own wire clients,
etc, not through our libraries)
Re: svn commit: r1329015 - in /subversion/trunk/subversion:
include/private/svn_ra_private.h libsvn_ra/editor.c libsvn_ra/ra_loader.c libsvn_ra/ra_loader.h
Posted by Greg Stein <gs...@gmail.com>.
On Apr 24, 2012 12:29 PM, "Daniel Shahaf" <da...@elego.de> wrote:
>
> Greg Stein wrote on Tue, Apr 24, 2012 at 12:20:26 -0400:
> > On Apr 24, 2012 10:08 AM, "Daniel Shahaf" <da...@elego.de> wrote:
> > >
> > > Greg Stein wrote on Mon, Apr 23, 2012 at 22:47:43 -0400:
> > > > On Apr 23, 2012 7:20 PM, "Hyrum K Wright" <hyrum.wright@wandisco.com
>
> > wrote:
> > > > >
> > > > > On Mon, Apr 23, 2012 at 4:55 PM, Greg Stein <gs...@gmail.com>
wrote:
> > > > > > On Mon, Apr 23, 2012 at 16:21, Hyrum K Wright <
> > hyrum.wright@wandisco.com>
> > > > wrote:
> > > > > >> On Mon, Apr 23, 2012 at 12:52 PM, Greg Stein <gs...@gmail.com>
> > wrote:
> > > > > >>...
> > > > > >>> Alright. It sounds like svn_ra.h has two purposes: stuff for
> > > > libsvn_client,
> > > > > >>> and stuff for all RA layers to use internally. Ugh.
> > > > > >>
> > > > > >> But the capability strings are part of the public API.
> > > > > >
> > > > > > Says who? Not server Ev2 support. The RA layer can isolate
that, so
> > it
> > > > > > should not be "part of the public API".
> > > > > >
> > > > > > Mergeinfo support? Sure. But Ev2? Nah.
> > > > >
> > > > > The entire RA interface is part of the public API. The wire
protocols
> > > > > are the public interface to the server, particularly for those who
> > > > > want to write their own clients and server. These strings are
part of
> > > > > that definition.
> > > >
> > > > Ah. There we go. That clinches it.
> > > >
> > > > It's too bad we don't have svn_wire.h. Right now, svn_ra serves both
> > > > purposes, so yah... I guess it makes sense to leave it there, unless
> > we'd
> > > > like to start migrating appropriate pieces to a new header.
Thoughts?
> > >
> > > Haven't followed the thread, but we generally declared only the C API
to
> > > be public, while the wire API was considered "internal". (i.e., we'll
> > > have to make it compatible to respect our 1.x-client/1.y-server
promise,
> > > but we don't officially support people writing their own wire clients,
> > > etc, not through our libraries)
> >
> > Hmm. True. .../include/private/svn_wire.h then.
> >
>
> subversion/include/private/svn_dav_protocol.h ?
>
> (or is ra_svn involved too?)
Yah, probably ra_svn, too.
Re: svn commit: r1329015 - in /subversion/trunk/subversion:
include/private/svn_ra_private.h libsvn_ra/editor.c
libsvn_ra/ra_loader.c libsvn_ra/ra_loader.h
Posted by Daniel Shahaf <da...@elego.de>.
Greg Stein wrote on Tue, Apr 24, 2012 at 12:20:26 -0400:
> On Apr 24, 2012 10:08 AM, "Daniel Shahaf" <da...@elego.de> wrote:
> >
> > Greg Stein wrote on Mon, Apr 23, 2012 at 22:47:43 -0400:
> > > On Apr 23, 2012 7:20 PM, "Hyrum K Wright" <hy...@wandisco.com>
> wrote:
> > > >
> > > > On Mon, Apr 23, 2012 at 4:55 PM, Greg Stein <gs...@gmail.com> wrote:
> > > > > On Mon, Apr 23, 2012 at 16:21, Hyrum K Wright <
> hyrum.wright@wandisco.com>
> > > wrote:
> > > > >> On Mon, Apr 23, 2012 at 12:52 PM, Greg Stein <gs...@gmail.com>
> wrote:
> > > > >>...
> > > > >>> Alright. It sounds like svn_ra.h has two purposes: stuff for
> > > libsvn_client,
> > > > >>> and stuff for all RA layers to use internally. Ugh.
> > > > >>
> > > > >> But the capability strings are part of the public API.
> > > > >
> > > > > Says who? Not server Ev2 support. The RA layer can isolate that, so
> it
> > > > > should not be "part of the public API".
> > > > >
> > > > > Mergeinfo support? Sure. But Ev2? Nah.
> > > >
> > > > The entire RA interface is part of the public API. The wire protocols
> > > > are the public interface to the server, particularly for those who
> > > > want to write their own clients and server. These strings are part of
> > > > that definition.
> > >
> > > Ah. There we go. That clinches it.
> > >
> > > It's too bad we don't have svn_wire.h. Right now, svn_ra serves both
> > > purposes, so yah... I guess it makes sense to leave it there, unless
> we'd
> > > like to start migrating appropriate pieces to a new header. Thoughts?
> >
> > Haven't followed the thread, but we generally declared only the C API to
> > be public, while the wire API was considered "internal". (i.e., we'll
> > have to make it compatible to respect our 1.x-client/1.y-server promise,
> > but we don't officially support people writing their own wire clients,
> > etc, not through our libraries)
>
> Hmm. True. .../include/private/svn_wire.h then.
>
subversion/include/private/svn_dav_protocol.h ?
(or is ra_svn involved too?)
> ?
Re: svn commit: r1329015 - in /subversion/trunk/subversion:
include/private/svn_ra_private.h libsvn_ra/editor.c libsvn_ra/ra_loader.c libsvn_ra/ra_loader.h
Posted by Greg Stein <gs...@gmail.com>.
On Apr 24, 2012 10:08 AM, "Daniel Shahaf" <da...@elego.de> wrote:
>
> Greg Stein wrote on Mon, Apr 23, 2012 at 22:47:43 -0400:
> > On Apr 23, 2012 7:20 PM, "Hyrum K Wright" <hy...@wandisco.com>
wrote:
> > >
> > > On Mon, Apr 23, 2012 at 4:55 PM, Greg Stein <gs...@gmail.com> wrote:
> > > > On Mon, Apr 23, 2012 at 16:21, Hyrum K Wright <
hyrum.wright@wandisco.com>
> > wrote:
> > > >> On Mon, Apr 23, 2012 at 12:52 PM, Greg Stein <gs...@gmail.com>
wrote:
> > > >>...
> > > >>> Alright. It sounds like svn_ra.h has two purposes: stuff for
> > libsvn_client,
> > > >>> and stuff for all RA layers to use internally. Ugh.
> > > >>
> > > >> But the capability strings are part of the public API.
> > > >
> > > > Says who? Not server Ev2 support. The RA layer can isolate that, so
it
> > > > should not be "part of the public API".
> > > >
> > > > Mergeinfo support? Sure. But Ev2? Nah.
> > >
> > > The entire RA interface is part of the public API. The wire protocols
> > > are the public interface to the server, particularly for those who
> > > want to write their own clients and server. These strings are part of
> > > that definition.
> >
> > Ah. There we go. That clinches it.
> >
> > It's too bad we don't have svn_wire.h. Right now, svn_ra serves both
> > purposes, so yah... I guess it makes sense to leave it there, unless
we'd
> > like to start migrating appropriate pieces to a new header. Thoughts?
>
> Haven't followed the thread, but we generally declared only the C API to
> be public, while the wire API was considered "internal". (i.e., we'll
> have to make it compatible to respect our 1.x-client/1.y-server promise,
> but we don't officially support people writing their own wire clients,
> etc, not through our libraries)
Hmm. True. .../include/private/svn_wire.h then.
?