OpenGuides-Dev March 2007

openguides-dev@lists.openguides.org

19 participants
20 discussions

Start a nNew thread

Google Sitemaps
by Markus Linke 03 Oct '07

03 Oct '07

Hi, is anyone using google sitemaps with openguides? Thanks, Markus

6 15

[OpenGuides-Dev] OG performance
by Paul Makepeace 20 Jun '07

20 Jun '07

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/

10 22

RDF improvements (was: What are people working on?)
by Earle Martin 25 Apr '07

25 Apr '07

Hi Tom, sorry for the slow reply, I've been busy. On 16/03/07, Tom Heath <tom.heath(a)gmail.com> wrote: > > ...It can be summarised as "if your server responds with a 200 range code to a > > URI, it's an information resource; but anything within that resource > > with a fragment identifier is not". > > If I've understood the theory correctly, then yes, this is largely > true and fine if you simply have an RDF document at the URI (in a > document that defines an ontology, for example), but is incorrect if > the information resource is an HTML document (where a fragment > identifier identifies a part of the document, i.e. an information > resource). Therefore we probably shouldn't make that assumption, but > instead say "we don't know what a hash URI identifies". Okay, I guess that's a fair call. > Richard Cyganiak covers this quite nicely I think: > > <snip>If TimBL says that hash URIs always represent concepts, and not > part of documents, then he contradicts RFC 3986 and introduces an > ambiguity that is just as bad as the original "URI crisis" which > httpRange-14 was designed to solve.</snip> > <http://dowhatimean.net/2006/11/content-negotiation-with-hash-uris-long> Hrm. Interesting discussion, thanks for the pointer. I certainly don't agree with that John Black fellow about "claims". RFC 3986 confuses me somewhat, as it says "Fragment identifiers... [allow] an author to specifically identify aspects of an existing resource..." This seems to imply that a fragment only refers to an aspect of a resource, which sounds at odds with fragmentInXML-28 (http://www.w3.org/2001/tag/issues.html#fragmentInXML-28), which says: "In general, the fragment part of a URI may be used to refer to abstractions as well as syntactic fragments of a representation". Still, it's not really our place to try and resolve this issue here; a perfectly acceptable workaround exists in the form of the 303 redirect proposed by the resolution to httpRange-14. So that's fine, I'm happy. > I prefer slash URIs as I believe they make a clearer > distinction between a thing and a document about a thing (and 303 > redirects help avoid any ambiguity). They also send a stronger message > about a URI of a thing being independent of any one particular > document. Yeah, sure; to a human a pile of line-noise (.?&=%bleah) isn't too clear. Would you prefer example.com/guide/Foo_Bar/rdf or example.com/guide/rdf/Foo_Bar? Also, since those would be the 303 redirects, what would they redirect to? For example, even though it makes no difference at the > machine level, as a human being using > <http://london.randomness.org.uk/wiki.cgi?id=Angel%2C_SE16_4NB;format=rdf#obj> > to identify the pub in a different document would still niggle me a > bit. It just seems the wrong way around; surely the pub is the primary > object, and any particular description of it is secondary? Right. I'm sure we can hash something better out. > > Incidentally, "obj" itself was something I made up after failing to > > find a better alternative to the word "thing", which I have a strong > > dislike for. I'm happy for better suggestions. > > I think it's fine, it follows the Ronseal approach. Would be > interested in hearing you reasons for dislike of "thing", although > you're welcome to save that for a face to face discussion over a beer > sometime if you'd prefer. Aw, no, I just think it sounds kind of weak. I think maybe "a strong aversion" was a little strong, it's more of a niggling dislike. :) > > Sorry? I don't follow... The RDF is completely independent of > > anything; it was hand-composed. Unless you're referring to schemata > > (yay Greek!) that we rely on as modules, rather than Perl modules? > > OK, that's interesting, I hadn't realised that. What I was really > getting at is that (as I understand it) the OG software relies on Perl > modules for generic Wiki functionality (of course I may be totally > wide of the mark here, having never really delved around under the > hood). If that is the case then our ability to redfine the addressing > scheme for OpenGuides and create "pretty URIs" may be limited, as the > modules define the URI syntax. Please clarify things for me if I'm > wrong about this. Right. Well, at present the CGI interface defines the URI syntax, but we control the code, so the format of the URIs is entirely up to us. What can be thought of can be coded. > Just so I follow you, are you wedded to the fragment identifiers > themselves, or simply the distinction between the "object/thing" and > the "document about the object/thing"? Definitely the latter. > > But you could say that; > > alternatively, the wn:Neighborhood item "Rotherhithe" could be given > > an rdfs:isDefinedBy > > rdf:resource="http://london.randomness.org.uk/wiki.cgi?id=Locale_Rotherhithe;format=rdf#o…">. > > Your version is more compact, but doesn't specify that Rotherhithe is > > a wn:Neighborhood, which is an explicit definition that I quite like. > > The more semantics the better I reckon, so saying that it's a > Neighbo(u)rhood would be great. Something like: > > <uriForRotherhithe> foaf:isPrimaryTopicOf <documentAboutRotherhithe> > <uriForRotherhithe> rdf:type wn:Neighborhood > > might be a nice way to express these things (would need to double > check this before commiting it to code); I'm not totally sure of the > semantics of rdfs:isDefinedBy, so not sure if we can make such a > strong claim as <uriForRotherhithe> rdfs:isDefinedBy > <documentAboutRotherhithe> (hence foaf:isPrimaryTopicOf). I'll look into it. > Not necessarily. If <http://wherever.openguides.org/contributors/bob/> > returned a HTTP303 response and a "Location: > http://wherever.openguides.org/contributors/bob/about" header, > (where <http://wherever.openguides.org/contributors/bob/about> was a > document describing Bob) then we'd be doing the right thing aswell. > The # isn't essential. Yep. That's great. Cheers, Earle. -- Earle Martin http://downlode.org/ http://purl.org/net/earlemartin/

5 6

Preview above edit box.
by Kake L Pugh 15 Apr '07

15 Apr '07

Any objections to me making the user preference for "put preview above edit box" default to "on"? Kake

3 5

categories, locales and tags
by Bob Walker 02 Apr '07

02 Apr '07

So I was playing with Operator the other day. https://addons.mozilla.org/en-US/firefox/addon/4106 to see what out microformat support looks like and it occured to me we are missing out on one of them... Tags. We have discussed before that we prefer categories and locales over "tags" becasue they are less freeform. However they are our "tags" and as such we should probably mark them up like that for microformat goodness. It would seem the way to do this is to add rel="tag" in the <a>. Comments, suggetions, patches? -- Bob Walker http://www.randomness.org.uk/ Stress Kittens: Squeeze them till they cry! The latest tech in homicidal tendency relief.

7 19

<base href=...">
by Kake L Pugh 30 Mar '07

30 Mar '07

I just rationalised up the links in the navbar a bit - previously we'd had a mix of full URLs (e.g. http://london.randomness.org.uk/wiki.cgi?action=rc) and partial URLs (e.g. newpage.cgi). This worked OK, but made it difficult to INCLUDE navbar.tt in your own add-on scripts. What I did for now was make them all be full URLs. However, it might be better to do this by using <base href="[% script_url %]"> and then using partial URLs everywhere. Can anyone give me a quick rundown on the pros and cons of each approach, and which they think would be best for OpenGuides? It's the edge cases I'm worried about. Kake

1 0

open guides development
by michael heimbinder 26 Mar '07

26 Mar '07

-Hello OpenGuides Developers- I learned of OpenGuides from Julian Priest while we were both participating in a locative media residency in Banff, Canada. Now, I am working to upgrade my current website, www.habitatmap.org, and would like to use OpenGuides as the platform. I hired a programmer to help me out, Rupinder Deol, whom I believe may have contacted you in the recent past. Recently Rupinder has had to step down from the project due to family obligations, and that leaves me looking for another OpenGuides developer for Habitatmap. Can you guys recommend someone for the job. I live in Brooklyn and would love to collaborate with someone local but I am willing to hire someone nationally or internationally. If you're interested, I can send you a detailed description of the project, just let me know. Thanks for the help. -Michael Heimbinder-

2 3

Common categories/locales
by Kake L Pugh 26 Mar '07

26 Mar '07

