| 10:20 |
shinohai |
hmmm |
| 10:21 |
shinohai |
$ticker btc usd |
| 10:21 |
busybot |
Current BTC price in USD: $19446.72 |
| |
~ 1 hours 47 minutes ~ |
| 12:08 |
awt |
Gm pestnet |
| 12:09 |
awt |
$ticker btc usd |
| 12:09 |
busybot |
Current BTC price in USD: $19526.05 |
| 12:13 |
signpost |
morning awt! |
| 12:13 |
awt |
What would be an appropriate mechanism through which blatta could expose an "API" to a mutable client? |
| 12:16 |
* |
signpost could see several things being useful. |
| 12:16 |
signpost |
in deedbot's case, I used a shared database into which the IRC-facing component writes, and an arbitrary number of services read. there's an "outbox" table into which services write, and deedbot spits the outbound message to IRC. |
| 12:17 |
signpost |
afaik sqlite's already plenty capable of concurrent access |
| 12:18 |
signpost |
a second suggestion would be named pipes for IN and OUT. |
| 12:19 |
signpost |
one'd have to define the protocol these speak, probably pulled directly from already defined client commands. |
| 12:20 |
* |
signpost checks what PIPE_BUF is in limits.h and whether it's larger than largest pest message. |
| 12:21 |
signpost |
(because that way there isn't iirc risk of message interleaving on the pipes with concurrent outbound writes) |
| 12:23 |
signpost |
see `man 7 pipe` |
| 12:24 |
signpost |
before 2.6.11 kernel, 4096 bytes fixed. >=2.6.11 65536 bytes and configurable. |
| 12:24 |
signpost |
so yeah, that's at least possible. |
| 12:26 |
awt |
Seems like what I'd want to do is send all received messages to the pipe, skipping the short buffer and order buffer. |
| 12:26 |
signpost |
wouldn't services want to receive deduplicated messages though? |
| 12:26 |
signpost |
with e.g. deedbot I wouldn't want it hit with every duplicate of the same command |
| 12:27 |
* |
asciilifeform doesn't see wai you'd want to bypass the shortbuffer |
| 12:27 |
awt |
ah ok yeah, so would want to send each short buffer dump to the pipe. |
| 12:28 |
signpost |
yup, w/e a human client would also receive. |
| 12:28 |
signpost |
protocol behavior shouldn't change whether the human or another program is attached to blatta. |
| 12:28 |
* |
shinohai like idea of named pipes .... |
| 12:36 |
awt |
Now thinking about how GETDATA responses would be routed to theh pipe... |
| 12:37 |
signpost |
isn't that a pest protocol detail? |
| 12:38 |
asciilifeform |
yer prolly stuck exposing some protocol, in particularly msg hashes, if you want operator to be able to e.g. answer in past threads |
| 12:38 |
awt |
They wouldn't need to go through the order buffer because the mutable client could display them in the proper order. |
| 12:39 |
* |
signpost responding specifically to GETDATA; in what case would it be a UI's responsibility to issue that vs blatta itself |
| 12:39 |
signpost |
the client-side should think in terms of a threaded log, and expose API to interact with that threaded log |
| 12:39 |
awt |
signpost: UI would not be responsible. |
| 12:40 |
signpost |
message hashes definitely come through. |
| 12:40 |
signpost |
right, so doesn't need to go through the pipe unless I'm mistaken. |
| 12:42 |
awt |
signpost: in that case how would the mutable client get access to GETDATA responses? Query said API based on hashes of messages coming through the short buffer? |
| 12:43 |
signpost |
blatta would say "there is a child message of message $hash" in some manner. |
| 12:44 |
signpost |
to my mind the role of the pest server is to process the protocol on one side, and express mutatons on its core data structure (a threaded log) on the other. |
| 12:46 |
signpost |
in this model GETDATA is an implementation detail for how the server requests the data needed to fill in missing parts of the log. this shouldn't be something that gets initiated by services (deedbot, busybot, etc) connected to the server. |
| 12:48 |
signpost |
to client services, I'd expect them to be passed messages (including info which allows a client to position the message correctly) |
| |
↖ |
| 12:50 |
signpost |
doesn't mean nothing of pest protocol comes through. one'd want to peer, key, at, etc all from the client. |
| 12:50 |
signpost |
just means the server is trusted to handle the mechanics of the messaging protocol by itself, without unnecessary leakage of abstraction. |
| 12:52 |
* |
signpost bbl, invites awt, asciilifeform, and others to disagree if I've missed something. |
| |
~ 53 minutes ~ |
| 13:45 |
awt |
Ok. Lots to chew on here. |
| 13:46 |
awt |
Also need to think about how to rip out the order buffer and where it might go. |
| 13:49 |
awt |
Would want to rip out the IRC server AND the order buffer and move them into a separate script/server for IRC clients. |
| |
~ 6 hours 35 minutes ~ |
| 20:25 |
signpost |
in the wake of the chicago shooting I demand that all dangerous transvestites, transsexuals, and transylvanians be recorded in a national registry. |
| |
~ 20 minutes ~ |
| 20:46 |
awt |
Yes and a 3 year twitter history must be submitted as well |