Domain specific language (DSL)

[Alex Rollin]

I just had a nice Skype call with Mike.  We talked about what a DSL is
and what architecture documents are.

Tthe purpose to which I am oriented is building an app that allow me
to do quite a bit of what the Pollwiki does currently while still
authenticating and tabulating votes on the pollserver and associated
systems.  The app is fitted to the needs of a group of organizations
that share some voting lists in some cases.

Mike is of the opinion that I need architecture documents.

Mike says there are a few documents already available that contain
important information relevant to this project.

In addition, I heard mention of "vote mirroring" and "draft medium
agnosticism" and I hope these will be placed into context in this list
as I understand more about how these equate to requirements for the
app I'd like to build.

I mentioned that I am specifically interested in a set of "mandatory
minimums" that would allow me to bypass the pollwiki, for the most
part, and still preserve and align with the open architecture model
that is so central to the project.

We talked about discussing architecture on the list first, and then at
some point placing additional documentation somewhere else so that
others who are building apps that talk to the Votorola system, with or
without pollwiki, could see what was needed within their app to
communicate with Votorola and respect the direction of the project.

Mike added a healthy layer of caution in our discussion.  To
paraphrase, probably poorly, I heard that all apps in this "wrapper"
category should be considered permanent alpha subject to changes
within Votorola itself, and that architecture changes that effect the
functioning of such apps would be discussed in detail.

Alex


On Fri, Oct 15, 2010 at 2:04 PM, David Bovill <david at vaudevillecourt.tv> wrote:
> On 15 October 2010 10:50, Michael Allan <mike at zelea.com> wrote:
>>
>> 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).
>
> The first thing to do will be to get it up and running on the server. I'd
> also like to get it running on my laptop - but that is less important. Can
> we organise an online coding session next week, where I can introduce you to
> some coders who may be interested in getting involved - that way you could
> talk us through the way things are structures and any installation issues?
>
>> 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'd have to disagree. If we want these people, a project manager and/or
> coder, then all that is needed is to go out and find one actively. It is not
> an issue of technical complexity or the volatility of code, it is a lack of
> a desire / prioritizing the social aspects of team work in terms of coding.
> I hope we can emphasise this now. I did try before, but we reached an
> impasse as i was unable to fund-raise for a project based on a sole
> programmer who would not commit to being a part of an interdisciplinary
> formal team. Funders and project managers cannot commit to a project when it
> is not clear who will actually do the work. As at the time I did not know
> any available and committed Java coders, it was not possible for me to
> actively support the project with my time and energy. This is a classic
> issue and no ones fault - it's just part of the system we live in. We simply
> don't have the tools yet to make these sorts of interdisciplinary
> collaborations possible (or at least not without a great deal of
> interpersonal difficulty).
>
> I think we have a chance now to give this a second go. This is partly
> because I have the possibility to work with a group of developers, and I can
> see how to do this in a practical way which is complementary with the bread
> and butter things I have to do to keep afloat. It is also because I am
> genuinely interested in exploring the new technical field of Domain Specific
> Languages and  Language Oriented Programming. There is no way I would learn
> Java, but I have decided to learn Groovy, which is a modern dynamic language
> built on top of the JVM, and works much more the way I like to code.
> Importantly it is ideally suited to the creation of DSL's and this is
> particularly suited to a methodology of working with stakeholders in the
> design of the language. In short it all seems to come together for me at the
> moment, technically, socially and philosophically - but most importantly
> practically.
>
> Of course many of these things are at the moment slightly out of my depth,
> and I am not sure about this strategy, but the only way to find out, is to
> be open about it, and ask for advise - to roll up my sleeves and get my
> hands dirty. I think we already have a relatively firm theoretical and
> technical underpinning. We have next to nothing on interface or community
> participation work, and we don't have an active open source project with
> multiple contributors. Thats what working together, I hope we can provide to
> Michael in terms of support  - whether he wants it or not :)