Notification: Why forbid response
CC
New kid on the block (blog) :-) with some questions.
When studying the RC for 2.0 I saw some strong feelings in favour of
forbidding a response of the server to a notification. What advantage
is there, if a response (with the exception of two error messages)
actually is forbidden? I understand the concept of the notification,
but I do not see an advantage in having the client crying "protocol
error" should the server chose to reply to a notification.
A second aspect: Notifications are one variant. They require one or
zero reply. What about having multiple replies? Has this been
discussed yet?
Matt (MPCM)
> forbidding a response of the server to a notification. What advantage
> is there, if a response (with the exception of two error messages)
> actually is forbidden? I understand the concept of the notification,
> but I do not see an advantage in having the client crying "protocol
> error" should the server chose to reply to a notification.
that would in essence make it a regular request with response that the
client just ignored (viable). Without an ID there would be no point in
tracking an error code as you couldn't map it back.
Notifications have the advantage of letting the client fire off a
message and just continue without waiting for a reply. If you are
planning on sending error prone json-rpc request objects, I would
suggest not use notifications.
> A second aspect: Notifications are one variant. They require one or
> zero reply. What about having multiple replies? Has this been
> discussed yet?
logically work, as again you could not map it easily with the ids.
Many to Many has been discussed has been discussed in 2 forms, a
system.multicall method and array based delivery system.
The system.multicall method is a dedicated system method that takes an
array of request objects to be processed and returns an array of
responses (all within a single request/response object), kind of like
json-rpc within json-rpc.
Array based multicall on the other hand suggests sending an array of
request objects instead of a single object. It would expect a return
of an array of response objects also. I prefer and use this method
currently. In systems like http it can get confusing without comet
style communication, as the server cannot reply whenever it needs to
and needs to wait for all messages to finish.
Neither have been approved, at this point I think either would fit
nicely into an extension.
--
Matt (MPCM)
Lorenzo Pastrana
> error" should the server chose to reply to a notification.
The client should never even check if a response is given.
I'd suggest even the "exception" of "Parse error" and "Invalid Request",
should be omitted. Especially "Invalid Request" is awkward for me in
this place since "Notifications" aren't requests by definition, "Parse
error" should be a debug-mode facility implemented by server.
Advantage is a cristal clear distinction with regular call :
notification is for non-critical/disposable/frivolous data/ping
streams : "just in case it gets through", if you COULD/SHOULD/MUST
process a response use a regular call.
Any comments on this one ?
> A second aspect: Notifications are one variant. They require one or
> zero reply. What about having multiple replies? Has this been
> discussed yet?
Multi-call has been evoked with possible id-matched multi-response,
nothing GRAS yet.
Lo.
CC
On Mar 12, 1:56 pm, "Matt (MPCM)" <WickedLo...@gmail.com> wrote:
> A notification is a one way message. While the server `could` reply,
> that would in essence make it a regular request with response that the
> client just ignored (viable). Without an ID there would be no point in
> tracking an error code as you couldn't map it back.
>
> Notifications have the advantage of letting the client fire off a
> message and just continue without waiting for a reply. If you are
> planning on sending error prone json-rpc request objects, I would
> suggest not use notifications.
asynchronous. As a consequence I never have to wait for responses
(having asynch response handlers in place). However, if you consider
synchronous mode, you would of course be waiting for a response. In
this case it is really helpful to know that you have a type of call
where the server does not respond to at all, since it makes the
overall architecture easier.
I agree completely with Lorenzo, that also "Parse Error" and "Invalid
Request" should be omitted (and we should have an according adaption
of the Spec, if this has not yet been made already).
> One message returns many messages? I am not sure how that would
> logically work, as again you could not map it easily with the ids.
transport layer it is easy (both of which is true in my applications,
I am delivering using multipart mime type). In case the transport
layer does not have a streaming semantics (a case I start considering
only right now, since I did not have it) I would at sub-IDs. The
responses to a call with ID x would be x.0, x.1, x.2 etc.
> Many to Many has been discussed has been discussed in 2 forms, a
> system.multicall method and array based delivery system.
>
> The system.multicall method is a dedicated system method that takes an
> array of request objects to be processed and returns an array of
> responses (all within a single request/response object), kind of like
> json-rpc within json-rpc.
>
> Array based multicall on the other hand suggests sending an array of
> request objects instead of a single object. It would expect a return
> of an array of response objects also. I prefer and use this method
> currently. In systems like http it can get confusing without comet
> style communication, as the server cannot reply whenever it needs to
> and needs to wait for all messages to finish.
objects in and array of objects out in both cases.
BTW, it is nice to combine this with the multi-response feature I
outlined above, since then you could have a single array of requests
followed by multiple reponses.
Matt (MPCM)
> That could easily be cured by adding an ID.
removal of notifications? I think this came up before... just looking
to clarify what you are trying to achieve.
> As soon as you have IDs in the request and a stream semantics in the
> transport layer it is easy (both of which is true in my applications,
> I am delivering using multipart mime type). In case the transport
> layer does not have a streaming semantics (a case I start considering
> only right now, since I did not have it) I would at sub-IDs. The
> responses to a call with ID x would be x.0, x.1, x.2 etc.
part mime. I am not sure of the implications, but if you want to put
something together to describe what you are suggesting in a separate
thread we can see what people around here think.
> I don't really see the difference of the two approaches. Array of
> objects in and array of objects out in both cases.
in the param of a single request object. In practice there is not much
difference, in implementation and design principle there is.
> BTW, it is nice to combine this with the multi-response feature I
> outlined above, since then you could have a single array of requests
> followed by multiple reponses.
we are trying to keep json-rpc simple and transport agnostic. Lots of
things *can* (and are) being done with json-rpc modifications, but
most *should not* be part of the official spec.
I look forward to seeing what you are suggesting.
--
Matt (MPCM)
Roland Koebler
[Notifications]
> The client should never even check if a response is given.
correct.
> I'd suggest even the "exception" of "Parse error" and "Invalid Request",
> should be omitted.
for clarification:
- syntactically correct Notifications *never* get a response.
- if you meant to send a Notification, but send something which is
not syntactically correct, you may get an error-response.
that's what "Parse error" and "Invalid Request" are for: invalid
json/jsonrpc.
so if you meant so send a notification, but send a syntactically
invalid jsonrpc-object, you may get "Parse error" or "Invalid Request"
as response. that's all.
of course I could remove these sentences from the specification if it
is too confusing. but that wouldn't change *anything* in the specified
behaviour.
> Especially "Invalid Request" is awkward for me in
> this place since "Notifications" aren't requests by definition,
they are.
A Notification is a special kind of request.
(see section "Notification" in the proposal)
> "Parse
> error" should be a debug-mode facility implemented by server.
no. please look into the json-rpc proposal, section "Error Object".
there you'll find what "Parse error" is for.
> Advantage is a cristal clear distinction with regular call :
> notification is for non-critical/disposable/frivolous data/ping
> streams : "just in case it gets through", if you COULD/SHOULD/MUST
> process a response use a regular call.
yes, that's how it is currently specified in the proposal.
regards,
Roland
Roland Koebler
> I understand the concept of the notification,
> but I do not see an advantage in having the client crying "protocol
> error" should the server chose to reply to a notification.
there are 2 kinds of requests:
- requests with a response
- requests without a response (called Notification)
a "request with maybe a response", which you suggest here, doesn't make
much sense in my opinion. how should the client handle this? it wouldn't
know if it should wait for a response or not...
> What about having multiple replies? Has this been
> discussed yet?
no, not directly. the proposal specifies a (synchronous) server-client-
architecture, where the client sends a request and gets an answer.
if you want an asynchronous architecture, or a peer-to-peer-archtecture,
you can simply use both a server and client on both sides.
regards,
Roland
CC
> much sense in my opinion. how should the client handle this? it wouldn't
> know if it should wait for a response or not...
The spec says
A Notification is a special Request, without id and without Response.
The server MUST NOT reply to a Notification, except for "Parse error"
and "Invalid Request".
But, a message to the server, to which the server could possibly reply
with a "Parse error" or an "Invalid request" is just not a
notification. At least, if you define a notification as a request
without an id. So the confusion comes from the sentence indicating
that their might be a perfectly legal notification to which the server
could send an answer.
By the way: Realizing that the notifications are meant for a
synchronous setting, a server response would not be heared by the
client anyhow. So it makes no sense to specify anything at all.
We agree on the semantics now, however I still would adapt the
wording, since it does not state what is intended here.
> if you want an asynchronous architecture, or a peer-to-peer-archtecture,
> you can simply use both a server and client on both sides.
practical deployment scenarios this is bound to fail quite often
(firewalls, security constraints, system architecture). Thus, I have a
client lib which allows asynch requests to be made from a browser. The
possible solution of having the browser act as a server is not
practical by any means.
Cheers
CC
Clemens Cap
> - if you meant to send a Notification, but send something which is
> not syntactically correct, you may get an error-response.
>
> that's what "Parse error" and "Invalid Request" are for: invalid
> json/jsonrpc.
Ok. But then I would state this in a proper chapter, not under "notifications".
> so if you meant so send a notification, but send a syntactically
> invalid jsonrpc-object, you may get "Parse error" or "Invalid Request"
> as response. that's all.
I would not even see that response, save in a packet sniffer ;-)
Cheers
CC.
Roland Koebler
> > that's what "Parse error" and "Invalid Request" are for: invalid
> > json/jsonrpc.
>
> Ok. But then I would state this in a proper chapter, not under "notifications".
"Parse error" and "Invalid Request" are expained in the "Error object"
section. under "notification" there's only a note, which I should probably
remove because it causes too much confusion...
regards,
Roland
Lorenzo Pastrana
> > this place since "Notifications" aren't requests by definition,
> they are.
> A Notification is a special kind of request.
> (see section "Notification" in the proposal)
Ok..
> > "Parse
> > error" should be a debug-mode facility implemented by server.
> no. please look into the json-rpc proposal, section "Error Object".
> there you'll find what "Parse error" is for.
You are right too.
> under "notification" there's only a note, which I should probably
> remove because it causes too much confusion...
It looks you are right as well..
Lo.