explanation of back-end changes [closed]

[ideology]

given the significant (hopefully short-term!) loss of functionality here we thought we should let you know why

as you know the server in sydney died so we moved into the beta site a lot earlier than we originally planned. we are now up to our fourth server in sydney and we are still having problems there, so we are glad we switched to the US server otherwise we'd have been going up and down all the time. at least despite the loss of functionality, the site, forum, gallery, wiki are all actually up!

anyway, the reason we didn't just migrate the code over to the US server was that we made some significant changes to the database structures on the beta site. the reason for this is that when we originally set up the structures, we designed them for statistics, so they were optimised for that.

since then, we have been doing a lot more than just statistics, and we wanted a data structure which could model all sorts of additions to the game.

the straw that broke the camels back was that we had a situation where a cacher wanted to give a swaggie to another cacher, but we couldn't model it because our data structures assumed that a swaggie would always be transferred via a cache.

some of you will know our involvement with the early adventure games. we have based our new data structures on those. (you can see hings ot that where we refer to "inventory" of swaggies)

the database models thee objects: cacher, cache and swaggie. then there is another table which models the actions that have been performed. each action has an actor, a subject, a verb and an object.

at the moment, the only things modelled are things that already exist in geocaching, ie cacher logs cache, cacher grabs swaggie from cache, cacher drops swaggie in cache.

with the new data structures, we can now represent:
- cacher1 gives swaggie to cacher2
- cacher grabs cache
- cacher1 grabs cacher2
- cacher puts cache1 in cache2

some of these seem ridiculous, but others make incredible sense. eg for moveable caches, you actually _do_ want to log that a cacher has grabbed a cache. and some of the innovative caches had caches within other caches, so it would be great to be able to model that.

when thinking about objects, you can also think about groups of objects. at the moment we have only one group, caches. at the moment we are only specifying caches by state. that's why you'll see that the urls are gravitating towards things like /caches/au/tas etc. this represents the group of caches in tasmania.

we have some rss code going now which operates on objects or groups. the old site had rss code which just did states or countries. that was fine, but by thinking about generic objects, we suddely open up rss feeds for all sorts of things. the structure allowed us to do an RSS feed of a cache. what would that be? aha! it's really a watchlist of logs on a cache. it also allowed us to do an RSS feed of a cacher. wow, that's a watchlist of a person. and RSS feeds of swaggies will be available too.

we have also made that code generic, so it doesn't just spit out RSS. it spits out google earth KML files. so what would a google earth KML file of a moveable cache look like? a route of all its travels! we could probably do the same for a cacher!

so we hope this gives you a feel for why we are taking the pain now. if we get the underlying data right it opens up the site to even more possibilities.

[Rabbitto]

I was expecting by the title of this thread that you had had a bum-lift .

[Cached]

we could probably do the same for a cacher!

That would be very cool! Imagine what one for "alex" would look like...

[Slider & Smurf]

... it also allowed us to do an RSS feed of a cacher. wow, that's a watchlist of a person.

<p>
Uh-oh - just wait til someone does a watchlist on Maccamob for their next interstate holiday. Now there's a peak load test for you!!
<p>
Google Earth KMLs of 'selected' caches sounds pretty cool ... now, if only I could get this functionality in the States to go with the better satellite image coverage! Don't suppose you feel like extending your coverage to Washington state?
<p>
Cheers guys, thanks for all the effort you're putting into the site - it is greatly appreciated. Even more so when we're home again and can actually put the listings to good use!!

[alpha993]

australian geocachers are very lucky to enjoy the benefits of all your efforts and planning for the future, I can only echo earlier comments and thank you for your contribution to the sport/hobby...

[EcoTeam]

the database models thee objects: cacher, cache and swaggie. then there is another table which models the actions that have been performed. each action has an actor, a subject, a verb and an object.

at the moment, the only things modelled are things that already exist in geocaching, ie cacher logs cache, cacher grabs swaggie from cache, cacher drops swaggie in cache.

with the new data structures, we can now represent:
- cacher1 gives swaggie to cacher2
- cacher grabs cache
- cacher1 grabs cacher2
- cacher puts cache1 in cache2

some of these seem ridiculous, but others make incredible sense. eg for moveable caches, you actually _do_ want to log that a cacher has grabbed a cache. and some of the innovative caches had caches within other caches, so it would be great to be able to model that.

Cool!
Can we drop cachers into caches?
What about swapping cachers with other cachers?

we have also made that code generic, so it doesn't just spit out RSS. it spits out google earth KML files. so what would a google earth KML file of a moveable cache look like? a route of all its travels! we could probably do the same for a cacher!

Coolamundo!
We could do caches in a certain order so that we can draw pictures on Google Earth with our travels!

EcoDave

[langy]

Will I be able to pick up wearable items that allow me to increase my Str stats so I can carry more in my Inventory - or was that just way to old school nerdy for people?

I so want to OT gloat here about DikuMUDs - but I wont ... unless people want to hear about it ...