shinohai[asciilifeform]: hmmm
shinohai[asciilifeform]: $ticker btc usd
busybot[asciilifeform]: Current BTC price in USD: $19446.72
awt[asciilifeform]: Gm pestnet
awt[asciilifeform]: $ticker btc usd
busybot[asciilifeform]: Current BTC price in USD: $19526.05
signpost[asciilifeform]: morning awt!
awt[asciilifeform]: What would be an appropriate mechanism through which blatta could expose an "API" to a mutable client?
signpost[asciilifeform] could see several things being useful.
signpost[asciilifeform]: 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.
signpost[asciilifeform]: afaik sqlite's already plenty capable of concurrent access
signpost[asciilifeform]: a second suggestion would be named pipes for IN and OUT.
signpost[asciilifeform]: one'd have to define the protocol these speak, probably pulled directly from already defined client commands.
signpost[asciilifeform] checks what PIPE_BUF is in limits.h and whether it's larger than largest pest message.
signpost[asciilifeform]: (because that way there isn't iirc risk of message interleaving on the pipes with concurrent outbound writes)
signpost[asciilifeform]: see `man 7 pipe`
signpost[asciilifeform]: before 2.6.11 kernel, 4096 bytes fixed. >=2.6.11 65536 bytes and configurable.
signpost[asciilifeform]: so yeah, that's at least possible.
awt[asciilifeform]: Seems like what I'd want to do is send all received messages to the pipe, skipping the short buffer and order buffer.
signpost[asciilifeform]: wouldn't services want to receive deduplicated messages though?
signpost[asciilifeform]: with e.g. deedbot I wouldn't want it hit with every duplicate of the same command
asciilifeform doesn't see wai you'd want to bypass the shortbuffer
awt[asciilifeform]: ah ok yeah, so would want to send each short buffer dump to the pipe.
signpost[asciilifeform]: yup, w/e a human client would also receive.
signpost[asciilifeform]: protocol behavior shouldn't change whether the human or another program is attached to blatta.
shinohai[asciilifeform] like idea of named pipes ....
awt[asciilifeform]: Now thinking about how GETDATA responses would be routed to theh pipe...
signpost[asciilifeform]: isn't that a pest protocol detail?
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
awt[asciilifeform]: They wouldn't need to go through the order buffer because the mutable client could display them in the proper order.
signpost[asciilifeform] responding specifically to GETDATA; in what case would it be a UI's responsibility to issue that vs blatta itself
signpost[asciilifeform]: the client-side should think in terms of a threaded log, and expose API to interact with that threaded log
awt[asciilifeform]: signpost: UI would not be responsible.
signpost[asciilifeform]: message hashes definitely come through.
signpost[asciilifeform]: right, so doesn't need to go through the pipe unless I'm mistaken.
awt[asciilifeform]: 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?
signpost[asciilifeform]: blatta would say "there is a child message of message $hash" in some manner.
signpost[asciilifeform]: 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.
signpost[asciilifeform]: 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.
signpost[asciilifeform]: to client services, I'd expect them to be passed messages (including info which allows a client to position the message correctly)
signpost[asciilifeform]: doesn't mean nothing of pest protocol comes through. one'd want to peer, key, at, etc all from the client.
signpost[asciilifeform]: just means the server is trusted to handle the mechanics of the messaging protocol by itself, without unnecessary leakage of abstraction.
signpost[asciilifeform] bbl, invites awt, asciilifeform, and others to disagree if I've missed something.
awt[asciilifeform]: Ok. Lots to chew on here.
awt[asciilifeform]: Also need to think about how to rip out the order buffer and where it might go.
awt[asciilifeform]: Would want to rip out the IRC server AND the order buffer and move them into a separate script/server for IRC clients.
signpost[asciilifeform]: in the wake of the chicago shooting I demand that all dangerous transvestites, transsexuals, and transylvanians be recorded in a national registry.
awt[asciilifeform]: Yes and a 3 year twitter history must be submitted as well