Unifying all the OC country sites into one global site?

You want to get involved in the Opencaching Network?
Highlander

[quote="oliver"]
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.
[/quote]

OK, thanks for clarification. But if all nodes obligatory replicate all users accounts, why did you suggest that PL user must manually set a flag and transfer his login credentials to JP or DE?

The concept of partial selective node replication (regarding caches/logs) is interesting, but has some serious drawbacks. I think that for many users it is very important to have one account with full statistics/history of caches hidden and found. If PL is my basic node and I visited Japan or USA I cannot have JP/US logs in one account history. Maybe some functionality for full account history synchronization should be added.

We also should consider change in the method of calling caches and logs in http addresses. Now OC code uses cache ID from database, i.e:
http://www.opencaching.pl/viewcache.php?cacheid=12302
but in future it should be changed to waypoint-based:
http://www.opencaching.pl/viewcache.php?wp=OP300A
because particular cache ID will be different in each node.

[quote="oliver"]
(...) 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 - (...) Features that are not implemented in this common source cannot be replicated - why should we replicate informations that other nodes does not support?
[/quote]

OK. This changes a lot in understanding nodes concept. But now we have new issues:
1) Other nodes will not be able to fully backup node which goes down - locally gathered data and functionality will be lost (PL reviewers queue will not be available in DE node, PL caches in DE will not have PL attributes etc.)
2) How to solve new cache reviewing problem - do you plan to sync such things? What will happen if DE user via DE node will register cache in PL node area - will it be published instantly or should it be hidden and transferred to PL node for review? What will happen if PL newbie registers in PL node his first cache in the DE node area - should it bypass polish reviewing queue?
3) The next question - What will be the prefixes of caches registered in PL node on the territory of Germany? OCxxxxx or OPxxxxx ? In OP, how to get the waypoint number - some online API?
4) Supposing that PL node will not sync with JP node, will it be possible to register PL cache on the JP territory?

[quote="oliver"]
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]

OK. But the functionality will be partial - i.e.
- new PL caches cannot be registered on DE node (no reviewers)
- in PL new traditional caches cannot have internet log password (DE user in PL node could not change it)
- user cannot search for local PL caches using local types and attributes.

[quote="oliver"]
Not every cache type has to be supported on all nodes (the only must-have-support is not breaking the replication.
[/quote]

I think that cache type, statuses and attributes are critical thing to be unified. Think about:
- set of cache types icons for cache map (what icon will You present on map for Polish "own caches"?)
- filtering criteria on maps and cache search (how to find DE math caches in PL node?)
- statistics which base on cache type

[quote="oliver"]
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]

The problem is that PL user may use his account on DE node to log finding of such virtual cache. And then DE node will synchronize this find with PL node (the basic idea of one user account with one complete history). Unless you want to block such synchronization - so user will have one account but two different histories on two nodes... complicated.

BTW, now it is possible to register virtual cache in Poland using DE node, and it is visible in PL node cache map :)

[quote="oliver"]
[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. [/quote]

In PL node it is not possible to make more than one "found" log for one cache. Is it really possible in DE node?

[quote="oliver"]
Logging after archivization is okay. (...) 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.
[/quote]

Your concept is good regarding the usability. But today in PL node it is not possible to log "found" when cache is "temporarily unavailable" and "archived". Comments are allowed only in "temporarily unavailable". Maybe it is a good idea to change this thing on PL node. But we do not have any developer at the moment :(


[quote="oliver"]
The question is: Are there issues without a solution?
[/quote]

There is always a solution, it is just the matter of time, human resources and number of mandays to do :)

It is true that regarding multi-node concept I presented more problems than solutions. I am not against this concept, I just wanted to show my concerns / fears about it. Thanks to your detailed explanations I now see much more pros of multi-node solution than before.

I work for years in IT consulting and all business IT solutions I know were oriented on one central database with powerful machine and farms of application & www servers. If solution used more than one DB server (ex. active-active cluster) it has always real-time data replication or used one external HDD matrix.
That's why I was afraid of the reliability of local data synchronization between 20 independent nodes without one referential "mother node". If you say it is no risk with that - I trust You. Maybe for OC databases synchronization is simple because most of parent data is only added (you cannot delete a cache so child data - logs/pictures/add.waypoints will always find its mother).

I suggest that we should start international discussion about unification of:
1) cache types
2) cache statuses
3) cache attributes
4) log types

I hope we can negotiate one set of rules. This will make our "product" more friendly for worldwide users.

One more question - what do you think about statistics? Should there be one global OC user/caches statistics and local ones? Or just local ones - showing node-controlled regions and one "foreign" region for finds from other nodes?
oliver

[quote="Highlander"]OK, thanks for clarification. But if all nodes obligatory replicate all users accounts, why did you suggest that PL user must manually set a flag and transfer his login credentials to JP or DE?[/quote]

