Getting user's time from web revlet?
jimaultwins at yahoo.com
Thu Jan 21 10:37:25 CST 2010
I agree that with On-Rev using irev scripts, the HTTP headers is a
However, the On-Rev server account features that we have now allow for
Rev CGI, which has the same header limitations, but stable code and
PHP which does have the full range of header access/control
and the blending of userPage.php calling cgi and irev scripts (plus
the cgi opening and using Rev stacks).
Remote servers can run both php and rev cgi, and call irev scripts to
process data and return info.
My plans are to continue using all these tools with the foundational
goal of writing code that will work well into the future. This means
mostly Rev cgi, with php, and very little irev scripting until we are
beyond beta. I am integrating assets located on several servers, so
reliability is crucial.
On Jan 21, 2010, at 8:14 AM, Andre Garzia wrote:
> I think the important part of this thread is that the browser does
> send time
> information in the form of an HTTP Date header which RevServer simply
> ignores. I want all the headers available, if we don't have all the
> then we'll loose some information such as ETag, if-modified-since
> and custom
> headers sent by some applications. It will me impossible to
> implement some
> features because the headers are not available
> On Thu, Jan 21, 2010 at 1:11 PM, Robert Brenstein <rjb at robelko.com>
>> On 21.01.10 at 21:56 +0900 Tim Selander apparently wrote:
>>> Hi Mark - yep, that is exactly what I want to do, but haven't
>>> figured out
>>> how yet. I have learned how to get the user's local time via
>>> don't know how to pass it to the revlet (actually, it seems I have
>>> my terms
>>> wrong, typical for a newbie... I'm trying to script this all in
>>> an .irev
>>> file on my on-rev account.)
>>> Someone mentioned cookies, which seems like a logical method --
>>> now to
>>> learn how to make and read cookies!
>>> Tim Selander
>>> Tokyo, Japan
>> Are your family members login in in any way? Presumably there is some
>> access protection. If so, time zone could be part of the user
>> account data.
>> You would not care then what time user computer has (and whether it
>> is set
More information about the use-livecode