> From: Raul Miller <[email protected]>
>
> On Mon, Nov 30, 2009 at 8:56 PM, Oleg Kobchenko wrote:
> > No, the intent of the proposal is exactly the same behavior
> > of the client and the server, with only two exceptions:
> >
> > - HTML is generated at the client
> >
> > - unless the whole page is explicitly refreshed (as in
> > reopening the page including bookmark), each command
> > execution results in transfer of only this command's result
> > and not the whole session transcript.
>
> Ok but that is not the "exactly the same behavior".
>
> For example, currently, if I have the same session
> open from multiple machines, I get different behavior
> from your current proposal.
This is a valid point, though very easily addressed
without a sticky session (as described below).
Namely, each command has an index, and with each
*stateless* command request, the last index is sent.
Then the server prepends any missing command outputs
to the response for the last command.
If, while the server is processing a command from
a client, a second client sends a command, then
the second command is queued.
The server still keeps track of all commands and responses,
which can be requested by index; so it is like a chat
session or a mail box. Sending a few command outputs
at a time makes it possible to have pagination for
long transcripts--useful for small devices like iPhone.
> That said, your initial proposal said nothing about
> refreshing the page and with further additions to
> the proposal "exactly the same behavior" could
> be achieved. (Namely, that each browser has a
> "session version number" and a "session index",
> which it sends with each request for update to the
> server, which lets the server craft an appropriate
> response. Also, the server response should
> probably be JSONP.)
Renouncing HTML from J web protocol also make other clients
possible, such as Java clients etc, whereas JSON is specific
to browsers (notwithstanding availability of JavaScript libraries).
So XML would probably be better.
> And, with that background, and with sufficient information
> about the state of the client at the time of the request,
> and using XMLHttpRequest we could change the
> "current behavior" of jhs to make it more closely match
> J6. Specifically, we could ensure that the browser always
> has a pending request to the server. If it times out, or
> fails, the browser could make another request. This would
> let the server post asynchronous updates to the client.
> There are a few race conditions here (what happens if the
> server sends a response right when the browser is requesting
> an update based on user input?) But if the server sends
> back to the client those state variables, the client can
> recognize responses based on obsolete state. [And, in
> the simplest implementation, the client asks the server again
> for an update when it gets a response based on obsolete
> state.]
I believe J6 protocol can be viewed as linear. For the purpose
of the web protocol, the "input request" (from server to client)
should be viewed as the disconnect step. (Technically, the wd
"wait" request could also be disconnect waiting for event,
but it could be done without, at least initially).
So there should not be a need for a sticky session or
asynchronous updates.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
