Unifying all the OC country sites into one global site?

[totsubo]

Following up on opencaching.su's comment and the related issue with .nl, what are the benefits of having multiple OC nodes (one per country)? I see lots of drawbacks but I don't fully understand any of the benefits. I'm hoping someone can  make it clearer.

I'm especially confused when it comes to the argument that having different nodes allows for country-specific rules. As pointed out above, a user can easily get around this by publishing on whatever node will accept his cache.

Also, what's stopping someone from starting a new node called opencaching-germany.de and having different rules from opencaching.de?

Also, it was mentioned that it would be too much work for a group of volunteer to maintain a global, consolidated site. Why? Maintaining one node or maintaining one 'global' site is exactly the same amount of work. Did I misunderstand?

On top of that isn't having 20 volunteers working to maintain one global site better than having 10 groups of 2 working separately on their own node?

One of the things that makes Grounspeak (geocaching.com) so attractive is that it is a one-stop location for geocachers. It's simple. When you have 20 nodes for 20 countries, users get confused.

Again, I love the idea of opencaching, I'm just not clear why we have to have 10 different web sites. (Just to be clear, I don't mean to say I want to stop people from creating their own nodes if they want. I just don't understand the reason why we, the current community, have decided to go this route; I don't agree that continuing to multiple nodes is the best solution, but I'm open to having someone change my mind

[oliver]

Just a few of the benefits:

1) Each node can serve features that the local users want to have. While in .nl it seems to be required to have reviewers, .pl only wants to review the first caches and in germany, we dont want to have reviewers at all (only acting when realy required). Just as one example of manys. In a little team, we are very flexible to decide what to implement and what to change. The more peoples are involed from different countries with local requirements, the more complicated and slower the decisions are.

2) Redundancy. If all nodes are "fully synced" and one node goes down because of server failure, power lost, crashed hard drive or simply down for maintainance, the users can simply switch to any other OC site, choose their language and search for caches, log caches or edit caches. When their home node gets online again, the data is replicated back.

3) Performance. One server hosting a worldwide OC site has to be one (or 2, 3) big and fat machines. When we loss the redundancy, the server have to be high available / clustered (99% uptime means 3 days offline! So we should have >99,9%). Performance also means latency from the user origin. Our current server is located in germany 20ms ping time from my location. opencaching.jp has 170ms ping time. Good performance can only be achieved when the servers are located by the users site.

4) Development. The nodes require different "modules" e.g. reviewing. Maybe we can handle most of the requirements with a good configurable big module. But with one big OC node, all optional modules have to run in coexistence. Or we have to cancel the many configuration options and loss most of the flexibility.

5) Testing. Having a bug in the code means that OC will be wordwide offline, until the bug is solved (in worst case).

6) Security. If you big server gets hacked - all hundrets of thousands account get compromissed. Sure, having more than one server makes it more likley to have a hacked server in far future.

7) Legal constraints. There has to be one official operator. He will be exposed to all lawsuits. The bad of this: While we known our local laws very well, we know nothing about other countries.

As i posted before: No single person that can dictate what happens in geocaching community. Having more than one node is a gurantee that the "openness" will be kept.

Maybe having 20 nodes is not good and not required. Maybe a european, american and asian node will be okay. But for replication code it is no difference if we synchronize with one other server or with 20 others.

If we want, we can handle country specific rules. We can forbid to hide .pl-caches at oc.de (or even better: after submission to oc.de, let the cache beeing reviewed by oc.pl before publishing at oc.de and submitting to the OC network). If thats a requirement we can handle it in the synchronisation concept.

Also, what's stopping someone from starting a new node called opencaching-germany.de and having different rules from opencaching.de?

We have the rights for opencaching trademark in germany. Maybe he publishes "somewhatcaching.de" and joins the OC-network. Why not? He will have the same legal restrictions as we have and we are not forces to list caches that are not in conformance with our laws. As of my experience: It will not happen that someone sets up a second OC node in germany. Maybe another geocaching site ...

Maintaining one node or maintaining one 'global' site is exactly the same amount of work.

No. Think of user support (and some points explained before).

