urbit/shrub
1
1
Fork 0
mirror of https://github.com/urbit/shrub.git synced 2024-12-25 13:04:17 +03:00
Code Issues Packages Projects Releases Wiki Activity
06c0d55a1e
shrub/pkg/arvo/app/clock.hoon

108 lines
2.4 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
boots off gall using fusion to build apps; some app errors on boot, but usable
2020-04-22 12:27:36 +03:00
/* tile %js /app/clock/js/tile/js
=/ as-octs as-octs:mimes:html
=/ tile-js (as-octs tile)
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
=, format
::
get geolocation from weather app, revise clock appearance to match new launch page
2020-02-06 05:08:22 +03:00
|%
::
+$ card card:agent:gall
+$ versioned-state
$% state-zero
==
+$ state-zero [%0 data=json]
--
ames: backpressure fixes
2019-11-27 01:56:20 +03:00
%+ verb |
get geolocation from weather app, revise clock appearance to match new launch page
2020-02-06 05:08:22 +03:00
=| state-zero
=* state -
gall: mall -> gall
2019-11-19 07:36:21 +03:00
^- agent:gall
|_ =bowl:gall
eyre: better userspace libraries
2019-11-09 23:22:59 +03:00
+* this .
def ~(. (default-agent this %|) bowl)
::
++ on-init
gall: mall -> gall
2019-11-19 07:36:21 +03:00
^- (quip card:agent:gall _this)
eyre: better userspace libraries
2019-11-09 23:22:59 +03:00
=/ launcha
get geolocation from weather app, revise clock appearance to match new launch page
2020-02-06 05:08:22 +03:00
[%launch-action !>([%clock /clocktile '/~clock/js/tile.js'])]
eyre: better userspace libraries
2019-11-09 23:22:59 +03:00
:_ this
:~ [%pass / %arvo %e %connect [~ /'~clock'] %clock]
[%pass /clock %agent [our.bowl %launch] %poke launcha]
==
goad: recompile apps after changes to /sys OTAs commonly end up in an inconsistent state if apps depend on changes to /sys. For example, the %sift changes break on OTA because %spider needs to be reloaded so that it's aware of the new thread type. This adds a %goad app, which reloads all apps after every change to /sys. Getting this to start OTA is nontrivial, but this pattern should work for apps in the future. The changes to clock shouldn't generally be necessary; they are only necessary here because we can't rely on hood to start goad, since hood fails to compile if it's run before zuse is reloaded. Once goad is active, this will cease to be a problem.
2019-12-14 03:32:13 +03:00
:: bootstrapping to get %goad started OTA
::
goad: make startup resilient to errors By not running the risky %goad card in on-init. Also includes some qol fixes.
2019-12-14 05:40:12 +03:00
++ on-save !>(%2)
goad: recompile apps after changes to /sys OTAs commonly end up in an inconsistent state if apps depend on changes to /sys. For example, the %sift changes break on OTA because %spider needs to be reloaded so that it's aware of the new thread type. This adds a %goad app, which reloads all apps after every change to /sys. Getting this to start OTA is nontrivial, but this pattern should work for apps in the future. The changes to clock shouldn't generally be necessary; they are only necessary here because we can't rely on hood to start goad, since hood fails to compile if it's run before zuse is reloaded. Once goad is active, this will cease to be a problem.
2019-12-14 03:32:13 +03:00
++ on-load
|= old-state=vase
goad: make startup resilient to errors By not running the risky %goad card in on-init. Also includes some qol fixes.
2019-12-14 05:40:12 +03:00
=/ old !<(?(~ %1 %2) old-state)
goad: recompile apps after changes to /sys OTAs commonly end up in an inconsistent state if apps depend on changes to /sys. For example, the %sift changes break on OTA because %spider needs to be reloaded so that it's aware of the new thread type. This adds a %goad app, which reloads all apps after every change to /sys. Getting this to start OTA is nontrivial, but this pattern should work for apps in the future. The changes to clock shouldn't generally be necessary; they are only necessary here because we can't rely on hood to start goad, since hood fails to compile if it's run before zuse is reloaded. Once goad is active, this will cease to be a problem.
2019-12-14 03:32:13 +03:00
=^ cards this
goad: make startup resilient to errors By not running the risky %goad card in on-init. Also includes some qol fixes.
2019-12-14 05:40:12 +03:00
?: ?=(%2 old)
goad: recompile apps after changes to /sys OTAs commonly end up in an inconsistent state if apps depend on changes to /sys. For example, the %sift changes break on OTA because %spider needs to be reloaded so that it's aware of the new thread type. This adds a %goad app, which reloads all apps after every change to /sys. Getting this to start OTA is nontrivial, but this pattern should work for apps in the future. The changes to clock shouldn't generally be necessary; they are only necessary here because we can't rely on hood to start goad, since hood fails to compile if it's run before zuse is reloaded. Once goad is active, this will cease to be a problem.
2019-12-14 03:32:13 +03:00
`this
:_ this :_ ~
[%pass /behn %arvo %b %wait +(now.bowl)]
::
[cards this]
::
eyre: better userspace libraries
2019-11-09 23:22:59 +03:00
++ on-poke
|= [=mark =vase]
gall: mall -> gall
2019-11-19 07:36:21 +03:00
^- (quip card:agent:gall _this)
get geolocation from weather app, revise clock appearance to match new launch page
2020-02-06 05:08:22 +03:00
|^
?: ?=(%json mark)
(poke-json !<(json vase))
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
get geolocation from weather app, revise clock appearance to match new launch page
2020-02-06 05:08:22 +03:00
::
++ poke-json
|= jon=json
^- (quip card:agent:gall _this)
=. data.state jon
:_ this
[%give %fact ~[/clocktile] %json !>(jon)]~
--
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
::
++ on-watch
|= =path
gall: mall -> gall
2019-11-19 07:36:21 +03:00
^- (quip card:agent:gall _this)
mall, eyre: refactor server apps to be stateless
2019-11-13 11:38:35 +03:00
?: ?=([%http-response *] path)
`this
get geolocation from weather app, revise clock appearance to match new launch page
2020-02-06 05:08:22 +03:00
?. =(/clocktile path)
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
(on-watch:def path)
get geolocation from weather app, revise clock appearance to match new launch page
2020-02-06 05:08:22 +03:00
[[%give %fact ~ %json !>(data.state)]~ 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
::
++ on-leave on-leave:def
++ on-peek on-peek:def
++ on-agent on-agent:def
++ on-arvo
|= [=wire =sign-arvo]
gall: mall -> gall
2019-11-19 07:36:21 +03:00
^- (quip card:agent:gall _this)
goad: recompile apps after changes to /sys OTAs commonly end up in an inconsistent state if apps depend on changes to /sys. For example, the %sift changes break on OTA because %spider needs to be reloaded so that it's aware of the new thread type. This adds a %goad app, which reloads all apps after every change to /sys. Getting this to start OTA is nontrivial, but this pattern should work for apps in the future. The changes to clock shouldn't generally be necessary; they are only necessary here because we can't rely on hood to start goad, since hood fails to compile if it's run before zuse is reloaded. Once goad is active, this will cease to be a problem.
2019-12-14 03:32:13 +03:00
?: ?=(%wake +<.sign-arvo)
?^ error.sign-arvo
:_ this :_ ~
[%pass /dill %arvo %d %flog %crud %clock-fail u.error.sign-arvo]
:_ this :_ ~
[%pass /gall %arvo %g %goad | `%hood]
::
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
?. ?=(%bound +<.sign-arvo)
(on-arvo:def wire sign-arvo)
[~ this]
::
++ on-fail on-fail:def
--
Reference in New Issue Copy Permalink