Domain specific language (DSL)

[Alex Rollin]

Hi David,

I share:

I'm interested in the horizontal but have immediate use of the vertical
I want to build a custom front end

I've done a bit of work on applying Votorola to a vertical, in a sense, at:
http://u.zelea.com/w/P2P

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.

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.

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?

Dave, add me on Skype, please: discursives.  I hope we can have a chat
soon about things.

I chat with Mike and Thomas on Skype a bit and we ought all meet there
soon, I think.

Alex



On Thu, Oct 14, 2010 at 10:37 AM, David Bovill <david at vaudevillecourt.tv> wrote:
> On 14 October 2010 07:33, Michael Allan <mike at zelea.com> wrote:
>>
>> What integration problem are you trying to solve?  It's difficult to
>> visualize, at first glance, where a DSL might fit for that purpose.
>
> Let's separate two things out. A vision of distributed LD for general open
> political emergent debate, and deployments for a particular group, or
> application area. We could call these vertical and horizontal markets for
> short. I'm interested in the former, but see it a a better strategy to
> bootstrap this on the latter.
>
> If we think therefore of getting a good quality trial up in a vertical
> market, where we get a sponsor to pay for things like consultation, user
> support, face-to-face meetings, and graphic design / UX work. In this
> scenario, we can look at Votorolla as a Java based backend for LD that can
> sit on a single server.
>
> The integration I have in mind is therefore to integrate Votorolla as a Java
> project, with OCO as a Ruby on Rails project (which at the moment has simple
> voting), and another Java project which has a good backend for secure
> digital currencies. The richest, and most elegant way to integrate these
> three things I feel would be to wrap each in a higher level DSL written in
> Groovy, with the aim of making it simpler to write custom organisational
> structures.
>
>>
>> The larger system is physically distributed across a network of
>> independent hosts, including many pollservers and codebases (not all
>> Votorola) and multiple host/component types (not all pollservers).
>> That's too loose of a configuration for a DSL to come to grips with,
>> isn't it?  Ad hoc network protocols are probably the best glue for
>> that purpose, at least in the beginning, when we're still prototyping
>> and experimenting.
>
> At this stage I am taking a careful look, the base decision is to use web
> services as you indicate, however it does seem that it is difficult to
> really get this going for a number of soft reasons.
>
> Each of the projects likes the idea of web services, but as it is never a
> priority, they don't really get round to implementing them or supporting
> them fully. There is always another feature of bug to fix in their code
> base. The centres of gravity in each project pull them apart, and people
> like me trying to integrate these tools around practical projects which need
> custom front ends created find it increasingly difficult to pull the pieces
> together.
>
> The other approach is to fork each of the code bases and bring them together
> on a single server. However then you are faced with the problem of
> maintaining the overall integration, and you end up with these big CMS type
> projects, which is a no-no.
>
> My latest thinking on this problem is that it may be easier to achieve a
> productive integration in the area of DSL's and the JVM. My guess, and that
> is all it is at this stage, is that this area is technically good enough
> (speed, robustness, unerlying concepts), socially integrative enough
> (programmers from different languages will be able to get involved), and
> cool enough to attract good developers to the project.
>
> As a practical example - I am not going to learn Java, to get involved in
> coding Votorolla, but I would learn Groovy, and it looks easy enough and
> interesting enough for me to be able to wrap existing Votorolla Java classes
> in a DSL which I can start using in projects. The same goes for other
> projects, and if that applies to me, it will apply to a Ruby programmer, or
> a Python programmer.
>
> 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. The added benefits of
> being able to work in the same technical domian as the digital currency and
> legal projects I've spoke of are just a bonus.