One of the things that makes Grounspeak (geocaching.com) so attractive is that it is a one-stop location for geocachers. It's simple. When you have 20 nodes for 20 countries, users get confused.

when node replication is running, each OC node is a "one stop location".

We have talked several times in the german team how much of international hosting can be done by us and our servers. Our focus is at the 3 main countries speaking german (DE/AT/CH). And we decided to help .es and .it for getting started. But hosting a worldwide OC site with all the assets and drawbacks seems to be no option here in germany. Our team has to do a lot of work to support the german community and our goal is to give our users the very best geocaching service. Not a "big but not so good" service. With the OC network we can get both - worldwide geocaching database with the very best service for each country.

[sp2ong]

I agree with Oliver.

[oliver]

Another point:

Risk management: If the one big OC site gets out of money, peoples or enthusiasm, OC will be dead. There is no backup for the community.

[Highlander]

Hi Everyone, I'm from the reviewer group on OC PL node.

Personally, I prefer simple solutions. Most of arguments used here is technical-oriented. But to make the site successful on the geo-market, we should focus more on geocacher-oriented issues.

For me geocaching is always connected with travelling, both domestic and abroad. As a geocacher, I would like to have one account, one place for publishing caches, one statistics, one rules worldwide. Separate nodes with different home rules make unnecessary borders, especially inside EU. One strong site will easier propagate OC caches in "OC empty" countries, than bare startups like UK or NO/SE.

Full synchronisation of local databases + SSO is a solution, but a very complex one. I think in general it would be easier to handle one database, one code and one portal. Think about synchronization issues: having different types of logs, methods of cache rating, different & incompatible cache types, different set of attributes. 
And it would be easier to have one international IT development & support team. If our node, which is the second biggest, has permanent problems with IT (lack of PHP/SQL developers), what will happen with small start-up nodes?

Regardless of the final database solution, we will have to synchronize basic rules. The reviewer problem is of less importance, than i.e.:
1) the fact that OC PL node banned virtuals and webcams
2) each OC node has some uniqe caches type (PL: own cache, DE: math cache, SE/NO: challenge cache etc.)

If we synchronize databases but not rules, Polish users which are very unhappy because of virtuals ban, will start to publish Polish virtual caches via OC DE. You said that we can check each cache according to local node regulations, but who will control that (I can publish virtual cache in Germany and then change coords to Poland)? What about countries without nodes, like France, Slovakia, Denmark - which node rules should be applied?

So my personal conclusion is: If we want to expand, we should unite rules, code and databases - and create clear offer for geocachers and one clear code for easier maintenance.

[totsubo]

I agree with Highlander

I think he presented the reasons why a global consolidated site is a better option  very well. I meant to say all that but Highlander said it much better than I.

Are the needs and requests of users in Poland and Germany so different?

As for needing local modules and the  technical difficulties of integrating that into a global/common codebase ... well, isn't that exactly the problem you are having now. Needing to spend time merging the .de and .pl code bases?

If we had a common code base and wrote and wrote new functionality as plugin modules this problem would go away.

As for the need for 3 or 4 big servers, we have 10 big ones right now as it is. Each site has it's own server, no? I'm sure we can pool them together.

So answering Oliver's points in order

1- Each wants different features. Is that really so? From a user's point of view (not an admin) are there really any features that some geocachers really don't want to have? As far as I understand it geocachers are always asking for *more* features, not to get rid of some

2- Redundancy. That's a technical issue that we can definitely solve. We have 10 servers worlwide, we could pool money/resources to have 3 for the main site and 1 for backup.

3- Performance. As noted if we pool our resources we can easily get 2 or 3 servers dedicated for the global site. As for ping latency, I'm not sure the user will notice a big difference between 20 or 170 *milli* seconds. Come to think of it, Geocaching.com is a global site and all servers are in the US and they have *hundreds* of thousands of non US caches and thousands of non US users ... latency issues have not stopped users from joining gc.com. So I don't see latency as being a big issue.

  I'm sure we can also improve the code to try and minimize the issues of latency. I see this as a challenge rather than a show stopper

