forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <>
Subject Re: file: implemented (Re: cvs commit: ...)
Date Fri, 13 Dec 2002 09:42:22 GMT
On Thu, Dec 12, 2002 at 11:48:49PM -0800, Stefano Mazzocchi wrote:
> Jeff Turner wrote:
> >  "To rave in violent, high-sounding, or extravagant language, without
> >  dignity of thought"
> >
> >Please remember the context; Nicola was suggesting an implementation of a
> >new feature (schemes) that would tie Forrest even tighter to the CLI.  If
> >it helps, more context is that I was writing at 3am after a day's
> >fighting with Transformers :P
> I know I shouldn't (and I'm getting year after year better on that) but 
> when somebody says that I did a "blindingly stupid" thing, I tend to get 
> pissed no matter what their context is :-Prrr

:) Sorry.  See above definition of 'rant'.

> >Or just hack it to support cocoon-view=links when it becomes necessary.
> FYI, the Cocoon CLI uses link views for both GET and POST. The GET part 
> is to retrive the list of hyperlinks that depart from that resource, the 
> POST request is to send the link of "translated links" that cocoon must 
> translate right before serializing.
> If you decouple the CLI from Cocoon, that POST view must be made public, 
> and this can create a *major* security hole, basically allowing anybody 
> to come up with a page with links translated with client-injected 
> information! Which is cross-side scripting attacks for dummies!

The intention is to run a Cocoon webapp locally, only for as long as it
takes the crawler to do it's job.  Security isn't an issue.

> >Yes, of course it's more elegant.  But _practically_, it is slow and full
> >of bugs which no-one has volunteered to fix, and Forrest is suffering
> >because of this.
> >
> >Now why don't I stop whining, get in there and fix it?
> >
> >Because in the long run,  I would prefer to develop a separate wget-like
> >tool with cocoon-view hacks added to it, than to develop the CLI into a
> >full-blown threaded crawler.  Why?  Because a separate tool has a _much_
> >larger audience, so will evolve faster.  Yes, a Cocoon CLI may be more
> >elegant, but a separate tool can grow geometrically while the CLI grows
> >linearly.
> Hey, know what? you'd have my full support if you took some of the CLI 
> code out of Cocoon and made it part of Forrest. (not all of it, some XSP 
> precompilation technology uses it) because I agree with you: the wrong 
> community is currently maintaing that code.

There are plenty of Cocoon committers here, so I don't think moving the
code achieves much.

> [BTW, to give you context, I'm writing this while Jon (Stevens) saw me 
> replying to this and now he's going around the house saying 'anakia 
> rulez', 'dvsl is the way to go', 'you have to figure out a way to beat 
> anakia's speed or you're doomed'... gotta love open source! :)]

:) Remind him that Forrest allows edited docs to be immediately viewed
with a live Cocoon.  So Forrest's edit/view cycle is inherently faster
than Anakia's edit/compile/view cycle, just as Anakia's CLI is inherently
faster than Cocoon's.


View raw message