mark benedetto king wrote:
>On Wed, Jun 25, 2003 at 01:43:45AM -0400, Sergey wrote:
>
>
>>Current table-driven approach may actually be a better one, at least in
>>ra_dav's case. Maybe it's going to be a better decision then to recreate
>>"old" Neon interface on top of the "new" one? What I mean is the
>>(validate_cb, startelm_cb, endelm_cb)->service functions->(startelm_cb,
>>cdata_cb, endelm_cb) transformation done as part of either Subversion's
>>or Neon's code. Does this make any sense? Thank you!
>>
>>
>>
>
>Yes. I have started work on this by building a shim layer around
>the new interface so that the current table-driven approach can be
>used by ra_dav for the time being. See below for more details.
>
>If you'd like to take over the work on this, I can send you my diffs;
>I do have other issues that I should probably be working on instead.
>
Since this is a "beta" issue now, I assume I have some time to slide
into Subversion code. I expect to have some time during this weekend to
get started. Actually, I did get started and have done something before
I realized that it's better to implement the "shim layer" as you put it.
>
>I apologize if the following is a duplicate message; I am resending it because
>it does not appear to have made it to the list:
>
I only got it once.
>
>On Wed, Jun 25, 2003 at 12:27:39AM -0400, Sergey A. Lipnevich wrote:
>
>
>>So, the idea is that there are callbacks now accepting ne_xml_elm, and
>>they need to be redone for two-parameter-style calling, right? That
>>seems to make it simpler, actually. Thanks!
>>
>>
>>
>
>It's much worse than that. The entire contract has changed. Neon
>is not taking any ownership of validation, cdata accumulation, etc.
>Essentially, Neon has exposed the SAX parser. Unfortunately,
>libsvn_ra_dav is built pretty tightly around the old interface.
>
>What I've done is pull all the constants that we need and Neon used to
>define, but no longer does, into the SVN_RA_DAV_XML__ namespace, changed
>all the usage of the old constants to the new ones, and am writing
>svn_ra_dav__xml_push_handler, which will act as a shim around the new
>interface.
>
Could you please send this to me? These constants are one of the things
I bumped into. I was hoping they've just changed name, not simply
disappeared. Now I know ;-).
>This will make it easy to support neon-0.23.x as well as neon-0.24.x;
>I can conditionally make the new constants macros for the old ones, and
>have one pass-through implementation of svn_ra_dav__xml_push_handler.
>
Even better.
>When support for 0.23.x is phased out, we can start to refactor the
>code around the new interface.
>
There's for instance only other package in out distro that needs Neon,
it's davfs driver which I use to mount DAV resources in Linux (GNOME-VFS
refuses to support DAV over https), and that's about it. I think
generally there's not much dependency on Neon right now in other
projects, so Subversion can just mandate which version to use.
Thank you!
Sergey.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 26 21:10:52 2003