El-Kabong HTML Parser -- has m0v3d
Aight, so since this has moved elsewhere, I thought I'd tell the people who may have initially been interested in the code. You can now grab it here: http://ekhtml.sf.net Should be handy for creating Apache filters that want to mangle content before shipping it to the browser. -- Jon
Re: El-Kabong -- HTML Parser
On Mon, Sep 09, 2002 at 11:21:04PM -0700, Greg Stein wrote: On Mon, Sep 09, 2002 at 01:33:25PM -0700, Jon Travis wrote: Ok, since I'm not seeing any activity towards getting this integrated, I'd like to set a deadline. This would help me out, since it gives direction as to where the project can go, as well as the ASF since political discussion shouldn't weigh down the process. It will just save us all a lot of time energy. Anyway, I'd like to give an additional week to the ASF to deal with the code. Next Monday, if it hasn't been decided I'll look into other options. Jon -- The HTTP Server Project, the APR Project, and the ASF will not abide by your threats of taking the code elsewhere. We will not be subject to coercive behavior, nor do we look kindly upon the attempt. The ASF is about working together. Your message certainly does not mesh with our concepts of community and respect. The ASF is apparently not about working together, since I (and everyone else who is not on the PMC list) have been entirely left out of all this conversation which is going on behind closed doors. I am not trying to coerce anyone -- I'm merely trying to put a limit on the maximum amount of time that this will be debated. That is a perfectly valid, and responsible thing to do. Frankly, there is no need or driving force for us to accept code donations. That means it isn't possible to hold this over our heads. We can easily choose to ignore the whole thing, with no real loss to our fundamental ideals and to our communities. It seems as though that is exactly what you've done -- ignored it. I am constantly probing for information as to where this stands, both via these lists and asking on the #apr IRC channel. You're interpretation if holding this over your head is fairly outrageous, since Apache exists perfectly fine without this contribution. As of this moment, I'm going to recommend that the ASF will work directly with Covalent management regarding the donation. The other members involved may certainly choose to continue working through you [to Covalent], as I do not speak for them, but I seriously doubt that will be the case. Your behavior does not bode well for your continued involvement in the process. That's quite the attack (and one which fits in well with your concepts of community and respect?) . All decisions which have been made about this project (Open sourcing it, setting a deadline, etc.) have been dictated by management at Covalent. If you want to persuade your management to publish the code through a different owner, or under a different license, then please feel free. If Covalent management chooses to not donate the code to the ASF, then so be it -- that is their choice. But take your coercive tactics elsewhere. Regards, Greg Stein Chairman, Apache Software Foundation These are not coercive tactics. These are processes which are beneficial to both the ASF and Covalent. I cannot continually monitor the progress of this project for eternity. I'm astonished that this deadline email has caused such a response. This sets an extremely bad precedent for other companies (or anyone for that matter) who wants to contribute to the ASF. Personally (Covalent hat off), it's a bummer that this is your response to the donation. I was the one who originally proposed it to management, they agreed to it, and now I've gotten involved in all kinds of politics and inflamatory emails. That's a long way from being excited about contritributing to the ASF, and sadly seems like more trouble than it's worth. -- Jon
Re: El-Kabong -- HTML Parser
On Mon, Sep 09, 2002 at 01:33:25PM -0700, Jon Travis wrote: Ok, since I'm not seeing any activity towards getting this integrated, I'd like to set a deadline. This would help me out, since it gives direction as to where the project can go, as well as the ASF since political discussion shouldn't weigh down the process. It will just save us all a lot of time energy. Anyway, I'd like to give an additional week to the ASF to deal with the code. Next Monday, if it hasn't been decided I'll look into other options. Jon -- The HTTP Server Project, the APR Project, and the ASF will not abide by your threats of taking the code elsewhere. We will not be subject to coercive behavior, nor do we look kindly upon the attempt. The ASF is about working together. Your message certainly does not mesh with our concepts of community and respect. Frankly, there is no need or driving force for us to accept code donations. That means it isn't possible to hold this over our heads. We can easily choose to ignore the whole thing, with no real loss to our fundamental ideals and to our communities. As of this moment, I'm going to recommend that the ASF will work directly with Covalent management regarding the donation. The other members involved may certainly choose to continue working through you [to Covalent], as I do not speak for them, but I seriously doubt that will be the case. Your behavior does not bode well for your continued involvement in the process. If you want to persuade your management to publish the code through a different owner, or under a different license, then please feel free. If Covalent management chooses to not donate the code to the ASF, then so be it -- that is their choice. But take your coercive tactics elsewhere. Regards, Greg Stein Chairman, Apache Software Foundation
Re: El-Kabong -- HTML Parser
The ASF is apparently not about working together, since I (and everyone else who is not on the PMC list) have been entirely left out of all this conversation which is going on behind closed doors. Which closed doors are those? There has been discussion on the dev list and on the board list. Both of which are public lists that you can subscribe to. It seems as though that is exactly what you've done -- ignored it. I am constantly probing for information as to where this stands, both via these lists and asking on the #apr IRC channel. You're interpretation if holding this over your head is fairly outrageous, since Apache exists perfectly fine without this contribution. I agree with you that Greg may have misinterpreted your message somewhat and come on a little strong, but everything I have seen has pointed at putting it somewhere, just nobody is sure where. I have yet to see you suggest something to help place it properly, but I could easily have missed that message in my flood of email. -Rasmus
Re: El-Kabong -- HTML Parser
On Tue, Sep 10, 2002 at 01:57:06AM -0700, Rasmus Lerdorf wrote: The ASF is apparently not about working together, since I (and everyone else who is not on the PMC list) have been entirely left out of all this conversation which is going on behind closed doors. Which closed doors are those? There has been discussion on the dev list and on the board list. Both of which are public lists that you can subscribe to. All I know of is the PMC list (which is private), but discussion on board (which is also private) is news to me. http://www.apache.org/foundation/mailinglists.html#foundation-board -- Jon
Re: El-Kabong -- HTML Parser
Which closed doors are those? There has been discussion on the dev list and on the board list. Both of which are public lists that you can subscribe to. All I know of is the PMC list (which is private), but discussion on board (which is also private) is news to me. Well, I had assumed you were already an ASF member. I guess I was wrong. Yes, the board list is private in the sense that non-ASF members can not subscribe. Any ASF member can though. -Rasmus
Re: El-Kabong -- HTML Parser
Jon Travis wrote: The ASF is apparently not about working together, since I (and everyone else who is not on the PMC list) have been entirely left out of all this conversation which is going on behind closed doors. I suspect that's rubbish, Jon, since this is the first I've heard of this issue. It's certainly the first thing I recall seeing on the httpd PMC list. I'm 'way behind on my dev@httpd mail (about 1k messages), so I assume that's where the rest/origin of this discussion is. I suggest everyone take a step back and a deep breath, and start again. That's quite the attack (and one which fits in well with your concepts of community and respect?) . Pots and kettles.. I have in mind an ApacheCon submission entitled 'Why Apache Sucks', which wasn't terribly respectful. :-) Again, let's step back and cool off, and try reasoning rather than emoting. There's a lot of frustration here, apparently, and I suspect some miscommunication and/or assumptions of what others know. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp!
Re: El-Kabong -- HTML Parser
[I am not an Apache contributor, merely a lurker, but...] On Tue, 10 Sep 2002, Jon Travis wrote: These are not coercive tactics. These are processes which are beneficial to both the ASF and Covalent. I cannot continually monitor the progress of this project for eternity. I'm astonished that this deadline email has caused such a response. This sets an extremely bad precedent for other companies (or anyone for that matter) who wants to contribute to the ASF. Personally (Covalent hat off), it's a bummer that this is your response to the donation. I was the one who originally proposed it to management, they agreed to it, and now I've gotten involved in all kinds of politics and inflamatory emails. That's a long way from being excited about contritributing to the ASF, and sadly seems like more trouble than it's worth. As I said earlier: if all you want is to contribute the code, put a compatible open source license on it and put it on a publicly accessable website, somewhere. From following the thread, I get the feeling you don't want to contribute it, you want someone to take ownership of it. A couple points: 1) Everyone here has a real-life job. 2) Many of those jobs don't involve Apache directly. 3) Anyone who's writing code has their own pet projects they want done. 4) Anyone without a pet project has a choice of dozens/hundreds of abandoned/unmaintained projects to work on. 5) Integration work is hard work. If you really want the ASF to pull this project into the Apache core, your best bet is to volunteer to integrate it and write some example code. After all, you're the one with the code, you're the one who wants to contribute it to the community. This isn't specific to the Apache group. This is just how open source software works. And this basic thread happens every couple months on every open source project I monitor. As far as inflammatory emails, you must be reading lists that I don't have access to, because I haven't seen it. Given that you've essentially asked the community to prove that it's worthy of accepting your contribution, I'm actually surprised the responses have been so calm. Later, scott
Re: El-Kabong -- HTML Parser
On Tue, Sep 10, 2002 at 09:47:01AM -0700, Scott Hess wrote: [I am not an Apache contributor, merely a lurker, but...] On Tue, 10 Sep 2002, Jon Travis wrote: These are not coercive tactics. These are processes which are beneficial to both the ASF and Covalent. I cannot continually monitor the progress of this project for eternity. I'm astonished that this deadline email has caused such a response. This sets an extremely bad precedent for other companies (or anyone for that matter) who wants to contribute to the ASF. Personally (Covalent hat off), it's a bummer that this is your response to the donation. I was the one who originally proposed it to management, they agreed to it, and now I've gotten involved in all kinds of politics and inflamatory emails. That's a long way from being excited about contritributing to the ASF, and sadly seems like more trouble than it's worth. As I said earlier: if all you want is to contribute the code, put a compatible open source license on it and put it on a publicly accessable website, somewhere. We decided to give the ASF the first shot at it if they wanted the project. It seemed to fit in well with things they did, and we have roots in the ASF. From following the thread, I get the feeling you don't want to contribute it, you want someone to take ownership of it. A couple points: Untrue. If you look at my very first email on this issue (the initial proposal), I site that I will be the initial maintainer. I certainly have the most experience with the code, and certainly some amount of passion for it, regardless of the simplicity. 1) Everyone here has a real-life job. 2) Many of those jobs don't involve Apache directly. 3) Anyone who's writing code has their own pet projects they want done. 4) Anyone without a pet project has a choice of dozens/hundreds of abandoned/unmaintained projects to work on. 5) Integration work is hard work. If you really want the ASF to pull this project into the Apache core, your best bet is to volunteer to integrate it and write some example code. After all, you're the one with the code, you're the one who wants to contribute it to the community. This is the point they are debating. There is no consensus that it will be integrated. It either would be, or it would be a seperate project, and that has not yet been decided. They have already agreed that the code is good (I've already sent it to people to review ). I'm more than happy to integrate it wherever they see it fit. As I've said in other emails (to this list and privately to members) I would definitely be involved. -- Jon
Re: El-Kabong -- HTML Parser
-- Original Message -- Reply-To: [EMAIL PROTECTED] Date: Tue, 10 Sep 2002 09:47:01 -0700 (PDT) From: Scott Hess [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: El-Kabong -- HTML Parser snip... As I said earlier: if all you want is to contribute the code, put a compatible open source license on it and put it on a publicly accessable website, somewhere. there have been proposed uses within the core or within core modules (e.g. usertrack). To facilitate these great extensions, the parser should be in apr. From following the thread, I get the feeling you don't want to contribute it, you want someone to take ownership of it. A couple points: Where did you get that idea? Jon said he would help maintain it i believe. 1) Everyone here has a real-life job. 2) Many of those jobs don't involve Apache directly. 3) Anyone who's writing code has their own pet projects they want done. 4) Anyone without a pet project has a choice of dozens/hundreds of abandoned/unmaintained projects to work on. 5) Integration work is hard work. this is ponderous - I don't think Jon needs your advice. He has been an active contributor here for a few years. The point is that there are some uses for an html parser in apache (e.g. usertrack rewriting urls, language translation, and many other filtering applications). I personally think it would be nice to get the parser into apr - then these extensions can be done immediately. If it is put external, core modules will basically not be able to use it (since we don't want to start adding external dependencies). sterling
Re: El-Kabong -- HTML Parser
Can we settle down? A donation of code was being offered, and there was discussion within the ASF about it, but the status of those discussions weren't being folded back to the donator. Before we veer off on yet another tangent, can we address the core issue? Should the ASF accept the code donation? I believe Greg has done a review of said code. Accept: Do Not Accept: Abstain: -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: El-Kabong -- HTML Parser
On Tue, 10 Sep 2002, Jim Jagielski wrote: Can we settle down? A donation of code was being offered, and there was discussion within the ASF about it, but the status of those discussions weren't being folded back to the donator. Before we veer off on yet another tangent, can we address the core issue? Should the ASF accept the code donation? I believe Greg has done a review of said code. This has been decided already. It was discussed in the APR PMC, and we decided to accept the code. We even decided where to put it. I personally disagree with the decision, but it was made by a majority of the voters, so I will stand by it. The code has been accepted by the APR PMC, and it is going into apr-util/html (I believe). Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: El-Kabong -- HTML Parser
Before we veer off on yet another tangent, can we address the core issue? Should the ASF accept the code donation? I believe Greg has done a review of said code. Accept: +1, and move somewhere into apr Daniel
Re: El-Kabong -- HTML Parser
Time for another ping. It's been 2 weeks. Any word? -- Jon On Mon, Aug 26, 2002 at 08:32:16PM -0700, Jon Travis wrote: Hi all... Jon Travis here... Covalent has written a pretty keen HTML parser (called el-kabong) which we'd like to offer to the ASF for inclusion in APR-util (or whichever other umbrella it fits under.) It's faster than anything I can find, provides a SAX stylee interface, uses APR for most of its operations (hash tables, etc.), and has a pretty nice testsuite. We use it in our code to re-write HTML on the fly. I would be the initial maintainer of the code. Please voice any interest, thanks. -- Jon
Re: El-Kabong -- HTML Parser
Ok, since I'm not seeing any activity towards getting this integrated, I'd like to set a deadline. This would help me out, since it gives direction as to where the project can go, as well as the ASF since political discussion shouldn't weigh down the process. It will just save us all a lot of time energy. Anyway, I'd like to give an additional week to the ASF to deal with the code. Next Monday, if it hasn't been decided I'll look into other options. -- Jon On Mon, Sep 09, 2002 at 10:36:21AM -0700, Jon Travis wrote: Time for another ping. It's been 2 weeks. Any word? -- Jon On Mon, Aug 26, 2002 at 08:32:16PM -0700, Jon Travis wrote: Hi all... Jon Travis here... Covalent has written a pretty keen HTML parser (called el-kabong) which we'd like to offer to the ASF for inclusion in APR-util (or whichever other umbrella it fits under.) It's faster than anything I can find, provides a SAX stylee interface, uses APR for most of its operations (hash tables, etc.), and has a pretty nice testsuite. We use it in our code to re-write HTML on the fly. I would be the initial maintainer of the code. Please voice any interest, thanks. -- Jon
Re: El-Kabong -- HTML Parser
I'm not sure I understand what your goal is, here. The discussion seems to be +1 for including your parser somewhere in some Apache project in the future, there's just no clear concensus on where. Is there any reason you can't just release your project under the ASF license and be done with it? Later, scott On Mon, 9 Sep 2002, Jon Travis wrote: Ok, since I'm not seeing any activity towards getting this integrated, I'd like to set a deadline. This would help me out, since it gives direction as to where the project can go, as well as the ASF since political discussion shouldn't weigh down the process. It will just save us all a lot of time energy. Anyway, I'd like to give an additional week to the ASF to deal with the code. Next Monday, if it hasn't been decided I'll look into other options. -- Jon On Mon, Sep 09, 2002 at 10:36:21AM -0700, Jon Travis wrote: Time for another ping. It's been 2 weeks. Any word? -- Jon On Mon, Aug 26, 2002 at 08:32:16PM -0700, Jon Travis wrote: Hi all... Jon Travis here... Covalent has written a pretty keen HTML parser (called el-kabong) which we'd like to offer to the ASF for inclusion in APR-util (or whichever other umbrella it fits under.) It's faster than anything I can find, provides a SAX stylee interface, uses APR for most of its operations (hash tables, etc.), and has a pretty nice testsuite. We use it in our code to re-write HTML on the fly. I would be the initial maintainer of the code. Please voice any interest, thanks. -- Jon
Re: El-Kabong -- HTML Parser
It's possible that if it goes elsewhere that it would be under a different license. That's of course contingent on the decision from the ASF. -- Jon On Mon, Sep 09, 2002 at 01:50:18PM -0700, Scott Hess wrote: I'm not sure I understand what your goal is, here. The discussion seems to be +1 for including your parser somewhere in some Apache project in the future, there's just no clear concensus on where. Is there any reason you can't just release your project under the ASF license and be done with it? Later, scott On Mon, 9 Sep 2002, Jon Travis wrote: Ok, since I'm not seeing any activity towards getting this integrated, I'd like to set a deadline. This would help me out, since it gives direction as to where the project can go, as well as the ASF since political discussion shouldn't weigh down the process. It will just save us all a lot of time energy. Anyway, I'd like to give an additional week to the ASF to deal with the code. Next Monday, if it hasn't been decided I'll look into other options. -- Jon On Mon, Sep 09, 2002 at 10:36:21AM -0700, Jon Travis wrote: Time for another ping. It's been 2 weeks. Any word? -- Jon On Mon, Aug 26, 2002 at 08:32:16PM -0700, Jon Travis wrote: Hi all... Jon Travis here... Covalent has written a pretty keen HTML parser (called el-kabong) which we'd like to offer to the ASF for inclusion in APR-util (or whichever other umbrella it fits under.) It's faster than anything I can find, provides a SAX stylee interface, uses APR for most of its operations (hash tables, etc.), and has a pretty nice testsuite. We use it in our code to re-write HTML on the fly. I would be the initial maintainer of the code. Please voice any interest, thanks. -- Jon
Re: El-Kabong -- HTML Parser
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: There are currently two possible avenues. 1) The code goes into apr-util. 2) The code goes into a sandbox project. It makes a lot of sense to have it also in XML as well, together with XERCES-C... Pier
Re: El-Kabong -- HTML Parser
There are currently two possible avenues. 1) The code goes into apr-util. 2) The code goes into a sandbox project. The APR option is faster, but there is some misgivings about whether it belongs in apr-util. The vote was done, and it seems to be accepted, but Greg was keeping tally, so I don't have the exact numbers about where it would go. I _think_, and I could be wrong, that it would be put in apr-util/html as a separate piece of apr-util. The second option will take a bit longer, because the sandbox project will need to be created first. I have tried to answer without letting any of my personal opinions show in the message, because that has caused some problems before. The real question now, is given those two options, which would you prefer. Not saying that your preference is the only factor i the decision, but it should be taken into account. There are also some people questioning why we are moving so quickly on this. The general feeling is that we should find the best fit before taking the code. If you are in a rush, then that would change things, but the understanding was just that you wanted to be kept in the loop about what is happening. Keep pinging, but the conversation is on-going, and very active, so there is little chance that it won't happen. It is really just a matter of time now. Ryan On Tue, 3 Sep 2002, Jon Travis wrote: Any word on this? (take 2) -- Jon On Mon, Aug 26, 2002 at 08:32:16PM -0700, Jon Travis wrote: Hi all... Jon Travis here... Covalent has written a pretty keen HTML parser (called el-kabong) which we'd like to offer to the ASF for inclusion in APR-util (or whichever other umbrella it fits under.) It's faster than anything I can find, provides a SAX stylee interface, uses APR for most of its operations (hash tables, etc.), and has a pretty nice testsuite. We use it in our code to re-write HTML on the fly. I would be the initial maintainer of the code. Please voice any interest, thanks. -- Jon -- ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: El-Kabong -- HTML Parser
My comments inline: On Tue, Sep 03, 2002 at 02:53:03PM -0400, [EMAIL PROTECTED] wrote: There are currently two possible avenues. 1) The code goes into apr-util. 2) The code goes into a sandbox project. The APR option is faster, but there is some misgivings about whether it belongs in apr-util. The vote was done, and it seems to be accepted, but Greg was keeping tally, so I don't have the exact numbers about where it would go. I _think_, and I could be wrong, that it would be put in apr-util/html as a separate piece of apr-util. The second option will take a bit longer, because the sandbox project will need to be created first. I have tried to answer without letting any of my personal opinions show in the message, because that has caused some problems before. The real question now, is given those two options, which would you prefer. Not saying that your preference is the only factor i the decision, but it should be taken into account. Either one is fine to me. Integrating the code into apr-util is probably an easier setup, but will require more work to adapt to the build system and change the symbols (and of course I'm quite liking the name 'el-kabong' ;-)). There are also some people questioning why we are moving so quickly on this. The general feeling is that we should find the best fit before taking the code. If you are in a rush, then that would change things, but the understanding was just that you wanted to be kept in the loop about what is happening. Keep pinging, but the conversation is on-going, and very active, so there is little chance that it won't happen. It is really just a matter of time now. Ryan I'm not in a rush, I just like to know where things stand. Since this discussion is seemingly happening off-list, I can't differentiate between no discussion or a heated one. I'd prefer this to be on-list, as I think it does affect the users of APR, and it would allow me to monitor the progress here. -- Jon
Re: El-Kabong -- HTML Parser
Jim Jagielski wrote: [EMAIL PROTECTED] wrote: I will make one exception to that statement. If it lands inside of APR-util, under the XML directory, and it is made to work with the XML parser, I can accept that landing spot. As it fits in closer with our goals (I think). Jim, I can't decide if this is what you meant or not. Yes, that is what I meant... side-by-side with the XML stuff under the APR project in apr-util. It makes more sense to me to have a parsers project, since they have a lot in common with each other (and not all that much with other things). But since I'm not going to take on the work of creating such a thing, you can treat that remark with the contempt it deserves :-) Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ Available for contract work. There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: El-Kabong -- HTML Parser
Any word on this? -- Jon On Mon, Aug 26, 2002 at 08:32:16PM -0700, Jon Travis wrote: Hi all... Jon Travis here... Covalent has written a pretty keen HTML parser (called el-kabong) which we'd like to offer to the ASF for inclusion in APR-util (or whichever other umbrella it fits under.) It's faster than anything I can find, provides a SAX stylee interface, uses APR for most of its operations (hash tables, etc.), and has a pretty nice testsuite. We use it in our code to re-write HTML on the fly. I would be the initial maintainer of the code. Please voice any interest, thanks. -- Jon
Re: El-Kabong -- HTML Parser
On Thu, 29 Aug 2002, Jon Travis wrote: Any word on this? These things take time... and it pays off to do them well. There is absolutely no rush. Dw
Re: El-Kabong -- HTML Parser
On Thu, Aug 29, 2002 at 06:42:39PM +0200, Dirk-Willem van Gulik wrote: On Thu, 29 Aug 2002, Jon Travis wrote: Any word on this? These things take time... and it pays off to do them well. There is absolutely no rush. Just wanted a word. More often than not, when something stops being discussed on the list, it drops off the face of the earth. I should know, I have many patches who've taken such a fall.. ;-) -- Jon
Re: El-Kabong -- HTML Parser
Jon Travis wrote: On Thu, Aug 29, 2002 at 06:42:39PM +0200, Dirk-Willem van Gulik wrote: On Thu, 29 Aug 2002, Jon Travis wrote: Any word on this? These things take time... and it pays off to do them well. There is absolutely no rush. Just wanted a word. More often than not, when something stops being discussed on the list, it drops off the face of the earth. I should know, I have many patches who've taken such a fall.. ;-) Well, as with most things, we got off on a tangent (geez, what a surprise) but in general, I think this is *very* positive. Has Greg had a chance to review it yet? -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: El-Kabong -- HTML Parser
On Thu, Aug 29, 2002 at 09:45:19AM -0700, Jon Travis wrote: On Thu, Aug 29, 2002 at 06:42:39PM +0200, Dirk-Willem van Gulik wrote: On Thu, 29 Aug 2002, Jon Travis wrote: Any word on this? These things take time... and it pays off to do them well. There is absolutely no rush. Just wanted a word. More often than not, when something stops being discussed on the list, it drops off the face of the earth. I should know, I have many patches who've taken such a fall.. ;-) Justin and I have both given our thumbs up. The question is now where to put the thing. A few people say APR, and few don't like that. A few say httpd, and a few don't like that. Bleh :-) Regardless of the landing zone, it definitely appears that people like the parser and would like to see it at the ASF. So the next step is the formal process. I'll grumble about to find the right bits to do and get back to you RSN. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: El-Kabong -- HTML Parser
Greg Stein wrote: Justin and I have both given our thumbs up. The question is now where to put the thing. A few people say APR, and few don't like that. A few say httpd, and a few don't like that. Bleh :-) I'm 100% comfy with the landing spot being in APR, as a compliment to the XML routines. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: El-Kabong -- HTML Parser
Justin and I have both given our thumbs up. The question is now where to put the thing. A few people say APR, and few don't like that. A few say httpd, and a few don't like that. Bleh :-) I'm 100% comfy with the landing spot being in APR, as a compliment to the XML routines. +1 from me, I prefer APR actually. -aaron
Re: El-Kabong -- HTML Parser
On Thu, 29 Aug 2002, Aaron Bannert wrote: Justin and I have both given our thumbs up. The question is now where to put the thing. A few people say APR, and few don't like that. A few say httpd, and a few don't like that. Bleh :-) I'm 100% comfy with the landing spot being in APR, as a compliment to the XML routines. +1 from me, I prefer APR actually. I am really uncomfortable with this going under the APR project. As things stand right now, it just doesn't fit with what we have stated our goals to be. If you want to change our stated goals, then go ahead and do it. Just committing code that doesn't fit with our goals isn't the way to do that. I will make one exception to that statement. If it lands inside of APR-util, under the XML directory, and it is made to work with the XML parser, I can accept that landing spot. As it fits in closer with our goals (I think). Jim, I can't decide if this is what you meant or not. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: El-Kabong -- HTML Parser
On Thu, Aug 29, 2002 at 02:24:28PM -0400, Ryan Bloom wrote: +1 from me, I prefer APR actually. I am really uncomfortable with this going under the APR project. As things stand right now, it just doesn't fit with what we have stated our goals to be. If you want to change our stated goals, then go ahead and do it. Just committing code that doesn't fit with our goals isn't the way to do that. (I will defer answering this for an apr-only discussion.) I will make one exception to that statement. If it lands inside of APR-util, under the XML directory, and it is made to work with the XML parser, I can accept that landing spot. As it fits in closer with our goals (I think). Jim, I can't decide if this is what you meant or not. I'm +1 on integrating it into our XML stuff. I consider it to be equivalent to apr-util, so either we put it inside apr-util, or we create a new APR subproject or sub-library for it. -aaron
Re: El-Kabong -- HTML Parser
On Thu, 29 Aug 2002, Aaron Bannert wrote: On Thu, Aug 29, 2002 at 02:24:28PM -0400, Ryan Bloom wrote: +1 from me, I prefer APR actually. I am really uncomfortable with this going under the APR project. As things stand right now, it just doesn't fit with what we have stated our goals to be. If you want to change our stated goals, then go ahead and do it. Just committing code that doesn't fit with our goals isn't the way to do that. (I will defer answering this for an apr-only discussion.) I will make one exception to that statement. If it lands inside of APR-util, under the XML directory, and it is made to work with the XML parser, I can accept that landing spot. As it fits in closer with our goals (I think). Jim, I can't decide if this is what you meant or not. I'm +1 on integrating it into our XML stuff. I consider it to be equivalent to apr-util, so either we put it inside apr-util, or we create a new APR subproject or sub-library for it. I should also mention that I completely do not see this as equivalent to apr-util. I reserve the right to ask for this project to be removed from APR after the APR project has decided on it's stated goals. That does not mean that it would be removed from the ASF (assuming my request is approved), only that it would need to find a new home within the ASF umbrella. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: El-Kabong -- HTML Parser
[EMAIL PROTECTED] wrote: I will make one exception to that statement. If it lands inside of APR-util, under the XML directory, and it is made to work with the XML parser, I can accept that landing spot. As it fits in closer with our goals (I think). Jim, I can't decide if this is what you meant or not. Yes, that is what I meant... side-by-side with the XML stuff under the APR project in apr-util. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: El-Kabong -- HTML Parser
On Thu, Aug 29, 2002 at 11:29:24AM -0700, Aaron Bannert wrote: On Thu, Aug 29, 2002 at 02:24:28PM -0400, Ryan Bloom wrote: +1 from me, I prefer APR actually. I am really uncomfortable with this going under the APR project. As things stand right now, it just doesn't fit with what we have stated our goals to be. If you want to change our stated goals, then go ahead and do it. Just committing code that doesn't fit with our goals isn't the way to do that. (I will defer answering this for an apr-only discussion.) I will make one exception to that statement. If it lands inside of APR-util, under the XML directory, and it is made to work with the XML parser, I can accept that landing spot. As it fits in closer with our goals (I think). Jim, I can't decide if this is what you meant or not. I'm +1 on integrating it into our XML stuff. I consider it to be equivalent to apr-util, so either we put it inside apr-util, or we create a new APR subproject or sub-library for it. I'm not keen on integrating it into the APR XML layer for a few reasons: 1 - APR's XML is not SAX-stylee. El-Kabong is. That isn't to say that E-K couldn't get a full object model interface, but it doesn't have it now. 2 - XML and HTML, while related, have several large differences which won't make a nice API (IMO). 3 - El-Kabong is quite speedy, and throwing another layer of indirection on top of it isn't particularly appealing. -- Jon
Re: El-Kabong -- HTML Parser
On Thu, 29 Aug 2002, Jon Travis wrote: On Thu, Aug 29, 2002 at 11:29:24AM -0700, Aaron Bannert wrote: On Thu, Aug 29, 2002 at 02:24:28PM -0400, Ryan Bloom wrote: I will make one exception to that statement. If it lands inside of APR-util, under the XML directory, and it is made to work with the XML parser, I can accept that landing spot. As it fits in closer with our goals (I think). Jim, I can't decide if this is what you meant or not. I'm +1 on integrating it into our XML stuff. I consider it to be equivalent to apr-util, so either we put it inside apr-util, or we create a new APR subproject or sub-library for it. I'm not keen on integrating it into the APR XML layer for a few reasons: 1 - APR's XML is not SAX-stylee. El-Kabong is. That isn't to say that E-K couldn't get a full object model interface, but it doesn't have it now. Expat is a stream based parsers that is pretty similar to SAX2. It isn't a DOM xml parser. -- Sander van Zoest [EMAIL PROTECTED] San Diego, CA, US http://Sander.vanZoest.com/
Re: El-Kabong -- HTML Parser
On Thu, Aug 29, 2002 at 02:30:35PM -0700, Sander van Zoest wrote: On Thu, 29 Aug 2002, Jon Travis wrote: On Thu, Aug 29, 2002 at 11:29:24AM -0700, Aaron Bannert wrote: On Thu, Aug 29, 2002 at 02:24:28PM -0400, Ryan Bloom wrote: I will make one exception to that statement. If it lands inside of APR-util, under the XML directory, and it is made to work with the XML parser, I can accept that landing spot. As it fits in closer with our goals (I think). Jim, I can't decide if this is what you meant or not. I'm +1 on integrating it into our XML stuff. I consider it to be equivalent to apr-util, so either we put it inside apr-util, or we create a new APR subproject or sub-library for it. I'm not keen on integrating it into the APR XML layer for a few reasons: 1 - APR's XML is not SAX-stylee. El-Kabong is. That isn't to say that E-K couldn't get a full object model interface, but it doesn't have it now. Expat is a stream based parsers that is pretty similar to SAX2. It isn't a DOM xml parser. What does this have to do with anything? Expat is uninvolved here. I was talking about the APR XML API, which may-or-may-not wrap Expat. That API is DOM style. -- Jon
Re: more on the charter (was: El-Kabong -- HTML Parser)
I was thinking mostly along the lines that under the web server project there exists the HTTP specific entities, and a HTML parser would Well - I am not sure where this APR (portability) or HTTP (hypertext protocol) focus comes from; we have umpteen parsers and processers and dommers and transformers and what not in the xml projects. IMHO that is where it fits perfectly. Especially if this form versus function (or language versus functional split) is to take hold. Dw
Re: more on the charter (was: El-Kabong -- HTML Parser)
At 11:16 AM +0200 8/28/02, Dirk-Willem van Gulik wrote: I was thinking mostly along the lines that under the web server project there exists the HTTP specific entities, and a HTML parser would Well - I am not sure where this APR (portability) or HTTP (hypertext protocol) focus comes from; we have umpteen parsers and processers and dommers and transformers and what not in the xml projects. Ah, the danger of categories: it's so easy and yet so difficult to define what they are. The above was just my interpretation of the present division. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: El-Kabong -- HTML Parser
A couple of notes on the parser: - It is pretty lightweight and self contained - This HTML parser can be used for a multitude of applications, in Apache 2.0 filter modules. The filter processes content generated by Apache or proxied content and can rewrite URLs embedded in HTML pages: a) URL rewriting on the fly for cookieless tracking and single sign-on b) Allow ProxyPassReverse to modify not only HTTP headers but look inside proxied content and rewrite hardcoded URLs c) Strip banners or malicious javascript before it reaches the client Those are some possibilities that having a fast, lightweight parser allows. Jon, maybe you can post the source somewhere so people can have a look and play with it Daniel On Mon, Aug 26, 2002 at 08:32:16PM -0700, Jon Travis wrote: Hi all... Jon Travis here... Covalent has written a pretty keen HTML parser (called el-kabong) which we'd like to offer to the ASF for inclusion in APR-util (or whichever other umbrella it fits under.) It's faster than anything I can find, provides a SAX stylee interface, uses APR for most of its operations (hash tables, etc.), and has a pretty nice testsuite. We use it in our code to re-write HTML on the fly. I would be the initial maintainer of the code. Please voice any interest, thanks. -- Jon -- Teach Yourself Apache 2 -- http://apacheworld.org/ty24/
Re: El-Kabong -- HTML Parser
On Tue, Aug 27, 2002 at 09:47:58AM -0700, daniel wrote: A couple of notes on the parser: - It is pretty lightweight and self contained - This HTML parser can be used for a multitude of applications, in Apache 2.0 filter modules. The filter processes content generated by Apache or proxied content and can rewrite URLs embedded in HTML pages: a) URL rewriting on the fly for cookieless tracking and single sign-on b) Allow ProxyPassReverse to modify not only HTTP headers but look inside proxied content and rewrite hardcoded URLs c) Strip banners or malicious javascript before it reaches the client Those are some possibilities that having a fast, lightweight parser allows. Jon, maybe you can post the source somewhere so people can have a look and play with it Daniel I can't publicly post the source under the ASF license until it has been accepted (which is a chicken egg issue). I can, however, distribute to individuals on a restricted basis for evaluation for acceptance. -- Jon
Re: El-Kabong -- HTML Parser
Well, if people are agreeing to this, can we get someone involved in the HTTPD project (non-Covalent affiliated) to review and approve/decline? Volunteers? -- Jon On Tue, Aug 27, 2002 at 01:22:03PM -0400, Jim Jagielski wrote: I didn't mean in the same tree at all! :) But, as you said, a subproj under HTTPD Jon Travis wrote: I personally think it belongs as some kind of sub-project to httpd, but not in the same tree. -- Jon On Tue, Aug 27, 2002 at 12:43:17PM -0400, Jim Jagielski wrote: Aaron Bannert wrote: On Tue, Aug 27, 2002 at 11:02:47AM -0400, Ryan Bloom wrote: I would prefer that this became it's own project either under the httpd project or the APR project. I don't believe that it should be a part of the APR-util library however. The functionality provided by el-kabong seems like a good fit within APR. I think it would be fine if el-kabong became a new subproject of APR. Personally, I think it's very cool that E-K is being folded into the ASF. I think the httpd project is a better fit however, simply because APR should be protocol ignorant. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: El-Kabong -- HTML Parser
Jon Travis wrote: Well, if people are agreeing to this, can we get someone involved in the HTTPD project (non-Covalent affiliated) to review and approve/decline? Volunteers? I can't publicly post the source under the ASF license until it has been accepted (which is a chicken egg issue). I can, however, distribute to individuals on a restricted basis for evaluation for acceptance. I don't think that is really the ASF Way. It would be rather unusual for Apache to accept code without a public review. The only cases I can think of are security-related. Why don't you just post the code under a Copyright Covalent, all rights reserved, with a promise to relicense if it is accepted. Joshua.
Re: El-Kabong -- HTML Parser
I can't publicly post the source under the ASF license until it has been accepted (which is a chicken egg issue). I can, however, distribute to individuals on a restricted basis for evaluation for acceptance. There is little (except for a few upset board members) stopping Covalent of posting the code somewhere publicly under an ASF (style) license. This has been done often in the past by the likes of IBM, Covalent and SUN at various moments. Either using an ASF license, an ASF style licecense or a BSD-ish license. Alternatively putting no or a simple (c) on it; and no further distribution clauses will make it simple 'look' but done re-distribute code. Which allows anyone to look at it - but would not allow anyone to re-distribute it. Getting that code accepted into the ASF repositories is another story. Dw
Re: El-Kabong -- HTML Parser
fyi, I've already emailed Jon about doing a review. I would recommend that at least one other review it, too. On Tue, Aug 27, 2002 at 10:28:18AM -0700, Jon Travis wrote: Well, if people are agreeing to this, can we get someone involved in the HTTPD project (non-Covalent affiliated) to review and approve/decline? Volunteers? -- Jon ... -- Greg Stein, http://www.lyra.org/
Re: more on the charter (was: El-Kabong -- HTML Parser)
At 12:43 PM -0700 8/27/02, Greg Stein wrote: APR is whatever we want it to be. If we start building things on You bet! Well, it depends on how far you want to take the statement whatever we want it to be :) *duck* top of APR that are functionally distinct from other projects under the ASF, then I believe it makes sense to keep them as subprojects of APR. Either we extend the meaning of APR to mean any portable libraries or we take away the server in HTTP Server Project. Per the Board, we are *already* about portable libraries. APR has evolved... Not only is the project about a portable runtime library, but also generic portable libraries as well. I also find this a Good Thing. Growth is good. But it isn't, and shouldn't be, a drop-box for every library or suite of routines that comes down the path (not that anyone is saying that it is or will be). Regarding specifically e-k, as a html parser, it's got more a family tie, IMO, to the HTTP server project, than APR. I think it fits in better among libapreq than in the APR world, mostly because it's focused towards the web server and web server functionality. Would it destroy APR to fold e-k into it... I don't think so. Is there a better place under the ASF than in APR? Maybe :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: more on the charter (was: El-Kabong -- HTML Parser)
Hi - -- Original Message -- Reply-To: [EMAIL PROTECTED] Date: Tue, 27 Aug 2002 16:14:20 -0400 To: [EMAIL PROTECTED] From: Jim Jagielski [EMAIL PROTECTED] Subject: Re: more on the charter (was: El-Kabong -- HTML Parser) Cc: [EMAIL PROTECTED] Would it destroy APR to fold e-k into it... I don't think so. Is there a better place under the ASF than in APR? Maybe :) I say make it a peer of the apr xml utilities. sterling
Re: more on the charter (was: El-Kabong -- HTML Parser)
On Tue, Aug 27, 2002 at 04:14:20PM -0400, Jim Jagielski wrote: At 12:43 PM -0700 8/27/02, Greg Stein wrote: APR is whatever we want it to be. If we start building things on You bet! Well, it depends on how far you want to take the statement whatever we want it to be :) *duck* Good thing you ducked, or you'd be sportin' a black eye, mister! :-) ... But it isn't, and shouldn't be, a drop-box for every library or suite of routines that comes down the path (not that anyone is saying that it is or will be). Agreed. I think that we're all very wary of that, so we've got a nice little resistance to ending up that way. Two more years from now? *shrug* Regarding specifically e-k, as a html parser, it's got more a family tie, IMO, to the HTTP server project, than APR. I think it fits in better among libapreq than in the APR world, mostly because it's focused towards the web server and web server functionality. Eh? I see this as mostly a client library. I'm thinking screen scraping, or the core of an HTML renderer, or something similar. Yes, it *also* has some neat server capabilities (filter-based processing). Because it falls into *both* camps, I don't see it associated with the HTTP Server Project. Would it destroy APR to fold e-k into it... I don't think so. Is there a better place under the ASF than in APR? Maybe :) I obviously don't see it falling into httpd :-). Elsewhere? Not with our current structure. If we created a web project, then it could go there. Of course, just about *everything* the ASF does is somehow related to the web, so I'd be wary of ever giving a +1 to creating a web project :-) Now, if there was a document project, or DOM project, or something like that. We could put the XML parsers, this HTML parser, and prolly some other xml/jakarta tools in there. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: more on the charter (was: El-Kabong -- HTML Parser)
Greg Stein wrote: Regarding specifically e-k, as a html parser, it's got more a family tie, IMO, to the HTTP server project, than APR. I think it fits in better among libapreq than in the APR world, mostly because it's focused towards the web server and web server functionality. Eh? I see this as mostly a client library. I'm thinking screen scraping, or the core of an HTML renderer, or something similar. Yes, it *also* has some neat server capabilities (filter-based processing). I was thinking mostly along the lines that under the web server project there exists the HTTP specific entities, and a HTML parser would fall into there. But yeah, it could also fit in APR too. But it's not going to ruffle my feathers either way. :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
