[IPython-dev] custom web notebook cells

[Brian Granger]

OK, lots of great discussion here, going in many different directions,
I will try to keep up...

>> The notebook document format is sort of our contract with the
>> universe.  We want to be able to have an extremely precise and
>> testable definition of what constitutes an IPython notebook, so that
>> everyone can open them, share them, convert them, run them etc.  If we
>> allow custom cell types, all of that goes out the door, so I don't see
>> how we can support custom cell types.  The notebook document format
>> would stop being the notebook document format.
>
> I think I have to disagree with you,
> You could make the same remarks with custom joan handler.
> Actually if someone does not have the plugin they might not be able to see
> the json repr.

I view Javascript plugins in the same way as I view python packages:

* They have to be installed by the person who manages the notebook server.
* They are optional.
*  People who want to run notebooks that use various  plugins and
python packages will have to make sure they are installed.

These things are transient features of the notebook.  On the other
hand, there are certain things that will be entirely invariant over
all ipython notebook experiences in the universe:

* The notebook document format.
* The kernel messaging protocol (note that kernels can be different,
but they will all speak the same protocol).

> And also we have the metadata for people to store almost any information they want.
> Also you can imagine people can want custom cell even just to replace our ours for X
> reason.

I have started to become very concerned about the metadata.  Our
thinking so far has been: that metadata is complete unstructured.
IOW, users can write to the metadata section whatever they want.  When
nobody is doing that it works fine, but as more people start to use
the metadata, it is going to turn into the wild west.  There will be
conflicting metadata.  There will backwards incompatibilties.  We will
allow this for a while, but when users start to complain that there
notebooks don't work as expected, we will have to become extremely
conservative about the metadata.

Case in point: we are about to add a slideshow section to the cell
level metadata.  And the notebook UI will rely on this metadata being
in a very particular format.  If we *ever* change that metadata in the
future, we will have to increment the notebook document format version
to reflect it.  Some changes (adding a new attribute) won't be
backwards incompatible, but some might be and it will affect the
entire notebook document format.

> I don't think they ask us to support those different cell but to allow easier hooks to add them.
>
> But actually think the problem is what you call a **different cell**.
> One could have 2 different type of code cell and you can choose which one to get
> with the metadata.

I am open to using metadata to control how cells act.  We are already
doing this with the slide show and this may be a very powerful way of
moving forward.

>> But, I would like to learn more about your usage cases.  There might
>> be other ways of supporting what you want to do:
>>
>> * Use an existing cell type with metadata.
>> * Provide a custom UI for an existing cell type but don't change the
>> notebook format.
>> * Actually add a new cell type to the notebook format officially if it
>> is something that a majority of our users would use often.
>
> I guess there is a confusion between cell and cell/type.
> and looking a blocky it seem the desire cell here is a code-cell, but with
> visual programming where you move block.
>
>
>>
>>> to get my stuff in, i have used the setuptools iter_entry_points method I am
>>> familiar with... and defined a new entry_point, ipnotebook. plugins provide
>>> their list of assets and where one might find their static paths. can anyone
>>> comment on how this is (potentially) different from The IPython Way? The
>>> extensions stuff in the doc didn't look like they would be useful, so i gave
>>> up on trying to use that.
>>
>> I am very interested in learning more about this.  Right now my
>> jsplugins/handlers branch uses a pretty simple way of installing
>> additional Js code = a user just drops it into a special dir in the
>> .ipython directory.  It would be nice if these Js plugins were regular
>> python modules that could be installed as usual.  But something to
>> keep in mind:
>>
>> * We have to serve these files on the web.  I don't want to have our
>> web server walking all over a users system to pull files as that is a
>> huge security risk.  We need to isolate the location of these files.
>> * Some plugins don't have any python code so I am not sure it makes
>> sense to bundle things into a python package.
>> * We need to maintain the ability to install ipython without setuptool.
>>
>> Do you have ideas on how we can improve the user experience of
>> installing and managing Js plugins?
>>
>>> the structure of working with cells in master is pretty rigid right now,
>>> with the enumerated list of cells type in the code explicitly in the front
>>> end in several places, js and html. my initial work (in a addition to
>>> inadvertently recreating some of ellisonbg's work on the tornado app) has
>>> been to refactor all of those cases of adding buttons or whatever into
>>> something that looks at a window.IPython-scope plugin registry.... this is
>>> defined in cell.js right now, but maybe should be someplace else.
>>
>> That rigidity is merely a reflection of the notebook format.
> It is still pretty flexible as long as you respect the structure.
> there are already inconsistencies,
> But if you change code cell `code` field to `source` field then all the cell have almost perfectly the same structure.
> And this structure should be enough for almost any cell type.
>
> The subtleties going into metadata.
> --
> Matthias
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



--
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu and ellisonbg at gmail.com