nnhtml type backends -- idea

nnhtml type backends -- idea

[Kai Großjohann]

It seems that many of the web-based backends have problems because the
HTML format changes and thus the parsing rules break.

WIBNI there was a central server (www.gnus.org would be an obvious
choice) which offered a couple of files containing the parsing rules?
And that the nnhtml backends would fetch the current parsing rules
before sending a query to the web server in question?

kai
-- 
Beware of flying birch trees.

Re: nnhtml type backends -- idea

[Shenghuo ZHU]

>>>>> "KG" == Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:

KG> It seems that many of the web-based backends have problems because
KG> the HTML format changes and thus the parsing rules break.

KG> WIBNI there was a central server (www.gnus.org would be an obvious
KG> choice) which offered a couple of files containing the parsing
KG> rules?  And that the nnhtml backends would fetch the current
KG> parsing rules before sending a query to the web server in
KG> question?

The idea sounds good. The parsing rules could be some urls and elisp
codes.

-- 
Shenghuo

Re: nnhtml type backends -- idea

[Jaap-Henk Hoepman]

On 18 Apr 2000 12:57:54 -0400 Shenghuo ZHU <zsh@cs.rochester.edu> writes:
> >>>>> "KG" == Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:
> 
> KG> It seems that many of the web-based backends have problems because
> KG> the HTML format changes and thus the parsing rules break.
> 
> KG> WIBNI there was a central server (www.gnus.org would be an obvious
> KG> choice) which offered a couple of files containing the parsing
> KG> rules?  And that the nnhtml backends would fetch the current
> KG> parsing rules before sending a query to the web server in
> KG> question?
> 
> The idea sounds good. The parsing rules could be some urls and elisp
> codes.

I'm not a big fan of dynamically loading remote code for the obvious security
problems this may cause. If anything, it should be off by default and should
always ask the user in case a new version of the rules are about to be
downloaded. Code signing stuff might be a second line of defence.

Jaap-Henk

-- 
Jaap-Henk Hoepman             | Come sail your ships around me
Dept. of Computer Science     | And burn these bridges down
University of Twente          |       Nick Cave - "Ship Song"
Email: hoepman@cs.utwente.nl === WWW: www.cs.utwente.nl/~hoepman
Phone: +31 53 4893795 === Secr: +31 53 4893770 === Fax: +31 53 4894590
PGP ID: 0xF52E26DD  Fingerprint: 1AED DDEB C7F1 DBB3  0556 4732 4217 ABEF

Re: nnhtml type backends -- idea

[Lars Magne Ingebrigtsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> WIBNI there was a central server (www.gnus.org would be an obvious
> choice) which offered a couple of files containing the parsing rules?

That would be nice, but wouldn't the parsing rules really have to be
elisp code?  And do you really want to download possibly harmful code
automatically? 

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: nnhtml type backends -- idea

[Dan Christensen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> That would be nice, but wouldn't the parsing rules really have to be
> elisp code?  And do you really want to download possibly harmful code
> automatically? 

I download gnus automatically, and that code isn't, umm, er, never mind.

:-)

Dan

-- 
Dan Christensen
jdc@math.jhu.edu

Re: nnhtml type backends -- idea

[Kai Großjohann]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> 
> > WIBNI there was a central server (www.gnus.org would be an obvious
> > choice) which offered a couple of files containing the parsing rules?
> 
> That would be nice, but wouldn't the parsing rules really have to be
> elisp code?  And do you really want to download possibly harmful code
> automatically? 

Maybe it is possible to do without Lisp.  And even if it isn't,
splitting out the parsing rules into something separate from Gnus so
that people can easily update the parsing rules might be a nifty
thing.  OTOH, one could just require them to update Gnus.  Hm.

kai
-- 
Beware of flying birch trees.

Re: nnhtml type backends -- idea

[Eric Marsden]

>>>>> "jh" == Jaap-Henk Hoepman <hoepman@cs.utwente.nl> writes:

  jh> I'm not a big fan of dynamically loading remote code for the
  jh> obvious security problems this may cause. If anything, it should
  jh> be off by default and should always ask the user in case a new
  jh> version of the rules are about to be downloaded. Code signing
  jh> stuff might be a second line of defence.

and sandboxing as per sandbox.el

   <URL:http://x34.deja.com/=dnc/getdoc.xp?AN=571014320&fmt=raw>

-- 
Eric Marsden

Re: nnhtml type backends -- idea

[Lars Magne Ingebrigtsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Maybe it is possible to do without Lisp.  And even if it isn't,
> splitting out the parsing rules into something separate from Gnus so
> that people can easily update the parsing rules might be a nifty
> thing.  OTOH, one could just require them to update Gnus.  Hm.

The various things that the html-based backends do to parse the stuff
they get are very hairy.  I don't think something non-Lispy would do
the trick.  (Well, one could define a language for doing stuff like
that, but it sounds (to me) like major work.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: nnhtml type backends -- idea

[Lars Magne Ingebrigtsen]

Eric Marsden <emarsden@mail.dotcom.fr> writes:

> and sandboxing as per sandbox.el
> 
>    <URL:http://x34.deja.com/=dnc/getdoc.xp?AN=571014320&fmt=raw>

Neat.  Is think going to be included in the Emacsen?

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen