I've just had a thought about all this DNS stuff. Apart from us
technical types, most people don't care. Despite having incredibly easy
domain names, most people still use their search engine to find sites,
even on return visits.
People have got used to search engines being very very good, so they've
stopped relying on memory.
--
Rev Simon Rumble <simon(a)rumble.net>
www.rumble.net
The Tourist Engineer
Geeks need vacations too.
http://engineer.openguides.org/
"When bankers get together for dinner they discuss art, when artists
get together for dinner they discuss money."
- Oscar Wilde
I need some feedback. Please test my change.
The changes I have made for ticket #18 are on
http://www.nurflax.net/cgi-bin/openguides/wiki.cgi
The change is touching a number of modules and templates, though the RDF
part isn't finished yet.
Ivor.
This has been discussed in the past on IRC but never went anywhere.
I think we should have a more scalable DNS naming structure. The flat
space we have at the moment won't scale particularly well - we've
already had a collision with Manchester, UK and Manchester, US.
So I think we should move to a simple two level system.
oxford.uk.openguides.orglondon.uk.openguides.orgmanchester.uk.openguides.orgmanchester.us.openguides.orgboston.us.openguides.orgvienna.at.openguides.org
and so on.
Worldwide sites like engineer.openguides.org could stay.
Whether we want to enforce existing guides to switch over I don't know,
but we should at least put in redirects.
Secondly, we were talking about improvements to the DNS management
recently. Various solutions were mentioned and no conclusions were
reached, so I'm going to offer mine here and see if we can get to a
conclusion.
Currently openguides.org is associated with Earle's personal account
with gandi.net. I suggest that we get an Openguides-specific account
with someone (them, or Black Cat Networks - my employer, I know we can
do this, for example). That would give us a web-based update interface
to which nominated individuals could have access.
We then have a wiki page that documents the DNS entries, who requested
them, when they were added, who by, etc etc, to keep track of things.
It's not a technically neat solution but is very easy to implement and
provides a more stable DNS platform than something custom would (for
example zone files in SVN were mentioned).
Comments welcomed for these two matters.
Regards,
Dominic.
--
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)
On Fri, Dec 02, 2005 at 05:28:46AM -0500, IvorW wrote:
> > Surely if you want to make it as easy as possible, SQLite would be a
> > better option?
> Sorry, SQLite won't scale. Concurrent access and locking is something that SQLite doesn't do, though it does have transactions and rollback.
Does it scale *enough* though? I can't imagine that the London guide
(which I imagine is still the biggest) ever has more than ten concurrent
users reading it and more than 2 or 3 writing it.
--
header FROM_DAVID_CANTRELL From =~ /david.cantrell/i
describe FROM_DAVID_CANTRELL Message is from David Cantrell
score FROM_DAVID_CANTRELL 15.72 # This figure from experimentation
> On Thu, Dec 01, 2005 at 01:36:38PM -0500, jesse wrote:
>> So, would that be Manchester NH, Manchester, MA or one of the other
Manchesters?
> I meant to add that I'll leave it to USians to comment on whether theirs
should be a three level system with state. In most countries this
doesn't tend to be necessary.
To quote the London guide:
* The names of English towns are by no means unique, for example,
there are two Ashfords, one in [Middlesex]?, near Heathrow Airport, and
the other in Kent.
(http://london.openguides.org/index.cgi?Easily_Made_Mistakes)
That said...
USians could probably cope with a first-come first-serve for top-level .us
domains with a fallback to city-state (saintpaul-mn) or somesuch if two
guides spring up with a namespace clash inside a country (springfield will
be painful). The generic domain either resolving to a "Choose which city
you mean" page or to the first guide to use the name, with the
understanding that they'll be good social people and have a "If you
intended to get to Boston, Arkansas please try
http://boston-ak.us.openguides.org"
I have no clue why I prefer a hyphen in this instance to a subdomain, but
I find it easier to parse [guide].[country].openguides.org vs
[guide].[possible state].[country].openguides.org just seems to be more
useful and global to me since Ashford in Middlesex will probably have to
resort to something like this after the OpenGuides Craze out near Heathrow
spreads.
-Chris
On Wed, Nov 30, 2005 at 10:41:41PM +0000, svnadmin(a)urchin.earth.li wrote:
> Author: earle
> Date: 2005-11-30 22:41:41 +0000 (Wed, 30 Nov 2005)
> New Revision: 726
>
> Modified:
> trunk/lib/OpenGuides/RDF.pm
> trunk/t/21_rdf.t
> Log:
> fixes #50
Could I ask that people continue to put meaningful log messages in
rather than *just* links to trac? It would be useful to be able to make
sense of changesets in their own right.
Cheers,
Dominic.
--
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)
On Fri, Dec 02, 2005 at 05:28:46AM -0500, IvorW wrote:
>
>
> > -----Original Message-----
> > From: openguides-dev-bounces(a)openguides.org
> > [mailto:openguides-dev-bounces@openguides.org]On Behalf Of Rev Simon
> > Rumble
> > Sent: 02 December 2005 10:01
> > To: openguides-dev(a)openguides.org
> > Subject: Re: [OGDev] Marketing to OG Admins
> >
> >
> >
> > On 1/12/2005, "(Christopher Schmidt)" <crschmidt(a)crschmidt.net> wrote:
> >
> >
> > > If there is a way to make it such that OG can be
> > installed by anyone
> > > with FTP and MySQL access
> >
> > Surely if you want to make it as easy as possible, SQLite would be a
> > better option?
>
> Sorry, SQLite won't scale. Concurrent access and locking is something that SQLite doesn't do, though it does have transactions and rollback.
In addition to that, MySQL is a relatively minimal requirement these
days, since most packages are PHP/MySQL hosting packages.
What it comes down to for me is that I see OpenGuides suffering because
its written in Perl. I see PHP packages - I'm thinking specifically
here of Drupal - specifically targeting those users who don't have root
accounts, or even the knowledge to run a shell. But they can edit a
config file, and they can use FTP. Drupal has more than 60,000
installations - OpenGuides has fewer than 100, at least as far as
popular/findable ones go.
If there was a way to package OG such that we could give a simple list
of requirements to their host, have them get it installed, and then FTP
upload a single set of files - even if its relatively large - then I
think that we would see increased adoption.
Perl is scary. It has a bad reputation. People don't want to muck with
installing it, most people don't even want to muck with running CPAN.
Huge numbers of people don't have the ability to install Debian packages
- either because they aren't running Debian, or because they don't have
root - and excluding these people as guide admins simply because they
don't want to learn Perl is probably not the best idea if you want
widespread adoption - and I think OpenGuides taking over the world would
be a very good thing indeed.
Maybe I'm overstating the importance that installation has on adoption,
but I think that some things speak for themselves. Drupal has a very
high adoption rate, and is very easy to install. PHP packages in general
get higher adoption rates, and are easier to install. It is my opinion
that the easier something is to install, the more likely someone will
install it.
OpenGuides does not make things easy to install. I couldn't install it
without help, and I'm a relatively competent user who is familiar with
CPAN. I can't imagine how anyone could expect that "normal" users could
get an OG setup without significant help - and when something doesn't
work, people don't usually ask for help, they give up.
--
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 Rev Simon
> Rumble
> Sent: 02 December 2005 10:01
> To: openguides-dev(a)openguides.org
> Subject: Re: [OGDev] Marketing to OG Admins
>
>
>
> On 1/12/2005, "(Christopher Schmidt)" <crschmidt(a)crschmidt.net> wrote:
>
>
> > If there is a way to make it such that OG can be
> installed by anyone
> > with FTP and MySQL access
>
> Surely if you want to make it as easy as possible, SQLite would be a
> better option?
Sorry, SQLite won't scale. Concurrent access and locking is something that SQLite doesn't do, though it does have transactions and rollback.
> -----Original Message-----
> From: openguides-dev-bounces(a)openguides.org
> [mailto:openguides-dev-bounces@openguides.org]On Behalf Of Christopher
> Schmidt
> Sent: 01 December 2005 19:12
> To: openguides-dev(a)openguides.org
> Subject: [OGDev] Marketing to OG Admins
>
[...]
>
> * 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.
Have a look at ticket #36: http://dev.openguides.org/ticket/36
>
> 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 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.
See ticket #36
> 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.
See above.
>
> * 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.
Good!
> * Whizbang features
> I think that some features could be shortlisted for adding to the
> whizbang effect of OpenGuides:
> * Google Maps support
Yup, that's what makes the Boston site look fantastic.
> * 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=js
, which I'm using to write a Python commandline client.)
We should look to make this pluggable, to support future requirements for exporting data.
> 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.
My £0.02
Ivor.