apr_xml (was: Re: libaprutil.la, libexpat.la, APRUTIL_EXPORT_LIBS)

[Greg Stein <gs...@lyra.org>]

[ back from a couple days off... ]

Yes: the apr_xml code is currently set up to just use Expat. However, the
intent is that it can be covers for other XML parsers. In particular, Xerces
and libxml would be great options.

And yes, the API is also based a very lightweight tree structure, rather
than event-based. Adding a second set of APIs to set handlers would be a
Good Thing, so please feel free to submit patches to do so.

The insertion of "DAV:" into the set of namespaces is definitely a negative,
but I haven't bothered to spend time to resolve the issue. That is about the
only DAV-specific thing in the whole set of apr_xml routines. The rest is
generally applicable to other problem domains.

The point is: the code originated as part of mod_dav, but it has been
extracted so that other code can use it (config reading? new modules? etc).
However, somebody just needs to spend a bit of time to sand off the rough
edges and to expand the APIs based on what people may need.

Cheers,
-g

On Thu, May 17, 2001 at 08:07:11AM -0700, Ian Holsman wrote:
> I think it is more than that.
> I was trying to get apr_xml usable as a xml_parser 
> the apr-xml api, doesn't provide any hooks so that I can
> be notified when I get an element, (which expat has) and
> is currently hard coded for 'DAV' only.
> 
> in order to be usefull it needs a couple more functions
> to set the start handler, namespace (on create) and to navigate
> the tree a bit better.
> 
> 
> > -----Original Message-----
> > From: Jeff Trawick [mailto:trawickj@bellsouth.net]
> > Sent: Thursday, May 17, 2001 4:37 AM
> > To: Ian Holsman; gstein@apache.org; dev@apr.apache.org
> > Subject: Re: libaprutil.la, libexpat.la, APRUTIL_EXPORT_LIBS
> > 
> > 
> > Ian Holsman <Ia...@cnet.com> writes:
> > 
> > > Expat is used by the 'apr_xml' set of routines inside of apr-util
> > > which look hard coded to work only for mod_dav.
> > > 
> > > you could always move expat and the apr_xml stuff into the mod_dav
> > > module directory.
> > 
> > (I don't know what I'm talking about but) maybe
> > apr_xml_parser_create() needs a parameter to specify the namespace?
> > (Or maybe this is an expat-specific concept and we don't want to tie
> > the apr-util API to expat?)
> > 
> > -- 
> > Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
> >        http://www.geocities.com/SiliconValley/Park/9289/
> >              Born in Roswell... married an alien...
> > 

-- 
Greg Stein, http://www.lyra.org/

Re: apr_xml (was: Re: libaprutil.la, libexpat.la, APRUTIL_EXPORT_LIBS)

[Luke Kenneth Casson Leighton <lk...@samba-tng.org>]

it may be better to consider getting the ODBC project
up to 2.0 compliance, and/or consuming / adopting it
as an apache project, if it's considered _that_ important.

basically, what you will be doing is writing another ODBC.

ODBC is extremely poorly supported on unix.

btw i investigated ODBC / MS-SQL native on unix:
it will involve writing a DCE/RPC API, by reverse-engineering
network traffic, examining the SQL function API etc,
shouldn't be too hard.  estimated time to completion:
approx 6 man-months, full time.

luke

