Hello Felix, 2006/2/20, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: > The statuses are stored on the server.
Partially: the server knows about voted questions (in each question) but has no knowledge of seen questions (except, indirectly, through RPC calls). Currently, the server has no explicit knowledge of seen and voted questions. > When the web client is used, we should > first decided whether we want to > 1/update the statuses on the client (and make some kind of synchronization > during disconnection) or > 2/update them on the server, on the fly. You forgot the third option I was thinking at: 3/ store seen and voted question on the web interface (proxy between the web client and the demexp server) > If we choose 1/, a file-based solution is probably preferable but I do not > know if it's even possible (to manipulate a file from the web client). It should be possible to locally store some information (through XML files with Javascript). But that makes Javascript mandatory. I did not thought about that, I'll try to look at it. > If we chose 2/, both options are possible. I'd still think that a file > based solution would be preferable. After all, AFAIK, the file would only > contain the id of the tag or question, and the status. It may be a bit > to heavy to get into SQL stuff for that. Yes, the server could keep track of seen and voted question. If this solution is kept, that should be an option so that people deciding to use the GTK client would not have personnal information on the server. In that case, the stored data would be kept in an XML file, with the other data. So we have three approaches to consider. Plus and minus points: - 1/ makes Javascript mandatory on the client; - 3/ makes the architecture quite complicated (information is stored within the web proxy); - 2/ implies that the server should store personal information. However, 2/ simplifies the code and requirements of the web proxy and it make synchronization much easier if a Participant wants to use simultaneously the web proxy and the GTK client[1]. 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? Best wishes, d. [1] think GTK client at home, and web proxy on holidays. _______________________________________________ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev