State of the AJAX Union

------=_Part_12879_25424363.1162531709620
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I know there is a rich history of challenges implementing any kind of
JavaScript interpretation using Mechanize or any other web
scripting/automation utility, but I was wondering if anyone has tried to
focus on "Mechanizing" AJAX?

I realize this would take at least some degree of JavaScript interpretation
and most likely some kind of internal DOM representation to maintain the
state of the page, and that it's probably extraordinarily challenging.
Nonetheless, with the increasing popularity of AJAX, it seems like it
eventually needs to be done. I'm watching more and more of the sites I've
written automation for slowly migrate to AJAX and it's getting increasingly
difficult to work around these designs.

I just wanted to get a handle on where other folks were at before I start
banging my head against the wall to come up with a solution. :-)

Thanks,
Chris

------=_Part_12879_25424363.1162531709620--

Re: State of the AJAX Union

On Fri, 3 Nov 2006, Christopher Hart wrote:

> I know there is a rich history of challenges implementing any kind of
> JavaScript interpretation using Mechanize or any other web
> scripting/automation utility, but I was wondering if anyone has tried to
> focus on "Mechanizing" AJAX?
>
> I realize this would take at least some degree of JavaScript interpretation
> and most likely some kind of internal DOM representation to maintain the

No doubt you could profitably concentrate your implementation / bug-fixing
effort on the DOM features you're interested in, but I don't think there's
any terribly obvious closed subset of the DOM &c. that you could implement
and save yourself lots of work as compared with implementing the full
monty.


> state of the page, and that it's probably extraordinarily challenging.

Probably only extraordinarily challenging in that it involves lots of work
-- that's why nobody has done it :-)


> Nonetheless, with the increasing popularity of AJAX, it seems like it
> eventually needs to be done. I'm watching more and more of the sites I've
> written automation for slowly migrate to AJAX and it's getting increasingly
> difficult to work around these designs.
[...]

Whether or not it "needs" to be done, it won't be, unless somebody steps
up to do it.


John

Re: State of the AJAX Union

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John J Lee wrote:
> On Fri, 3 Nov 2006, Christopher Hart wrote:
>
>> I know there is a rich history of challenges implementing any kind of
>> JavaScript interpretation using Mechanize or any other web
>> scripting/automation utility, but I was wondering if anyone has tried to
>> focus on "Mechanizing" AJAX?
>>
>> I realize this would take at least some degree of JavaScript
>> interpretation
>> and most likely some kind of internal DOM representation to maintain the

I too thought about that. Maybe using the JavaScript or
JavaScript::Spidermonkey module and XML::DOM. I will certainly
experiment around with them, as we need it at work. Doesn't seem to be
too hard to me, but of course, I'm underestimating that :)

Nine
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFFZHiJ1QuEJQQMVrgRApH4AJsGUuTZ85lrZ97YcM2YySYYyrHCBgCd EtMg
ADzh50sEDXnzqIywxLkPBi4=
=/YKn
-----END PGP SIGNATURE-----

Re: State of the AJAX Union

On Wed, 22 Nov 2006, Stefan Seifert wrote:
[...]
> I too thought about that. Maybe using the JavaScript or
> JavaScript::Spidermonkey module and XML::DOM. I will certainly
> experiment around with them, as we need it at work. Doesn't seem to be

Sigh, we've had this same little discussion at least five times here.

The browser object model is not the XML DOM. It is the HTML DOM (which is
ill-defined in practice, and is not really a superset of the XML DOM),
plus other stuff. There is currently no implementation of it outside of
browsers. Plus you have to build the damned DOM in the first place :-)


> too hard to me, but of course, I'm underestimating that :)

Yes.

As I've said many times before here, getting something working is not too
hard, getting something useful is harder (how much depends on the
audience, I guess), getting something good is a lot of work. Maybe this
is universally true, but especially so of JS support for LWP :-)


John

Re: State of the AJAX Union

------=_Part_77513_12808635.1164228705915
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Would an "easier" (yet still monumental) starting point be to tackle the DOM
implementation independent of a JS engine?

It seems like attempting to create any kind of a JavaScript framework
implementation would be pretty useless (and horribly incomplete) without the
DOM being present first. An internal DOM representation seems to be pretty
useless by itself, but at least it's a foundation for a useful JS
implementation later.

