You should produce a %diff card and return it on your subscription bone.
Let me step back and explain the theory behind this architecture a
little better. A poke causes some state on the server to change; this
change is reported to one or more subscribers. By decoupling the
effect and the change report, we're forcing you to create an
application that works by keeping subscribers in sync with (some part)
of server state. If some other user-agent caused the same state
change, you would also see this update even though you didn't cause
it.
For example, a trivial case of coupling is a console with nontrivial
server-side update semantics. You press a key. This changes the
input line, in a way that the client can't (always) predict. The
classic function-as-RPC approach would POST the key and return the new
input line in the response.
If instead we POST the key and send the new input line as a diff, this
same application -- though slightly more complex -- can be trivially
generalized to let other users watch your console session. If you did
it the classic way, this refactoring is nontrivial. Do you want this
feature in the product? Maybe, maybe not -- but you can see how
separating "causing" from "watching" is abstractly more elegant, I
hope.
Post by Jeremy WallPost by Curtis YarvinYou're sending a poke; by definition, this is not an RPC but rather a
transaction whose result only contains content if it fails. It's a
procedure, not a function, as it were. Or if it's a function, it
returns void.
As long as the poke arm doesn't crash, you should get 200 OK with an
empty body (Anton, correct me if I'm wrong). Again, this naked ack is
a feature, not a bug; it's just what an end-to-end ack looks like to a
JS client.
If you want to read data from the server, you need a subscription -- a
different communication pattern. Note however that the gall appliance
gets the same bone if the same client both subscribes and pokes with
the same wire (caller's causal path), so it's easy for the poke to
cause some response on a downstream channel.
Ahhh okay this is what I was beginning to suspect.
So what we want then is for the poke to cause something to occur in the
subscription channel for this request. (e.g. /~/of/[ixor]) Would I use the
same ixor that I got when I authenticated? or do I need to do something get
a new ixor associated to this app and my session?
And in that case what cards should the poke arm produce to cause things to
happen in the ixor for this session?
Alternatively is there now or are their plans to introduce a mechanism
similar to poke that works like a function call rather than a procedure?
This is a lot of work for third party services to consume an urbit service
and is likely to be a hindrance to them. (Perhaps this is desired?) Enough
work that I'm almost persuaded to create a go proxy that abstracts the whole
thing away into a restful service for me :-p
Post by Curtis YarvinOkay now the rubber is starting to meet the road. I've successfully perfomed
a handshake for authentication and then hit a poke-json arm in a gall app
and seen the payload.
What I can't quite figure out right now is what do I produce from the
poke-arm to send a response back? In other word what card should my %gall
app produce to tell eyre send this out as a response to this request?
Any guidance here?
On Fri, Nov 27, 2015 at 7:50 PM, Jeremy Wall
Post by Jeremy Wallhttp://hidduc-posmeg.urbit.org/home/tree/pub/hoon-intro/rest/notes
I've worked out how to do a successful authentication handshake. Now to
work out how to use that authentication handshake for future requests :-p
On Fri, Nov 27, 2015 at 7:17 PM, Jeremy Wall
Post by Jeremy WallActually never mind. I think I just figured it out. My bash-fu was
lacking :-p
On Fri, Nov 27, 2015 at 7:09 PM, Jeremy Wall
Post by Jeremy Wall#!/bin/bash
oryx=$(curl http://localhost:8081/~/auth.json | jq "{.oryx") # just
grabs the oryx from this request.
genpayload () { #construct an auth.json payload for posting
cat<<EOF
{
"oryx":$1,
"ship":"zod",
"code":"wisnyx-sitnev-podwen-matzod"
}
EOF
}
echo $(genpayload $oryx)
#Post that payload and see the result.
curl -i \
-H 'Accept: application/json' \
-H 'Content-Type: application/json' \
-X POST -d "$(genpayload $oryx)" \
http://localhost:8081/~/auth.json?PUT
Given what you just said and what I think I understand from the spec doc
I would have expected it to work.
Post by Anton DyudinYou're right, that should only happen on requests actually making use
of it. Any random auth.json oryx should in fact work for auth.json PUT
On Friday, November 27, 2015, Jeremy Wall
Post by Jeremy WallPost by Anton DyudinWhat precisely do you mean by "won't let you reuse"? Is it crashing
on some specific assert, or printing an error?
%bad-oryx, for example, means that your csrf token isn't in the set
recorded for your session cookie (for example if you don't have
the latter).
This is all happening with curl.
I'm assuming I don't have a session cookie since I haven't yet
authenticated. Do you get a session before authenticating? And is there a
url you hit to drop the cookie that you then use when you authenticate?
Post by Anton DyudinOn Friday, November 27, 2015, Jeremy Wall
Post by Jeremy WallHey Anton,
I've been reading your spec and playing with curl for a bit
attempting to manually succeed in a handshake. It looks to me like you
should be able authenticate using a POST /~/auth.json?PUT with a
payload
containing the csrf token, ship name and code. However I can't
figure out
how you get the csrf token to start with. It seems like a bit of
a chicken
and an egg problem to me. It won't let you resuse the oryx from a GEt
/~/auth.json so that won't work according to my testing.
Post by Anton Dyudinhttp://sondel-forsut.urbit.org/home/tree/pub/spec/eyre, was
private doc and
may be lost with the ship etc.
The /~/to endpoint also accepts wire and oryx as query string
parameters, in which case the entire post body is treated as the
message.
The query string can also contain 'anon', which obviates the
need for an
oryx parameter.
On Tuesday, November 24, 2015, Jeremy Wall
Post by Jeremy WallWe can still treat http requests as comets as long as the
token/cookie and process for getting/using one is well documented.
On Tue, Nov 24, 2015 at 9:27 PM, Galen Wolfe-Pauly
I wonder whether we have made a design error here. It’s nice
to
be able to treat all HTTP requests as comets — but there are
likely devices
that want to communicate over HTTP that can’t set up an oryx.
Correct. There is a way to send a json post anonymously to an
app(and get a nice/mean), or there is a way to access the
query string from
a hook file.
I suppose crashing in the app and sticking JSON in the stateless
"error" might work?
On Tuesday, November 24, 2015, Jeremy Wall
Post by Jeremy WallSo it doesn't appear that there is a clean way to set up urbit
to handle restful api endpoints.
i.e. I can tell urbit to handle this url, method with this
code.
And have that code get access to the payload in the body of
that request if
it is say a post or put request.
Am I wrong? or does this just not exist yet?
--
Jeremy Wall
http://jeremy.marzhillstudios.com
--
You received this message because you are subscribed to the
Google Groups "urbit" group.
To unsubscribe from this group and stop receiving emails from
To post to this group, send email to
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the
Google Groups "urbit" group.
To unsubscribe from this group and stop receiving emails from it,
To post to this group, send email to
For more options, visit https://groups.google.com/d/optout.
--
Jeremy Wall
http://jeremy.marzhillstudios.com
--
Jeremy Wall
http://jeremy.marzhillstudios.com
--
Jeremy Wall
http://jeremy.marzhillstudios.com
--
Jeremy Wall
http://jeremy.marzhillstudios.com
--
Jeremy Wall
http://jeremy.marzhillstudios.com
--
Jeremy Wall
http://jeremy.marzhillstudios.com
--
Jeremy Wall
http://jeremy.marzhillstudios.com
--
You received this message because you are subscribed to the Google Groups
"urbit" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.
--
Jeremy Wall
http://jeremy.marzhillstudios.com
--
You received this message because you are subscribed to the Google Groups "urbit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to urbit-dev+***@googlegroups.com.
To post to this group, send email to urbit-***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.