Domain specific language (DSL)

[Michael Allan]

David Bovill wrote:
> However I am not a Java programmer, and I am not familiar with the
> innards of Votorolla, so i would value your thoughts on this. What
> I'd like to do is start hosting Votorolla on a good virtual host,
> and start work personally on creating a wrapper for it in Groovy
> (eventually leading to a DSL), so that we have the added flexibility
> of being able to create Ruby on Rails like sites (ie in Grails) with
> embedded Liquid Democracy...

I guess almost all compilers can link to Java libraries.  You should
have no problem, with or without Groovy (which I'm unfamilar with).
You can call straight into Votorola's API.  It's well documented:
http://zelea.com/project/votorola/_/javadoc/index.html

But I wouldn't do that.  I'd float the UI separately, and call the
servers via network protocols.  Don't worry about the coding of the
service points, they're easy.  Worry about the design of the UI (more
below).

Alex Rollin wrote:
> Hi David ... I share...

It's painful because Votorola is an exploratory project.  We've been
exploring in abstract and prototype what might have taken decades to
explore in production code.  (I guess I share too, when I recall all
the code that was ditched on account of arch shifts.)  For sake of
speed, and especially in the last year, we've suppressed coding and
other deployment issues to a minimum.  That doesn't leave you much to
come to grips with, I know.  I'm hopeful we can attract a
nuts-and-bolts architect or a down-to-earth project leader, at some
point.

> I've been working to understand the architecture of Votorola enough
> to understand where the gaps are with application to this particular
> test example.  I've identified, for example, something
> yet-to-be-coded in the form of the "custom authentication list" that
> an organization might create that would add voters, in Votorola, to
> a qualified voting list that would be applied within polls.

Yes, I remember we spoke about that.  The registration framework does
allow for organization-specific voter registers:
http://u.zelea.com/w/User:Mike-ZeleaCom/Registration_framework

The code doesn't look too difficult, either.  It shouldn't hold you
up.

> This, barring other practical and theoretical issues with voter
> registration having to do with sock puppets and clean voting and the
> like, is the only issue I have seen to moving ahead with the pollwiki
> and pollserver implementation as-is.

Sock puppets aren't a concern in organization-specific polls, provided
the org supplies and certifies the voter register.  They only become a
concern in cross-organizational polls, where the voter list is an
aggregate of multiple registers.

> I can and do see that there is room to help with the GUI/UI issues
> with the current pollwiki, then, now and in the near future, assuming
> as I do, that this piece will-be-coded as I move towards a more
> "official" sort of deployment with a "real organization" making "real"
> decisions and becoming reliant on the current pollwiki.
> 
> Mike, as you continue to build out your theory docs, what is your
> current position on the "horizontal and vertical" as being drivers of
> features and extensibility, in the are of web services and "other"
> front ends?

I don't mind (speaking for myself) if the first deployment is vertical
(private org).  I would only be concerned (if I'm asked to contribute)
that the architecture be kept open.  It's not good to bootstrap on the
wrong foot, because a closed arch can never compete in this domain (at
least I don't see how).  Radical openness is the only way to go, I
think.

You and David both mention the UI, and I think that's the crux.  I
wouldn't worry too much about the pollwiki, because it's not a top UI.
Most users will touch it only for drafting.  (Even there it can be
wrapped, I guess, because MediaWiki has an editing API.)  I would
start building outside of the existing codebase.  I think that apps
like crossforum theatre, separately deployed and straddling the whole
show, are the way to go.  You can start designing them, today.  No
obstacles there.  (The design of crossforum theatre seems to have
landed in the right ballpark, but probably not on base yet.)  Whatever
you float at that height will necessarily push many of the existing
facilities into the ground, to serve as supporting infrastructure.
The upside of designing "out of the box" like that, is the freedom to
experiment (and that's exactly what's needed now) while the downside
is it's not efficient (and that's not needed, not yet).

-- 
Michael Allan

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