Skip to content

Latest commit

 

History

History
91 lines (74 loc) · 3.59 KB

2018-12-04-weekly.md

File metadata and controls

91 lines (74 loc) · 3.59 KB

sunrise choir - 04-12-2018

Attendees

  • pie
  • alj
  • mik

Agenda

  • checkins
  • how's alj going? What are his plans for more choir work?
  • alj going to scuttle summit?
  • getting clmr into usage?
  • what did alj and dominic go over on their call?
  • flume progress
    • quick walkthrough of the code
    • any notes from alj for the meeting tomorrow?
    • rubber ducky on thinking about the flume api.
      • is flumeview-query a query or a view?

Alj future plans

  • finish off the current work (message data formats)
  • then finish doing this as payed work, carry on doing it as hobby work. At least for now.
  • finishing off the data format will be covered in payment already made.

Alj + scuttle-summit

  • does have the time
  • does have the money
  • only has excuses
  • gonna do it!
  • can stay with mik

Get CLMR into usage

  • specced and implemented.
  • ~60% of space of legacy messages
  • would be good if sbot started using it.
  • we'd need js bindings
    • Dominic would need to be the one to do the rpc design.
    • Should be a dropin replacement for JSON.*
  • can Pie do the bindings?
    • should be pretty easy.
  • would force the gpl copyleft convo to happen.
  • alj is not blocked by getting bindings done.
  • mik: happy for Pie to pick up whenever it suits.
    • excited by flume.

Dominic + Alj call

  • got to ask lots of blocking questions that has made things much easier.
  • content might just be bytes, not json in the future. That's what dtarr wants in the future.

flume progress

  • written some traits that are maybe hopefully roughly what we want for a Log and a View
    • implemented the traits on an offset Log and a memory Log
    • reasonably well-tested
    • got benchmarks comparing the two
    • implemented an Iterator for both logs
    • got an Iterator over a buffered file for offset Log working

benchmark screenshot

  • a view gets each message exactly once and builds a "view" from all the messages.
  • you can ask a view questions which it can answer based on the indexes it has stored
  • alj: that's interesting what this means for programming language agnostic situations.
    • mik: that's why there might be a rpc-like interface
  • pie: are there better ways to do dependency-injection / wrapping functions than how dtarr does it?
  • pie: are there better ways to answer questions on data than flumeview-query or level or whatever?
    • we will talk to Matt and Mix tomorrow about which questions they need answered to build their apps
  • alj: how much is flume js-specific?
    • either we re-implement the same in Rust
    • or we standardize an RPC-based flume thing
    • doesn't make sense at the moment to go fully general, we don't know the plugin story yet
  • mik: the plugins do need to be re-written. That's why we're talking to mix and matt.
    • rust-sbot is a long way away. Goal is collaborate with app devs to get our stuff in there. If we can get Matt on board (rustifarian too.)
    • I don't have the answer for all the questions. Might be about cutting corners and people and what they're excited about.
  • alj: what about scuttleshell?
  • could jsbot rely on rust flume?
  • alj: we should co-operate more closely with cryptix.
  • pie: zoom out, should this be in or out of process?
    • go back and forth on this
  • piet: my github project is here: https://github.com/ssbrs/flumedb-rs/projects/1
  • mik: hopefully from talking to Mix and Matt (app devs), we can get a more clear story on what flume views are, or what we want them to be
  • alj: ordering. jsbot uses receive time.
  • pie: we should make flumeview-causality.
  • alj: what if it sorts by...