Actually I think we have a problem with all three points in the CAP theorem, so we should start coding for fault tolerance. Still this goes off-topic. I'm done with this thread.
On Mon, Jul 13, 2015 at 6:29 PM, John Erling Blad <[email protected]> wrote: > A property function for versioned labels would look _exactly_ the same > as today, but the request for the actual value would use the label and > a timestamp. The timestamp would be the last revision of the template. > > Look up books on distributed databases, and check out how they > maintain consistency. In our case it is a simplified set up with a > single master server with multiple clients that has read access to the > server. In addition they have their own state that interfere with the > master state. > > We have a consistency problem (CAP theorem) because the clients don't > update their state (the templates) according to changes on the server > (the labels). One solution to this is to keep the last known version > (a timestamp) to make it possible to continue using outdated > information. > > Another way to say this is that a change in the label leaves an > invalid state at the clients, because the transaction ends prematurly. > That is the templates are not updated, which they must be if the > system lacks versioning. > > Even another way to describe this is that the process running on the > server and the clients lacks isolation, which again can be restored > with versioning. > > There are several consistency models that can be used, but I don't > know if anyone includes something like the proposed "alias model". > > CAP theorem is described in these two, but I havn't read them, sorry for that! > > Brewer, Eric A.: Towards robust distributed systems (abstract), in: > Proceedings of the nineteenth annual ACM symposium on Principles of > distributed computing, PODC’00, ACM, New York, NY, USA, pp. 7– > > Gilbert, Seth and Lynch, Nancy: Brewer’s conjecture and the > feasibility of consistent, available, partition-tolerant web services. > SIGACT News (2002), vol. 33:pp. 51–59 > > On Mon, Jul 13, 2015 at 4:21 PM, Markus Krötzsch > <[email protected]> wrote: >> On 13.07.2015 16:01, John Erling Blad wrote: >>> >>> No we should not make the aliases unique, the reason aliases are >>> useful is because they are _not_ unique. >>> Add versioning to labels, that is the only real solution. >> >> >> Following this thread for a while, I still have no idea what this solution >> is. Could you give an example of how the #property function in Wikitext will >> look for this proposal? >> >>> >>> There are books on the topic, and also some dr thesis. I don't think >>> we should create anything ad hoc for this. Go for a proven solution. >> >> >> Citation needed ;-) >> >> Markus >> >> >>> >>> On Mon, Jul 13, 2015 at 3:24 PM, Daniel Kinzler >>> <[email protected]> wrote: >>>> >>>> Am 13.07.2015 um 13:00 schrieb Ricordisamoa: >>>>> >>>>> I agree too. >>>>> Also note that property IDs are language-neutral, unlike english names >>>>> of >>>>> templates, magic words, etc. >>>> >>>> >>>> As I said: if there is broad conseus to only use P-numbers to refer to >>>> properties, fine with me (note however that Lydia disagrees, and it's her >>>> decision). I like the idea of having the option of accessing properties >>>> via >>>> localized names, but if there is no demand for this possibility, and it's >>>> a pain >>>> to implement, I won't complain about dropping support for that. >>>> >>>> But *if* we allow access to properties via localized unique labels (as we >>>> currently do), then we really *should* allow the same via unique aliases, >>>> so >>>> property labels can be chanegd without breaking stuff. >>>> >>>> -- >>>> Daniel Kinzler >>>> Senior Software Developer >>>> >>>> Wikimedia Deutschland >>>> Gesellschaft zur Förderung Freien Wissens e.V. >>>> >>>> _______________________________________________ >>>> Wikidata mailing list >>>> [email protected] >>>> https://lists.wikimedia.org/mailman/listinfo/wikidata >>> >>> >>> _______________________________________________ >>> Wikidata mailing list >>> [email protected] >>> https://lists.wikimedia.org/mailman/listinfo/wikidata >>> >> >> >> _______________________________________________ >> Wikidata mailing list >> [email protected] >> https://lists.wikimedia.org/mailman/listinfo/wikidata _______________________________________________ Wikidata mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata
