Hi, I don't follow OG development but as host operator a few things are
coming up. The machine's load is gradually climbing over time and some
of that is OG.
Despite a relatively low hit rate on OG it is consuming quite a bit of
resource. If OG started taking off it would take the machine down.
First up: index.cgi requires 0.35s to perform a `perl -c` syntax check.
Any thoughts on putting OG on a mod_perl server? I have mod_perl running
here of course and we'd need to coordinate some apache.conf stuff.
Second: the supersearch.cgi gulps down CPU, often for seconds at a time.
It is a frequent resident of `top` output. This isn't really
acceptable. I'm going to request this feature be turned off unless an
effective optimisation plan or some other way to reduce its impact
here is constructed pretty soon. Sorry about this but it's encroaching
on others.
Third: I wonder if there's some way to instruct robots not to spider
parts of your wiki. This ought to speak for itself:
$ grep crawl /var/log/apache/london.openguides.org-access.log | grep 'action=edit' | wc -l
8242
$
Finally: I posted about a DoS and was wondering what the status of a
solution was. http://openguides.org/mail/openguides-dev/2004-October/000542.html
Cheers,
Paul (any overbearing tone unintentional ;-)
--
Paul Makepeace .............................. http://paulm.com/inchoate/
"If my elbow was straight, then I'll show oyu mine!"
-- http://paulm.com/toys/surrealism/
>-- Original Message --
>Date: Thu, 27 Jan 2005 18:16:49 +0100
>From: maximilian attems <maks(a)sternwelten.at>
>To: OpenGuides software developers <openguides-dev(a)openguides.org>
>Subject: Re: [OpenGuides-Dev] encoding troubles
>Reply-To: xlai-feat(a)xemaps.com
>
>
>On Wed, 26 Jan 2005, IvorW wrote:
>> I wonder whether this might be the time to revisit node_name_to_node_param
>> and provide something more flexible. I have in mind something inwardly
>> pluggable that supplies a normalisation function for node names.
>
>what do you mean by "normalisation",
What I have in mind is a many to one mapping (or rather a several to one
mapping).
http://mywiki/?café and http://mywiki/?cafe should both reach the same page.
Also,
a link to [[café]] should work, as should a link to [[cafe]]. These indicate
that there is
a single wiki page for café, and that the various ways of expressing it
are translated
into a "normal form" (in computer science speak).
People would be encouraged to use the accented form in page links.
>it would be cool to support the "äöü" and others?
I agree :)
>
>> Currently, n_n_t_n_p reduces multiple whitespace to a single space, replaces
>> spaces with underscores and adds Title Case. There is no reason why this
>
>> could not apply de-accenting of letters or turning umlauts into diphthongs.
>> I think that there is a strong case for this being a plugin.
>
>please explain diphthongs.
Example: the word für can also be written fuer. Schön can be written schoen.
I don't know what the German word for a diphthong is, but it means putting
two vowels together.
Also, ß can be replaced with ss.
>i'm not a native speaker and dict doesn't know it either.
>why de-accenting letters?
>"café" should well be permitted as category.
café will still work (see above).
This would be an option for someone setting up a guide, whether the
title munging rules included such normalisations.
If there were no normalisations, [[café]] and [[cafe]] point to two different
pages.
The #REDIRECT mechanism is probably sufficient if there were just a few
mappings
needed (as is the case with an English language guide: it would be nice
for [[café]] to work).
>
>> Also, this could provide a solution to some of the King's_cross_st_pancras
>> problem (I originally raised this as an issue with search, but it could
>> equally be thought of as a node name munging issue).
>> see http://openguides.org/mail/openguides-dev/2003-October/000091.html
>
>as i'm not familiar with the openguides code,
>i may have misunderstood your statements.
>
>i hope you'll find a solution for this encoding problem. :)
Hopefully my explanations are making more sense to you now.
Ivor.
___________________________________________________________
Book yourself something to look forward to in 2005.
Cheap flights - http://www.tiscali.co.uk/travel/flights/
Bargain holidays - http://www.tiscali.co.uk/travel/holidays/
On Wed, 26 Jan 2005, IvorW wrote:
> [snip...]
> > I am still poking at this issue, having got distracted by the one
> > below, which I think is related but not the same.
> >
> > Note that the page you get redirected to on a saved edit is wrong, being
> > http://vienna.openguides.org/vienna.cgi?Category_CD/Platten-Gesch%C3%A4fte
> > instead of
> > http://vienna.openguides.org/vienna.cgi?Category_CD/Platten-Gesch%E4fte
> >
> > This is because the node name parameter is not being properly URL-encoded
> > before the Location: header is printed to STDOUT. This bug slipped in
> > because I forgot that CGI::Wiki::Formatter::UseMod's ->node_name_to_node_param
> > method doesn't actually URL-encode, but expects you to do it yourself
> > after calling the method (this _is_ documented).
>
> > I think it perhaps should, since what I expect from that method is
> > something I can bung into a URL and it will Just Work. However
> > changing it to do that would break backwards compatibility and could
> > lead to things being doubly-encoded, which would suck. Thoughts? I
> > may punt this to cgi-wiki-dev as well.
>
> I wonder whether this might be the time to revisit node_name_to_node_param
> and provide something more flexible. I have in mind something inwardly
> pluggable that supplies a normalisation function for node names.
what do you mean by "normalisation",
it would be cool to support the "äöü" and others?
> Currently, n_n_t_n_p reduces multiple whitespace to a single space, replaces
> spaces with underscores and adds Title Case. There is no reason why this
> could not apply de-accenting of letters or turning umlauts into diphthongs.
> I think that there is a strong case for this being a plugin.
please explain diphthongs.
i'm not a native speaker and dict doesn't know it either.
why de-accenting letters?
"café" should well be permitted as category.
> Also, this could provide a solution to some of the King's_cross_st_pancras
> problem (I originally raised this as an issue with search, but it could
> equally be thought of as a node name munging issue).
> see http://openguides.org/mail/openguides-dev/2003-October/000091.html
as i'm not familiar with the openguides code,
i may have misunderstood your statements.
i hope you'll find a solution for this encoding problem. :)
--
maks
On Wed, Jan 26, 2005 at 12:57:28PM -0500, IvorW wrote:
> I'm sorry I can't be around for the hackfest. I'll try and recall and
> braindump the ideas I have had to the list between now and then.
>
> Good festing and good hacking all.
Did I miss something actually being organised?
--
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)
> -----Original Message-----
> From: openguides-dev-bounces(a)openguides.org
> [mailto:openguides-dev-bounces@openguides.org]On Behalf Of Kake L Pugh
> Sent: 24 January 2005 18:14
> To: OpenGuides software developers
> Subject: Re: [OpenGuides-Dev] encoding troubles
[snip...]
> I am still poking at this issue, having got distracted by the one
> below, which I think is related but not the same.
>
> Note that the page you get redirected to on a saved edit is wrong, being
> http://vienna.openguides.org/vienna.cgi?Category_CD/Platten-Gesch%C3%A4fte
> instead of
> http://vienna.openguides.org/vienna.cgi?Category_CD/Platten-Gesch%E4fte
>
> This is because the node name parameter is not being properly URL-encoded
> before the Location: header is printed to STDOUT. This bug slipped in
> because I forgot that CGI::Wiki::Formatter::UseMod's ->node_name_to_node_param
> method doesn't actually URL-encode, but expects you to do it yourself
> after calling the method (this _is_ documented).
> I think it perhaps should, since what I expect from that method is
> something I can bung into a URL and it will Just Work. However
> changing it to do that would break backwards compatibility and could
> lead to things being doubly-encoded, which would suck. Thoughts? I
> may punt this to cgi-wiki-dev as well.
I wonder whether this might be the time to revisit node_name_to_node_param
and provide something more flexible. I have in mind something inwardly
pluggable that supplies a normalisation function for node names.
Currently, n_n_t_n_p reduces multiple whitespace to a single space, replaces
spaces with underscores and adds Title Case. There is no reason why this
could not apply de-accenting of letters or turning umlauts into diphthongs.
I think that there is a strong case for this being a plugin.
Also, this could provide a solution to some of the King's_cross_st_pancras
problem (I originally raised this as an issue with search, but it could
equally be thought of as a node name munging issue).
see http://openguides.org/mail/openguides-dev/2003-October/000091.html
I'm sorry I can't be around for the hackfest. I'll try and recall and braindump
the ideas I have had to the list between now and then.
Good festing and good hacking all.
Ivor.
hello,
i saw in the readme that there are utf8 bugs around.
our webserver doesn't deliver utf8, so i changed the encoding to
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
vienna.og has troubles with non-ascii chars in categories:
http://vienna.openguides.org/vienna.cgi?Category_CD/Platten-Gesch%E4fte
abovesis not beeing recognized as Category,
nor is one beeing able to see the pages of that cat.
should ask domm what encoding the postgresql database uses,
maybe that disturbs too.
--
maks
So today I was reading the page on the dev wiki about Greylisting
(http://openguides.org//dev/?node=Wiki%20Greylisting) and it's a fairly
straight forward and a kinda nice idea to avoid the anti-wiki like idea of
requiring user logins for submissions. However there is one minor change that
I'd like to add.
After an IP address has a post moderated and accepted the first time that IP
address is then whitelisted for a time, meaning any of their further posts
are automatically accepted for a period of time. This will reduce the amount
of admin intervention required.
Possible drawbacks I've thought of so far:
* Dynamic IP address change after unknown periods of times. Initially I was
thinking the whitelist period could be measured in months, but now I suspect
it should be days or possibly hours on a very active guide.
* It won't block a spammer from making a useful edit to gain whitelist access
then using that elevated status to wreak havoc. But then that would be a
fairly dedicated spammer, and their IP address would be blacklisted very
quickly.
* There is a question of which user is whitelisted in the case of multiple
edits (Bob edits FooNode, Alice edits FooNode, AdminHex moderates Alice's
merge with Bob ... who's IP address is whitelisted? Alice? Bob? Both?) I
suggest that it's only Alice's, but this could be configurable.
I'm sure there are drawbacks I haven't thought of. Suggestions?
-Chris
This one time, at band camp, IvorW wrote:
> My thoughts about this are to have a new type of node called a route.
> Such nodes contain a list of (x,y) or (lat,long) pairs tracing a route.
> These are joined together by straight lines when displaying on SVG or suchlike.
Sounds similar to an idea I had for when you're going on a journey and
want to find all the stuff that is within a range of your route.
Ideally upload your MS Autoroute or GPS route waypoints?
This idea would be great for my site. Geek goes on holiday with
non-geeks and non-geek agenda. Geek puts in route to find where the
group's plan can be merged with some geek sites to see :)
--
Rev Simon Rumble <simon(a)rumble.net>
www.rumble.net
The Tourist Engineer
Geeks need vacations too.
http://engineer.openguides.org/
"To retain respect for sausages and laws, one must not
watch them in the making."
- Otto von Bismarck
