Re: [xslt] Relase of xsldbg-0.7.9, : release of xsldbg-0.8.1

[Daniel Veillard <veillard redhat com>]

On Fri, Nov 30, 2001 at 07:15:15AM +0000, k_isdale@tpg.com.au wrote:
> Hi ,
> 
> Daniel wrote, 
> >   Hum, I don't remember removing anything. I applied 
> your last patch that's 
> > all...
> > 
> Ok I'm not sure how it happened I did a diff on my 
> working checkout of libxslt using cvs.

  Okay, then it might be my fault :-)

> >   I think this just won't work with most compiler 
> chains. When module A and
> > module B are in the same library, most linkers resolve 
> statically references
> > from A to B when generating the library, shared or 
> not. This construct is
> > doomed to fail on most platform/compiler chains 
> whether the libraries are
> > shared or not.
> That's bad!  I'm look forward to seeing how the call 
> back registration is done. And will conform to use of 
> callbacks as soon as possible.

  Basically I'm tempted to do somthing similar to the SAX
interface of libxml. The upper layer provide a "driver" block
containing all the callback routines. And when of the routines
are called from the lower level, it checks if the current callback
is non-NULL and simply call it.
  Very simple, very flexible, and adds only a single entry point
to the library.

> > It's the wrong approach to the problem. Using the 
> linker to put in place an
> > overtride mechanism was just plain wrong. I should 
> have been more careful
> > I really expected the breakpoint code to be the 
> actual implementation not
> > dummies references to functions possibly 
> implemented by other modules.
> It wasn't planned this way I thought the breakpoint API 
> was to stay in libxslt. But that lead to a dead end ... 

  Okay, the current situation is the following:
    - being uncareful, I activated the breakpoint library by default
      and now a bunch of released applications relies on this shared
      library being present. I goofed, and must maintain at least for
      1+ year libxsltbreakpoint.so.1 even if it does nothing.
    - it seems to me there is only a few callbacks in the libxslt library
      which really need to be handled to have the debugging framework
      usable.
    - the best is to give you back control on top of this set of
      entry points which would be the set of callbacks. That way new
      versions of libxslt would not need the dependancy on libxsltbreakpoint

  So if this looks okay, I suggest:
    - to provide a debugger callback installation routine in libxslt
      based on a "SAX like" approach, currently it seems only 
      xslHandleDebugger() would need to be forwarded. But I would
      prefer to still use a block of callbacks so 'if needed' we can
      add more interfaces without changing the API or breaking the
      bianry compatibility.
    - to provide a local implementation  of the current set of routines
      needed for the debugger use in libxslt:
       + xslHandleDebugger
       + xslAddCall
       + xslDropCall
      did I miss something ?
    - as a result, drop the dependancy on libxsltbreakpoint

  Does this looks okay ? If yes, then writing the code is easy, a couple
of hours will do.

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/