To me, the key challenge appears to be coming up with a DOM framework that
can manage its state in the same way that a browser does while providing an
interface that can later be wired up with a JS engine and, perhaps, some
kind of a UI simulation layer (to simulate events that would normally occur
in a browser - onClick, onBlur, etc.). I don't think we'd want to tie the
DOM directly to the JS engine anyway, so having an abstracted interface is
actually a benefit.

This seems like a great open source project - it's way too much to handle
for most individual developers, but I think could be tackled with a
moderately organized team of folks with a good design laid out in advance.

Chris

On 11/22/06, John J Lee wrote:
>
> On Wed, 22 Nov 2006, Stefan Seifert wrote:
> [...]
> > I too thought about that. Maybe using the JavaScript or
> > JavaScript::Spidermonkey module and XML::DOM. I will certainly
> > experiment around with them, as we need it at work. Doesn't seem to be
>
> Sigh, we've had this same little discussion at least five times here.
>
> The browser object model is not the XML DOM. It is the HTML DOM (which is
> ill-defined in practice, and is not really a superset of the XML DOM),
> plus other stuff. There is currently no implementation of it outside of
> browsers. Plus you have to build the damned DOM in the first place :-)
>
>
> > too hard to me, but of course, I'm underestimating that :)
>
> Yes.
>
> As I've said many times before here, getting something working is not too
> hard, getting something useful is harder (how much depends on the
> audience, I guess), getting something good is a lot of work. Maybe this
> is universally true, but especially so of JS support for LWP :-)
>
>
> John
>
>

------=_Part_77513_12808635.1164228705915--

Re: State of the AJAX Union

On Nov 22, 2006, at 2:51 PM, Christopher Hart wrote:

> Would an "easier" (yet still monumental) starting point be to
> tackle the DOM
> implementation independent of a JS engine?

All of this is pointless unless someone is willing to step up and
JFDI. Otherwise, it's just rehashing the same theoreticals. People
have been talking to me about adding JavaScript support for years,
and nobody has ever done it.

http://search.cpan.org/dist/WWW-Mechanize/lib/WWW/Mechanize/
FAQ.pod#JavaScript

xoxo,
Andy

--
Andy Lester => andy@petdance.com => www.petdance.com => AIM:petdance

Re: State of the AJAX Union

------=_Part_77645_2631437.1164229284803
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I agree that folks have been talking about JS for a long time, and that it's
frustrating, but what I'm suggesting is that we need to tackle a different
problem first.

This isn't an academic question - without knowing how the DOM is going to
work (or even if there is one), the JS conversation can't be anything but
theoretical (or, at best, very incomplete in the concrete).

I'm just trying to see if any work was already going on in this space, or if
there was any interest in a team effort to attempt it.

On 11/22/06, Andy Lester wrote:
>
>
> On Nov 22, 2006, at 2:51 PM, Christopher Hart wrote:
>
> > Would an "easier" (yet still monumental) starting point be to
> > tackle the DOM
> > implementation independent of a JS engine?
>
> All of this is pointless unless someone is willing to step up and
> JFDI. Otherwise, it's just rehashing the same theoreticals. People
> have been talking to me about adding JavaScript support for years,
> and nobody has ever done it.
>
> http://search.cpan.org/dist/WWW-Mechanize/lib/WWW/Mechanize/
> FAQ.pod#JavaScript
>
> xoxo,
> Andy
>
> --
> Andy Lester => andy@petdance.com => www.petdance.com => AIM:petdance
>
>
>
>
>

------=_Part_77645_2631437.1164229284803--

Re: State of the AJAX Union

I've also been interested for a long time and tried to work on
this 2 years ago but didn't get far enough to bother trying
to release anything.

DOM could be tackled in an HTML::Tree-->XML::"parser" fashion.
That way, bad mark-up could be legitimized and something like
XML::LibXML could handle the DOM.

I would gladly throw down if there was a group effort with a
real plan. I'm not the right hacker to lead this project though.


-Ashley

On Wednesday, Nov 22, 2006, at 13:01 US/Pacific, Christopher Hart wrote:

> I agree that folks have been talking about JS for a long time, and
> that it's
> frustrating, but what I'm suggesting is that we need to tackle a
> different
> problem first.
>
> This isn't an academic question - without knowing how the DOM is going
> to
> work (or even if there is one), the JS conversation can't be anything
> but
> theoretical (or, at best, very incomplete in the concrete).
>
> I'm just trying to see if any work was already going on in this space,
> or if
> there was any interest in a team effort to attempt it.
>
> On 11/22/06, Andy Lester wrote:
>>
>>
>> On Nov 22, 2006, at 2:51 PM, Christopher Hart wrote:
>>
>> > Would an "easier" (yet still monumental) starting point be to
>> > tackle the DOM
>> > implementation independent of a JS engine?
>>
>> All of this is pointless unless someone is willing to step up and
>> JFDI. Otherwise, it's just rehashing the same theoreticals. People
>> have been talking to me about adding JavaScript support for years,
>> and nobody has ever done it.
>>
>> http://search.cpan.org/dist/WWW-Mechanize/lib/WWW/Mechanize/
>> FAQ.pod#JavaScript
>>
>> xoxo,
>> Andy
>>
>> --
>> Andy Lester => andy@petdance.com => www.petdance.com => AIM:petdance
>>

Re: State of the AJAX Union

------=_Part_78438_20243666.1164232694368
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I'm willing to take a crack at laying out a vision, high level objectives
and some implementation requirements based on my experiences and see how
much interest there is for a group effort if others are interested in
helping out. I'm sure I'll miss a lot that others with different
experiences could help fill in the gaps in terms of requirements. Having a
good design going into this is going to be critical to having something
usable, so I think it'd be worthwhile to spend the time documenting what's
needed and potential approaches before defining the solution.

If there's enough interest and potential contributors, we can move forward
from there... What do you think?

Chris

On 11/22/06, apv wrote:
>
> I've also been interested for a long time and tried to work on
> this 2 years ago but didn't get far enough to bother trying
> to release anything.
>
> DOM could be tackled in an HTML::Tree-->XML::"parser" fashion.
> That way, bad mark-up could be legitimized and something like
> XML::LibXML could handle the DOM.
>
> I would gladly throw down if there was a group effort with a
> real plan. I'm not the right hacker to lead this project though.
>
>
> -Ashley
>
> On Wednesday, Nov 22, 2006, at 13:01 US/Pacific, Christopher Hart wrote:
>
> > I agree that folks have been talking about JS for a long time, and
> > that it's
> > frustrating, but what I'm suggesting is that we need to tackle a
> > different
> > problem first.
> >
> > This isn't an academic question - without knowing how the DOM is going
> > to
> > work (or even if there is one), the JS conversation can't be anything
> > but
> > theoretical (or, at best, very incomplete in the concrete).
> >
> > I'm just trying to see if any work was already going on in this space,
> > or if
> > there was any interest in a team effort to attempt it.
> >
> > On 11/22/06, Andy Lester wrote:
> >>
> >>
> >> On Nov 22, 2006, at 2:51 PM, Christopher Hart wrote:
> >>
> >> > Would an "easier" (yet still monumental) starting point be to
> >> > tackle the DOM
> >> > implementation independent of a JS engine?
> >>
> >> All of this is pointless unless someone is willing to step up and
> >> JFDI. Otherwise, it's just rehashing the same theoreticals. People
> >> have been talking to me about adding JavaScript support for years,
> >> and nobody has ever done it.
> >>
> >> http://search.cpan.org/dist/WWW-Mechanize/lib/WWW/Mechanize/
> >> FAQ.pod#JavaScript
> >>
> >> xoxo,
> >> Andy
> >>
> >> --
> >> Andy Lester => andy@petdance.com => www.petdance.com => AIM:petdance
> >>
>
>

------=_Part_78438_20243666.1164232694368--

libwww-perl-5.805 install problems

Howdy:

I guess that this means that my subscription to libwww-perl was
accepted. :-|

I am trying to install libwww-perl-5.805.
In ../libwww-5.805/ I run the ./install.sh script and it complains that
I need
URI, HTML::Parser, and Compress::Zlib 1.10.

