[IPython-dev] thoughts on the notebook, alternative front-ends and remote editing

[Nicholas Bollweg]

My thought with this prototype is to get something out the door quickly
that others can look at, and start thinking about what "modeling
collaboration" looks like.

Once I have the REPL basics, and maybe an initial stab at faking widgets
into working against derby,  the real fun begins: what the hell is a
multiuser notebook? What UX will make it work, and not fail like google
wave? I have some thoughts, and as I show it to people, wheels start
turning.

As for my architectural choices: I like Derby (on racer on sharejs on
livedb on mongo/redis) because it gives me models, routes, pubsub,
templating, sessions, validation, url routes, operational transform, asset
packaging, and synthetic models (more below), but doesn't decide to
reinvent the whole ecosystem like meteor.

With both of them, though, you kinda buy into the whole thing, and it would
be hard to get off it... so maybe it's not a good choice for the real
solution... but it might be. Because eventually, you gotta write some
javascript. So I am not selling derby, really, but there is a lot of stuff
that I would be really sad to lose or have to reinvent.

How much does it rely on derby/nodejs being there ?
>

That would be, well, 100%. See above.

I've looked at opencoweb,and webalchemy, but didn't see how to make them
work for me easily. Specifically on coweb, love the multi backend concept.
But not much momentum. And... at the end of the day you still have to write
some javascript :P And then there's firebase...


> The proxy was one of the things I though about, but I'm not sure that
> completely the way we want to go.
> But let see.
>

Sheer laziness on my part: doing the proxy gave me all of the assets for
free, and those routes that I didn't care to re-implement (tree). I didn't
even bother to proxy websockets. When it's done, I'll even replace
/notebooks/ with the multi-user one for demo purposes..

That's nice, I really want to decouple the notebook model which is on disk
> to the on memory one.
>

I'm just working with what I find...again, the challenge is in modeling
collaboration. With a model of the collaboration


> I'm pondering not a list for cell, but actually dict of id-> cell plus a
> list of id order.
>
> that should make partial update simple.
>

As I am learning, you still must order it on the page! This is non-trivial,
once you start talking about moving stuff that corresponds to DOM, and
messing with people's viewports.

The approach I have taken in derby/racer/mongo is to model the notebooks in
one collection and the cells in another. Strong ID, good. The cells
maintain a simple reference to the notebook, and the reactive query plus
local filter and sorting handles the rest.

There are likely other solutions, but this gives me pretty good
robustness... or should, once I figure everything out.

thought ?
>
> I really want to think about user UI state that is synced vs the one that
> is not synced.
> For example I doubt the hidden state of cell toolbar should be synced.
>
> Same with collapse state of output area.
>

Yes. I mean, sync is interesting. Sync to whom? If you are personally
working on two windows, would you want to sync everything between the two
of them? Some things?

In derby, one is provided with several constructs that handle these cases:

   - THE MODEL is... well, the model. that persists. and is shared. and is
   versioned (but you can't touch the versions... yet)
   - _page is "this user using this url in this browser"
   - _session is "this user using this site"

For things like the state of the UI, if you really, really don't care about
it, just toss it in _page. It never even goes to mongo, i don't think.

Things you want to persist for a while: maybe _session.

But the magic thing is references. In a given scope (a route or a compnent)
you have a model. It is made of bits and pieces of those model above, but
none of them know where they are bound. Except when they need to, to serve
higher-level goals: right now, for example, my toolbar has the logic for
turning a DOM click into an insertion into the actual collection. THis is
ugly, and I need to do better, but because all the changes fire locally,
it's fast enough to replace jquery/backbone... and happens to get persisted
to the database.


> I don't think there is a compelling way to make _repr_javascript_ work
> with this, but widgets are *perfect* as they already work this way...
> though it may require adding an additional View.view_model if there are UI
> things that one would want to share among many users.
>
>
> reprjs make sens for "static widget" (mpld3m or Julia Gadfly) that allow
> in browser panning and zooming.
>

Sure: totally reasonable. I guess i meant, there's no way to make a
"static" widget work with multiuser/OT, which widgets might be reusable
whole cloth. But nothing that uses dirty tricks to talk to the kernel is
going to fly, not saying I've done that :P

I would really like building the structure of the notebook in a way that
> the realtime backend would be plug able.
>

Funny, just had that discussion with some colleagues. Agreed that an OT
standard-like spec would be ideal.


> WE also need to think carefully about the execution logic. I would like to
> have real-time where I would be able to execute, but the people I share
> with would not.
>

I haven't handled this case yet, but i think it should be possible to
prevent a specific user from changing a specific field in a document, in
this case the state of a cell


> I suppose we would need to bake login into RT framework. How do you handle
> that for now ?
>

In my proxy, i'm just using the existing password stuff. Once you get to
the RT views, you'll already have been authorized.


>
> Should we make a place just to discuss realtime collaboration ?
>

Might be in order. Are we talking IPEP, or something more informal? Is this
really a jupyter discussion?

Cheers!
Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20150305/c306ad5a/attachment.html>