Domain specific language (DSL)

[Michael Allan]

David Bovill wrote:
> What tweeks use this lovely obfuscated language :)

The build scripts are in Perl.

> Question - a bit left-field - is there any reason not to use a
> single db schema that is shared with LiquidFeedbacks PostgreSQL db?

It wouldn't work, unfortunately.  The role of the data structures is
to provide concrete support to the voting logic.  LiquidFeedback and
Votorola have different voting logic so they have different data
structures at bottom.  The votes cannot be interrelated by "pooling".
They can only interrelated at a higher, more abstract level.

In Thomas's technique of vote mirroring for example, we do scripted
translations in order to aggregate the votes across multiple
pollservers and voting methods.  This technique allows us to support
not only pollservers that do recursive delegation (LD), but also those
that do plurality, range voting, STV - anything that can meet the
requirements for vote mirroring:
http://u.zelea.com/w/User:ThomasvonderElbe_GmxDe/Vote_mirroring#Requirements

In combination with free-range drafting and crossforum ranging, vote
mirroring is our best hope for avoiding the Scylla of split consensus
on the one hand, and the Charybdis of a closed architecture on the
other.

> We've made a start on getting the server up and running, and will
> get Votorolla up and running on it.

It looks your plan is:

 1. Remove Votorola from the current open, distributed architecture,
    or network of hosts, in which it is being prototyped;

 2. Encase it in a Groovy shell; and

 3. Insert it as a component in a newly designed closed, localized, or
    "vertical" system, running on a single host.

The immediate aim is to deliver on a private venture.  But overall,
you believe this is "a better strategy" for delivering on the
"horizontal market" too, meaning the open, distributed system of
e-democracy in general.  Is that true?

> I'm going to get myself technically up to speed gradually. I've decided to
> do this using the newer higher level Java based abstraction languages, that
> I'd be happier working in. This should let me build upon any java classes /
> code base you have in PollServer. This will I hope serve as a learning
> platform for me as i go through each class, and provide a standardised
> structure for the project which will open it up to other developers whether
> they come from Java, or Ruby / Python based backgrounds. I also think it may
> help in architectural terms.
> 
> So to be clear the technical architecture I personally will be working
> towards is to use Groovy to interface with the current Java code base, and
> use Grails to create simple web services in XML and JSON based on PollServer
> in a tidy standardised way. Longer term the aim will be to create a DSL for
> voting, and in particular proxy voting, using the nice features for this in
> Groovy.
> 
> As a practical focus, I am going to take an existing and well structured
> project by One Click Orgs (OCO), and port this class by class, from Ruby on
> Rails to Groovy and Grails. OCO is designed to be used by organisations to
> agree a legal constitution and then run it online with simple voting but it
> would be, and it is planned that LD voting should be integrated as well into
> the software and constitutional frameworks.
> 
> The aim is to use it with a network of organisations. The end result should
> be a practical tool that integrates LD into the constitution and member
> votes of the organisation.

-- 
Michael Allan

Toronto, +1 647-436-4521
http://zelea.com/