I need this for a LTSP v4.2 server.

I am running Slackware v11.0, so a .rpm or .tar. would be fine with me.

Has anyone a URL for URI, HTML::Parser, and Compress::Zlib 1.10 ?

Regards, Chuck

Re: libwww-perl-5.805 install problems

On Nov 22, 2006, at 4:13 PM, Chuck Gelm wrote:

> Has anyone a URL for URI, HTML::Parser, and Compress::Zlib 1.10 ?

Same place you got libwww, probably. Did you go to search.cpan.org
to get it?

You can also use the CPAN shell to automagically take care of those
dependencies.

xoxo,
Andy


--
Andy Lester => andy@petdance.com => www.petdance.com => AIM:petdance

Re: libwww-perl-5.805 install problems

Andy Lester wrote:
>
> On Nov 22, 2006, at 4:13 PM, Chuck Gelm wrote:
>
>> Has anyone a URL for URI, HTML::Parser, and Compress::Zlib 1.10 ?
>
> Same place you got libwww, probably. Did you go to search.cpan.org to
> get it?
>
> You can also use the CPAN shell to automagically take care of those
> dependencies.
>
> xoxo,
> Andy
>
>
> --
> Andy Lester => andy@petdance.com => www.petdance.com => AIM:petdance
Hi, Andy:

Thanks for the response.
I am not finding those three items.
I, probably, found libwww-perl-5.805 at CPAN, but I am not finding
URI, HTML::Parser, and Compress::Zlib 1.10.

I do not know what a 'CPAN shell' is.
I have never used perl.
I am trying to install LTSP v4.2. (http://ltsp.org/)
which requires perl and libwww-perl.

Please, just post the URLs.

RE: State of the AJAX Union

I've scripted with JS for 12 years and would contribute all I could to a
project of this type. My interest would be more from a reverse engineering
view point. If the LWP could be used to efficiently parse JS at useragent
level it would be both a blessing and a curse. Right now JS is great for
blind-siding un-wanted spiders that are slowly learning what to do. Getting
a jump on this could be advantageous to combating A JS capable robot
harvesting information for nefarious purposes.

Jim

-----Original Message-----
From: John J Lee [mailto:jjl@pobox.com]
Sent: Wednesday, November 22, 2006 2:35 PM
To: Stefan Seifert
Cc: libwww@perl.org
Subject: Re: State of the AJAX Union


On Wed, 22 Nov 2006, Stefan Seifert wrote:
[...]
> I too thought about that. Maybe using the JavaScript or
> JavaScript::Spidermonkey module and XML::DOM. I will certainly
> experiment around with them, as we need it at work. Doesn't seem to be

Sigh, we've had this same little discussion at least five times here.

The browser object model is not the XML DOM. It is the HTML DOM (which is
ill-defined in practice, and is not really a superset of the XML DOM),
plus other stuff. There is currently no implementation of it outside of
browsers. Plus you have to build the damned DOM in the first place :-)


> too hard to me, but of course, I'm underestimating that :)

Yes.

As I've said many times before here, getting something working is not too
hard, getting something useful is harder (how much depends on the
audience, I guess), getting something good is a lot of work. Maybe this
is universally true, but especially so of JS support for LWP :-)


John




--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.409 / Virus Database: 268.14.13/546 - Release Date: 11/22/2006

Finding CPAN modules (was Re: libwww-perl-5.805 install problems)

http://search.cpan.org

URI: http://search.cpan.org/author/GAAS/URI-1.35/URI.pm
HTML::Parser: http://search.cpan.org/author/GAAS/HTML-Parser-3.55/Parser.p m

and I'll let you do your own search (I promise it will work) for Compress::Zlib.

All the best,

J

PS: By the way, if you run Linux or have a Mac you may want to use your
operating system's default package manager to fetch and install these modules.
Likewise if you run Windows and have installed ActiveState Perl, you may want to
use the PPM (package manager) that comes with Active State Perl.

Re: State of the AJAX Union

On Wed, 22 Nov 2006, apv wrote:

> I've also been interested for a long time and tried to work on
> this 2 years ago but didn't get far enough to bother trying
> to release anything.
[...]
> I would gladly throw down if there was a group effort with a
> real plan. I'm not the right hacker to lead this project though.

Publish and be damned!

Doesn't matter if you don't want to lead something. Somebody has to get
the ball rolling if it's to happen, so why not you?


John

Re: State of the AJAX Union

On Wed, 22 Nov 2006, Christopher Hart wrote:

> I'm willing to take a crack at laying out a vision, high level objectives
> and some implementation requirements based on my experiences and see how
[...]

Everyone who's seriously interested is willing to do that. Indeed, many
have surely done that already, including myself.


John

Re: State of the AJAX Union

On Wed, 22 Nov 2006, Christopher Hart wrote:

> I agree that folks have been talking about JS for a long time, and that it's
> frustrating, but what I'm suggesting is that we need to tackle a different
> problem first.
[...]

An HTML DOM implemention is a necessary part of JS support, sure (though
Stefan points out that for web app testing -- as opposed to scraping -- an
XML DOM may be sufficient for some purposes).

Forgive me for being blunt, but that's not the blinding flash of insight
that's needed

What's needed is for somebody to actually write and publish some code --
and then for people to *keep on* working on it. No doubt it sometimes
happens, but I've never seen a "free-range" open source project (as
opposed to one started within a company) start up based on one person's
plan and another's code.

perspiration-not-inspiration-ly y'rs,


John

Any interest in an HTML DOM in C / C# / similar? (was Re: State ofthe AJAX Union)

On Wed, 22 Nov 2006, Christopher Hart wrote:

> Would an "easier" (yet still monumental) starting point be to tackle the DOM
> implementation independent of a JS engine?
[...]
> This seems like a great open source project - it's way too much to handle
> for most individual developers, but I think could be tackled with a
> moderately organized team of folks with a good design laid out in advance.
[...]

So, having pooh-poohed Christopher's proposal, I'm going to make a very
similar proposal of my own.

Give me some slack, I have the excuse of actually having put in some
implementation effort on this, and published the code :-) (but not in
Perl). And I'm asking with a view to writing some more code myself
(albeit only a slim chance of that happening).

So, my question / semi-serious proposal is: is anybody here interested in
collaborating in writing a portable HTML DOM library and DOM builder in a
language *other* than Perl, with the intent of wrapping it for Perl and
other languages (Python is my own interest)?

I'm afraid I'm not interested in Perl 6's cross-language support, though.
If it were me working on it, it would probably have to be C, C++ or C# (or
possibly Java, or something weirder like Caml). Cross-language use is one
reason for my thinking about doing it in one of those languages. Memory
usage and execution speed is another. I lean towards C or C#.


John

Re: Any interest in an HTML DOM in C / C# / similar? (was Re: State of the AJAX Union)

------=_Part_94276_3112833.1164313518508
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

For one particular application, I need the speed of Perl's regex engine and
I have not been able to match it in C# or even with limited attempts using
C++ and Boost's regex library. So, regardless of feature availability on
other platforms, I'm going to continue pursuing DOM & JS functionality in
Perl extending WWW::Mechanize.

That said, I do a lot of *other* work in C# and what you suggest would be
useful. If you already have something in the works (you mentioned
publishing some code), I'd be interested in learning more.

On 11/23/06, John J Lee wrote:
>
> On Wed, 22 Nov 2006, Christopher Hart wrote:
>
> > Would an "easier" (yet still monumental) starting point be to tackle the
> DOM
> > implementation independent of a JS engine?
> [...]
> > This seems like a great open source project - it's way too much to
> handle
> > for most individual developers, but I think could be tackled with a
> > moderately organized team of folks with a good design laid out in
> advance.
> [...]
>
> So, having pooh-poohed Christopher's proposal, I'm going to make a very
> similar proposal of my own.
>
> Give me some slack, I have the excuse of actually having put in some
> implementation effort on this, and published the code :-) (but not in
> Perl). And I'm asking with a view to writing some more code myself
> (albeit only a slim chance of that happening).
>
> So, my question / semi-serious proposal is: is anybody here interested in
> collaborating in writing a portable HTML DOM library and DOM builder in a
> language *other* than Perl, with the intent of wrapping it for Perl and
> other languages (Python is my own interest)?
>
> I'm afraid I'm not interested in Perl 6's cross-language support, though.
> If it were me working on it, it would probably have to be C, C++ or C# (or
> possibly Java, or something weirder like Caml). Cross-language use is one
> reason for my thinking about doing it in one of those languages. Memory
> usage and execution speed is another. I lean towards C or C#.
>
>
> John
>
>