Hello! Here's an update on what I'm doing, and a request for input. At the moment, I'm concentrating on making it easier for people to customise their Guides without having to fork. I've added a config option to let you suppress the recent changes on the home page, and I've split out the "guts" of the navbar into smaller sub-templates, so navbar.tt is now incredibly simple: <div id="navbar"> [% INCLUDE navbar_home_link.tt %] [% INCLUDE navbar_tools.tt %] [% INCLUDE navbar_help.tt %] [% INCLUDE navbar_options.tt %] [% INCLUDE navbar_search.tt %] [% INCLUDE navbar_this_page.tt %] [% INCLUDE navbar_revision_info.tt %] </div> (I noticed some people had rearranged the order of things in their navbar; this allows you to do that without potentially locking yourself out of upgrades if we have to make code changes in the navbar templatey bits. And it makes it a lot clearer what's going on, which is good.) Anyway, while I was doing this I came across the question of these common categories/locales. When Nick put them in, Clair asked if they could be moved into the navbar, and Nick said he didn't want to do this, but didn't really explain why. I think they should be in the navbar. Semantically, they belong there; they're means of navigation, entry points into the Guide. Also, I see only three guides that actually have them turned on; RGL has a hacked template that puts them in the navbar anyway, and the other two (can't remember which, sorry) seem not to have noticed them, since they're just stuck awkwardly at the bottom of the page. Nick, can you explain why you think they don't belong in the navbar? The other thing is that they should really be specified in wiki.conf, since (a) they should be configurable, and (b) they need to be run through the node_name_to_node_param method of the formatter before being plonked on the page. I'm not sure of the best way of doing this, since Config::Tiny doesn't let you specify more than one value for a key. Can we assume that nobody will ever want to use a category/locale with a comma in for this purpose, and just use a comma-separated list? Or can someone come up with a better idea? I don't want to rush in with a half-baked solution that will need to be done over again in a few months. Kake

4 16

OpenGuides 0.59 released
by Dominic Hargreaves 25 Mar '07

25 Mar '07

Thanks, largely, to Kake who has returned to the project recently, we have a feature-packaged new release. This'll be the last one, unless there are any major bugs, before I disappear on a journey of marriage and honeymooning next week. As ever, you can fetch the distribution from CPAN (shortly), or directly from http://www.larted.org.uk/~dom/computing/code/openguides/OpenGuides-0.59.tar… md5sum is 854d655acdab9f7271d29c3864fbac17 (and it's signed with cpansign, as usual). Debian packages will be making their way into the archive in due course. Below is the extract from UPGRADING: 0.59 Some CSS was altered; you should check and update your stylesheets. See README.CSS for details. Common categories and locales were moved within the navbar Below is the extract from Changes: 0.59 25 March 2007 Move preview_node() and edit_node() from wiki.cgi into OpenGuides.pm Remove edit_conflict.tt - use edit_form.tt instead to reduce duplication. Make sure to always pass the config object into the templates. Add some extra test utilities to OpenGuides::Test Allow Guide admins to control the content of autocreated nodes (#47). Let people add name of copyright holder, licence URL, and info page URL for node images (#179). Add config option to omit recent changes from home page. Split out "modules" from navbar.tt into separate templates navbar_*.tt to make it easier for people to change the order in a custom template Add a new div to wrap the entire body; also, use header.tt in home_node.tt instead of copy/paste. Add a new div for the atom/RSS feed links on the recent changes page. Add config option to place content above navbar in HTML. Add config option to suppress inline maps on geotagged nodes. Add support for custom template to add to page <head> (#191). Fix preferences to take notice of users turning off inline Google maps. Add option to include Google Analytics. Fix "Link to this page" on index maps to remember the map type and the thing it's indexing (#190). Write tests for and fix: #48 (Edit conflict page erroneously converts lat/lon to os_x, os_y). #173 (edit conflict form doesn't let you edit everything). Fix: #184 (Build.PL doesn't treat the absence of Config::Tiny gracefully.) Add admin function for reverting changes by a specified user or host. Cheers, Dominic.

1 0

Release imminent
by Dominic Hargreaves 24 Mar '07

24 Mar '07

Please liase with me if you want to commit anything to SVN from now on - as I am preparing a release. Dominic. -- Dominic Hargreaves | http://www.larted.org.uk/~dom/ PGP key 5178E2A5 from the.earth.li (keyserver,web,email)

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

OpenGuides-Dev March 2007