[repost of private mail to list]
We're having a hackfest some time in the new year, though, and I will try and make this a priority, as a single point of entry/search for OpenGuides is indeed quite important.
Excellent :) It is quite a change from the distributed approach you've taken so far.
We tend to export mostly in RDF format with geo namespaces; is this likely to be useful? (see the RDF format search on one of the existing guides for an example).
RDF sounds fine (XML format), what about the return path, say you've got WhereAmI (my app) on your phone, you've identified your location with GPS or GSM CellID, downloaded the map around you, listed the openguides locations, picked your pub for lunch, routed to it, had a meal, but found an error in the guide, what is the desired return path? Would it make sense to have a 'comment' option where you just describe the change to the entry, then next time someone on the web views that article they see the suggestion, and can edit the article according to the suggestion, this would then archive the comment. Or we could go for allowing editing of the entire article on the phone and then upload the new version.
I presume that with your distributed architecture you have independant user accounts on each site, what about supporting openid? or something else? to let remote users authenticate their changes.
Cheers,
Adam.
Dominic wrote:
We're having a hackfest some time in the new year, though, and I will try and make this a priority, as a single point of entry/search for OpenGuides is indeed quite important.
On Mon 10 Dec 2007, Adam Boardman via Dominic Hargreaves dom@earth.li wrote:
Excellent :) It is quite a change from the distributed approach you've taken so far.
I don't think we have to abandon the distributed approach in order to do what Adam wants. How about, we have an API where any Open Guide will be able to answer the following questions:
1. What's the bounding box for all your pages? 2. Give me details of all your pages within a chosen bounding box.
Then we have a central service which asks each guide question 1 every so often and caches the result. When someone asks this central service to find all OpenGuides pages within a given bounding box, it uses this cached result to figure out which guides it needs to contact and ask question 2 of.
Does that fit in with what Adam wants his app to do?
The central service will of course need to have a list of the active guides, but I don't see this as a great hardship.
RDF sounds fine (XML format), what about the return path, say you've got WhereAmI (my app) on your phone, you've identified your location with GPS or GSM CellID, downloaded the map around you, listed the openguides locations, picked your pub for lunch, routed to it, had a meal, but found an error in the guide, what is the desired return path?
Sounds like something similar to RGL's "add a comment" link would work for this. This is how I usually update RGL when I'm out and about - my phone has Opera on it, and so I could in theory use the full edit form, but it's a lot simpler just to add a comment and then someone who's at an actual computer can do any tidying necessary.
I presume that with your distributed architecture you have independant user accounts on each site, what about supporting openid? or something else? to let remote users authenticate their changes.
If we do ever add authentication then OpenID would be the way to go.
Kake
Kake,
I was purswaded to join this list :)
Does that fit in with what Adam wants his app to do?
Yep that sounds like a grand plan. Assuming that the central server can also be given any comments or new additions (why not be flexible), which it would then return to the relivant local guide site.
You would need to handle the case for new additions to the guides that are not within the bbox of any current guide, I'd suggest that these are held on the central server waiting for a local guide for the specified area to be setup (or to be assigned to an existign one if just outside the bbox). Might be useful to guage a feeling of how much interest an area would have in a guide.
Having a view the full guide in the browser on your phone would be a useful feature for those on all you can eat mobile tarrifs.
If we do ever add authentication then OpenID would be the way to go.
Ok so currently there is no authentication, that makes things easier.
Cheers,
Adam.
On Mon 10 Dec 2007, Adam Boardman openguides-dev@adamboardman.co.uk wrote:
You would need to handle the case for new additions to the guides that are not within the bbox of any current guide[...]
And also those that are within the bbox of more than one guide, especially where one of the guides is more specialised than the other. For example, Oxford has both the normal guide and the vegan guide. Clearly you'd not want to be sending reviews of steakhouses to the vegan one! I think the only cities this applies to are Oxford and London though.
Ok so currently there is no authentication, that makes things easier.
That's right - no authentication at all. You just type your username in a box on the edit form (there's an option to store this in a cookie too). Although we also save IP addresses in the database, and some guides make these visible in the edit history too. If someone doesn't type a username then their edit is credited to Anonymous.
Kake
On Mon, 10 Dec 2007, Kake L Pugh wrote:
And also those that are within the bbox of more than one guide, especially where one of the guides is more specialised than the other. For example, Oxford has both the normal guide and the vegan guide.
There's also some overlap between the Oxford guide (rectangular) bbc and the Cotswolds guide to the north of Oxford. (Not too bad an overlap in terms of content, it's just that the boundary isn't a nice bbox)
Could be other cases too in future where two coverage bbox's overlap, even if the two guides have non-overlapping (but non-rectangular) coverage areas
Nick
On Dec 10, 2007, at 4:09 p, Nick Burch wrote:
On Mon, 10 Dec 2007, Kake L Pugh wrote:
And also those that are within the bbox of more than one guide, especially where one of the guides is more specialised than the other. For example, Oxford has both the normal guide and the vegan guide.
There's also some overlap between the Oxford guide (rectangular) bbc and the Cotswolds guide to the north of Oxford. (Not too bad an overlap in terms of content, it's just that the boundary isn't a nice bbox)
Could be other cases too in future where two coverage bbox's overlap, even if the two guides have non-overlapping (but non-rectangular) coverage areas
Perhaps in these edge cases the central service stores the content and sends a notification to the relevant guide admins?
-Chris
On Mon 10 Dec 2007, Chris Prather chris@prather.org wrote:
Perhaps in these edge cases the central service stores the content and sends a notification to the relevant guide admins?
Or to make it even simpler, it could just email the entire addition out to the admins straight away. Maybe the app could have the option to also mail the addition to the end-user's own email account, so if the admin turns out to be absent then the end-user can add the page themselves when they get home.
Note that this is just in the case where someone wants to add an entirely new establishment. If the end-user wants to add a comment on an existing review then the app already knows which guide to tell the central service to send the update to, and the comment can just be appended to the page as we already do on RGL.
Incidentally, if anyone wants the RGL "add a comment" code, just shout. (I think it has some kind of encoding bug in it, but it's not a really annoying one, and I haven't been able to trigger it myself. I only know about it because it sometimes gets triggered by one of the very few spammers that get through our spamblocker.)
Kake
On Tue, Dec 11, 2007 at 06:22:01PM +0000, Kake L Pugh wrote:
On Mon 10 Dec 2007, Chris Prather chris@prather.org wrote:
Perhaps in these edge cases the central service stores the content and sends a notification to the relevant guide admins?
Or to make it even simpler, it could just email the entire addition out to the admins straight away. Maybe the app could have the option to also mail the addition to the end-user's own email account, so if the admin turns out to be absent then the end-user can add the page themselves when they get home.
[I think this wouldn't be required if we go down the method I suggested]
Incidentally, if anyone wants the RGL "add a comment" code, just shout. (I think it has some kind of encoding bug in it, but it's not a really annoying one, and I haven't been able to trigger it myself. I only know about it because it sometimes gets triggered by one of the very few spammers that get through our spamblocker.)
Is it suitable for adding to the main codebase?
Dominic.
On Tue, Dec 11, 2007 at 06:22:01PM +0000, Kake L Pugh wrote:
Incidentally, if anyone wants the RGL "add a comment" code, just shout. (I think it has some kind of encoding bug in it, but it's not a really annoying one, and I haven't been able to trigger it myself. I only know about it because it sometimes gets triggered by one of the very few spammers that get through our spamblocker.)
On Thu 13 Dec 2007, Dominic Hargreaves dom@earth.li wrote:
Is it suitable for adding to the main codebase?
It would be if I could figure out the encoding bug. I just added it to RGL to start with so it could get a thorough testing. I think all other problems have been ironed out now. Note that I'm not _absolutely_ certain there's a bug in the "add a comment" thing at all, but every so often one of the pages on RGL acquires that A-with-a-little-hat in front of its non-ASCII characters, and I suspect it might be due to comments being added and then the page version deleted because it's spam. But I can't replicate this and it's quite intermittent.
Be warned: the "add a comment" link does generate quite a lot of spam traffic; I suspect because of scripts which target blogs. Ours is kept mostly under control by our spamtrapper module, but it's still a point to consider.
Kake
On Thu, Dec 13, 2007 at 10:23:16AM +0000, Kake L Pugh wrote:
It would be if I could figure out the encoding bug. I just added it to RGL to start with so it could get a thorough testing. I think all other problems have been ironed out now. Note that I'm not _absolutely_ certain there's a bug in the "add a comment" thing at all, but every so often one of the pages on RGL acquires that A-with-a-little-hat in front of its non-ASCII characters, and I suspect it might be due to comments being added and then the page version deleted because it's spam. But I can't replicate this and it's quite intermittent.
The same thing happens on the front page of the Oxford Guide with "Cafes" - I spent quite a long time looking at this before and decided it must be to do with buggy browsers, but typically I can't remember the details now.
Just a data point for you, anyhow.
I noticed that the comment stuff is currently implemented as a CGI - it really should be refactored into a method within OpenGuides.pm (or OpenGuides::Comment for that matter) for integration with the main code, then having it dispatched by wiki.cgi, but I assume that's fairly trivial.
Dominic.
On Thu 13 Dec 2007, Dominic Hargreaves dom@earth.li wrote:
I noticed that the comment stuff is currently implemented as a CGI - it really should be refactored into a method within OpenGuides.pm (or OpenGuides::Comment for that matter) for integration with the main code, then having it dispatched by wiki.cgi, but I assume that's fairly trivial.
Yep, wouldn't be hard at all. It's a separate CGI because I preferred that to forking the OpenGuides code. It does use the OpenGuides modules.
Kake
On Mon, Dec 10, 2007 at 10:00:44PM +0000, Kake L Pugh wrote:
And also those that are within the bbox of more than one guide, especially where one of the guides is more specialised than the other. For example, Oxford has both the normal guide and the vegan guide. Clearly you'd not want to be sending reviews of steakhouses to the vegan one! I think the only cities this applies to are Oxford and London though.
Rather than having the central portal accept edits itself, it should present the user with a choice of relevant guides to add to:
"OpenGuides has found the following local guides in your area. Please choose from the following options to add an entry there:
o Oxford Guide o Vegan Guide to Oxford"
The interface between the guides and the portal would include information on how to update entries (essentially a quick link to the "edit" bit of the main CGI).
Dominic.
On Thu 13 Dec 2007, Dominic Hargreaves dom@earth.li wrote:
The interface between the guides and the portal would include information on how to update entries (essentially a quick link to the "edit" bit of the main CGI).
Oh, I see! I'd been assuming that Adam's app was for people who didn't have a phone that would run a web browser. I suppose this was a silly assumption, since if he can write an OpenGuides app then surely someone can write a web browser.
Kake
On Thu, Dec 13, 2007 at 10:12:28AM +0000, Kake L Pugh wrote:
Oh, I see! I'd been assuming that Adam's app was for people who didn't have a phone that would run a web browser. I suppose this was a silly assumption, since if he can write an OpenGuides app then surely someone can write a web browser.
If there is a need for a simplified or more clearly defined interface to editing that would be usable by some custom app, this could be added, but that would still belong in the guide instances rather than a central service, I think.
Dominic.
On Mon, Dec 10, 2007 at 09:33:25PM +0000, Adam Boardman wrote:
Kake,
I was purswaded to join this list :)
Does that fit in with what Adam wants his app to do?
Yep that sounds like a grand plan. Assuming that the central server can also be given any comments or new additions (why not be flexible), which it would then return to the relivant local guide site.
I don't think any central service should be storing data; it needs to be kept lightweight. I also see it being quite different to the main OpenGuides code, so..
You would need to handle the case for new additions to the guides that are not within the bbox of any current guide, I'd suggest that these are held on the central server waiting for a local guide for the specified area to be setup (or to be assigned to an existign one if just outside the bbox). Might be useful to guage a feeling of how much interest an area would have in a guide.
..maybe there is also a need for a global OpenGuide that can be used as a place to store such things.
Having a view the full guide in the browser on your phone would be a useful feature for those on all you can eat mobile tarrifs.
I don't quite understand what you're getting at here; what, technically is required that isn't already provided by OpenGuides? Is it just a case of mobile-friendly stylesheets?
Dominic.
Replying to bits of two of Dominic's mesages:
Rather than having the central portal accept edits itself, it should present the user with a choice of relevant guides to add to:
I would rather keep the UI simple, I dont imagine that peoples comments are sent imediately, though I wouldnt stop them, but rather have the client code store up a batch of changes which are uploaded at once, along with any blog posts, gsm cell id to location mappings, osm map corrections etc. So I want a fire and forget API (well a msg accepted/failed response is ok).
..maybe there is also a need for a global OpenGuide that can be used as a place to store such things.
Yep that would be fine, and any new ambigous articles can go there and then be adopted by new or existing local guides as relivant, or live on the global one if not, which would always have to be asked for articles when the mobile app requests articles for a specific bbox.
I don't quite understand what you're getting at here; what, technically is required that isn't already provided by OpenGuides? Is it just a case of mobile-friendly stylesheets?
Just that I personally dont do remote web access unless I have to, I use a PAYG sim when out and about, and then free WiFi (at home or where I find it) to sync up any larger activities. If I had an all you can eat tarrif then I might be more inclined to do things like edit web pages online. Also my app uses a compressed binary protocol for communicating to my server (acting as a proxy) so saving costs over using a normal bloated html/xml.
Cheers,
Adam.
On Thu 13 Dec 2007, Adam Boardman openguides-dev@adamboardman.co.uk wrote:
I would rather keep the UI simple, I dont imagine that peoples comments are sent imediately, though I wouldnt stop them, but rather have the client code store up a batch of changes which are uploaded at once, along with any blog posts, gsm cell id to location mappings, osm map corrections etc. So I want a fire and forget API (well a msg accepted/failed response is ok).
In that case it's definitely best to go the "add a comment" route rather than having people edit the entire article, because it means we don't have to worry about merging (e.g. if you edit the article on your phone, then someone else edits it before you get home, and you get home and try to sync your updates). With "add a comment", we just append it.
Kake
On Mon, Dec 10, 2007 at 08:30:45PM +0000, Kake L Pugh wrote:
I don't think we have to abandon the distributed approach in order to do what Adam wants. How about, we have an API where any Open Guide will be able to answer the following questions:
- What's the bounding box for all your pages?
- Give me details of all your pages within a chosen bounding box.
Then we have a central service which asks each guide question 1 every so often and caches the result. When someone asks this central service to find all OpenGuides pages within a given bounding box, it uses this cached result to figure out which guides it needs to contact and ask question 2 of.
Does that fit in with what Adam wants his app to do?
The central service will of course need to have a list of the active guides, but I don't see this as a great hardship.
This is pretty much exactly how I envisaged a central portal service working.
Dominic.
openguides-dev@lists.openguides.org
-
Adam Boardman -
Adam Boardman via Dominic Hargreaves -
Chris Prather -
Dominic Hargreaves
-
Kake L Pugh -
Nick Burch