--On November 28, 2005 9:54:44 AM -0600 kfogel@collab.net wrote:
> Sure -- I'm also proposing that they be kept separate. All I meant
> was, reorganize libsvn_ra_dav/ to have two separate subdirs:
>
> libsvn_ra_dav/neon/ <-- for everything currently in libsvn_ra_dav/
> libsvn_ra_dav/serf/
>
> The above change sounds major, but it's pretty trivial to implement.
> The compile-time switch would determine which subdir gets used.
I guess we have a gap on just how difficult this would be to implement in
the build system. Are you seeing a short-cut I'm not seeing? The build
system *could* make that choice at autogen.sh, but I'm not seeing an easy
way to do it at configure-time because gen_make walks all of the
dependencies at autogen-time.
I think we're in agreement that neon and serf can't *both* be loaded at the
same time because they both want control over the http/https scheme. I
don't think an 'agent' system like what ra_svn does makes sense here.
Plus, if we have a library that has the same name but could have two
completely independent implementations, I'm very concerned that it would
present difficulties on a user-support issue.
> By putting them both under libsvn_ra_dav/, we'd make the layout
> reflect reality, namely, that we have two different implementations of
> the DAV protocol.
Like we have libsvn_fs_fs and libsvn_fs_base, I could see
libsvn_ra_dav_neon and libsvn_ra_dav_serf. But, I'd be wary of having the
library name not clearly indicate what client library we'd use. I've also
been trying to avoid forcing a rename in libsvn_ra_dav as I haven't thought
through the consequences on our compatiblity rules if we remove that
library. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 28 21:46:22 2005