headers
David MENTRE | 3 Jun 2005 23:28
Favicon

some thinking on the client: how to improve its usability and attract programmers

Hello,

I'm thinking at the different ways to improve the current client. Here
are some ideas I have, in no particular order.

 - programming language: Python vs. OCaml

   Since Thomas has made the RPC mechanism available in Python, it is
   now conceivable to write some user interface in Python, using
   e.g. PyGTK. Python is much more known than OCaml. Of course, all
   current code is in OCaml, so it would need a rewrite in
   Python. Should we invest time in a Python client?

 - modularity of client.

   The current client is one big binary, with several windows but no
   real links between those windows. The user might be easily lost in
   it. I'm thinking at making several binaries, one for each task
   (vote, browse database, classification). Those graphical programs
   would be callable from shell scripts, other programming languages,
   etc. 

   Another less extrem approach would be to keep the same single demexp
   client but add options like --browse or --vote to open directly the
   requested window, using a demexp URL
   (demexp://server:port/question/N);

   My main objective: I would like to write the necessary parts so that
   external developers could reuse them to make a more complex demexp
   client. For example, I can add options to given informations in
(Continue reading)

Permalink | Reply | 3 comments |
headers
David MENTRE | 4 Jun 2005 21:42
Favicon

Re: [PATCH] Compatibility with CDuce 0.3

Thomas Petazzoni <thomas.petazzoni <at> enix.org> writes:

> As previously reported by Thomas de Grenier de Latour on this
> mailing-list, the CDuce language changed between 0.2 and 0.3. The old {|
> and |} are now replaced by simple { and }.
>
> The attached patch fixes the problem. (Note: the included patch is a
> Debian patch. It can be applied by simply removing the first few lines).

Patch applied... oh well, not exactly, it failed, probably because I
have modified the file (your patch is for 0.4, right?).

No I have a compile error with:
No implementations provided for the following modules:
  Expat referenced from /usr/lib/ocaml/3.08.3/cduce/cduce_lib.cmxa(Cduce_lib)
  Curl referenced from /usr/lib/ocaml/3.08.3/cduce/cduce_lib.cmxa(Cduce_lib)

I suppose this is because you have compiled CDuce with expat and curl
instead of netclient and pxp.

You told me once that you had a patch that fixed this issue once and for
all. Could you sent it to me?

Sincerely yours,
d.
--

-- 
pub  1024D/A3AD7A2A 2004-10-03 David MENTRE <dmentre <at> linux-france.org>
 5996 CC46 4612 9CA4 3562  D7AC 6C67 9E96 A3AD 7A2A
(Continue reading)

Permalink | Reply | 0 comments |
headers
David MENTRE | 4 Jun 2005 21:44
Favicon

Re: XDR file compilation issue

Thomas Petazzoni <thomas.petazzoni <at> enix.org> writes:

>> The attached dpatch fixes the problem. The XDR file still compiles
>> with ocamlrpcgen, and DemExp still compiles with it. And my RPC
>> Generator also compiles it ! ;-)

Patch applied.

Yours,
d.
--

-- 
pub  1024D/A3AD7A2A 2004-10-03 David MENTRE <dmentre <at> linux-france.org>
 5996 CC46 4612 9CA4 3562  D7AC 6C67 9E96 A3AD 7A2A
Permalink | Reply | 0 comments |
headers
David MENTRE | 5 Jun 2005 12:24
Favicon

Proper way to send patches to me

Hello,

I you send patches to me, could you please include them as _attachement_
(and not _inline_ attachement in the email) or directly in the body of
the email (if you email reader don't cut long lines). I have a issue
with my current email reader (Gnus) where I cannot save inline attached
text file in a separate file. The issue is probably between the keyboard
and the chair. ;)

Yours,
d.
--

-- 
pub  1024D/A3AD7A2A 2004-10-03 David MENTRE <dmentre <at> linux-france.org>
 5996 CC46 4612 9CA4 3562  D7AC 6C67 9E96 A3AD 7A2A
Permalink | Reply | 0 comments |
headers
felix.henry | 7 Jun 2005 18:46
Picon
Favicon

Re: some thinking on the client: how to improve its usability and attract programmers

Hi David, here are my thoughts about your proposals,

>
> - programming language: Python vs. OCaml
>
>   Since Thomas has made the RPC mechanism available in Python, it is
>   now conceivable to write some user interface in Python, using
>   e.g. PyGTK. Python is much more known than OCaml. Of course, all
>   current code is in OCaml, so it would need a rewrite in
>   Python. Should we invest time in a Python client?

This could be one approach but if we really want to attract people
I would rather see it the other way around: maybe we can first find some
people ready to invest time in demexp development and ask them what
they would like to use as language.

