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!
Sergey.
Scott Lamb wrote:
> On Tuesday, Jun 24, 2003, at 17:48 US/Central, Sergey A. Lipnevich wrote:
>
>> Greg Stein wrote:
>>
>>> On Mon, Jun 23, 2003 at 07:52:26PM -0400, Sergey A. Lipnevich wrote:
>>>
>>>> ...
>>>> Also, I saw that Neon 0.24.0 is out, and tried compiling it with
>>>> Subversion. This fails because there's no more type ne_xml_elm in Neon.
>>>
>>> Please go ahead and file an issue. As far as where to start: just start
>>> looking for compilation errors :-)
>>
>> That's easy because we're a source-based distro, they come out right
>> away when I try to install Subversion ;-). If you have time, could you
>> please describe a general idea of how to migrate from ne_xml_elm to
>> "callbacks" that are now used in ne_xml.h? Here's what's in now:
>
>
> From that log message, it sounds like the callbacks are not new; they
> just take new argument types. A callback is just a function pointer that
> the library user provides to the library for pluggable behavior. I'm not
> familiar with Neon, but it sounds like all that needs to be done is
> switch a few function prototypes and variable references to remove a
> "mystruct->" or similar.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 25 20:01:30 2003