4- The nodes require different modules. The only module I can think of that is problematic is the reviewing one. Are there any others? And I come back to the question, what's the point of the reviewing module? There are so many ways around it at the moment. You either have to make all nodes implement reviews or all nodes not implement reviews. So why not just get rid of it?

5-  Bugs. Hmm ... if there is a bug in the base code then all nodes that use that base code are affected. Worse, one node might go and fix the bug but the other nodes have no way of getting the fix automatically. If we share one code base/site we only have to fix the bug in one place. Now the bug has to be fixed and distributed to all the nodes.

Legal restrictions: I'll admit that I don't understand this. Are there laws in Germany or Poland for placing geocaches? It doesn't seen like Geocaching.com has anything in place to deal with country specific laws, why can they get away with not worrying about German laws (or other country's laws) but it's a problem for us? (I'm genuinely curious about this and happy to be informed)

User support: I think that user support will be easier. Some nodes are overwhelmed with support issues while other don't have so many. We can spread out the load over all the volunteer admins.

Oliver, I wish we were closer so we could meet for a beer somewhere and talk this over. You have much more experience than I do in regards to running an OC node and I feel that there's something I'm missing!

[mic@]

[quote="totsubo"]Oliver, I wish we were closer so we could meet for a beer somewhere and talk this over.[/quote]
Do You have a headset? 
http://forum.geocaching-network.com/http://localhost//viewtopic.php?p=14614#p14614

[oliver]

[quote="totsubo"]As for needing local modules and the  technical difficulties of integrating that into a global/common codebase ... well, isn't that exactly the problem you are having now. Needing to spend time merging the .de and .pl code bases?[/quote]

We need to merge the codes ... regardless of single-node or multi-node concept.

I totally agree that we need to have a central repository were all OC developers commit to.
Of course, with some sort of configuration options (via code switches or modules).

Can you suggest a modules list?
(what function to implement in what module)

How could viewcache.tpl look like when there are several modules that want to show informations on that page?

[quote="totsubo"]As for the need for 3 or 4 big servers, we have 10 big ones right now as it is. Each site has it's own server, no? I'm sure we can pool them together.[/quote]

We can pool them together - we can do it also in a mulit-node concept.
Why do we have 10 big ones?
Do we need 10 big ones?

Most of the current OC nodes could be hosted very easy at an virtual private hosting server.
For somewhat around 20 Euro/Month. Hey, where is the problem to get a total of 20 Euro per month from your users?

[quote="totsubo"]2- Redundancy. That's a technical issue that we can definitely solve. We have 10 servers worlwide, we could pool money/resources to have 3 for the main site and 1 for backup.[/quote]

Sure, we could.
But is this concept better?

[quote="totsubo"]3- Performance. As noted if we pool our resources we can easily get 2 or 3 servers dedicated for the global site. As for ping latency, I'm not sure the user will notice a big difference between 20 or 170 *milli* seconds. Come to think of it, Geocaching.com is a global site and all servers are in the US and they have *hundreds* of thousands of non US caches and thousands of non US users ... latency issues have not stopped users from joining gc.com. So I don't see latency as being a big issue.[/quote]

gc.com is slow very often? Isnt it? Do you realy think some IT peoples can make more reliable hosting, less downtime and better performance in their free time than gc.com has? (think of it for a moment) My real life job takes lot of time and i dont think we can find anybody who guarantees to support our hosting solution on that professional basis for serveral years.

Yes, i think the ping-time is an issues - japan has good internet connections and international links. ping times to china can be 300ms. Yes, this is an issue, because every round-trip requires at least that time. Think of a HTML page that has 100 pictures. The performance at oc.jp is good at the moment, because our HTML design requires very few resource files.

As of my feeling, opencaching.de delivers a search result page faster than opencaching.us. In the US, oc.us might be faster. Thats why cloud computing, amazon and google uses serveral computing centers around the world. If server location would be no problem, all servers would be located in the US or somewhere in a state without restrictive laws.

With the network concept, the servers are located where the users need them. Less users per server, less hardware resource, less problems.

[quote="totsubo"]  I'm sure we can also improve the code to try and minimize the issues of latency. I see this as a challenge rather than a show stopper [/quote]

ping latency cannot be reduced by php. Its a TCP/IP issue.