p.s. it would be easier to use XML - see
http://sourceforge.net/projects/pyxsqmll
(i'm assuming i can spell that stupid name :)

implementing this in c as an ODBC driver, especially
as a large number of the ODBC-ODBC bridges use
XML for the ODBC-client-on-unix -> ODBC-server-shim-thing-to-ODBC-on-win32
communication, should be trivial.

On Sat, May 19, 2001 at 12:19:28AM +0100, David Reid wrote:
> Seems like a good idea.  Did we ever do anything about defining/writing code
> for a common apr interface to databases.  I'd think MySQL and Postgresql
> would make the most sense, but we should probably try and get people who
> develop using Oracle and MS SQL server involved...  I know it's been
> discussed, just wondering how we're doing :)
> 
> BTW, I'm off on holiday on Sunday for a week and will be totally out of
> touch all week.

have fun!

> david
> ----- Original Message -----
> From: "Greg Stein" <gs...@lyra.org>
> To: "Ian Holsman" <Ia...@cnet.com>; <de...@apr.apache.org>
> Sent: Thursday, May 17, 2001 9:50 PM
> Subject: apr_xml (was: Re: libaprutil.la, libexpat.la, APRUTIL_EXPORT_LIBS)
> 
> 
> > [ back from a couple days off... ]
> >
> > Yes: the apr_xml code is currently set up to just use Expat. However, the
> > intent is that it can be covers for other XML parsers. In particular,
> Xerces
> > and libxml would be great options.
> >
> > And yes, the API is also based a very lightweight tree structure, rather
> > than event-based. Adding a second set of APIs to set handlers would be a
> > Good Thing, so please feel free to submit patches to do so.
> >
> > The insertion of "DAV:" into the set of namespaces is definitely a
> negative,
> > but I haven't bothered to spend time to resolve the issue. That is about
> the
> > only DAV-specific thing in the whole set of apr_xml routines. The rest is
> > generally applicable to other problem domains.
> >
> > The point is: the code originated as part of mod_dav, but it has been
> > extracted so that other code can use it (config reading? new modules?
> etc).
> > However, somebody just needs to spend a bit of time to sand off the rough
> > edges and to expand the APIs based on what people may need.
> >
> > Cheers,
> > -g
> >
> > On Thu, May 17, 2001 at 08:07:11AM -0700, Ian Holsman wrote:
> > > I think it is more than that.
> > > I was trying to get apr_xml usable as a xml_parser
> > > the apr-xml api, doesn't provide any hooks so that I can
> > > be notified when I get an element, (which expat has) and
> > > is currently hard coded for 'DAV' only.
> > >
> > > in order to be usefull it needs a couple more functions
> > > to set the start handler, namespace (on create) and to navigate
> > > the tree a bit better.
> > >
> > >
> > > > -----Original Message-----
> > > > From: Jeff Trawick [mailto:trawickj@bellsouth.net]
> > > > Sent: Thursday, May 17, 2001 4:37 AM
> > > > To: Ian Holsman; gstein@apache.org; dev@apr.apache.org
> > > > Subject: Re: libaprutil.la, libexpat.la, APRUTIL_EXPORT_LIBS
> > > >
> > > >
> > > > Ian Holsman <Ia...@cnet.com> writes:
> > > >
> > > > > Expat is used by the 'apr_xml' set of routines inside of apr-util
> > > > > which look hard coded to work only for mod_dav.
> > > > >
> > > > > you could always move expat and the apr_xml stuff into the mod_dav
> > > > > module directory.
> > > >
> > > > (I don't know what I'm talking about but) maybe
> > > > apr_xml_parser_create() needs a parameter to specify the namespace?
> > > > (Or maybe this is an expat-specific concept and we don't want to tie
> > > > the apr-util API to expat?)
> > > >
> > > > --
> > > > Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
> > > >        http://www.geocities.com/SiliconValley/Park/9289/
> > > >              Born in Roswell... married an alien...
> > > >
> >
> > --
> > Greg Stein, http://www.lyra.org/
> >
> 

databases in APRUTIL (was: apr_xml)

[Greg Stein <gs...@lyra.org>]

On Sat, May 19, 2001 at 12:19:28AM +0100, David Reid wrote:
> Seems like a good idea.

Yes, but somebody just has to do it. That is: somebody with an itch.

> Did we ever do anything about defining/writing code
> for a common apr interface to databases.

No, although it would be a nice addition. After designing the DB-API for
Python, I have to say, though: you *MUST* have it properly scoped before
beginning the API design work. The simple fact is that every database is
different in any number of unimaginable ways. To create an API to make them
look the *SAME* is impossible. Given that, you have to set yourself a bar
that says "we'll make them look the same to <THIS> level and no more."

The Python DB-API set a bar that some people think is just right, and some
people think is too low. The Perl DBI bar is a bit higher. Last I looked,
the PHP folks have separate function sets for each database (e.g. there is
no attempted commonality).

I can go on, but the point is moot until somebody wants to spend time
implementing such a beast.

> I'd think MySQL and Postgresql
> would make the most sense, but we should probably try and get people who
> develop using Oracle and MS SQL server involved...  I know it's been
> discussed, just wondering how we're doing :)

Zero work on design or implementation. We have "DBM style" support for most
of the DBMs out there (be nice to add the Samba's TDB(?) support, tho). DBM
is just key/value pairs; nothing at all like SQL.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: apr_xml (was: Re: libaprutil.la, libexpat.la, APRUTIL_EXPORT_LIBS)

[David Reid <dr...@jetnet.co.uk>]

Seems like a good idea.  Did we ever do anything about defining/writing code
for a common apr interface to databases.  I'd think MySQL and Postgresql
would make the most sense, but we should probably try and get people who
develop using Oracle and MS SQL server involved...  I know it's been
discussed, just wondering how we're doing :)

BTW, I'm off on holiday on Sunday for a week and will be totally out of
touch all week.

david
----- Original Message -----
From: "Greg Stein" <gs...@lyra.org>
To: "Ian Holsman" <Ia...@cnet.com>; <de...@apr.apache.org>
Sent: Thursday, May 17, 2001 9:50 PM
Subject: apr_xml (was: Re: libaprutil.la, libexpat.la, APRUTIL_EXPORT_LIBS)


> [ back from a couple days off... ]
>
> Yes: the apr_xml code is currently set up to just use Expat. However, the
> intent is that it can be covers for other XML parsers. In particular,
Xerces
> and libxml would be great options.
>
> And yes, the API is also based a very lightweight tree structure, rather
> than event-based. Adding a second set of APIs to set handlers would be a
> Good Thing, so please feel free to submit patches to do so.
>
> The insertion of "DAV:" into the set of namespaces is definitely a
negative,
> but I haven't bothered to spend time to resolve the issue. That is about
the
> only DAV-specific thing in the whole set of apr_xml routines. The rest is
> generally applicable to other problem domains.
>
> The point is: the code originated as part of mod_dav, but it has been
> extracted so that other code can use it (config reading? new modules?
etc).
> However, somebody just needs to spend a bit of time to sand off the rough
> edges and to expand the APIs based on what people may need.
>
> Cheers,
> -g
>
> On Thu, May 17, 2001 at 08:07:11AM -0700, Ian Holsman wrote:
> > I think it is more than that.
> > I was trying to get apr_xml usable as a xml_parser
> > the apr-xml api, doesn't provide any hooks so that I can
> > be notified when I get an element, (which expat has) and
> > is currently hard coded for 'DAV' only.
> >
> > in order to be usefull it needs a couple more functions
> > to set the start handler, namespace (on create) and to navigate
> > the tree a bit better.
> >
> >
> > > -----Original Message-----
> > > From: Jeff Trawick [mailto:trawickj@bellsouth.net]
> > > Sent: Thursday, May 17, 2001 4:37 AM
> > > To: Ian Holsman; gstein@apache.org; dev@apr.apache.org
> > > Subject: Re: libaprutil.la, libexpat.la, APRUTIL_EXPORT_LIBS
> > >
> > >
> > > Ian Holsman <Ia...@cnet.com> writes:
> > >
> > > > Expat is used by the 'apr_xml' set of routines inside of apr-util
> > > > which look hard coded to work only for mod_dav.
> > > >
> > > > you could always move expat and the apr_xml stuff into the mod_dav
> > > > module directory.
> > >
> > > (I don't know what I'm talking about but) maybe
> > > apr_xml_parser_create() needs a parameter to specify the namespace?
> > > (Or maybe this is an expat-specific concept and we don't want to tie
> > > the apr-util API to expat?)
> > >
> > > --
> > > Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
> > >        http://www.geocities.com/SiliconValley/Park/9289/
> > >              Born in Roswell... married an alien...
> > >
>
> --
> Greg Stein, http://www.lyra.org/
>