Unifying all the OC country sites into one global site?

You want to get involved in the Opencaching Network?
totsubo

Now that opencaching.com has come online it has made me wonder, what do people think of the idea of unifying all the various opencaching sites into one global site?

In my humble opinion it would offer the following advantages:

1- Look more 'professional'. Instead of multiple sites loosely linked we would have one global and unified service. This would attract more users.

2- Allow the developers more time to concentrate on development. Individual developers would no longer need to devote time to country specific fixes/etc. (Also, currently any bug fixes on one site don't get propagated to other sites)

3- Reduce costs. We'd only need to pay for one domain name and one hosting service.

I might be totally incorrect and I'm happy to hear other opinions/ideas :)
sp2ong

- some countries want to ensure that all geocache were reviewed by the reviewers (OC U.S.) in Poland first 5 caches are reviewed and user can create first cache need find 10 caches, OC DE do not use system reviewers.
- if they are technical problems with one OC sewer is not available, if one OC node does not work, this does not affect the rest OC Nodes
- local geocachers in the country establish local rules for placing geocaches. It's not easy when the server would be only one.
- If will be one OC server and the OC will be use system reviewers are need local reviewers and this may to find they  not easy.

I am not against to  one OC site (it maybe create a few node Europe, America, Asia etc) We have domain www.opencaching.eu not used (it is only show OC NOdes)
Zuletzt geändert von sp2ong am 15.12.2010, 17:35, insgesamt 1-mal geändert.
oliver

The current nodes can be handled by small teams in their free time with very little budget ...
... i think one global site cannot be maintained in this way (if the site has success).

You pointed out that the current sites are loosely linked and that the source has to be fixed on each node. We want to solve both problems by using a common source code and sychronisation of databases.

One of the major priciples of opencaching is to have multiple sites with independent operating persons or organisations. Each site (=node in the network) contributes their data to the network and uses the data of the other nodes via this network. There is no single person that can dictate rules to the sport or forbid new ideas - if the other node operators does not agree with very bad decisions of another site admin, they can ban that node from the network. So it will be impossible to do very bad things just for making money and annoy users. Of course, each site has some decisions to do and the other sites have to respect that decisions like reviewers yes/no, advertisements and so on.
DudleyGrunt

I've heard some whispers about the possibility of maintaining separate nodes, but introducing a single sign-on capability.  This would allow someone to create a single account that would then be able to access any of the OC sites.  Perhaps there could even be a way to create a combined stat banner.

I think this would be a good middle ground between the current state and on monster OpenCaching site.
OlofL

Another option would be to have all caches replicated over all the nodes, but each cache has its master node and that is always the country in which it is located. Single sign on for users would allow anyone to register a cache according to the specific rules in each country, viewing caches would see upon all caches as equal no matter of its master node, they are visible to all, but logging a note or found is done at the site that is master.

Why? It is rare that you log a cache and does not know in which country it was located. And it would prevent registering caches in Sweden according to polish rules etc. And all the time everyone can see all caches and the search engine for them is their local site.

The foreign_caches table and concept could be ditched, just add a flag to the caches whether this node is its master or not and it is treated as readonly if it's not its master.
OlofL

I'm not against a global oc-site, I'm just realistic, there are too many different points of view at the moment. But .se and .no are working together with .dk to create a one site for all of us and we have some caches from Portugal making it the unofficial oc-node for them. I would encourage those who feel they can to unite with someone to run a common site. We are open for more on our site.
oliver

[quote="OlofL"]
Another option would be to have all caches replicated over all the nodes, but each cache has its master node and that is always the country in which it is located. Single sign on for users would allow anyone to register a cache according to the specific rules in each country, viewing caches would see upon all caches as equal no matter of its master node, they are visible to all, but logging a note or found is done at the site that is master.[/quote]

Thats the concept and database layout is prepared to allow that synchronisations with basic data (i dont know if your source already includes the "node" field). But logging should be able to do on all nodes for all caches. Even editing a cache can be enabled on all nodes, when the user "opts-in" for node-trust. A user registers at his home node and there he can set trusts to other nodes, that he wants to use with his login. The home/master node will accept changes to his records from that node. So each user can decide what OC site is trusted to get his login creditials (and mail address) and which sites are not trusted (because of security).

[quote="OlofL"]The foreign_caches table and concept could be ditched, just add a flag to the caches whether this node is its master or not and it is treated as readonly if it's not its master.
[/quote]

Dont introduce a table foreign_caches, please! That will complicate search queries a lot!

I suggest a teamspeak meeting to explain the concepts already done and most parts tested and prototyped. It would be very bad if the work that has already been done on that is lost and reinvented.
miklobit

Hi All.
In long term, maintaining common code ( but not single server ) have big advantages over creating network of similar however separate maintained country repositories.
Despite of my little ( for he time being ) OC source code knowledge,  is clear for me that unyfing several repositories with country specific extension would be a big challenge.
But, having experience from other similar opensource project - Typo3 CMS - i see some guidelines that are obvious  to  follow:
1. The server code should be divided into  VERY small core ( which is commonly used and have to be maintained by small central core developers team ) and  flexible extension API that allow anybody to create its own extension.
2. The central extension repository allow to share extensions - no manual installation/activation is needed - all is maintained by core code ( dependency, versioning, dynamic switching on/off ).
3. Either core and extensions have to follow object model - so one can adjust extension code by inheritance rather than by copying/forking the code.
4. The main set of common used logic is also maintained as extensions ( by core team ).

Ofcourse - starting unyfing code from scratch is crazy idea - but using cms's like mentioned Typo3 -  allows to migrate projects ( like OC ) as a set of new extensions. Keeping most of existing database structure, but having "out of the box" thousands of exisitng extensions, including such as state-of the art template engine, backend administration, openID logging, intergated forums, pools, rich text editing, mailing systems and professional-level documentation avalable

If we are thinking about joining efforts, let's think how to not waste time developping commonly used, already existing functions, but to focus on geocaching specific logic/code.

Milosz.
OlofL

[quote="oliver"]...Dont introduce a table foreign_caches, please! That will complicate search queries a lot!...[/quote]
I agree. The current pl-branch alreay has this, but it is only used in the map since it is too complex to incorporate this in all cache searches. I did an experiemnt of creating a view that joined the normal and foreign caches but I didn't like that solution.
sp2ong

[quote="OlofL"]
[quote="oliver"]...Dont introduce a table foreign_caches, please! That will complicate search queries a lot!...[/quote]
I agree. The current pl-branch alreay has this, but it is only used in the map since it is too complex to incorporate this in all cache searches. I did an experiemnt of creating a view that joined the normal and foreign caches but I didn't like that solution.
[/quote]

Yes foreign_cache was only us to display on cache map from Others Nodes. But we are need map on every node which will be displayed all OC Caches, maybe caches registered on others Nodes will be marked other. But when we define API REST we can use to download caches info from others  Node where they have number of Node in cache table and we can use this to inform users about this that cache is from other not local node
maltee_h

It would be better, when we have more sites than one!
opencaching.su

[quote="oliver"]
The current nodes can be handled by small teams in their free time with very little budget ...
... i think one global site cannot be maintained in this way (if the site has success).

You pointed out that the current sites are loosely linked and that the source has to be fixed on each node. We want to solve both problems by using a common source code and sychronisation of databases.

One of the major priciples of opencaching is to have multiple sites with independent operating persons or organisations. Each site (=node in the network) contributes their data to the network and uses the data of the other nodes via this network. There is no single person that can dictate rules to the sport or forbid new ideas - if the other node operators does not agree with very bad decisions of another site admin, they can ban that node from the network. So it will be impossible to do very bad things just for making money and annoy users. Of course, each site has some decisions to do and the other sites have to respect that decisions like reviewers yes/no, advertisements and so on.
[/quote]

Oliver,

I do not object against your ideas, but I need some more explanation. Look:

1. All the nodes synchronize databases (cache listings).
2. We have common code so every node can change interface language.

This makes all the nodes just mirrors of the networks. It is a good idea (load is distributes between multiple nodes, one node may serve as a backup for another, etc). But I do not quite understand how it agrees with different node policies? Few posts above sp2ong wrote that there are different rules (e. g. reviews) in different nodes. For example, if my new cache does not pass review at oc.us, I can publish the cache at oc.de, and it will be available at oc.us in a day or so. It effectively eliminates US review policy, doesn't?
OlofL

[quote="opencaching.su"]...For example, if my new cache does not pass review at oc.us, I can publish the cache at oc.de, and it will be available at oc.us in a day or so. It effectively eliminates US review policy, doesn't?
[/quote]
That right. Perhaps it is the registration and publishing of a cache that needs to be bound to the specific rules of that node? To make that work, registering of caches outside of the country/countries of of the site cannot really be allowed.
zaanhoeve

We have in the Netherlands the same problem. Not allowed? publish it in Germany.

One Db would make it better I think. If a cache is made in the Netherlands It could be announced to the Dutch "reviewer". Now we have no influence to any off it. But it still will be linked to oc.nl specially when there are problems.

one Db has also the advantage that every site is always up to date.
oliver

About what type of rules do you think?

1) legal restrictions

2) custom rules of a opencaching website, that most of the users accept

3) custom rules of a opencaching website, that most of the users NOT accept
Antworten