[quote="totsubo"]4- The nodes require different modules. The only module I can think of that is problematic is the reviewing one. Are there any others? And I come back to the question, what's the point of the reviewing module? There are so many ways around it at the moment. You either have to make all nodes implement reviews or all nodes not implement reviews. So why not just get rid of it?[/quote]

Why do you want to force us to review listings?
We dont want to do that for several reasons. Some reasons have to do with legal constraints, some with the word "open" and some with our experience with reviewers of other sites. Users dont like that - and here in germany it works without strict reviewing - we need some attention to listing quality, but that not what is understood on others sites by reviewing.

[quote="totsubo"]5-  Bugs. Hmm ... if there is a bug in the base code then all nodes that use that base code are affected. Worse, one node might go and fix the bug but the other nodes have no way of getting the fix automatically. If we share one code base/site we only have to fix the bug in one place. Now the bug has to be fixed and distributed to all the nodes.[/quote]

Sure, we need a central repository and the bugs must be fixed there.

[quote="totsubo"]Legal restrictions: I'll admit that I don't understand this. Are there laws in Germany or Poland for placing geocaches? It doesn't seen like Geocaching.com has anything in place to deal with country specific laws, why can they get away with not worrying about German laws (or other country's laws) but it's a problem for us? (I'm genuinely curious about this and happy to be informed)[/quote]

Yes, there are a lot of laws to take into consideration. Private property of land owners, nature protection laws, copyright laws for photographs and cut&paste listing text. gc.com has the same problems, but not all german laws apply to them because they are located in the US and it is not typical in germany to sue companies from other countries. Contact for public authorities to gc.com is not easy, because they have to do it in english, wait a long time and cannot force gc.com to answer. At oc.de the peoples can sue us very easy and we have to react on that, or we will get punished (until now, all went well).
(It is hard to translate that to english, but be sure it is an issue in germany. Hosting outside germany would be nice at this point, but we dont want to circumvent the german laws)

[quote="totsubo"]User support: I think that user support will be easier. Some nodes are overwhelmed with support issues while other don't have so many. We can spread out the load over all the volunteer admins.[/quote]

For good user support, the support has to be done in the language of the country. I cannot support english users, nor can i support polish users. Are you able to support german users?

[quote="totsubo"]Oliver, I wish we were closer so we could meet for a beer somewhere and talk this over. You have much more experience than I do in regards to running an OC node and I feel that there's something I'm missing![/quote]

Hm, okay. Maybe we have to do a real life meeting in february or march. Is teamspeak no option?

[Highlander]

Single database of OC caches will host less than 40.000 caches. Groundspeak hosts > 1.000.000 caches. So in the nearest future OC should not have efficiency problems like GC has.

I see that reviewing is a problematic issue. I think we can solve using rule that if cache is registered inside the coordinates of Poland/Netherlands, it may go to reviewer queue. Registration in Germany with be published instantly. We could have a reviewer configuration per country.

I do not get the idea of one node backing up another which is down due to some errors (situation mentioned above - user can edit his caches and submit new logs in any site):

1) How to efficiently synchronize changes between 10-20 nodes? Offline? How frequent? How to check if the databases have complete sync?
2) How to handle collisions (ex. user made three found logs for the same cache on three nodes)?
3) How to handle local node differences when logging/editing foreign cache (rating, attributes, cache types, log types) - ex. how to provide German list of attributes when editing German cache via Polish node?

P.S.
Personally I will very happy to have the virtuals back again in Poland. They must return if we want to synchronize rules.

[oliver]

[quote="Highlander"]
Single database of OC caches will host less than 40.000 caches. Groundspeak hosts > 1.000.000 caches. So in the nearest future OC should not have efficiency problems like GC has.[/quote]

Do you want to design a system for the next 2 years or the next 10 years? With OC node synchronisation each node can decide what other node to replicate - if the server has enough power, all nodes can be replicated. If not, the neighbourhood has to be enough (and OC user accounts of all nodes). Having a million caches is not the problem - having 20 million logs is a bigger problem ...

[quote="Highlander"]I see that reviewing is a problematic issue. I think we can solve using rule that if cache is registered inside the coordinates of Poland/Netherlands, it may go to reviewer queue. Registration in Germany with be published instantly. We could have a reviewer configuration per country.[/quote]

