[IPython-dev] History

[Robert Kern]

[OT: *please* stop Ccing me. I am on the list!]

On 2/18/11 12:06 PM, Brian Granger wrote:
> On Fri, Feb 18, 2011 at 9:11 AM, Robert Kern<robert.kern at gmail.com>  wrote:

>> SQLite is more easily extended to also record outputs. You get a basic notebook
>> format practically for free!  :-)
>
> Some thoughts about this:
>
> * The history is a chronological picture of the command that happen on
> a particular engine session.
> * The notebook is a "spatial" picture of a subset of commands that is
> completely independent of a particular session.
> * The history can contain things that are not in a notebook (from a
> terminal IPython) and a notebook can contain things not in a history.
> * In the past, we have envisioned the notebook server as being a
> completely separate process/server than the kernel.  For examples, you
> could imagine a centralized notebook server for a group that is used
> by frontends/kernels running all over the world.
> * Notebooks are inherently multiuser (notebooks in a notebook server
> are associated with users, they can be shared, etc.).
>
> But...it is an interesting idea to combine the kernel and notebook
> server.  There could be some significant benefits for this, but it is
> definitely not the model we have been thinking.  Any ideas about how
> this would work?

The only thing that is fundamentally "multiuser" about a notebook is that one 
usually makes them to share with people. That sharing can take many forms, is 
frequently just for them to view, and often the only "other person" is yourself, 
six months later. None of that necessitates (or is even facilitated) by a server 
model, so I think that is a very limiting view and substantial overhead. 
Swapping files has worked pretty well for Mathematica, the Ur-notebook.

To use a buzzword, a more "social" notebook interaction like you are talking 
about is something that's valuable and does require a server, but this is 
something built on top of the fundamental notebook idea; it's not the notebook 
itself. I think if you are chasing just the social features, you're missing out 
on a large segment of use cases that can't support the overhead of a server.

As my smiley and "basic" indicated, I don't think that it's really a notebook, 
but it is an extension feature that I've wanted for a long time: record 
everything I execute and everything that's output. Less of a Mathematica 
notebook than a lab notebook. Given that all-inclusive history, I can write 
tools that let me extract the stuff I have been doing now and make a proper 
notebook whenever you get around to implementing one. :-)

Mostly, I hate needing to make decisions before I start. Don't make me decide 
whether I want this session to be a notebook or not before I even begin typing.

> One other thought:  possibly, something like the history storage
> format should be abstracted through an API that we could implement
> using sqlite/json/mongodb/etc.

I think you just need to flesh out the HistoryManager interface a little. I 
don't think it's worth making another interface.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco