Prototyping the infrastructure and UI together

[Michael Allan]

David Bovill wrote:
> ... I think it would be a good idea to set aside a day, where we go
> through and document things together? Some of us can ask stupid
> questions and you can talk us through it?

Yes definitely.  Please just read as far as you can, and I'll answer
your questions.  Apologies it's all so rough.

> ... I can't find a link to free-range drafting ...

See drafting media in section I:
http://zelea.com/project/autonomy/content.xht

Free-range drafting is not well documented.  The user will be able to
choose his own drafting medium.  MediaWiki is the default.

> > most of the other functions [of the pollwiki] cannot
> > be freed in that manner.
> 
> Could you list these main functions and what application /
> programming language they are implemented in?

  * Poll identification and definition
  * Defining electoral districts and other polling divisions
  * Voter registration (streetwiki only)
  * Trust signing (streetwiki only)
  * Indexing of poll positions by mailish username
  * Provision of default drafting medium, e.g. for position statements
  * Pollwiki hosting (in case of multi-area pollwiki)

All implemented in MediaWiki wikitext, with semantic extensions.
(MediaWiki itself is PHP, ofc.)

> >  http://zelea.com/project/edo/overview-state.png
> 
> I see the diagram - but I stare at it blankly :) Identifying a poll
> is done how, and where? ...

You've clearly not used the software.  (Man are you in for a
dissappointment. :-) A poll is (as you guessed) identified by its URL:
http://u.zelea.com/w/Tor/p/grfin

See voting media in section I:
http://zelea.com/project/autonomy/content.xht

> But I don't see why it is not separated out, or easy to separate out
> as functionality discrete to the pollserver?

There is no single pollserver, there are any number of multiple
pollservers of different designs.  Poll identification *is* therefore
factored out into a separate facility, the pollwiki.

See the classification engine = poll-classifier wiki (C) here.  It's
since been absorbed (along with much else) into the pollwiki:
http://u.zelea.com/w/User:Mike-ZeleaCom/Opening_an_architecture

That's an old working document, but it's correct in spirit.

> First to backtrack - we have the following applications indicated:
> 
>    1. Pollwiki = a semantic mediawiki? = serves to integrate polls between
>    streetwiki?

It serves functions as listed above.

>    2. Pollserver - a Java application - uses what frameworks - what
>    dependencies - installation requirements?

Stores and counts votes.  There are many pollservers per pollwiki
(although just V currently), and they can be coded as the designers
please.

We are mirroring some NationBuilder votes, but Jim Gilliam doesn't
know, so I guess it doesn't count as a bona-fide pollserver yet.

>    3. Streetwiki = a local semantic mediawiki - uses which mediawiki
>    extensions - is there a votoralla extension?

It's just a wiki.  It's the local residential voter registry (like for
a city), and is usually deployed in combo with the local pollwiki,
both as a single wiki.

>    4. Trust Server = not done yet? - or uses some existing software?

All of the above are prototyped and running, except the UI of the
streetwiki (street layouts, and so forth).

> Is there a list of pollwiki functions? I think it would be good to
> describe this in terms of basic MVC like components, perhaps with
> additional "service layers" for the core logic for voting etc?

Again, as listed above.  No actual voting services in a pollwiki, only
in a pollserver.  The implementation details of the services are not
important at this stage (alpha prototyping = little better than
hacking) and anything that works is OK, in my books.

But the architectural *design* has to be solid, that's the crucial
thing, I think.

> > If you wanted to re-implement it in Drupal, say - instead of
> > merely interfacing to it or wrapping it ...
> 

> I'm not sure what you mean by interfacing or wrapping? What I'd
> guess most developers would want is a nice set of Restful web
> services so that they could roll their own plugins for Drupal,
> WordPress and so forth. This too me would be a very important
> starting point to grow this software project, and I think it would
> help all of us if we could get a clear working definition of these
> services - which of course will be subject to change etc.
> 
> I would have thought that you had interfaced with MediaWiki by
> creating a Mediawiki extension? What I do not understand is what the
> major difference in doing this is with any other plugin, or why you
> would want or need to be relying on functionalities specific to
> MediaWiki?

Like if you wanted to shield your users from MediaWiki for the
function of poll identification, you could do it by wrapping (building
a shell interface).  So for the specific function of creating a poll,
you could offer this wrapper UI:

   Poll name: ________________________    [Create poll]

Your user inputs the poll name, then presses 'Create poll'.  The
wrapper calls the MediaWiki editing API in order to create the poll
page.  The new poll is now defined, and the user was never exposed to
MediaWiki, only to the wrapper.  That's wrapping.

> > - then you'd need to do so in the common infrastructure that
> > everyone uses.  We'd all have to retool for Drupal instead of
> > Semantic MediaWiki.
> 
> I just can't see this? If this is the case then surely we need to
> rethink the structural separation into services that fit more
> naturally into the way people use social media. People will want to
> use their own frameworks and there is no reason why we cant
> structure things to give them that? Or is there? I find it hard to
> think it is even possible not to structure this in a way in which we
> have a platform serving a range of plugins for WordPress, Drupal,
> mediaWiki, OpenSocial, FaceBook and mobile devices.

All those are served.  The UI layer is invisible to the
infrastructure, meaning that anything can be placed there.  Nothing
sees into that layer, so nothing has dependencies on it.

It's like Web browsers (UI layer) are invisible to the Web
infrastructure, so anything goes in terms of what language/platform
you can code your browser in, and what it looks like, when it's on and
off, how many of them are floating out there, at any one time, whether
they even work or not, and so on.

> Sorry for all these basic questions, but there seems to be a
> mysterious gap between the theory, and the code that a bit of
> straight talking clarification will unlock?

I'm always free.  (Why can't I see you on Skype anymore?  I'm
michael_c_allan.)  But please keep reading as far as you can, and
again, apologies that it's all so rough and scattered.

-- 
Michael Allan

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