Yes, we could do that with both concepts.

[quote="Highlander"]1) How to efficiently synchronize changes between 10-20 nodes? Offline? How frequent? How to check if the databases have complete sync?[/quote]

My current prototype would be able to sync new records with a few seconds to all OC nodes. There will be a TCP-channel opened to each synchronized node, all the time. Check of consistance and resync of missing records can be done very efficient with timestamped records. I would like to explain you the concept - it is tested with previous OC.de XML interface ( http://www.opencaching.de/doc/xml/xml11.htm - sorry, german with wrong charset). Existing problems can be solved with new prototype.

[quote="Highlander"]2) How to handle collisions (ex. user made three found logs for the same cache on three nodes)?[/quote]

Why should he do the same found log three times for the same cache?
After synchronization has been run, there will be 3 logs because he submitted 3 logs to the network. But a user will only log once, on one node.

[quote="Highlander"]3) How to handle local node differences when logging/editing foreign cache (rating, attributes, cache types, log types) - ex. how to provide German list of attributes when editing German cache via Polish node?[/quote]

attributes and cache types have to be the same on each node. However, a node can decide to hide some of the attributes and cache types for their own caches. And the node can hide caches from other nodes with that cache-type or attribute.

I dont say its easy to implement - but i am sure it can be done and the solution will be reliable.

[Highlander]

OK. I see that you have strong concept for decentralized node-based infrastructure.

As I understand correctly, the main bonus is faster portal -  due to fast ping and smaller amount of concurrent users of particular node? The problem is that the database size will be the same for all nodes and will require constant maintenance - so we will need DB admins for each node instead of one.

As I understand correctly, database structures, tables and columns must be the same in all nodes. This means we are losing the local flexibility to introduce new functionalities on local community demand.

Also I'm interested about sync of reviewers cache queues and handling problems with caches reported by users. Will we have individual queues per node but all data still will be synchronized? If one node will collapse, how the reviewers can access their queue using other node? Or this part of database will not be synchronized?

I must admit that I do not like the idea of local sets of attributes and local cache types. On example - if I live in near border in Szczecin (Stettin) and want to publish caches in Germany and in Poland, I will see different set of attributes depending on the country. And I could publish virtuals on the PL/DE border, but not inside PL. I think this is not a good idea. Basic rules - types, attributes, sizes, ratings should be unified globally.


About collisions handling - It's hard to predict behaviours of users
1) People may log their findings on multiple nodes to pump up statistics of finds.
2) It is possible that somebody on one node will archive the cache at 9:00, and some people will post found logs to this cache before sync. So we will have found logs after archivization, which is now impossible.
3) Other collision - the cache was edited on two nodes. Some attributes and pictures were deleted, later on other node some were added. Description was changed few times. Should system delete all deleted pictures and make multiple changes to description or just sync the final change with the last date?

[oliver]

[quote="Highlander"]As I understand correctly, the main bonus is faster portal -  due to fast ping and smaller amount of concurrent users of particular node? The problem is that the database size will be the same for all nodes and will require constant maintenance - so we will need DB admins for each node instead of one.[/quote]

No, i tried to explain that not every node has to replicate all other nodes. A smaller node can decide to sync only some of the other nodes - those that are most important to their users. Example: If you life in poland, it might be interesting to see and log caches from .de and .cz Very few users in poland want to view caches from .jp. So, if the server resource is low, it is okay not to replicate from the .jp node. But the .jp node could replicate the .pl node. The important part: The .jp node replicates user accounts from .pl node and .pl node replicates user accounts from .jp node. So the user can login at both nodes. The user in poland will see "oh, oc.pl does not have the .jp caches", where can i view them? The answer: at oc.jp and maybe at .de node which replicates all other OC nodes. So the users sets a flag at oc.pl to transfer his login creditials to one of these nodes. Then the user can login there and log the caches with the same account.

