search

jupyter / colaboratory

[deprecated] Jupyter CoLaboratory, goto google colab now
https://colab.research.google.com
BSD 3-Clause "New" or "Revised" License
740 stars 111 forks source link

Proposal : substitute Google Drive by remoteStorage. #104

Closed almereyda closed 7 years ago

almereyda commented 10 years ago

remotestorage.js allows self-hosted per-user storage.

Please consider it over maintaining a Google Drive integration. It also takes care of that, including Dropbox.

I am sure @michielbdejong, @galfert and @skddc can give fruitful advice, if only pointers, if needed. There's also a community discourse.

raucao commented 10 years ago

Google Drive and Dropbox are still in experimental stage, but we'll be glad to support any integration efforts and improve our implementation in the process. If this finds open ears, just ping us with any questions whatsoever!

marksandler2 commented 10 years ago

It is an interesting proposal, and i quickly glanced at remotestorage. It seems that the main obstacle is that colaboratory is geared towards realtime collaboration - changes on your screen are visible on other's immediately, whereas remotestorage is geared more towards traditional version control model. (Correct me if i am wrong!)

In particular our model, require a tree-like document model, with listeners receiving updates on parts of the documents that are being changed.

While there are circumstances when version model is more preferrable than realtime model, at this point we are unlikely to switch over, though it is certainly something that we are interested in addition to realtime model.

m

On Thu, Sep 18, 2014 at 9:16 PM, Sebastian Kippe notifications@github.com wrote:

Google Drive and Dropbox are still in experimental stage, but we'll be glad to support any integration efforts and improve our implementation in the process. If this finds open ears, just ping us with any questions whatsoever!

— Reply to this email directly or view it on GitHub https://github.com/jupyter/colaboratory/issues/104#issuecomment-56133567 .

almereyda commented 10 years ago

Well, the real-time synchronization part could maybe be handled by some socket.io'ish, or WebRTC layer?

Further on, ChronoSync (paper), implemented in ChronoChat-js could be one of the many approaches leading to future developments. Like combining different layers for different tasks : rS for data retention and and interactive layer for collaboration.

@skddc Does your statement still apply that rS is just not designed for real-time?

raucao commented 10 years ago

Yes, real-time data transfers should be handled by WebRTC. And yes, I think although it's perfectly feasible in theory, at the moment we don't support real-time collab use cases very well, because you'd have to conceptualize and implement these mechanisms from scractch yourself as an app developer.

marksandler2 commented 10 years ago

It is not sufficient to have low level routines for realtime communications such as socket.io. It is much more important to have a good well defined model for realtime documents, with conflict resolution, partial update models, and tracking distributed changes.

On Fri, Sep 19, 2014 at 10:36 AM, Sebastian Kippe notifications@github.com wrote:

Yes, real-time data transfers should be handled by WebRTC. And yes, I think although it's perfectly feasible in theory, at the moment we don't support real-time collab use cases very well, because you'd have to conceptualize and implement these mechanisms from scractch yourself as an app developer.

— Reply to this email directly or view it on GitHub https://github.com/jupyter/colaboratory/issues/104#issuecomment-56209192 .

almereyda commented 10 years ago

I see. Until rS couldn't offer a reference implementation of how it would go together with real-time models (i.e. Operational Transformation or Differential Synchronization ?), there's no chance to use it as a drop-in replacement for Google Drives realtime capabilities.

Close at will. Or we rename the issue like Laverna to something like Sync to non-commercial storage and leave it open.

KesterTong commented 10 years ago

There is currently work being done on modifying IPython to allow for other storage backends, both realtime and non-realtime. So far it is only up to the non-realtime. The bigger plan is to add support for other file management backends (both realtime and non-realtime) to IPython/Jupyter. I think it would be better to focus efforts on this long term plan than on making coLaboratory more flexible.

See https://github.com/ipython/ipython/pull/6351 for the work so far, we are currently creating a new PR because of technical issues with that PR's git history. I would welcome comments and contributions to this work in progress, although it is in very early stages so far, so there will be plenty of time before the code reaches its final form.

rgbkrk commented 7 years ago

This version of colaboratory is no longer supported, please switch to https://colab.research.google.com.