[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Demexp-dev] Current status of development

From: Lionel Eyraud
Subject: Re: [Demexp-dev] Current status of development
Date: Tue, 21 Feb 2006 11:47:10 +0100


> Right now, solution 2/ seems the most seducing to me. However we need
> to find a solution for the privacy issues. Maybe a set of RPC to load
> and unload statuses, and to activate/deactivate status tracking on the
> server?

Solution 2/ does indeed simplify things. But I am mainly concerned
about scalability issues : storing more and more information on the
server will inevitably lead to problems if you ever have a high number
of users. Maybe it's not your main concern yet ;)

But I think I would like an architecture where the main subject of
demexp (voting) is separated from the cosmetic aspects and the history
of each user. We could imagine several "history" servers, that are
either proxies for the user and vote in their place to the central
demexp server, or serve as a complementary service while the user still
votes directly to the central server. I think I like best this last

In the very long term, I think you might need to have a
hierarchical structure of demexp servers, that collect votes from a
number of users and reports them to a central server. I know you do not
think about that yet, but  I think it is a good thing to keep it in

Additionally, after having looked at the code of the server, I have the
feeling that it keeps all information of all questions, votes,
participants, ... in memory while it is up, saves this information in
an XML file each time it is changed, and never reads it back...
(correct me if I'm wrong :)). Still with scalability in mind, I am not
sure that this approach will support a reaonably large number of
participants/questions. I think only data about current or recently
accessed objects should be kept in memory; and I also think that the
data should be stored in a way that allows to read only a part of it.
Personnally, I would recommend using a database system, since that's
what they're designed for -- efficiently storing large data.

Of course, this is my own opinion, and since you know this project much
better that I do, feel free to disagree :)

Yours truly,
Lionel Eyraud-Dubois.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]