------=_Part_94276_3112833.1164313518508--

Re: Finding CPAN modules (was Re: libwww-perl-5.805 install problems)

Hi, J:

Thanks. I see how that web page works now.
It is very alien. I have never seen a web interface like that before.

The complaint specifies that Compress::Zlib 1.10 is missing and
that web page's search for Compress::Zlib
only returns Compress-Zlib-2.001.tar.gz
.
:-|

I have since found Compress-Zlib-1.10.tar.gz at another site.

I am using Slackware v11.0, kernel 2.6.17.13, but I do not
know how to make its package manager 'fetch'.

Again, Thanks.

Chuck

Jacinta Richardson wrote:
> http://search.cpan.org
>
> URI: http://search.cpan.org/author/GAAS/URI-1.35/URI.pm
> HTML::Parser:
> http://search.cpan.org/author/GAAS/HTML-Parser-3.55/Parser.p m
>
> and I'll let you do your own search (I promise it will work) for
> Compress::Zlib.
>
> All the best,
>
> J
>
> PS: By the way, if you run Linux or have a Mac you may want to use
> your operating system's default package manager to fetch and install
> these modules. Likewise if you run Windows and have installed
> ActiveState Perl, you may want to use the PPM (package manager) that
> comes with Active State Perl.
>
>

Re: Any interest in an HTML DOM in C / C# / similar? (was Re: Stateof the AJAX Union)

Can you explain how wrapping a C/C# DOM implementation and using that from
Perl is in conflict with using Perl's regex engine?


John

On Thu, 23 Nov 2006, Christopher Hart wrote:

> For one particular application, I need the speed of Perl's regex engine and
> I have not been able to match it in C# or even with limited attempts using
> C++ and Boost's regex library. So, regardless of feature availability on
> other platforms, I'm going to continue pursuing DOM & JS functionality in
> Perl extending WWW::Mechanize.
>
> That said, I do a lot of *other* work in C# and what you suggest would be
> useful. If you already have something in the works (you mentioned
> publishing some code), I'd be interested in learning more.
>
> On 11/23/06, John J Lee wrote:
>>
>> On Wed, 22 Nov 2006, Christopher Hart wrote:
>>
>> > Would an "easier" (yet still monumental) starting point be to tackle the
>> DOM
>> > implementation independent of a JS engine?
>> [...]
>> > This seems like a great open source project - it's way too much to
>> handle
>> > for most individual developers, but I think could be tackled with a
>> > moderately organized team of folks with a good design laid out in
>> advance.
>> [...]
>>
>> So, having pooh-poohed Christopher's proposal, I'm going to make a very
>> similar proposal of my own.
>>
>> Give me some slack, I have the excuse of actually having put in some
>> implementation effort on this, and published the code :-) (but not in
>> Perl). And I'm asking with a view to writing some more code myself
>> (albeit only a slim chance of that happening).
>>
>> So, my question / semi-serious proposal is: is anybody here interested in
>> collaborating in writing a portable HTML DOM library and DOM builder in a
>> language *other* than Perl, with the intent of wrapping it for Perl and
>> other languages (Python is my own interest)?
>>
>> I'm afraid I'm not interested in Perl 6's cross-language support, though.
>> If it were me working on it, it would probably have to be C, C++ or C# (or
>> possibly Java, or something weirder like Caml). Cross-language use is one
>> reason for my thinking about doing it in one of those languages. Memory
>> usage and execution speed is another. I lean towards C or C#.
>>
>>
>> John
>>
>>
>

Re: Any interest in an HTML DOM in C / C# / similar? (was Re: State of the AJAX Union)

------=_Part_49_33217823.1164376869389
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Well, maybe it isn't in conflict, but I failed to mention another
requirement - the application that I'm referring to also has to run on
Linux. Perhaps that still doesn't represent a problem - could Mono be
workable? I haven't worked with it enough to know.