E-Mail and password-token are considered to be "private data". The synchronisation concept does not require that other node owners are "fully trusted". Because we dont know each other in real life, i think that is an important point. When having more nodes, the possibility of successfull hacks somewhere in the network is growing. Only sending the mail-adress and password tokens/hashes to those nodes that realy require it, will reduce the number of compromissed accounts and further spam and hacking-possibility for the end user. So, this is mainly for security reason of the whole network.

[quote="Highlander"]The concept of partial selective node replication (regarding caches/logs) is interesting, but has some serious drawbacks. I think that for many users it is very important to have one account with full statistics/history of caches hidden and found. If PL is my basic node and I visited Japan or USA I cannot have JP/US logs in one account history. Maybe some functionality for full account history synchronization should be added.[/quote]

I know, full statistic is a problem. Maybe we can setup one database the deliviers services for all nodes that are (realy) difficult to synchronize like statistics. So the forum-signature image (stats-image) could be delivered by "stats.geoaching-network.org", which replicates all nodes but has low hardware requirements, because it only serves some minor functionality.

[quote="Highlander"]We also should consider change in the method of calling caches and logs in http addresses. Now OC code uses cache ID from database, i.e:
http://www.opencaching.pl/viewcache.php?cacheid=12302
but in future it should be changed to waypoint-based:
http://www.opencaching.pl/viewcache.php?wp=OP300A
because particular cache ID will be different in each node.[/quote]

This is already changed in the smarty template code:
http://www.opencaching.de/viewcache.php?wp=OCB8B1

Maybe we can introduce common calling API like
http://www.opencaching.de/wp/OCB8B1
(the correct url will be called via mod_rewrite)
oliver

[quote="Highlander"]1) Other nodes will not be able to fully backup node which goes down - locally gathered data and functionality will be lost (PL reviewers queue will not be available in DE node, PL caches in DE will not have PL attributes etc.)[/quote]

The reviewer queue should be part of the common source - so activating it on oc.de may be no problem. However, the current data inside the queue may not be replicated. Replicating attributes that are not "selectable" on each node will be no problem.

[quote="Highlander"]2) How to solve new cache reviewing problem - do you plan to sync such things? What will happen if DE user via DE node will register cache in PL node area - will it be published instantly or should it be hidden and transferred to PL node for review? What will happen if PL newbie registers in PL node his first cache in the DE node area - should it bypass polish reviewing queue? [/quote]

I have not thought about reviewing issues in all consequences, because it was no issue until now. There are many options how we can handle it - depending how much work we want to invest:

1) We can agree to accept new caches for PL country only at the PL node (which should be no long-term-solution)
2) New PL-caches created at oc.de could be shown at oc.de, but hidden at oc.pl until they have been reviewed at the OC.pl node
3) New PL-caches created at oc.de could be hidden at oc.de, until they have been reviewed at OC.pl node

However, we should not delay the introduction of the sychronisation because of that minor issues. The basic concept has to grow with its future requirements. I think it is not possible to have the ideal solution from the very beginning of the sychronisation. If everybody says "all of our current functionality has to be fullfilled by anything new, before we will join the development", we will make no progress in synchronisation and no progress in common source code.

[quote="Highlander"]3) The next question - What will be the prefixes of caches registered in PL node on the territory of Germany? OCxxxxx or OPxxxxx ? In OP, how to get the waypoint number - some online API?[/quote]

For the beginning, the waypoint prefix depends on the node where the caches has been created.

[quote="Highlander"]4) Supposing that PL node will not sync with JP node, will it be possible to register PL cache on the JP territory?[/quote]

Yes, it should be possible - however, there has to be a very well placed notice to the user warning that it is not recommended. In this case, the user should list the cache at OC.jp (with the same account, that has been replicated to OC.jp).

[quote="Highlander"]OK. But the functionality will be partial - i.e.
- new PL caches cannot be registered on DE node (no reviewers)
- in PL new traditional caches cannot have internet log password (DE user in PL node could not change it)
- user cannot search for local PL caches using local types and attributes.[/quote]

new caches => explained above, possible depending on the concept

log password => the log password must be replicated and used on each node

search for attributes => explained above, could be possible. However, i think the attributes and cache types will be very same on each node. Why should in PL other requirements exist for good attributes than in DE? (virtual caches => can be hidden at OC.pl node).
oliver

[quote="Highlander"][quote="oliver"]
Not every cache type has to be supported on all nodes (the only must-have-support is not breaking the replication.
[/quote]

I think that cache type, statuses and attributes are critical thing to be unified. Think about:
- set of cache types icons for cache map (what icon will You present on map for Polish "own caches"?)
- filtering criteria on maps and cache search (how to find DE math caches in PL node?)
- statistics which base on cache type[/quote]

Yes, having the same types on each node will be an advantage.
Each cache type can have a flag "allow_usage".
OC.de allows usage for virtual cache type, PL does not. But with common source, each node has the required images to show it at the maps.

[quote="Highlander"]The problem is that PL user may use his account on DE node to log finding of such virtual cache. And then DE node will synchronize this find with PL node (the basic idea of one user account with one complete history). Unless you want to block such synchronization - so user will have one account but two different histories on two nodes... complicated.[/quote]

=> explained above, there could be a central statistic node, that holds all OC network data and possibly data of other non-OC-sites

[quote="Highlander"]BTW, now it is possible to register virtual cache in Poland using DE node, and it is visible in PL node cache map :)[/quote]

