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/
Hi all,
Not having used openguides before I'm trying to work my way through the
long chain of cpan dependencies and have got stuck with CGI::Wiki. I'm
getting the error messages reported on
http://www.nntp.perl.org/group/perl.cpan.testers/269669
which are all from trying to write nodes with no contents. As far as I
can see from the CGI::Wiki documentation this is required behaviour, so
it looks like I need to find a fix for it. In an initial fit of optimism
I thought I'd try to track down where the problem was originating from,
but I've got lost. I assume Text::Wikiformat is being invoked through
the format() routine, but I've failed miserably at following the tangled
route from $wiki->write_node() to format(). Has anyone got any
further, or found a way round this? I did mail chromatic to ask him if
he had any ideas, but he (very reasonably) suggested I provide a clear
test case first (though he also said he might look at it in the next few
days).
Thanks
Graham
Well done Dom and Chris for getting Google Maps integrated into OG svn.
I've found a few things missing, and I will be committing when the list
is complete.
I'm trying to use this to set up a mirror of OGLondon with the map of
all points. URL is
http://www.nurflax.net/cgi-bin/openguides/wiki.cgi?action=index;format=map
But it's not working :(. I've gone on to Google to register account, and
requested an API key for http://www.nurflax.net/cgi-bin/openguides/,
which I have installed. (at no point did google ask me for my account
email address).
The page source looks OK, but no map is being displayed. Viewing the
page source looks OK compared with the Oxford one.
Any suggestions?
If anyone would like to help, I can give you access to a shell account -
drop me a line on IRC if you need this.
Merry Christmas all,
Ivor.
This fixes a bug in the og_mirror script, where local coordinates were
not being set in the database. This prevented find_within_distance from
working.
Thanks to Jody for pointing this bug out to me.
-------- Original Message --------
Subject: CPAN Upload: I/IV/IVORW/OpenGuides-RDF-Reader-0.05.tar.gz
Date: Mon, 19 Dec 2005 01:50:47 +0100
From: PAUSE <upload(a)pause.perl.org>
Reply-To: 48mn-wuei(a)spamex.com
To: Ivor Williams <6bed-rgew(a)spamex.com>
The uploaded file
OpenGuides-RDF-Reader-0.05.tar.gz
has entered CPAN as
file: $CPAN/authors/id/I/IV/IVORW/OpenGuides-RDF-Reader-0.05.tar.gz
size: 12019 bytes
md5: 62663a6e356de3c0afbeb0c8e1d4e270
No action is required on your part
Request entered by: IVORW (Ivor Williams)
Request entered on: Mon, 19 Dec 2005 00:48:32 GMT
Request completed: Mon, 19 Dec 2005 00:50:45 GMT
Thanks,
--
paused, v460
I've seen a lot more activity in OpenGuides in the past month than I
have in the 6 before that, so I think that maybe we're looking at a good
time to take advantage of the energy that people have been putting forth
to the guides aspect and turn some of it away from technical matters and
to the more social matters that I feel may be blocking some uptake of
OpenGuides.
* Lack of stylesheet.
Perigrin and I have stolen stylesheets back and forth for a while
now, and have something that is a pretty basic, but still useful,
stylesheet. Including this stylesheet, with some recommendations as
to how to change it, would be easy and would make a huge difference
to the first result you get when setting up a guide.
* Ardurous Installation
I personally find setting up a guide to be a non-trivial task. I'm
getting used to it now - with Milton Keynes, it only took about 20
minutes total to get everything up and running - but the biggest
reason for that is that the OG packages are already installed for
Boston.
Many users don't have the ability to install systemwide perl modules,
and users like me who don't know perl don't know how to set up the
guide to point to a local directory. I think that a self-contained
package for OG including all the perl modules which the app needs,
and a preset use lib() pointing to a relative directory, would be the
most useful thing that OG could do to ease installation.
I suppose this might get relatively ridiculous: You can require that
easy to install or commonly installed packages are already taken care
of, but documenting these dependancies could go a long way towards at
least letting people know if they could install OG.
I don't know if this is realistic or not, but I know that I do not
find installing OpenGuides to be easy, nor is maintaining two
seperate copies of the libraries (for Boston and Milton Keynes: I
have a number of boston specific changes) to be something that I know
how to do.
If there is a way to make it such that OG can be installed by anyone
with FTP and MySQL access, without any need for a shell account or
CPAN, given a list of perl modules that they already have, and that
seperate instances can be maintained for multiple guides, I think
that it would be more commonly installed by guide admins and more
commonly tested as well. If you can provide a nightly build that
someone can just upload with a hand edited wiki.conf, you'll probably
see more people able to test the changes without risking breaking
their current guide.
* Reaching out Globally
Right now, OpenGuides feels very much like a UK-centric project. Dom
is doing work to correct this, learning about projections and so on.
I think that once we have cleaned up some of the Euro-centric aspects
of openguides (and made clear some of the Geo aspects that are
confusing at the moment), a good goal would be to reach out to other
global users and try and find guide admins. With an easier setup
process or the offer to host a guide for them, a number of users may be
willing to support a wiki-guide to their city, especially in the
absense of other similar services in the area. It would be
interesting to see, for example, the Open Guide to Sydney - perhaps
even hosting it with a current OGDev member as admin, and then trying
to pimp it to sydney locals, thus skipping the setup step.
* Whizbang features
I think that some features could be shortlisted for adding to the
whizbang effect of OpenGuides:
* Google Maps support
* New Data Format support - I'm thinking something along the lines
of providing JSON data interface as well as RDF, to possibly
improve the integration with other web or non-web applications.
(I've already implemented a JSON export of Boston, via
http://boston.openguides.org/?id=Central_Square_Station;action=edit;format=…
, which I'm using to write a Python commandline client.)
I don't know what else is considered Whizbang, but I think those
could be neat to take advantage of some of the "OMG AJAX" movement
going on in the web world today.
Just some ideas that I had as I was chatting with Dom on IRC, and
thought I'd toss them out before I lost them again.
--
Christopher Schmidt
Open Guide to Boston
http://boston.openguides.org/
> -----Original Message-----
> From: openguides-dev-bounces(a)openguides.org
> [mailto:openguides-dev-bounces@openguides.org]On Behalf Of
> Earle Martin
> Sent: 02 December 2005 23:16
> To: OpenGuides software developers' list
> Subject: Re: [OGDev] Marketing to OG Admins
>
>
> On Fri, Dec 02, 2005 at 06:03:19PM -0500, Christopher Schmidt wrote:
> > The "Slo-penguides" joke has already been made even with the "real"
> > databases :)
>
> I'm really interested to see how we do speed-wise under mod_perl....
> <deja-thread />
I know from IRC that some of us are experimenting with running OG under Apache::Registry.
How are you getting on? What code changes are needed to OpenGuides 0.51? What Apache conf changes are needed? Has anyone found any problems yet?
Please update ticket #6 with any findings. You can do so if you aren't registered on trac.
http://dev.openguides.org/ticket/6
Thanks,
Ivor.
On Fri, Dec 02, 2005 at 05:28:34AM -0500, IvorW wrote:
> [Christopher Schmidt wrote:]
> > Many users don't have the ability to install systemwide perl modules,
> > and users like me who don't know perl don't know how to set up the
> > guide to point to a local directory. I think that a self-contained
> > package for OG including all the perl modules which the app needs,
> > and a preset use lib() pointing to a relative directory, would be the
> > most useful thing that OG could do to ease installation.
>
> Maybe PAR is an option. I am successfully using PAR at work.
> http://search.cpan.org/~autrijus/PAR
I'd like to second this after seeing Ivor's recent presentation about Perl
packaging systems at the London Perl Workshop[0]. A PAR file would not only
contain all the prerequisites, but Perl Itself. As I understand it, it's a
self-extracting zip archive that just runs like an executable. This might
work for users who only have shell access. (Although I'm not addressing the
issue of setting up the database. Thoughts anyone?)
> > Right now, OpenGuides feels very much like a UK-centric project. Dom
> > is doing work to correct this, learning about projections and so on.
For which my thanks, and to Kake too for originally sorting out this
business with ellipsoids, the mathematics of which I admit is largely beyond
me at this point.
> > a good goal would be to reach out to other global users and try and
> > find guide admins.
I'd also like to try and convince people with "non-OpenGuides Open Guides"
(that is to say, who are running a city guide on something like Mediawiki)
to Think Differently and Switch (erm...) but that's not going to be easy
without whizbang. :)
Talking of attracting people, people who have guides need to pimp^H^Htch to
potential users. For a long time I've been meaning to, but never got around
to, printing leaflets and stickers for the Open Guide to London. How else
can we publicize our guides? Snappy web buttons and banners?
> > * New Data Format support - I'm thinking something along the lines
> > of providing JSON data interface as well as RDF, to possibly
> > improve the integration with other web or non-web applications.
Data formats are good. Having seen your JSON export, we might as well do a
YAML export too since it's similar enough. Why YAML? I don't know really, just
in case someone has a cool app that uses it. (I admit that this is a
slippery slope!)
> > I don't know what else is considered Whizbang, but I think those
> > could be neat to take advantage of some of the "OMG AJAX" movement
> > going on in the web world today.
>
> I'd qite like to see OG running under mod-perl.
That'd certainly be whizbang for server admins, anyway. :) Bob showed me
some benchmarking output which seems to indicate about 99% of runtime is
getting the pre-reqs up and running. But this is another thread in the
making, I think.
[0] http://london.pm.org/lpw/talks/2005/ivor_williams-packaging_apps.tar.gz
Cheers,
Earle.
--
Earle Martin
http://downlode.org/http://purl.oclc.org/net/earlemartin/