On 11/24/06, John J Lee wrote:
>
> Can you explain how wrapping a C/C# DOM implementation and using that from
> Perl is in conflict with using Perl's regex engine?
>
>
> John
>
> On Thu, 23 Nov 2006, Christopher Hart wrote:
>
> > For one particular application, I need the speed of Perl's regex engine
> and
> > I have not been able to match it in C# or even with limited attempts
> using
> > C++ and Boost's regex library. So, regardless of feature availability
> on
> > other platforms, I'm going to continue pursuing DOM & JS functionality
> in
> > Perl extending WWW::Mechanize.
> >
> > That said, I do a lot of *other* work in C# and what you suggest would
> be
> > useful. If you already have something in the works (you mentioned
> > publishing some code), I'd be interested in learning more.
> >
> > On 11/23/06, John J Lee wrote:
> >>
> >> On Wed, 22 Nov 2006, Christopher Hart wrote:
> >>
> >> > Would an "easier" (yet still monumental) starting point be to tackle
> the
> >> DOM
> >> > implementation independent of a JS engine?
> >> [...]
> >> > This seems like a great open source project - it's way too much to
> >> handle
> >> > for most individual developers, but I think could be tackled with a
> >> > moderately organized team of folks with a good design laid out in
> >> advance.
> >> [...]
> >>
> >> So, having pooh-poohed Christopher's proposal, I'm going to make a very
> >> similar proposal of my own.
> >>
> >> Give me some slack, I have the excuse of actually having put in some
> >> implementation effort on this, and published the code :-) (but not in
> >> Perl). And I'm asking with a view to writing some more code myself
> >> (albeit only a slim chance of that happening).
> >>
> >> So, my question / semi-serious proposal is: is anybody here interested
> in
> >> collaborating in writing a portable HTML DOM library and DOM builder in
> a
> >> language *other* than Perl, with the intent of wrapping it for Perl and
> >> other languages (Python is my own interest)?
> >>
> >> I'm afraid I'm not interested in Perl 6's cross-language support,
> though.
> >> If it were me working on it, it would probably have to be C, C++ or C#
> (or
> >> possibly Java, or something weirder like Caml). Cross-language use is
> one
> >> reason for my thinking about doing it in one of those
> languages. Memory
> >> usage and execution speed is another. I lean towards C or C#.
> >>
> >>
> >> John
> >>
> >>
> >
>

------=_Part_49_33217823.1164376869389--

Re: Finding CPAN modules (was Re: libwww-perl-5.805 install problems)

On 11/23/2006 09:23 PM, Chuck Gelm wrote:
> Jacinta Richardson wrote:
>> http://search.cpan.org
>>
>> URI: http://search.cpan.org/author/GAAS/URI-1.35/URI.pm
>> HTML::Parser:
>> http://search.cpan.org/author/GAAS/HTML-Parser-3.55/Parser.p m
>>
>> and I'll let you do your own search (I promise it will work) for
>> Compress::Zlib.
>>
>> All the best,
>>
>> J
>>
>> PS: By the way, if you run Linux or have a Mac you may want to use
>> your operating system's default package manager to fetch and install
>> these modules. Likewise if you run Windows and have installed
>> ActiveState Perl, you may want to use the PPM (package manager) that
>> comes with Active State Perl.
>>
>>
>
>
> Hi, J:
>
> Thanks. I see how that web page works now.
> It is very alien. I have never seen a web interface like that before.
>
> The complaint specifies that Compress::Zlib 1.10 is missing and
> that web page's search for Compress::Zlib
> only returns Compress-Zlib-2.001.tar.gz
> .

>
> :-|
>
> I have since found Compress-Zlib-1.10.tar.gz at another site.
>
> I am using Slackware v11.0, kernel 2.6.17.13, but I do not
> know how to make its package manager 'fetch'.
>
> Again, Thanks.
>
> Chuck
>

AFAIK, Slackware's native package manager doesn't fetch things for you.
That's part of the reason that the CPAN shell exists.

If you had configured the CPAN shell, you could have installed
Compress::Zlib without having to know where it was located. The CPAN
shell takes care of that for you.

Oh, and BTW, if you want to update Slackware easily, get a program
called "slapt-get."