Give back models not strings

[ellisonbg]

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

[blink1073]

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.

[ellisonbg]

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 <notifications@github.com

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
#49 (comment)
.

Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgranger@calpoly.edu and ellisonbg@gmail.com

[Carreau]

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.

[ellisonbg]

Good idea

On Thu, Oct 29, 2015 at 2:11 PM, Matthias Bussonnier <
notifications@github.com> 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
#49 (comment)
.

Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgranger@calpoly.edu and ellisonbg@gmail.com

[blink1073]

@Carreau, what does the RTmodel consist of? I was seeing RT as a separate plugin providing an IContents interface.

[ellisonbg]

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 notifications@github.com
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
#49 (comment)
.

Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgranger@calpoly.edu and ellisonbg@gmail.com

[Carreau]

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.

[blink1073]

Based on discussions this week, we should revert back to string, correct?

[ellisonbg]

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 notifications@github.com
wrote:

Based on discussions this week, we should revert back to string, correct?

—
Reply to this email directly or view it on GitHub
#49 (comment)
.

Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgranger@calpoly.edu and ellisonbg@gmail.com

[blink1073]

Okay, let's leave this open and revisit. 

—
Sent from Mailbox

On Thu, Nov 5, 2015 at 8:49 AM, Brian E. Granger notifications@github.com
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 notifications@github.com
wrote:

Based on discussions this week, we should revert back to string, correct?

—
Reply to this email directly or view it on GitHub
#49 (comment)
.

Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub

bgranger@calpoly.edu and ellisonbg@gmail.com

Reply to this email directly or view it on GitHub:
#49 (comment)