Digest 2014-08-13

Welcome to the Federated Wiki conversation for August 13, 2014

(0) Ward mentioned that he demo'ed FedWiki on a GovLab hangout yesterday. See https://www.youtube.com/watch?v=FV0bXEnqxnU for YouTube recording of hangout.

(1) Joseph joined the call

  • He has experience working on Google Wave
  • Had  a tree of servers -- complicated
  • Team was huge, only 2 people working on federation
  • Were missing some simple things, like printing a wave
  • Some updates weren't getting through, so didn't know content had been updated
  • User graph was flattening out when Google killed it

(2) Ward did an interview on Google Wave
  • Wiki is slow motion
  • There's times when it speeds up
  • If three people are there, and don't want to wait, could speed up
  • Wave had this

(3) Joseph:  Wave was 1.1 million lines of Java
  • Team ramped up quickly

(4) Joseph has been working on share.js
  • Shouldn't need so much overhead, as did with Wave
  • Wave is an XML tree, with annotations
  • People then started to try to build Wave gadgets
  • e.g. a poll if you want to have dinner tonight
  • When that type of data was added, XML is terrible, it doesn't allow arbitrary semantic data, and text operations are hard
  • If have JSON object, and throw in a string, and then insert a key, and delete all of the keys, there will be a trailing comma
  • Have people write their own semantic pipes

(5) Hop onto the share.js web site?
  • Play with widgets
  • Sort widget
  • Let's do this a bit later, as people join this call in the first 5 to 10 minutes

(6) Paul has helped Ward advanced federated wiki, taking it out of a single file
  • Now has been working on node.js
  • Also advanced identity, persona

(7) Paul:  has been in computer for 30 years, was at British Telecom, took an early retirement
  • Every programming language back into the 1980s

(8)  Ward:  maybe we should plot a course to version 1.0

(9) David talked about Service Systems Thinking

(10) Joseph:  microformats

(11) We all tried http://sharejs.org/
  • This site is running on a old version of share.js, have added some features.
  • Client library and server library, talking through a browser channel.
  • Scroll down to the bottom of the page:  can reorder the trains.
  • If you go offline and then online, can synchronize.
  • There's a wiki demo (in the top bar ... Demos .....)
  • In the wiki demo, there's a markdown window on the left, results on the right
  • Moving around that wiki page, can lose track of the people:  don't have proper presence support
  • Since then, have added presence support, but it doesn't work with load-balanced servers, yet

(12)Seph does work with data visualization, D3
  • Planning to do more examples
  • Share is powering a lot more, integrated into D3
  • Arbitrary JSON structures
  • Any of us could be making modifications, and we could see all of the changes
  • Just rendering? Actually two-way
  • At http://charts.derbyjs.com:8080/, can manipulate data through sliders

(13) Joseph: If want to do collaborative text, want to see result as soon as striking the key
  • Would like to have the same with data binding
  • When the operation is acknowledged, then data model would remember

(14) Ward: Federated wiki as a JSON tree
  • Change in share.js is finer-grained?
  • Open an editor on a data structure (text or graphical), but while editing, make some adjustments, then done, and wiki could then save
  • Don't have to resolve as much in conflicts, as people write to own wikis
  • Can think about when we would edit live, back end services from my server, but for the duration of when the page is up, then could be a connection that wouldn't go through the usual wiki RESTful interface, but instead editor-to-editor, and then when done, go back into wiki as if I had done all of the editor
  • Yes, coordinate editors through a server
  • When to build with something like Git?
  • Seeing collaborative editing live, no conflict if can both see it
  • So, this is reducing the delay when the conflict is noticed
  • But does this scale? May not want the half-finished changes from someone else
  • At commit, want conflicts to occur
  • Real-time, each knows what the other is doing
  • Have different editors (of which most is done in the text editor)
  • If had share.js engaged, would know which server it's writing to, ready to engage
  • If knew the editor was there, could join
  • When done editing, could do editing, and not have to worry about stuff changing
  • Make all of the changes, and then copy-and-paste into share.js, then saving call back to server about the next text for the document
  • Could mark the document as complete or closed, so that others would know
  • Worry about sliding in and out of OT environment.  Workable?
  • Another option of deeper integration would be to have the whole document saved in share.js, and then have changes write to the document immediately
  • Not batch operation, think as one semantic change (which is what Wave did)

