Hi Derrell,
Am 30.05.2006 um 15:23 schrieb [EMAIL PROTECTED]:
Andreas Junghans <[EMAIL PROTECTED]> writes:
- Using an ID for each asynchronous call doesn't seem very
elegant. Using
seperate handlers for separate calls seems more logical.
Using separate handlers for separate calls is fine, if the calls
are to
different procedures. If you're issuing a whole bunch of calls to
the same
procedure, most likely you'll want the same handler, so the ID
matches a
particular response to a specific request. This is actually a very
standard
process, used in most networking protocols. The ID is optional
here, so you
can use just the handler as the response identifier if desired, but
having the
ID also available is, IMO, a good idea.
Sounds reasonable. I'll think about how to best add an optional id
without cluttering the API.
Thanks. Assuming that there is not widespread use of some JSON-RPC
protocol
by the big guys (e.g. Google), what I'd like to do is make our
implementation
match, as closely as is reasonable, the JSON-RPC spec.
OK.
For those things that
can't (or shouldn't, due to technical issues, such as Date), we can
put
together a proposal to the JSON-RPC folks to update the spec with
the issues
we identify.
I'd also like to identify a set of "common" error codes which are
likely to
arise in nearly any implementation (service not found; method not
found; etc.)
and add those to the spec if possible.
Sounds good.
Regards,
Andreas
--
Dipl.-Inform.(FH), M.Sc. Andreas Junghans
STZ-IDA an der Hochschule Karlsruhe
email [EMAIL PROTECTED]
internet http://stz-ida.de
telefon ++49-721-920-3302
fax ++49-721-160-890-56
Moltkestrasse 30, D-76133 Karlsruhe/Germany
-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
Qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
