Mini-pollwiki and architecture

[Michael Allan]

Hi Alex,

Last time we spoke of this, the architecture lacked a documentary
overview, which I think led to misunderstandings.  Sorry for that.  We
now have an overview.  See the left-hand links for defs, specs and
impls: http://zelea.com/project/votorola/d/architecture.xht

Crossforum theatre is one of the blue planes floating at top.  The
Votorola vote-server is one of the blue cylinders labeled "V".  They
are optional and needn't be present.

The architecture is open and interconnected by web APIs.  If an API is
missing or inadequate, then we can fix it, no problem.  The pollwiki
APIs are complete, however, and Votorola has no special access to the
pollwiki's data.  (The pollwiki is primarily a shared database and
naming system, and is the only mandatory component in the
architecture.)

If what you're doing involves people reaching agreements, then our
stuff can definitly be made to work together.  There are no immediate
design requirements on your part.  It doesn't matter what platform you
code on (Drupal is fine), and you can code anything you like.  It will
help if you identify your users by email address, but that's optional.
You needn't even recognize the centrality of the pollwiki if you don't
wish to.  Although it's central to *this* architecture, we can always
cross-link with competing architectures.  We have complete flexibility
in that regard.

If you share a design sketch, then I can help in pointing out the
necessary interfaces.

Mike


Alex Rollin wrote:
> 
> Mike and all,
> 
> I think attempting a focus on a 20 (smallworld) user groups is a great  
> idea.
> 
> This was also the imagined size of my test case, P2P Housing, that I  
> setup and tested on the pollwiki.
> 
> It seems to me that you are now working to abstract the entire  
> pollwiki interface for small groups.
> 
> I think this is a laudable goal: yay!
> 
> It seems to me that the project has gone a long way around back to a  
> central issue:
> 
> The centrality of the pollwiki and then the interface with the  
> pollserver.
> 
> Here's my stab at what the pollwiki does:
> 
> User logins
> User "grouping"
> Drafting
> Rectification of login with draft
> Rectification of login with pollserver
> Data exchange with pollserver
> 
> It seems to me that these are the basic functions of any "pollwiki".   
> What am I
> Missing?
> 
> What I am wondering is, why not just make the pollserver work better  
> with services and thereby define a general set of requirements for a  
> pollwiki type app.  Call it an API for front end apps like the  
> pollwiki.  It seems this is getting jumped over with a project to  
> abstract the cross-forum.
> 
> I still just want to be able to build a Drupal based app that talks  
> directly to the pollserver and other votorola services servers,  
> replacing any need for me to deal with the pollwiki and pollwiki  
> related issues.
> 
> I want to
> Register and group my own users in my own app
> Draft my own petitions in my own app
> Submit draft urls to the pollserver
> Submit login approve/deny/grouping information to the pollserver or  
> other utilities
> 
> I tried very hard to push this forward before.  I am quite capable of  
> building such an app on my own.  I just needed to know where to push  
> the data.  The answer I kept getting was that I had to go through the  
> pollwiki.  Then and now this added to much complexity.
> 
> What I understand now (and surely I am wrong in some ways and not  
> using the correct language) is that you are planning to build yet  
> another customized front end, and that you, the core deceloper, will  
> be able to make it , the new app, talk to the pollwiki but I won't.  I  
> can't simply clone out that function and rebuild it in my own tools  
> because you are building a special case that will again talk to or  
> through the pollwiki or other tools that don't yet have a clear API.
> 
> My request:
> 
> Let the end users build their own front end.  Focus on the spec for  
> how that can work and call it an API.  Build an API for all the  
> servers you are running.
> 
> We out here with communities with build front ends to meet the needs  
> of our communities.  Please help us by making yoir APIs useable.
> 
> We, the user communities, want:
> 
> Global login IDs that are federated
> Our own access control lists
> Our own front end
> Our user user management tools
> Our own vote tally algorithms thay access our own voter access lists
> Global vote mirroring services (anyone can vote but not all votes are  
> tallied)
> Access to render vote trees filtered for access lists
> 
> These are simple things and no doubt yoi will be using these functiobs  
> in te cross forum interface.  What I see is that this group could be  
> organized in some way as a consensus group that votes and resources  
> API services.  Instead I see a group trying to build attractive user  
> interfaces to lure alpha testers when there is no services API.
> 
> Alex