Re: [Demexp-dev] And now, what for demexp--dev--0.7?

[David MENTRE]

Hello John,

skaller <address@hidden> writes:

> It is not as bad as you think. Do not assume 'newbie' users
> are dumb people :)

Yes, but as I don't specially find the current interface particularly
user friendly and as I am the main developer of it, I assume that a new
user would be lost in front of it. A good UI doesn't need a user manual.

> I would also love to say "Hey, can you install a server 
> for my project please" to another friend -- he has access
> to a machine that can be used as a host (i.e. he can
> configure it to allow a server to run on various ports).

Installing a server is not that difficult (but the binary somewhere and
launch it). It is just that I never had time to write a doc.

> [me :]
>>  - At one point, I considered implementing a Firefox plugin for demexp,
>>    but as I would like to keep the RPC protocol between client and
>>    server, it would make a complicated plugin (XPCOM component, biding
>>    between C++ and OCaml) or would be a Javascript nightmare. And the
>>    task of installing a plugin would lost us users;
>> 
>>  - Another approach would be to implement a module on the server side
>>    that makes the link between the web server and the demexp server;
>> 
>>  - The last approach would be to implement an HTTP server into the
>>    current demexp server.
>
> Why?? What's wrong with a CGI script which acts as the client
> and talks to the server? Why do you need to implement a whole
> HTTP server when you can just plug into Apache or some other
> server?

In fact, I underlined that I'm in favor of the 2nd approach, which is
the CGI one (this is what I called "implement a module on the server
side..."). 

> Surely all you need is that the CGI process has permission
> to connect to the real demexp server?

Yep.

> To maintain session state, php may be the way to go,
> since most web sites have Apache with php_mod installed:
> this is better than CGI.

I'm not fond of PHP, despite I recognize it is quite easy to develop web
apps with it. However, as underlined in a parallel post, I'm in favor of
WDialog, mainly because it is written in OCaml and is intendeed to be
programmed in OCaml.

> The downside of the server side demexp interface is:
>
> * loss of security -- may not matter for some applications

Anyway, we don't have much security right now. We won't lose
anything. :) 

> * loss of sophisticated navigation techniques

That was the main reason behind using an autonomous client. However we
have failed to build sophisticated navigation techniques until now.

> but what you gain is a half a billion potential clients,
> without having to distribute ANYTHING to them: everyone
> everywhere with web access can 'just vote, right now'.

Yes, exactly.

> Maintaining state isn't hard (use cookies as a session key)
> but accounting for server load, denial of service attacks,
> and other security issues may not be so easy: it requires
> real world experience .. so I'd be looking to see how
> php does it, simply because it the most widely used system.

WDialog has some facilities that seem interesting:
 Session management and security
  http://wdialog.sourceforge.net/manual/page-26.html

> The way delegation should work is this: a proxy *offers* to
> vote a certain way on certain kinds of issues for anyone
> that registers with them. A voter can then *subscribe*
> to their platform. This permits that proxy to vote for
> the client.

This is an option. The other option is to let the client informs the
server of the user delegations and the server takes care of updating
vote counts accordingly. We are currently in favor of the second one. 

> What are the Concordant rules on this?

AFAIK, description of Cordorcet voting never speak about delegation.

Yours,
d.
-- 
pub  1024D/A3AD7A2A 2004-10-03 David MENTRE <address@hidden>
 5996 CC46 4612 9CA4 3562  D7AC 6C67 9E96 A3AD 7A2A