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?