Performance at the nodes is one of the advantages, but not the only one. I have written many of them before. From my experience, the most important advantage is to have a network where a single node can discontinue the service and the users have no disadvantage of that (they only have to enter another URL and switch language of user interface at the other OC site). There are several reasons why a oc.de could discontinue his service in (far) future ... legal, political, bad team harmony, hackers, hardware, money, new hobbies of the team members etc.pp.

[quote="Highlander"]As I understand correctly, database structures, tables and columns must be the same in all nodes. This means we are losing the local flexibility to introduce new functionalities on local community demand.[/quote]

No. Database structures are irrelevant. It may help and reduce work to have the same structure, but it is not required. We have to agree what attributes and features to replicate and what not to replicate. Those things that will be replicated, have to be on all nodes - how to map the synchronisation protocol to the database is another question.

BUT: We are discussion about a source code that all nodes use. Then there will be a common database structure! Features that are not implemented in this common source cannot be replicated - why should we replicate informations that other nodes does not support?

[quote="Highlander"]Also I'm interested about sync of reviewers cache queues and handling problems with caches reported by users. Will we have individual queues per node but all data still will be synchronized? If one node will collapse, how the reviewers can access their queue using other node? Or this part of database will not be synchronized?[/quote]

Well, node collapse is somthing that should not happen very often. I am not sure if we should prepare the reviewer queues to be redundant. After node collapse, some cleanup is always required ...

... try to compare the node replication with some other muli master replication like active directory and domain controllers. The big IT companies show us how to do things very reliable. Domain controllers should be located at customer site for latency, load and performance ...

If one node wants to replicate the entire network, the server must be able to host the entire database, as it is required to host the entire database in a one-node-concept. But in mutli-node-concept there will be much less users on that database and so the performance requirements are much lower. I cannot estimate how much resource will be required for both concepts, but for multi-node replication i am sure that typical web hosting root server do the job for nodes with the number of users as oc.de has (quad core with 8 GB RAM). For single node concept, i dont know what database engines are required, but i know that scalability of the mysql master server costs a lot when you require more than a dual processor machine. In germany, we had a lot of performance issues in the past and site broke down completly at burst times (e.g. after reports in TV). Now it looks very stable since we introduced a second hardware server for mysql slave hosting and more RAM for mysql master and apache host ... but it took a lot of time to find those solutions and i am sure that we will get more of these performance issues when hosting worldwide access on a single node. With only one node the trackdown of this performance and stability issues is time critical - and we all have other real life jobs. If you have multiple nodes, you can say your users "we have problems, upgrades and test the next week - i our site is not accessible at a certain time, simply use oc.xx)

[quote="Highlander"]I must admit that I do not like the idea of local sets of attributes and local cache types. On example - if I live in near border in Szczecin (Stettin) and want to publish caches in Germany and in Poland, I will see different set of attributes depending on the country. And I could publish virtuals on the PL/DE border, but not inside PL. I think this is not a good idea. Basic rules - types, attributes, sizes, ratings should be unified globally.[/quote]

I agree, things will be easier. But do we find a consense on all points?

Not every cache type has to be supported on all nodes (the only must-have-support is not breaking the replication). If a user of oc.pl wants to hide a virtual cache not allowed in poland, he has to go to oc.de and publish his virtual there. This virtual must not be accessible from oc.pl if oc.pl admins dont want that. Where is the problem with that?

[quote="Highlander"]
1) People may log their findings on multiple nodes to pump up statistics of finds.[/quote]

They might do that on the same node, too. Do we have to install a "parental control"? The community will solve those problems on their own way (flame wars and such nice things )

[quote="Highlander"]2) It is possible that somebody on one node will archive the cache at 9:00, and some people will post found logs to this cache before sync. So we will have found logs after archivization, which is now impossible.[/quote]

Logging after archivization is okay. Why not? I have found the cache at 8:30 and i am back at home at 11:00. The owner archived at 9:00. Why should i not log my found? In germany we have 2 states of archive ... a archive state that enables new logs and one that forbids new logs. You are right, there are some issues that we dont have without synchronisation. The question is: Are there issues without a solution?

Lets start with small replication like "user only", make some experience with that and then go to cache-sync ... after that the logs ... and then some additional features like ratings ...

