On 12/14/11 12:58 PM, Volker Braun wrote:
Is there any specification / documentation for the JSON returned by the
single-cell server? Maybe I haven't looked enough, but all I see is how
to use it via the js api. For the Android app I'd like to access the
server on a bit lower level. Right now I've just hacked something
together, but it would be nice if we could make it more permanent and
perhaps include the java parser into the server testing framework.
That sounds like a great idea. One of the last things we wanted to do
before releasing the big 1.0 version is to write more tests and
documentation about the protocol. Things have been on hold for the last
little while (school has been busy), but with the end of the semester, I
hope that we can finish things up over the holiday break.
We tried to follow pretty closely the ipython messaging spec (or a
subset of it, anyway, with a few of our own extensions like
session_end). The ipython messaging spec is here:
http://ipython.org/ipython-doc/dev/development/messaging.html
The hope is that when we switch to ipython 0.12, a lot of the work we
are doing manually now will be automatic for us, and our front ends will
still just work.
On a more direct level, I'm confused by the following:
1) When evaluating a cell, I also get all previous responses back
(previous msg_ids). Is there a way to omit the history?
You can specify a starting "sequence number" for the message history.
When you get the history back, each message has a sequence number.
Typically you will send back the last sequence number in your request.
You can see the protocol in action at sagemath.org:5467. You can see
the output_poll calls always specify a sequence number, like:
http://sagemath.org:5467/output_poll?callback=jQuery150567467032931745_1323889675362&computation_id=ec0b2637-86f8-439f-93f1-0a4d0cbb5390&sequence=8&_=1323889715558
We request messages starting with sequence number 8 (so the sequence
parameter is the first sequence you number you haven't seen yet.)
2) The session_end object seems to be very different from the other
objects: Its parent_header misses the msg_id, whats the rationale behind
that? And its ["header"]["msg_id"] seems to be a new uuid that isn't
used anywhere else, whats that for?
The parent_header should be the same as the execute request header. We
were taking a shortcut by just putting the session id in the parent
header. I just fixed it in this commit and pushed the change to
sagemath:5467, so that should be fixed now.
The msg_id just should be unique, so it's okay that the session_end
msg_id is a uuid and not a random integer. Originally, all msg_id
fields were going to be uuids, but there was a bug in python on OSX [1]
that meant that we settled for using random integers for the output
msg_id fields.
Thanks,
Jason
[1] http://bugs.python.org/issue8621
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
