services
services copied to clipboard
jupyter-attic
Give back models not strings
The IContentsModel.content attribute needs to return a model object for the notebook of text file rather than the actual string. Some implementations of the content service will not even have a string representation. The challenge is that we have not yet written the interfaces or implementations for the Notebook and Textfile yet. But I am hesitant to call this 1.0 in the current state. Sorry I had missed this one. Pinging @Carreau
If I am understanding correctly, these two lines need to be changed to a richer object model: https://github.com/jupyter/jupyter-js-services/blob/master/src/contents.ts#L121 https://github.com/jupyter/jupyter-js-services/blob/master/src/contents.ts#L47
I think they'd need to be any, because it could be a string, a JSON notebook object, or some other unknown representation.
Yes, I think for now that any would work fine in the interface. In the
long run though, we will need to figure out how to get an actual
NotebookModel or FileModel back.
On Wed, Oct 28, 2015 at 10:49 AM, Steven Silvester <[email protected]
wrote:
If I am understanding correctly, these two lines need to be changed to a richer object model:
https://github.com/jupyter/jupyter-js-services/blob/master/src/contents.ts#L121
https://github.com/jupyter/jupyter-js-services/blob/master/src/contents.ts#L47
I think they'd need to be any, because it could be a string, a JSON notebook object, or some other unknown representation.
— Reply to this email directly or view it on GitHub https://github.com/jupyter/jupyter-js-services/issues/49#issuecomment-151869609 .
Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub [email protected] and [email protected]
I think we could think about a
{
model?:RTmodel
raw_data?:string
}
To make work for people not using realtime easy and transition easier.
Beyond NotebookModel or FileModel I think that non-RT model for binary blob should also be considered.
Good idea
On Thu, Oct 29, 2015 at 2:11 PM, Matthias Bussonnier < [email protected]> wrote:
I think we could think about a
{ model?:RTmodel raw_data?:string }
To make work for people not using realtime easy and transition easier.
Beyond NotebookModel or FileModel I think that non-RT model for binary blob should also be considered.
— Reply to this email directly or view it on GitHub https://github.com/jupyter/jupyter-js-services/issues/49#issuecomment-152270104 .
Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub [email protected] and [email protected]
@Carreau, what does the RTmodel consist of? I was seeing RT as a separate plugin providing an IContents interface.
Its won't be RTModel, just Model, but it will either be INotebookModel or IFileModel
On Thu, Oct 29, 2015 at 3:17 PM, Steven Silvester [email protected] wrote:
@Carreau https://github.com/Carreau, what does the RTmodel consist of? I was seeing RT as a separate plugin providing an IContent interface.
— Reply to this email directly or view it on GitHub https://github.com/jupyter/jupyter-js-services/issues/49#issuecomment-152292067 .
Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub [email protected] and [email protected]
Sure, IModel or RTmodel, sorry for the confusing name, I was just trying to convey the interface things should expose.
The way I did it was building everything as a Real Time Syncronized model, and just have the non real-time expose the same API with potentially no-op operation where unnecessary.
Based on discussions this week, we should revert back to string, correct?
I think so, but I am a little hesitant about this part of the API given that we are haven't built everything around it.
On Wed, Nov 4, 2015 at 9:18 AM, Steven Silvester [email protected] wrote:
Based on discussions this week, we should revert back to string, correct?
— Reply to this email directly or view it on GitHub https://github.com/jupyter/jupyter-js-services/issues/49#issuecomment-153734680 .
Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub [email protected] and [email protected]
Okay, let's leave this open and revisit.
— Sent from Mailbox
On Thu, Nov 5, 2015 at 8:49 AM, Brian E. Granger [email protected] wrote:
I think so, but I am a little hesitant about this part of the API given that we are haven't built everything around it. On Wed, Nov 4, 2015 at 9:18 AM, Steven Silvester [email protected] wrote:
Based on discussions this week, we should revert back to string, correct?
— Reply to this email directly or view it on GitHub https://github.com/jupyter/jupyter-js-services/issues/49#issuecomment-153734680 .
Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub
[email protected] and [email protected]
Reply to this email directly or view it on GitHub: https://github.com/jupyter/jupyter-js-services/issues/49#issuecomment-154062770