ilyakooo0/urbit
1
0
Fork 0
mirror of https://github.com/ilyakooo0/urbit.git synced 2024-11-11 04:48:00 +03:00
Code Issues Packages Projects Releases Wiki Activity
9862dccc0e
urbit/pkg/arvo/app/clock.hoon

72 lines
1.6 KiB
Plaintext
Raw Normal View History

eyre: subscribe to apps for responses This removes the %http-response special case from gall. In its place, we implement a subscription regime with the following steps: - Agent sends %connect to Eyre - Eyre pokes agent with %handle-http-response, including unique eyre-id - Agent passes %start-watching to Eyre with eyre-id and unique app-id - Eyre subscribes to agent on /http-response/app-id - Agent produces a %http-response-header fact followed by 0 or more %http-response-data facts and possibly a %http-response-cancel fact - Agent produces a %kick to close the subscription, which Eyre interprets as completion of the message. This works when there is data. There is currently a bug where if the response has no data in total (as in the case of a naked 404), no response will be sent. This also includes lib/http-handler, which implements a convenient interface for agents that want to respond immediately with all the data. This lets them avoid carrying extra state to keep track of pending requests. This should really have access to your state and the ability to change it. Perhaps a more minimalist design would be better: just keep track of the requests, then hand it off to +on-watch when eyre is ready to receive responses. It's not clear how to pass in the request data in +on-watch.
2019-11-09 10:31:11 +03:00
/+ *server, default-agent, verb
/= tile-js
/^ octs
/; as-octs:mimes:html
/: /===/app/clock/js/tile
/| /js/
/~ ~
==
=, format
::
%+ verb &
^- agent:mall
eyre: better userspace libraries
2019-11-09 23:22:59 +03:00
|_ =bowl:mall
+* this .
def ~(. (default-agent this %|) bowl)
::
++ on-init
^- (quip card:agent:mall _this)
=/ launcha
[%launch-action !>([%clock /tile '/~clock/js/tile.js'])]
:_ this
:~ [%pass / %arvo %e %connect [~ /'~clock'] %clock]
[%pass /clock %agent [our.bowl %launch] %poke launcha]
==
++ on-save on-save:def
++ on-load on-load:def
++ on-poke
|= [=mark =vase]
^- (quip card:agent:mall _this)
mall, eyre: refactor server apps to be stateless
2019-11-13 11:38:35 +03:00
?. ?=(%handle-http-request mark)
eyre: better userspace libraries
2019-11-09 23:22:59 +03:00
(on-poke:def mark vase)
mall, eyre: refactor server apps to be stateless
2019-11-13 11:38:35 +03:00
=+ !<([eyre-id=@ta =inbound-request:eyre] vase)
eyre: better userspace libraries
2019-11-09 23:22:59 +03:00
:_ this
mall, eyre: refactor server apps to be stateless
2019-11-13 11:38:35 +03:00
%+ give-simple-payload:app eyre-id
eyre: better userspace libraries
2019-11-09 23:22:59 +03:00
%+ require-authorization:app inbound-request
eyre: subscribe to apps for responses This removes the %http-response special case from gall. In its place, we implement a subscription regime with the following steps: - Agent sends %connect to Eyre - Eyre pokes agent with %handle-http-response, including unique eyre-id - Agent passes %start-watching to Eyre with eyre-id and unique app-id - Eyre subscribes to agent on /http-response/app-id - Agent produces a %http-response-header fact followed by 0 or more %http-response-data facts and possibly a %http-response-cancel fact - Agent produces a %kick to close the subscription, which Eyre interprets as completion of the message. This works when there is data. There is currently a bug where if the response has no data in total (as in the case of a naked 404), no response will be sent. This also includes lib/http-handler, which implements a convenient interface for agents that want to respond immediately with all the data. This lets them avoid carrying extra state to keep track of pending requests. This should really have access to your state and the ability to change it. Perhaps a more minimalist design would be better: just keep track of the requests, then hand it off to +on-watch when eyre is ready to receive responses. It's not clear how to pass in the request data in +on-watch.
2019-11-09 10:31:11 +03:00
|= =inbound-request:eyre
=/ request-line (parse-request-line url.request.inbound-request)
=/ back-path (flop site.request-line)
=/ name=@t
=/ back-path (flop site.request-line)
?~ back-path
''
i.back-path
::
?~ back-path
not-found:gen
?: =(name 'tile')
(js-response:gen tile-js)
not-found:gen
::
++ on-watch
|= =path
^- (quip card:agent:mall _this)
mall, eyre: refactor server apps to be stateless
2019-11-13 11:38:35 +03:00
?: ?=([%http-response *] path)
`this
eyre: subscribe to apps for responses This removes the %http-response special case from gall. In its place, we implement a subscription regime with the following steps: - Agent sends %connect to Eyre - Eyre pokes agent with %handle-http-response, including unique eyre-id - Agent passes %start-watching to Eyre with eyre-id and unique app-id - Eyre subscribes to agent on /http-response/app-id - Agent produces a %http-response-header fact followed by 0 or more %http-response-data facts and possibly a %http-response-cancel fact - Agent produces a %kick to close the subscription, which Eyre interprets as completion of the message. This works when there is data. There is currently a bug where if the response has no data in total (as in the case of a naked 404), no response will be sent. This also includes lib/http-handler, which implements a convenient interface for agents that want to respond immediately with all the data. This lets them avoid carrying extra state to keep track of pending requests. This should really have access to your state and the ability to change it. Perhaps a more minimalist design would be better: just keep track of the requests, then hand it off to +on-watch when eyre is ready to receive responses. It's not clear how to pass in the request data in +on-watch.
2019-11-09 10:31:11 +03:00
?. =(/tile path)
(on-watch:def path)
[[%give %fact ~ %json !>(*json)]~ this]
::
++ on-leave on-leave:def
++ on-peek on-peek:def
++ on-agent on-agent:def
++ on-arvo
|= [=wire =sign-arvo]
^- (quip card:agent:mall _this)
?. ?=(%bound +<.sign-arvo)
(on-arvo:def wire sign-arvo)
[~ this]
::
++ on-fail on-fail:def
--
Reference in New Issue Copy Permalink