lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AJAX-powered search auto-completion for the docs


From: Reinhold Kainhofer
Subject: Re: AJAX-powered search auto-completion for the docs
Date: Sun, 11 Apr 2010 21:29:51 +0200
User-agent: KMail/1.13.2 (Linux/2.6.31-20-generic; KDE/4.4.2; i686; ; )

I have now updated the patch to apply to current master:
http://codereview.appspot.com/24076/show

It is also available in git in the dev/kainhofer branch.


Am Freitag, 9. April 2010 16:45:27 schrieb Graham Percival:
> On Thu, Apr 08, 2010 at 02:07:52PM +0200, Reinhold Kainhofer wrote:
> > Once you have started using that patch, you won't accept that as a viable
> > option any more ;-) That search box is even better than the TOC on the
> > left...
> 
> That could be the case.  Since I never use lilypond and only look
> at the docs when evaluating a patch, I'm not the best person to
> judge whether or not this would be useful.

It's actually the main reason why I missed most of the website redesign, since 
I'm using the docs quite a lot and without the search box it's quite hard to 
remember where exactly to find some feature you need.

> > > c)  Accept the patch, disable it on a normal build, enable it on
> > > lilynet.net (which IIRC has tons of resources), and then create a
> > 
> > We can use that to check out whether there are any resource problems
> > created by the ajax.
> 
> Definitely!

For now, the dev/kainhofer branch can be used, compiled and installed for the 
latest docs.

> > > d)  Accept the patch, make it default, host it on lilypond.org.
> > > Unless there's a substantial amount of interest from skilled PHP
> > > and web security people, I do not like this option.
> > 
> > The #1 security problem in general is SQL injection attacks. Since there
> > is no SQL involved, we don't have that problem.
> 
> More CS researchers include DoS (denial of service) as part of
> "security" -- so if this PHP script requires a lot of disk access
> or CPU power, an attacker could easily tie up the resources of the
> web server.

The script of course requires reading the index file from disk. And it goes 
through it line by line (i.e. basically no memory consumption apart from the 
apache fork for the request).
The CPU power needed for the script is also minimal, it only has a loop going 
through each line and searching the requested string verbatim (i.e. no 
regexp).

> An alternative client-side solution: theoretically, we could
> include the index entries inside javascript, then search *that*
> list in javascript, and generate a list of URLs from that.  This
> option would increate the amount of stuff to download, but the
> searching wouldn't touch the server disk or CPU at all.

Ahm, actually, it will probably be even worse. 
The web server will still have to load the same amount of data from disk (the 
index) and then send the whole(!) stuff over the net.

Cheers,
Reinhold

-- 
------------------------------------------------------------------
Reinhold Kainhofer, address@hidden, http://reinhold.kainhofer.com/
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org




reply via email to

[Prev in Thread] Current Thread [Next in Thread]