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

[skaller]

On Fri, 2005-08-05 at 23:49 +0200, David MENTRE wrote:
> Hello,
> 
> Now that stable 0.6 is out, we can focus on next development version
> 0.7.
> 
> Currently, I plan following items for next stable 0.8:
> 
>  - implement delegation *in the server*, i.e. all the server and network
>    code, without user related code;
> 
>  - internationalisation and localisation, if the wanabee demexp hacker
>    wakes up. ;)

Lol .. I'm a wanabee  .. but I really need to just download
client and server sources and have the build
work 'out of the box'.

A GODI package for this might help, at least that will
reliably fetch the Ocaml dependencies.

> 
> Now, there is also a hard point that I would like to improve for 0.8:
> the client.
> 
> I'm *very* unsatisfied with the current client[1]: I think the user
> interface is pretty complicated (i.e. bad) 

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

> and, more importantly, it is
> difficult for newcomers to "be into the loop", i.e. install the client
> and use it. Even core project members have issues to setup the
> client[2].

yes, this is more of a problem. I have some friends who
I would love to tell "Hey, do 'apt-get install demexp-client' and
tell me what you think!"

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

If both these 'ease of use' conditions were met,
I'd actually install the system right now to help
manage some of my software project. Just brain dead
questions like "What OS are you installing on" 
for a start, but there are issues where people talk
about things and make noise on mailing lists, 
(like me, hehe) but it would be nice to actually
see a proper survey of opinion, since the results
might not agree with impressions gained from discussions.

I know that the GHC people have recently done a survey,
and found some of the results a bit surprising, and are
using those results to prioritise work on their product.

It is a major effort to conduct such a survey, hard to know
how good the results are, and hard to analyse the results.
With Demexp, the amount of work would be reduced enormously,
making 'grass roots' participation in the project much easier.

> So, once again, I'm considering a way to have a web interface to
> demexp. 

Yes. However my experience is: to really judge user interaction,
you need users!!

Making it possible to install the client and server easily
on various systems is probably harder and more important
than improving the client: provided the client implements
the protocols correctly, the 'casual' user is probably
prepared to do a bit more work navigating in order to
participate in a 'democratic experience' than you might think.
And you really need those people to do so, and to comment.

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

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

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.

The downside of the server side demexp interface is:

* loss of security -- may not matter for some applications
* loss of sophisticated navigation techniques

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

> I'm in favor of the second approach, that still forces us to keep the
> RPC protocol and separate the server issues from client issues. Now, how
> to proceed? OCaml code for writing web server side code exists (Gerd
> Stolpmann's libraries come to mind). The main issue is to implement a
> statefull demexp binding with HTTP stateless protocol. I don't know if
> it is easy or not. 

Php does this automagically .. that's probably why it
is so popular.

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.

> Having fancy graphics is
>    important for users... and developers ;-) ;

Yes, but importance and development order may not be the same.

>  - to implement user side delegation (no idea how to do that, we need to
>    think about it).

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.

What are the Concordant rules on this?

-- 
John Skaller <skaller at users dot sourceforge dot net>

signature.asc
Description: This is a digitally signed message part