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.
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:
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.
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.
When support for 0.23.x is phased out, we can start to refactor the
code around the new interface.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 26 00:55:46 2003