Prototyping the infrastructure and UI together

[David Bovill]

I got a bit lost I'm afraid. 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?

On 16 October 2010 09:21, Michael Allan <mike at zelea.com> wrote:

>
> I'm sure you can build whatever you need.  I know you're unhappy with
> MediaWiki for the pollwiki, so I'll just underline what's involved in
> replacing it.  Although position drafting can be lifted outside of the
> pollwiki and freed from MediaWiki (by free-range drafting) without
> raising any architectural problems,


OK - by this I assume (I can't find a link to free-range drafting), there is
a rudimentary API for posting a text of some form - what form? - wiki markup
? And therefore if you wanted you could "draft" a "position" in another
platform relatively easily. But I'm still in the dark as to what is meant.


> most of the other functions cannot
> be freed in that manner.


Could you list these main functions and what application / programming
language they are implemented in? The diagrams are nice but they need some
basic explanation of what the different lines and icons mean. It has been
nearly 10 years since I used UML diagrams and there ilk - so I need some
help :)


> The function of poll identification (for
> example) cannot be separated from the infrastructure where it is
> currently attached to the pollwiki without breaking the architecture.
> The reason is shown in this diagram, at the service interface labeled
> "issue posting" (which means "poll identification"):
>
>  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? By a url? A hash? A signature? I would have guessed that a
url and sha1 hash of the document would be a starting point, though I'd also
think t was important to actually backup the document in a repository as
well?

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

First to backtrack - we have the following applications indicated:

   1. Pollwiki = a semantic mediawiki? = serves to integrate polls between
   streetwiki?
   2. Pollserver - a Java application - uses what frameworks - what
   dependencies - installation requirements?
   3. Streetwiki = a local semantic mediawiki - uses which mediawiki
   extensions - is there a votoralla extension?
   4. Trust Server = not done yet? - or uses some existing software?

So you couldn't lift that particular function (or most of the other
> pollwiki functions) into the UI layer.


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?


> 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?


> - 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.

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?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.reluk.ca/list/votorola/attachments/20101016/1f5d650f/attachment-0007.html>