Re: Fwd: timestamps and cookies (Re: [Demexp-dev] First XML RPC proxy available

[David MENTRE]

Augustin <address@hidden> writes:

> David, another solution to the cookie/goodbye problem I explained below, is 
> to 
> call login at the beginning of a page load, and call goodbye() at the end of 
> the page load. I like this solution much less because:

In fact I was think at this approach. ;-)

> 1) in increases the number of calls to the server, 

Yes.

> 2) increases the time to build a whole page because of the latency of the xml 
> call.

Yes.

But your not forced to do a login()/goodbye() for each RPC call. In
fact, for calls not related to an individual, e.g. question_info() or
max_question_id(), you can use zero as cookie without any
login()/goodbye().

I can provide a list of such calls if needed (I need to look at server
code). 

> 3) I need to store the user's demexp password on the website (DB though I 
> could also put it in $_SESSION[]).

I'm new to Drupal, to which extent lives $_SESSION[]? Any documentation
pointer on it?

> So, all in all, it's difficult to completely avoid login() without goodbye() 
> altogether.

Well, right now it pollutes the server. I have to setup a cleanup
process for such remaining cookies on the server.

> I have a question already: I have read in your pdf and in the list archives
> the definition of your timestamp.
> I saw that some timestamp == 0
> is it for those questions that have never been updated since their
> creation?

Yes and...

> Don't you store the timestamp of the date of creation?

... yes we do store timestamp at question creation (I just checked). But
those questions with 0 timestamp where created and never updated since
the addition of the timestamp mechanism. :-)

> I am asking because I'm thinking to have all questions sorted somewhere by
> date of last update, but if all recently created questions have a timestamp
> of 0, I cannot use your timestamp for this purpose, and I need to create my
> own timestamp.

No, you can sort them by timestamp, the bigger the timestamp the fresher
the question.

> Also, about session cookies. I plan to have a login valid for the duration of
> an http session.

What do you call exactly an HTTP session? Do you mean the duration where
the user is authentified on the Drupal side?

>>  To close the current connection opened with login(). It is *strongly*
>>  recommended to do a goodbye() for each login().
>
> I cannot know when the user will stop using the web site, so I have to store
> the cookie somewhere so that I can call goodbye either just before the next
> session starts, or using cron and cleaning the sessions of users who have
> been innactive for an hour or more...
>
> Hmmm... This forces me to store the cookie in two places. One, in the
> $_SESSION['demexp_cookie'] variable: this value is definitively lost at the
> end of the user's http session. Since I don't know how long the user is going
> to browse the site, I don't get a chance to call goodbye.
> So, I need to store the cookie in a second more permanent place (in the DB),
> and check it against the $_SESSION cookie. If it matches, we are in the same
> session. If not, I call goodbye() using the stored cookie, and ask the user
> to login again onto the demexp server for the duration of the new http
> session.

This second approach seems also nice to me, even if it might complicates
your code. It might be even better that the systematic login()/goodbye()
at the beginning of this email.


> But, I have no way to know whether the same user has tried to login again
> using a hard client before I got a chance to say goodbye(): Imagine the
> scenario of a user wanting to compare the web client and the hard client. He
> logs in through the web client and just after that logs in with the client.
> This way, the user may have two different cookies at the same time (or would
> the first cookie delivered be automatically be invalidated when the second is
> served)

The user would have two cookies, one for the hard client and one for the
web client.

> Would that be a problem for you? I cannot prevent that.

Yes and right now there is no way for the web client to know the exact
state of the hard client. For example, the hard client stores number of
seen and voted questions in a local file. To make the web client really
usable, I need to provide API for you to synchronize with hard client
state, but I haven't done that work yet.

Let's start slowly, release early and often and add new features in an
incremental way.

Best wishes,
d.
-- 
GPG/PGP key: A3AD7A2A David MENTRE <address@hidden>
 5996 CC46 4612 9CA4 3562  D7AC 6C67 9E96 A3AD 7A2A