[Demexp-dev] Current status on demexp development & issues on delegation

[David MENTRE]

Hello,

In current demexp development, we have a server and a basic text
client. Both of them seem to run, however I am not so sure that the
server is reliable (of course, I have tested each module. But a test is
not a proof. And module integration adds its own layer of complexity).

To increase the level of confidence into the server, I started to design
routines to save and restore bases to/from XML files. However, in order
to do that properly, I realized I needed to check invariants on demexp
bases (aka data structures). So I'm currently writing code to do that.

Now, doing that, I realized that I'm not so satisfied with current
code. The most biggest issue for me in the current delegation system:

 - I find the code difficult to read (despite it is my own code!) and
   the data structures are unnecessarily redundant;

 - I don't like the current design when a newly added sub-category to a
   delegated category is not taken into account in the delegation (fred
   would say it is logical, but I don't find it natural);

 - I don't know how to save the delegation in XML in a readable manner;

 - I would like to have a more clear view of vote recomputation (what is
   strictly necessary to recompute) when a delegation is added or
   removed;

 - I think we will have big issues to add anonymous delegation to
   current system. For example, how to cancel votes of an anonymous
   delegator? 

In short, I don't like current algorithms and code in the delegation
subsystem.

I'm probably in a bad mood today, but I feel the necessity to refactor
current delegation code. The questions are: to what extent and when?

Because we have another big issue, on the client side. We absolutely
need a graphical client and this will take time and knowledge. The
system will be (partially) judged on its client.

And last but not least, without even considering security requirements,
we need to define a minimal access control system on the server for
management reasons.

While I'm at complaining, I also think we should think about the process
used to handle new questions/new voters/question classification in the
immediate and ideal demexp system.

I feel the need to get some help from other people. Even if those people
can't code, having advices on algorithm design and requirement writing
would be necessary.  Taking decisions alone is not very good, and even
more bad when resulting code is at the heart of our system.

Of course, we could try to make a working system quickly. But as a free
software developer, I feel the need to make the code the most elegant
and safe we can do, even at the expense of delaying our first stable
release.  People will rely on demexp code only if they can read it and
are confident in it.

Fred and Félix, would it be possible to plan a
planning/requirements/algorithms/development session in the following
days/weeks? If possible, I would like to have time to discuss issues
(i.e. do that a saturday or sunday afternoon). If it is not possible due
to your personal agenda, then we can do that one evening.


If people on this list have advices on ways to handle such refactoring
vs. availability issues, I'll gladly accept them.


Yours,
d.
-- 
 David Mentré <address@hidden>