apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luke Kenneth Casson Leighton <l...@samba-tng.org>
Subject Re: XMLvL, apache, apr, mod_virgule origins: advice needed [LONG]
Date Thu, 07 Jun 2001 11:33:15 GMT
On Thu, Jun 07, 2001 at 02:14:58AM -0700, Greg Stein wrote:

> On Wed, Jun 06, 2001 at 04:28:43PM +0200, Luke Kenneth Casson Leighton wrote:
> >...
> > it doesn't use apache authentication, in fact there's a whole
> > boat-load of stuff it can't use.  it provides its own
> > authentication, from cookies stored in xml-based
> > user-profile files.
> Side question: why don't you write mod_auth_FOO to authenticate against
> those files? Then you wouldn't need to bother with authentication in xvl.
> Users could also swap in/out their own authentication as they desired. Or,
> of course, use the default mod_auth_FOO mechanism.
... the xvl code (and the original mod_virgule) have
zero hooks back to using other mod_xxxes.

yes, i would dearly love to be able to hook into other
authentication mechanisms, and to that end i have already
split authentication from authorisation (acct.c and profile.c)
and user credentials and profile information.

once i have a clear idea of how to proceed to hook
into mod_auth_xxxes, i'll probably do it real quick :)

> > so.  any suggestions?  what components already
> > exist?
> Well, you obviously have an entire httpd server to grab code from.


> But in
> terms of isolated components? Nothing beyond APR and APRUTIL.
ack.  if i make a [rather short] list of functions i am literally
duplicating line-for-line, would that suffice as motivation to,
say, add them to aprutil?

ahh, heck, why not just cp the file over now :)
these are the functions that i am duplicating - verbatim -
from httpd.  needless to say, duplicating code makes
me very unhappy, and if anything can be done about that,
i'd be willing to help make it happen.

API_EXPORT(char *) ap_escape_html(apr_pool_t *p, const char *s);
API_EXPORT(char *) ap_os_escape_path(apr_pool_t *p, const char *path, int partial);
API_EXPORT(char *) ap_make_full_path(apr_pool_t *a, const char *src1,
				  const char *src2);
API_EXPORT(char *) ap_ht_time(apr_pool_t *p, time_t t, const char *fmt, int gmt);
API_EXPORT(char *) ap_gm_timestr_822(apr_pool_t *p, time_t sec);
API_EXPORT(char *) ap_getword(apr_pool_t *atrans, const char **line, char stop);
API_EXPORT(int) ap_count_dirs(const char *path);
API_EXPORT(char *) ap_make_dirstr_prefix(char *d, const char *s, int n);
API_EXPORT(char *) ap_make_dirstr_parent(apr_pool_t *p, const char *s);

API_EXPORT(int) ap_regexec(const regex_t *preg, const char *string,
                           size_t nmatch, regmatch_t pmatch[], int eflags);
API_EXPORT(size_t) ap_regerror(int errcode, const regex_t *preg, char *errbuf, size_t errbuf_size);
API_EXPORT(char *) ap_pregsub(apr_pool_t *p, const char *input, const char *source,
			   size_t nmatch, regmatch_t pmatch[]);

API_EXPORT(void) ap_str_tolower(char *str);

> > i'm using a brain-dead installation
> > of mandrake 7.0 with glibc 2.2 (so i get
> > error, cannot find symbol dl_init_next@@GLIBC_2_0
> > whenever i compile a shared library with -ldl,
> > that includes libxml2, apr, pretty much damn
> > well everything: anyone any clues?  i'm
> > installing a lot of RPMs recently to overcome
> > this, _when_ they're available...)
> Hmm. No clue on that link error. Never seen it. Of course, I have glibc 2.1
> on my box. Have you tried dropping the -ldl? Maybe 2.2 includes that
> already.
yes i tried dropping -ldl: it says error, cannot find dlopen [and friends]
at link-time instead.

i have found a temporary solution: compile everything with
./configure --enable-shared=no

which doesn't exactly make me very happy, but there y'go.
i shouldn't be so damn stupid as to stuff up my development
machine, _should_ i? :)

> > xvl uses the ap_pool code, the table code,
> > list code, ap_psprintf, i need to exec
> > / spawn programs, ideally i also need a
> > portable version of unix-domain-sockets, which
> > i understand doesn't exist in APR, yet.
> APR does Unix domain sockets. We use them in mod_cgid.c.
hooray!  i tried glib for this job, a while back, but its
'object-orientated' nature just... got in the way :)

> APRUTIL also locates Expat on the system for you, or builds its bundled copy
> of Expat. You could drop your libxml2 dependency. 

ah, uh... libxml2 is a thorougly harsh dependency in xvl.
when i say harsh, i mean, in a 12,000-line codebase there
are 1,000 occurrences of lines with xml in it [grep xml *.c */*.c | wc]

one of the modules - the socket module - uses the SAX2 
interface in such a way so as to provide an easily intuitive
[and not original] way to make data transfer look like XML that
took *four weeks* to implement.

i really don't have the kind of time available on my hands
that took up so much concentration to get that stupid code

> Even better, there has
> been a call for a SAX-like API in APRUTIL, backed by Expat, libxml, or
> Xerces. If you're motivated, you could implement that API for APRUTIL :-)

interesting concept.

would keep _me_ happier too because i'm not entirely
ok with the clash between libxml and libxml2 caused
by the gnome people bundling libxml 1.8.x with their
codebase.  rrrr :)

> For exec/spawn of programs, take a look at the mod_cgi(d) code. There is
> also the "other child" features of APR.

uh... i am slightly embarrased.  having solved the
issue of the dl_init_next@GLIBC2_0 thing, i got the
latest cvs apr and aprutil compiled and tested, and...
well... converted xvl to use it in about 2 hours flat.

including using testprog.c as the basis for getting the
cgi code up and running again.

so, _anyway_, apr is now the proud owner of yet another
project for its existence :)

[anyone interested: it's available at http://virgule.sourceforge.net.
we'll have a development site, run by xvl, up and going soon:
more later]

anyway: if it's ok with all y'all, i'll come back with
some more questions about portability, later?  now that
i have the apr bit between my teeth, i'd like to carry
this through the whole hog and actually prove that
xvl can be compiled and run on different platforms.

that means using your ux-dom-socket code etc.
...does that work on win32, out of interest?

many thanks,


View raw message