View Source

A "pre- and post-transcript" of discussion between Colin, Antranig and Clemens.

Coloration:

Antranig

Clemens

Things we would like to ask about (from Antranig):

Experiences with Haverbeke's tools -

What aspects of CodeMirror's semantics were unhelpful and required the component to be wrapped?

CodeMirror treats the DOM as an ephemeral view. Webstrates' DOM is persistent. I might be able to adapt CodeMirror to reestablish it self based on its stored view in the DOM.

What aspects of ProseMirror's sync algorithm were found unhelpful?

Reconcile our ideas of "is/is not suitable for application to recursive data types"

I must admit I haven't completely understood the ProseMirror sync algorithm, but was struck by its focus on relatively flat text with some markup as data model

How the taxonomy expressed in VIGO has evolved in the years since 2009 (in particular, the distinction between "Views" and "Instruments")

I believe the concept of Views have faded into the background. They are just an object representing another object. So my thinking is much more aligned with your ideas now.

What we do have (suggested by Clayton some time ago) was the concept of a "materialization strategy" (which, when run in reverse, might be considered a "dematerialisation strategy). That is, this is what occurs when "model material" needs to be imaged into some external material (substance!) - which might be a database but even a "view" as traditionally conceived (the DOM). "Dematerialisation" might correspond to "instruments" - e.g. the stream of activities corresponding to mouse clicks needs to be transduced down into a stream of state. Our current challenge is to cast component configuration for the system itself as a "materialisation strategy" - then the system will be able to close upon itself as a self-contained declarative system (given components can themselves house transform and relay rules etc.)

I like this. Although I am not sure about materialisation/dematerialisation as it seems to imply that the stuff in the computer isn't material.

Yes, that is a very good point. It's hard really to account for what is "more material" or "less material" than another thing... but ideally we want the stuff "inside" the materialisation boundary to behave more similarly to stuff "on the outside" so ultimately the relationship, one hopes, would become a more symmetric one. Each person, I imagine, on seeing stuff being imported from the other side of the boundary might consider that it has been "materialised".

Is Michel still pursuing "instumental interaction"?

He is, yes!

You might enjoy reading this: http://www.csc.kth.se/utbildning/kth/kurser/DH3050/hcihist11/MichelBLonWegner.pdf

Get hold of the following:

Berlin, R., Klokmose, C.N. (2007). Undo in dynamic and distributed user interfaces. In DHRS 2007 Proceedings of the Sixth Danish Human-Computer Interaction Research Symposium. (Copenhagen, Denmark, November, 2007).

http://bit.ly/1Lxx6RN (warning: early and naïve paper)

Gjerlufsen, T., Klokmose, C. N., Eagan, J. R., Pillias, C. and Beaudouin-Lafon, M. (2011) Shared Substance: Developing Flexible Multi-Surface Applications. In Proceedings of the 29th international Conference on Human Factors in Computing Systems (Vancouver, BC, Canada, May 7-12, 2011). CHI'11. ACM, New York, NY, USA, 3383-3392.

http://bit.ly/1IR1zal

Excellent! DATA ORIENTATION with NODES and FACETS... we have wanted some good, shared names for a while (have tried to refer to "STATE ORIENTED PROGRAMMING" which has not really been intelligible)

Tony (the first author) had developed a really really cool framework (Substance) which we build upon in Shared Substance. He unfortunately never finished his PhD and got to write about it (beyond the couple of paragraphs in this paper)

Old sourceforge repo: http://substance-env.sourceforge.net

What could a CRDT achieve from the user point of view?

We didn't manage to get to this in call 1

Remember to talk about Self, and the issue of "divergence"

How behaviour is represented and synchronised - and the problem of dealing with DEFERRED as opposed to MANIFEST INTENTION (at a rough pass, we represent this as an attempt by the author to make a "static assertion" of the form formerly represented by jQuery.live() (now subsumed into jQuery.on()) rather than manifest handlers written into the DOM)

This presumably corresponds to the point in the mail, "supporting editing of behaviour with late binding"

The DOM is a RES EXTENSA and cannot effectively represent the RES POTENTIA - http://www.npr.org/sections/13.7/2011/01/03/132607500/an-hypothesis-res-potentia-and-res-extensa-linked-by-measurement

Brilliant!

An "ideological rant" about the idea of "substance" or "reality" in software https://wiki.fluidproject.org/display/fluid/If+What+We+Made+Were+Real

Clemens' notes

Different tools vs. different representations

How's the user 'ontology' defined.

I.e. types, properties and relationships.

How does/can it evolve?

Complex example of two representations: Code + UML

The question of how well the user has to understand the 'model'

Becomes a really tricky thing when it comes to merging

Graph of creators?

We didn't get to this in call 1

Clemens' notes on Harmonious Authorship from Different Representations

Questions

Is the fahrenheitHolder in fig 1 ephemeral?

When does relaying stop. Could the visualization on screen (through HTML) be based on relaying?

Similarly could the user interface (in fig 5) be based on relaying?

We dream that, one day, it can - see incredibly crude diagram: https://docs.google.com/drawings/d/1T1vO_cnrDg83-dxCSQRNqw6k_P53i3w2G3e4tzYXSSg/edit
(I don't have access to read this - have made public now, should be visible) Works!

Elaborate on "Another result from this correlation from user E's view, "the actual application itself" to be the target of authoring actions, in the style of Self's "the thing on the screen is the thing itself""

Elaborate on containment without dependency – same as transclusion (Nelson)?

From the point of view of the "design in extension" it is like transclusion in that the referenced material is brought into place "without dependency". However, from the point of view of "design in potential" the material is also brought into place into the space of aligned names such that it may be "advised" (in the AoP sense) during the inclusion. Because of this, arbitrary relationships can be set up between the included and including material, and the included material can also be arbitrarily transformed. So it is not strictly transclusion, since under that model, the included material is held to be "the same" as its source. cf the different forms of model relay - "implicit relay" sets up an analogue of transclusion (material is identical at source and target - whilst, as with transclusion, "knowably in more than one place"), whereas "explicit relay" allows the included material to be a transform of its source.

docs at https://github.com/amb26/infusion-docs/blob/FLUID-5249/src/documents/ModelRelay.md#implicit-model-relay-style - THIS IS JUST AN ANALOGY! We cannot yet set up these kinds of relationships outside the model realm (that is, between arbitrary configuration) - but this work will be part of what is called "the new renderer" &&& - work now in progress in some form or other for > 5 years but constantly expanding in scope... https://issues.fluidproject.org/browse/FLUID-5047

It does seem that some kind of "parameterization" is allowed for in some models of transclusion

Possible to create relays that is only active under certain conditions? E.g. for doing interactive stuff. "When the mouse cursor intersects and object create a relay [of something] until it doesn't intersect anymore"

Yes, possible under the "cellular model" - given each component can house relay rules linking arbitrary 3rd parties, relays may be brought into existence by constructing a housing component in response to a condition, which when destroyed when the condition is no longer met, will cause the relay to be torn down (this works now, but the reaction to conditions cannot yet be itself operated declaratively - part of the same work package as &&& above)

cf https://wiki.haskell.org/Yampa - a very different approach

Interesting points

"the representation is an exhaustive summary of the state that can be used to move it from place to place", "it should be possible to effectively move an application between systems or users by transmitting just its models"

"This implies that what has been previously thought of as "an application" has been endowed with a regular but free-form cellular-structure" (Relates to Shared Substance)