And nobody uses this workaround, because PL-users agree to the restriction of OC.pl-node?

Please note that virtual caches at OC.de also have strict requirements - no coach-potatoes, the user has to be at a specified location and find something that cannot be googled. Virtuals are only allowed if no physical container can be placed for serious reason.

[quote="Highlander"]In PL node it is not possible to make more than one "found" log for one cache. Is it really possible in DE node?[/quote]

Yes, its possible. But only counted once, as i remember.

This is because of various reasons:
- some caches change the final location and the user has to search the cache again, as it would be a real new cache. Sometimes its call "reloaded" in the cache name
- some events will be archived after they happended and reactivated in the next year - this enables good information to the users via watchlist

[quote="Highlander"]Your concept is good regarding the usability. But today in PL node it is not possible to log "found" when cache is "temporarily unavailable" and "archived". Comments are allowed only in "temporarily unavailable". Maybe it is a good idea to change this thing on PL node. But we do not have any developer at the moment :( [/quote]

Okay, i didnt know that. So we should realy start to implement the additional oc.pl-features in the smarty code to have the developers in the network working together and have a code that can be used from SVN on different nodes without modification that prevent updates.

[quote="Highlander"]There is always a solution, it is just the matter of time, human resources and number of mandays to do :) [/quote]

I aggree ;)
So starting with small number of replication supported features and improve in future is the way to go.

[quote="Highlander"]It is true that regarding multi-node concept I presented more problems than solutions. I am not against this concept, I just wanted to show my concerns / fears about it. Thanks to your detailed explanations I now see much more pros of multi-node solution than before.[/quote]

I know some other more technical related problems with replication ... but i am absolutly sure that once having the replication working and having the same source on the nodes, we will be able to reduce the required work and improve the source faster - the nodes can concentrate on their key business - user support, (real) local customisations and hosting.

[quote="Highlander"]I suggest that we should start international discussion about unification of:[/quote]

May suggestion of the next points to talk:
http://forum.geocaching-network.com/http://localhost//viewtopic.php?p=14837#p14837

[quote="Highlander"]One more question - what do you think about statistics? Should there be one global OC user/caches statistics and local ones? Or just local ones - showing node-controlled regions and one "foreign" region for finds from other nodes?[/quote]

At OC.de we only provide very basic statistics, because we think that it reduces the quality of the caches. My opinion is that a dedicated statistics site can do better statistics than any single node can do. A good statistics site will combine caches of all OC nodes, caches of gc.com, caches of oc.com, gc.com.au, gc.hu and all the others. To create good statistics, there is some knowledge of static theory required and the tools to create statistics are different from the ones we require at OC development (most important the charting components). So having the statistics mananged by a dedicated development team (or other website) is prefered by me. However, until we find such a dedicated team, we may create the suggested "stats.geocaching-network.org".
Highlander

[quote="oliver"]
[quote="Highlander"]BTW, now it is possible to register virtual cache in Poland using DE node, and it is visible in PL node cache map :)[/quote]
And nobody uses this workaround, because PL-users agree to the restriction of OC.pl-node?

Please note that virtual caches at OC.de also have strict requirements - no coach-potatoes, the user has to be at a specified location and find something that cannot be googled. Virtuals are only allowed if no physical container can be placed for serious reason.
[/quote]

I think nobody uses this workaround now because of separate user accounts. Our map can show basic data of DE cache, but link goes do DE node. So if you find such cache you cannot log find under PL account.

I didn't know you have such virtual cache restrictions - it seems to be the similar to those I suggested to use in PL instead of total ban of virtuals. Most of PL node management is against virtuals. Can you give me a link to DE cache publication rules? I couldn't find any wiki-link on DE site.
oliver

German rules are documented here:
http://www.opencaching.de/articles.php?page=impressum#tos

Beside this very specific rules for virtuals, the most rules are related to real legal stuff, non-commercial, no-advertisement, listing publication on other websites and keeping listings up2date.
Benutzeravatar
mic@
Vereinsmitglied
Vereinsmitglied
Beiträge: 6623
Registriert: 04.12.2009, 00:31

[quote="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?[/quote]
Yesterday I would have argued in the same way as Oliver, which means that many nodes are more stable
and allows individual community orientated solutions.

But now I think Your idea is very attractive, because:
- problem with unified login is no problem anymore  8)
- problem with synchronization is no problem anymore  8)
- problem with german justice is eliminated (**)
- more cost efficient


(**) We had a cache where people climbed up an old antenna and got problems afterwards with german justice.
Antworten