You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Greg Stein <gs...@lyra.org> on 1999/06/14 12:58:56 UTC
[PATCH] XML Handling, Part 2
Hi,
Here is the patch for the additional XML handling that I discussed in
Message-ID:<37...@lyra.org>.
This patch should incorporate (by reference) the three files in that
message.
Per the project guidelines, I'm now looking for a few +1 votes :-)
Thx,
-g
Index: Makefile.tmpl
===================================================================
RCS file: /home/cvs/apache-1.3/src/main/Makefile.tmpl,v
retrieving revision 1.35
diff -u -r1.35 Makefile.tmpl
--- Makefile.tmpl 1999/01/12 15:47:00 1.35
+++ Makefile.tmpl 1999/06/14 10:38:42
@@ -11,7 +11,7 @@
http_config.o http_core.o http_log.o \
http_main.o http_protocol.o http_request.o http_vhost.o \
util.o util_date.o util_script.o util_uri.o util_md5.o \
- rfc1413.o
+ util_xml.o util_xmlparse.o rfc1413.o
.c.o:
$(CC) -c $(INCLUDES) $(CFLAGS) $<
Re: [PATCH] XML Handling, Part 2
Posted by Manoj Kasichainula <ma...@io.com>.
On Tue, Jul 13, 1999 at 09:36:57PM -0700, Greg Stein wrote:
> Anyhow... I presume your comments suggest a +1 on concept?
+0 actually, but it's non-binding anyway.
--
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
"Hypocrisy is the greatest luxury." - Disposable Heroes of Hiphoprisy
Re: [PATCH] XML Handling, Part 2
Posted by Rasmus Lerdorf <ra...@lerdorf.on.ca>.
> I wonder if we're taking the wrong approach... maybe we should be working
> on a shared memory IPC approach -- so that mod_php could live in its own
> process, and not have to worry about linkages with apache.
Can this be made both quick and portable? How would it work on Windows?
Would the entire Apache API be available to a module like mod_perl which
needs all sorts of low-level stuff?
I have never had much luck with any of the solutions out there that uses
this approach, but perhaps it could be done in a way where it actually
works.
-Rasmus
Re: [PATCH] XML Handling, Part 2
Posted by Dean Gaudet <dg...@arctic.org>.
I wonder if we're taking the wrong approach... maybe we should be working
on a shared memory IPC approach -- so that mod_php could live in its own
process, and not have to worry about linkages with apache.
Dean
On Wed, 14 Jul 1999, Rasmus Lerdorf wrote:
> > If a module is introducing new functionality, then they may be okay with
> > saying "the XML feature requires 1.3.7". It is really up to the module
> > author; and you're right... they may say "well, if I can't offer it to
> > all 1.3 users, then I won't." IMO, that is short-sighted :-), and I'd
> > point out to those authors the simple fact that we continue to add
> > capabilities in recent versions. For example, a 1.3.2 user finds he
> > needs virtual hosting, so they upgrade or they don't use it. A 1.3.4
> > user finds they what XML Feature A from some module, so they upgrade or
> > they don't use it. :-)
>
> It does become a support nightmare though, and people are not happy about
> upgrading. Quite a few people complained when Apache 1.1 support was
> dropped from PHP and we still have thousands of sites running PHP on
> Apache-1.2.x servers. In the case of PHP it also needs to run as a CGI
> and with other web servers, so no matter what we need to be able to
> provide XML capabilities without relying on them being present in Apache.
>
> It is a bit like back when a regex library was added to Apache. I think
> that happened between 1.1 and 1.2 and it happened to be different from the
> regex library I was bundling with PHP at the time. It also had
> conflicting symbols and I ended up having to dump the regex library I was
> bundling and instead bundle the same one Apache bundled to alleviate the
> nightmare.
>
> In general I think it is a good idea for Apache to provide these sort of
> essential functionalities to modules that need them, but we have to
> realize that it can also be a pain in the butt for larger and more
> extensive modules. Especially when the bundled library may or may not
> actually be there as with this whole WANT_HSREGEX deal where you have to
> go check which regex library a particular build is using.
>
> -Rasmus
>
>
Re: [PATCH] XML Handling, Part 2
Posted by Rasmus Lerdorf <ra...@lerdorf.on.ca>.
> If a module is introducing new functionality, then they may be okay with
> saying "the XML feature requires 1.3.7". It is really up to the module
> author; and you're right... they may say "well, if I can't offer it to
> all 1.3 users, then I won't." IMO, that is short-sighted :-), and I'd
> point out to those authors the simple fact that we continue to add
> capabilities in recent versions. For example, a 1.3.2 user finds he
> needs virtual hosting, so they upgrade or they don't use it. A 1.3.4
> user finds they what XML Feature A from some module, so they upgrade or
> they don't use it. :-)
It does become a support nightmare though, and people are not happy about
upgrading. Quite a few people complained when Apache 1.1 support was
dropped from PHP and we still have thousands of sites running PHP on
Apache-1.2.x servers. In the case of PHP it also needs to run as a CGI
and with other web servers, so no matter what we need to be able to
provide XML capabilities without relying on them being present in Apache.
It is a bit like back when a regex library was added to Apache. I think
that happened between 1.1 and 1.2 and it happened to be different from the
regex library I was bundling with PHP at the time. It also had
conflicting symbols and I ended up having to dump the regex library I was
bundling and instead bundle the same one Apache bundled to alleviate the
nightmare.
In general I think it is a good idea for Apache to provide these sort of
essential functionalities to modules that need them, but we have to
realize that it can also be a pain in the butt for larger and more
extensive modules. Especially when the bundled library may or may not
actually be there as with this whole WANT_HSREGEX deal where you have to
go check which regex library a particular build is using.
-Rasmus
Re: [PATCH] XML Handling, Part 2
Posted by Greg Stein <gs...@lyra.org>.
Manoj Kasichainula wrote:
>
> I haven't had a chance to actually try this out yet, but it doesn't
> appear that this code would be left out of the build if I set Rule
> EXPAT=no.
Good call. I'll add that before checkin.
> With that changed, I have no objection to the patch. But, I don't know
> how useful it will be in the 1.x series. Modules using XML will have
> to resort to using their own routines anyway if they want to support
> any Apache version older than 1.3.7.
If a module is introducing new functionality, then they may be okay with
saying "the XML feature requires 1.3.7". It is really up to the module
author; and you're right... they may say "well, if I can't offer it to
all 1.3 users, then I won't." IMO, that is short-sighted :-), and I'd
point out to those authors the simple fact that we continue to add
capabilities in recent versions. For example, a 1.3.2 user finds he
needs virtual hosting, so they upgrade or they don't use it. A 1.3.4
user finds they what XML Feature A from some module, so they upgrade or
they don't use it. :-)
Anyhow... I presume your comments suggest a +1 on concept?
thx!
-g
--
Greg Stein, http://www.lyra.org/
Re: [PATCH] XML Handling, Part 2
Posted by Manoj Kasichainula <ma...@io.com>.
I haven't had a chance to actually try this out yet, but it doesn't
appear that this code would be left out of the build if I set Rule
EXPAT=no.
With that changed, I have no objection to the patch. But, I don't know
how useful it will be in the 1.x series. Modules using XML will have
to resort to using their own routines anyway if they want to support
any Apache version older than 1.3.7.
But you did the work already so that hardly matters. :)
--
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
"Yes, I know a nose is not a butt." -- Darrell Fuhriman
Re: [PATCH] XML Handling, Part 2
Posted by Greg Stein <gs...@lyra.org>.
Greg Stein wrote in <37...@lyra.org>:
>
> Hi,
>
> Here is the patch for the additional XML handling that I discussed in
> Message-ID:<37...@lyra.org>.
>
> This patch should incorporate (by reference) the three files in that
> message.
>
> Per the project guidelines, I'm now looking for a few +1 votes :-)
Hey all...
I've got a +1 on concept from Martin (in STATUS) and Ken (in mail to
this list on June 21). That isn't quite enough to get this checked in
however.
Given some of the recent discussion about XML-based configuration, it
seems like there is some interest. I think this patch will make it much
easier for us to move in that direction (as an option, and whether
attribute or element based :-). Of course, it can be used for numerous
other tasks; in particular, WebDAV.
If I could ask some people to review it (I believe it is solid since it
was extracted from mod_dav), or provide some more +1 concepts, or
whatever... that would be great. Feedback on changes necessary before
providing the vote is welcome!
thx!
-g
--
Greg Stein, http://www.lyra.org/