(15) In wiki on share.js, each page is a separate document
  • In fed wiki, every page could have a different markup, e.g. showing signals, or signal processing link
  • Then use share.js not for communicating signals, but instead for communicating signal processing, e.g. every 2 minutes

(16) Share.js doesn't save from one part of the tree to another part of the tree
  • Designed so people could have their own custom semantics, but most things can be expressed with JSON (although not rich text)
  • Share.js supports defined types
  • Have had some recent work on defining subtypes

(17) Embracing share.js for storage management?
  • Could do either way
  • In experience with wiki, found editing other people's work, since they put it in the right place
  • Thus, the first operation in federated wiki is "move"
  • Sorting trains example is a move
  • Share.js doesn't support moving items arbitrarily inside a tree, but the trains are part of a list
  • Jeremy's pet application is a collaborative to-do list, which can't be implemented because of the arbitrary nested link problem

(18) Nick joined, who got Ward into node
  • Have been working on web socket connections to hardware, low latency
  • Share.js might work in a similar way?

(19) Typing, fast and slow?  (A book, there?)
  • Thinking when fingers are going, and not thinking about how somebody else is doing
  • Identifying self as the first step? Thinking about what the other person is reading
  • Jamming, playing music together

(20) Joseph: On Google Wave, there's collaboration, and then on editing semantic content
  • Would use the root, and then branch conversations off a tree
  • Conversation tool, versus collaborative editing:  different protocols
  • Could use OT to do this, merging content, tranforming content, then properties if both edit or delete
  • Could have an OT type that created conflict markers
  • Slow merge on things that we don't want to collaborate on
  • Instead of keeping two edits on the same line, splitting into two lines, and then merging later?

(21) 3 years, had started with a partner working on OT
  • Pattern
  • Have been revisiting
  • In the past week, looking into merging independent action streams:  is merging A with B the same as B with A?
  • An abstract protocol
  • Could get some easy experience with share.js by taking existing editor and making it share.js aware
  • But share.js is a more powerful protocol?  Not thinking about keystrokes, but semantics instead
  • Slip in share.js overnight?

(22) Share.js is missing insertions, merges in real time
  • Share.js is already in node.js
  • Needs a real-time stream talking to the browser
  • Share.js needs to talk with a database to store, connect, update
  • Currently only MongoDB, there's a specified API

(23) Persistence from share.js in minutes or hours?  Could save on existing wiki infrastructure for longer-term storage
  • Using Port 80 for the RESTful interface
  • Just connect to a node module, through web sockets, sharing the same port without interferring?
  • Yes, could run on a different URL
  • Then could have a federated real-time wiki (something like Wave, then iPad could talk with PC, synchronize)

<< Meeting closed out >>

Here's a transcript of comings and goings from the Hangout, before closing the window
me        13:04
I've started an Etherpad at http://pad.s2t.org/p/2014-08-13
If you want to join the transcript, I'm taking notes at http://pad.s2t.org/p/2014-08-13
Ward Cunningham        13:19
me        13:21
The wiki for Service Systems Thinking is at http://s2t.org  , but most of the federated content is at http://fed.coevolving.com .
Joseph Gentle        13:26
Allen Byerly joined group chat.
Batu Les Iris joined group chat.
me        13:42
If you want to join the transcript, I'm taking notes at http://pad.s2t.org/p/2014-08-13
Batu Les Iris left group chat.
Batu Les Iris joined group chat.
Ward Cunningham muted Batu Les Iris.
Allen Byerly joined group chat.
Ward Cunningham blocked Batu Les Iris.
Paul Rodwell blocked Batu Les Iris.
Allen Byerly blocked Batu Les Iris.
Batu Les Iris left group chat.
Allen Byerly left group chat.
me        14:02
If you want to join the transcript, I'm taking notes at http://pad.s2t.org/p/2014-08-13
Joseph Gentle left group chat.
Paul Rodwell left group chat.
Ward Cunningham left group chat.

<< This content will be exported to http://fed.coevolving.com/view/welcome-visitors/view/digests-from-sfw-meetings >>