>
> - modularity of client.
>
>   The current client is one big binary, with several windows but no
>   real links between those windows. The user might be easily lost in
>   it. I'm thinking at making several binaries, one for each task
>   (vote, browse database, classification). Those graphical programs
>   would be callable from shell scripts, other programming languages,
>   etc.
>
>   Another less extrem approach would be to keep the same single demexp
>   client but add options like --browse or --vote to open directly the
>   requested window, using a demexp URL
>   (demexp://server:port/question/N);
(Continue reading)

Permalink | Reply | 2 comments |
headers
David MENTRE | 7 Jun 2005 19:34
Favicon

Re: some thinking on the client: how to improve its usability and attract programmers

felix.henry <at> free.fr writes:

> -Finding a large amount of money by "seducing" a rich person/institution
> and pay developpers (we have not really tried that yet)

As underline by Thomas Petazzoni on another list, even in that case this
won't help long term development because as soon as cash will dry, most
of paid developers will quit the project.

I'm afraid that despite all of our efforts (announces, call for
developers, first running release) we are stuck to have a usable
version, a user community then to maybe obtain a developer community.

Yours,
d.
--

-- 
pub  1024D/A3AD7A2A 2004-10-03 David MENTRE <dmentre <at> linux-france.org>
 5996 CC46 4612 9CA4 3562  D7AC 6C67 9E96 A3AD 7A2A
Permalink | Reply | 0 comments |
headers
David MENTRE | 7 Jun 2005 19:47
Favicon

Re: some thinking on the client: how to improve its usability and attract programmers

Hi Félix,

felix.henry <at> free.fr writes:

> I would rather see it the other way around: maybe we can first find some
> people ready to invest time in demexp development and ask them what
> they would like to use as language.

Yes, it would be wiser. Just show me an external demexp developer. ;)

> Here you are mentionning two different issues
>
> 1/ The 'single executable' may confuse the user because of the number of
> windows and options.
>
> 2/ There is an advantage for multiple executables (or the option approach)
> because external developper can call the programs in accordance with their
> needs.
>
> Concerning 1/, I'm not sure it's that confusing. Too me, at the moment, the
> most confusing thing is the impossibility to immediately view the status of
> each question:
> -old question on which I have voted
> -old question on which I have not voted
> -new question

Yes. Everybody is telling me that. :) 

> Concerning 2/, I agree with your approach, but if it requires a substantial
> amount of development time, one should probably check if there are some
(Continue reading)

Permalink | Reply | 0 comments |
headers
David MENTRE | 7 Jun 2005 21:54
Favicon

Which timestamp at each modification?

Hello,

For the caching mechanism, I will need to store a timestamp each time a
question is modified on the server. This timestamp is communicated to
the client, that uses it internally to determine if something has
changed since last time it connected.

I'm thinking of three way to store and communicate this timestamp:

 1. as a date in an ASCII string, e.g. 2005-06-07T12:00;

 2. as a 32 or 64 bits integer, incremented each time something is
    modified, e.g. 165778, 165779, 165780;

 3. as a float storing time since 00:00:00 GMT, Jan. 1, 1970, in
    seconds, as given by OCaml's gettimeofday[1].

Solution 1 seems overcomplicated to me. Solution 2 is quite efficient to
handle in CPU and size (on both the server and client side) but solution
3 provides the advantage to give an absolute time of last modification
that might be useful later. The main issue against solution 3 is that
comparison of floating point numbers is unprecise and vary from
processor to processor (i.e. strange bug might occur).

Any advice? Any other scheme I might have missed?

Yours,
d.

[1] http://caml.inria.fr/pub/docs/manual-ocaml/libref/Unix.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
David MENTRE | 7 Jun 2005 22:07
Favicon

Ok for not displaying author of questions?

Hello,

I can't remember if we have taken a decision on this point or not:
should I remove the display of author of each question or not in the
client (and of course underlying protocol)?

Personally, I would *not* display author of questions, as the important
act is to think on the question and not its author.

Your advice?

Yours,
d.

PS: for the record, the latest client no longer display author of
    _responses_.
--

-- 
pub  1024D/A3AD7A2A 2004-10-03 David MENTRE <dmentre <at> linux-france.org>
 5996 CC46 4612 9CA4 3562  D7AC 6C67 9E96 A3AD 7A2A
Permalink | Reply | 4 comments |
headers
Felix HENRY | 7 Jun 2005 22:36
Picon
Favicon

[Fwd: Re: Which timestamp at each modification?]
Picon Favicon
From: Felix HENRY <felix.henry <at> free.fr>
Subject: Re: [Demexp-dev] Which timestamp at each modification?
Date: 2005-06-07 20:35:32 GMT
David MENTRE a écrit :

>Hello,
>
>For the caching mechanism, I will need to store a timestamp each time a
>question is modified on the server. This timestamp is communicated to
>the client, that uses it internally to determine if something has
>changed since last time it connected.
>
>I'm thinking of three way to store and communicate this timestamp:
>
> 1. as a date in an ASCII string, e.g. 2005-06-07T12:00;
>
> 2. as a 32 or 64 bits integer, incremented each time something is
>    modified, e.g. 165778, 165779, 165780;
>
> 3. as a float storing time since 00:00:00 GMT, Jan. 1, 1970, in
>    seconds, as given by OCaml's gettimeofday[1].
(Continue reading)

Permalink | Reply | 602 comments |

Gmane