Hi Derrell,
Am 16.06.2006 um 00:59 schrieb [EMAIL PROTECTED]:
> Andreas Junghans <[EMAIL PROTECTED]> writes:
>
>> I would greatly prefer a single, standard format, no matter in which
>> direction a date is sent.
>> ...
>> Since it's so difficult to properly handle timestamps in PHP (and
>> maybe
>> other backends too), I suggest we standardize on the second
>> syntax: new
>> Date(Date.UTC(...)). More comments on that below.
>
> I would have a slight preference to use the same format in both
> directions,
> but I found that I'd have to entirely rewrite the JSON parser in
> PHP to use
> this alternate format. The current one uses commas as a separation
> point at a
> level that is not easily modifiable, so getting the entire
> "DATE(Date.UTC(x,y,z...))" as a string for easy parsing isn't part
> if this
> parser's design . I'm *really* not eager to rewrite a JSON
> parser. The
> format I selected is so incredibly easy to parse that any server
> should be
> able to deal with it. That's why I switched to it.
>
> I also think it makes a lot of sense to leave it to the server to
> select one
> of the two supported output formats (msSinceEpoch or Date.UTC)
> since different
> server implementations will want to internally maintain one or the
> other. The
> Java and PHP implementations are a good example.
Who says that one side of the conversation will always be JavaScript?
What if two PHP implementations want to talk to each other? With your
different syntax conventions for both directions, this wouldn't be
possible. I still believe it's much better to use a single syntax
(and the UTC syntax is trivial to implement in Java as well).
>> I think it should be fairly easy to parse the UTC syntax (comma-
>> separated numbers).
>
> Definitely -- if one is writing the JSON parser from scratch.
> (Please don't
> ask me to do that. This is all "spare time" work and that's really
> just 'busy
> work'.)
Come on, it's not that hard! You simply have to treat the start and
end of a date the same way you treat the quotes for strings.
Attached is a patch to your JSON parser that does exactly that. I've
tested it, and dates in the "new Date(Date.UTC(...))" syntax are
parsed without problems (except for the fractional part, see below).
This is my first ever encounter with PHP code (apart from making a
trivial copy and paste change to a file some time ago), so it's
probably not the most elegant and efficient code, but it works, and
optimizations can easily be made later.
Please note that I didn't adjust the setUtcDateTimeFields()
implementation (it now gets milliseconds instead of a fractional
part). I didn't want to steal all the work ;-) (And I'm sure you're
speaking PHP much more fluently than I do.)
With these changes, do you still have objections to using the "new
Date(Date.UTC(...))" syntax?
>> Backends like PHP can choose to ignore the milliseconds when
>> receiving and
>> not add them when sending.
>
> Nope. That breaks my "echo" rule. The server *must* maintain all
> information
> it is given such that if it echos back the same date as it
> receives, no
> information is lost. The current PHP implementation supports that.
OK.
>> What do you think about standardizing on "new Date(Date.UTC
>> (...))"? If you
>> agree, do you think it's necessary to disallow spaces around the
>> commas? I
>> can change the Java implementation accordingly.
>
> I think my statements above make my opinion pretty clear. ;-)
Ditto ;-)
>> I have no problem with adding a call id, but please leave the
>> original
>> instanceId functionality in!
>
> I would propose to add this feature on top of RPC rather than being
> part of
> the generic RPC mechanism, possibly by appending the instance
> number to the
> URL. By doing it this way, if the client and server know about
> instances,
> they'll be used. If the server doesn't support them, the URL will
> never
> include an instance id, and it just won't be used.
Sounds good, but I'd like to check first if it's easy to implement in
Java (the problem I see is getting an additional query parameter from
the URL when the request method is POST and the body is not form-
encoded). It would be great if you could wait until monday (when I'm
at my work machine again), so that I can confirm the URL-based
approach doesn't cause problems in the Java implementation. It'll
probably work just fine, but I want to make sure.
>> 2.) I don't like the synchronous call warning. You could as well
>> issue a
>> similar warning in the asynchronous case because it's so easy to get
>> asynchronous communication wrong. Sometimes it's just necessary
>> to make a
>> truly synchronous call to preserve application semantics.
>>
>> For example, when you commit some changes to a database entry, and
>> continuing in your application requires that the server validated
>> and stored
>> the changes, there's just no way around a synchronous call.
>
> Test RPC_4.html shows how one might use async calls and await
> completion
> before moving on to something new. I believe this is the safest
> way to handle
> the situation.
Sure, but it's a trivial test case. I've worked with many
asynchronous programming patterns, and in many cases it's pretty easy
to screw it up. I'd rather have a stable application that takes over
my browser on some occasions than a fancy one that's not reliable.
(I'm not saying it's not possible for async handling to be reliable,
it just can be pretty hard.) I often use a mixture of sync and async
calls (depending on the application/task at hand).
> OTOH, I'm not wedded to the warning about sync calls. I
> believe it should be there to discourage people from using it, but
> I'm willing
> to remove it if the team believes it doesn't belong.
Please remove it. I'm not "the team", but I believe the warning
should only be included if other qooxdoo developers state they find
it useful (and not included now and removed later if there are
objections). You could comment it out before checking in so it can
easily be enabled.
>> A strong warning should be present in the API documention,
>
> That I definitely agree with! Then again, who reads
> documentation? :-)
:-)
> I made the assumption that, as in my examples, you can use a
> relative URL
> (path name only) as I did in the RPC_*.html tests.
>
> Yes, I'd definitely like to hear why you need it, but I also have
> no problem
> adding the helper method you request.
Let me give an example how I can use the current implementation in an
HTML page:
<script type="text/javascript" src=".qxrpc">
<script type="text/javascript" src="qooxdoo.js">
...
function test() {
var service = new qx.io.remote.Rpc("com.test.MyClass");
var call = service.callAsync(...)
}
On the server side, a servlet is mapped to the ".qxrpc" extension
(which makes it work in a relative way no matter where in the
directory tree the HTML page is). It returns a simple JavaScript that
sets qx.core.ServerSettings. The prefix and suffix properties are
necessary for sessions without cookies (;jsessionId suffix and the
like).
It's a good idea to take this logic out of the Rpc class, but there
has to be a replacement. IMHO, it should work something like this:
<script type="text/javascript" src=".qxrpc">
<script type="text/javascript" src="qooxdoo.js">
...
function test() {
var service = new qx.io.remote.Rpc(
qx.io.ServerUtils.makeLocalServerURL(),
"com.test.MyClass");
var call = service.callAsync(...)
}
The important point is that including ".qxrpc" fills in some internal
qooxdoo structure with the settings of the current server (i.e. the
server where the HTML page came from). It's not enough to simply use
some absolute URL for the same server (i.e. "/myApplicationURL") - if
this would work, there would be no need for something like
makeLocalServerURL(). However, at least in the Java case, an
application can be deployed at an arbitrary server path, and IMHO it
should not be necesssary to adjust the JavaScript code (i.e. the same
JavaScript code should work no matter if the actual URL to the
application is /XYZ/ or /some/path/ABC/). It also shouldn't matter
whether the HTML page making the call is in some deep subdirectory.
To achieve this "location independence", the Java servlet containing
the RPC implementation sends out a little script that stores the path
to the application (and a session id if there is one) in
qx.core.ServerSettings.serverPathPrefix and
qx.core.ServerSettings.serverPathSuffix. It guess it would be pretty
easy to also add such a mechanism in PHP? If you want to call an
arbitrary service, you can still provide a simple URL, but when you
want to call a local service, there should be an easy way to do so.
Regards,
Andreas
_______________________________________________
Qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