[quote="Highlander"]3) Other collision - the cache was edited on two nodes. Some attributes and pictures were deleted, later on other node some were added. Description was changed few times. Should system delete all deleted pictures and make multiple changes to description or just sync the final change with the last date?[/quote]

I think it is okay to favor the "last change" only. Pictures are replicated independantly of the cache record. So deletition of pictures and adding new one on other node is no issue. The same for logs.

[opencaching.su]

[quote="totsubo"]
I agree with Highlander

I think he presented the reasons why a global consolidated site is a better option  very well. I meant to say all that but Highlander said it much better than I.

Are the needs and requests of users in Poland and Germany so different?

As for needing local modules and the  technical difficulties of integrating that into a global/common codebase ... well, isn't that exactly the problem you are having now. Needing to spend time merging the .de and .pl code bases?

If we had a common code base and wrote and wrote new functionality as plugin modules this problem would go away.

As for the need for 3 or 4 big servers, we have 10 big ones right now as it is. Each site has it's own server, no? I'm sure we can pool them together.

So answering Oliver's points in order

1- Each wants different features. Is that really so? From a user's point of view (not an admin) are there really any features that some geocachers really don't want to have? As far as I understand it geocachers are always asking for *more* features, not to get rid of some

2- Redundancy. That's a technical issue that we can definitely solve. We have 10 servers worlwide, we could pool money/resources to have 3 for the main site and 1 for backup.

3- Performance. As noted if we pool our resources we can easily get 2 or 3 servers dedicated for the global site. As for ping latency, I'm not sure the user will notice a big difference between 20 or 170 *milli* seconds. Come to think of it, Geocaching.com is a global site and all servers are in the US and they have *hundreds* of thousands of non US caches and thousands of non US users ... latency issues have not stopped users from joining gc.com. So I don't see latency as being a big issue.

  I'm sure we can also improve the code to try and minimize the issues of latency. I see this as a challenge rather than a show stopper

4- The nodes require different modules. The only module I can think of that is problematic is the reviewing one. Are there any others? And I come back to the question, what's the point of the reviewing module? There are so many ways around it at the moment. You either have to make all nodes implement reviews or all nodes not implement reviews. So why not just get rid of it?

5-  Bugs. Hmm ... if there is a bug in the base code then all nodes that use that base code are affected. Worse, one node might go and fix the bug but the other nodes have no way of getting the fix automatically. If we share one code base/site we only have to fix the bug in one place. Now the bug has to be fixed and distributed to all the nodes.

Legal restrictions: I'll admit that I don't understand this. Are there laws in Germany or Poland for placing geocaches? It doesn't seen like Geocaching.com has anything in place to deal with country specific laws, why can they get away with not worrying about German laws (or other country's laws) but it's a problem for us? (I'm genuinely curious about this and happy to be informed)

User support: I think that user support will be easier. Some nodes are overwhelmed with support issues while other don't have so many. We can spread out the load over all the volunteer admins.

Oliver, I wish we were closer so we could meet for a beer somewhere and talk this over. You have much more experience than I do in regards to running an OC node and I feel that there's something I'm missing!
[/quote]

Generally, I support Oliver. The idea of network of opencaching nodes is more attractive to me:

1. Single big node would be more complicated for development just because of bureaucracy. For enabling any new feature we would have to make an agreement between a lot of people from different countries. The more countries works with the same node, the more people involved into decision making, the more complicated would be making any decision.

2. In contrast, in a opencaching network one node is more free for experiments. Am experimental feature could be discarded, or stay as a local opencaching "module" (or whatever we name it), or adopted by other nodes.

[OlofL]

Another option would be to have one database shared between different nodes. I.e. not having the database and the webserver on the same machine. This would still allow a lot of flexibility, but there would be a sence of one database.

[oliver]

[quote="OlofL"]
Another option would be to have one database shared between different nodes. I.e. not having the database and the webserver on the same machine. This would still allow a lot of flexibility, but there would be a sence of one database.
[/quote]

Bad idea ... having different sources administrated from different adiminstrators accessing the same database makes debugging of failures and performance issues impossible. To upload the sources or database schema you would need many peoples from the different nodes. The server have to be in the same IT center to have fast network connection between webserver and db server ...