Meta-Tool

[David Bovill]

Yes - I think I get it. Quick question is this any different form providing
"vote casting" messaging API, that any implementation can post to and
optionally subscribe to?

2009/12/4 Michael Allan <mike at zelea.com>

> I was originally saying what Friedrich says: it's premature to talk
> about vote pooling, and it's hardly feasible anyway.  But I eventually
> came to agree with Thomas.  It's not premature at all.  There are two
> immediate problems (two sides of the same coin) to address: split
> consensus among voting engines, and irrational competition.  I added
> brief explanations to the intro here:
>
>  http://t.zelea.com/wiki/User:ThomasvonderElbe_GmxDe/Vote_mirroring
>
> Friedrich Lindenberg wrote:
> > Of course we'll have to talk about interoperability in the long term,
> > but right now there is just no basis for a debate based on empirical
> > experience. Let me take your vote mirroring proposal as an example:
> > you don't discuss different kinds of voting systems, preference voting
> > v. binary voting, security, synchronization and timing issues, etc.
> > etc. Essentially this is a proposal for the replication of Votorola
> > pollserver state in a controlled environment, but that's it.
>
> None of this is properly documented yet, so it's not easy to see.  But
> I think it's the opposite of what you say.  I think autocast mirroring
> is both a practical solution, and also universal.  On the practical
> side, autocasting simply doesn't raise any issues of timing and
> security that aren't already raised by manual casting.  How could it?
> The autocaster is a bona fide agent, a stand-in for the user.  It can
> do whatever the user does, only faster.
>
> Universality isn't a problem, either.  The native engine retains the
> original vote.  The other engines get a thin translation that's
> entirely dependent (mirror-like) on the original.  So there's no loss
> of info.  At the same time, there's no ugly standards-stew of common
> vote representations.  Mirroring is an elegant solution compared with
> pooling.
>
> It's robust, too.  Some kind of translation is usually going to be
> possible between any two voting methods (X,Y), provided you don't have
> to worry about the reverse translation and (crucially) the attendant
> loss of info.  What pair (X,Y) can't we code a one-way translation
> (X->Y) for?  For that pair, any engine using Y will be blind to the
> votes of engines using X.  That's all, the system won't fall apart.
> It's robust.
>
> The autocaster is also something that a developer could start working
> on tomorrow.  The interfaces it needs the most (vote monitoring and
> vote casting) won't be hard to agree, because they're pretty narrow.
> And once it's coded, there's no lack of alpha voting engines to test
> it on.  The testing will be a draw for users, and the kind of thing -
> like David says - that can snowball to everyone's advantage.  (But
> mirroring won't really come into its own till we have common
> registers.  So I guess this is a good use case for the registration
> framework, too.)
>
> --
> Michael Allan
>
> Toronto, +1 647-436-4521
> http://zelea.com/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.reluk.ca/list/votorola/attachments/20091204/fa5084bc/attachment-0007.html>