-
Notifications
You must be signed in to change notification settings - Fork 141
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Filter rcloud extensions, take 2 #1609
base: develop
Are you sure you want to change the base?
Conversation
you can only .then() a function, not a promise upgrading bluebird caught this
perhaps a poor name, but the idea is that when we initialize a session, we say what kind of session we need, and only the appropriate extensions are loaded
What @s-u and I discussed... a long time ago... was to use the existing
This means e.g. changing if (mode %in% cs.modes) { ## use fork only in modes that require it https://github.com/att/rcloud/blob/develop/rcloud.support/R/ocaps.R#L88 to a union operation, etc etc. And removing most of the virulent interface changes in the current PR (yay). |
I'll clean this up soon and pass back to @s-u for review. |
can cause CSS problems, etc. still not the extension-flags feature we want (#1609)
This seemed potentially too disruptive for the point release - could have strange effects for third-party extension developers, and we also need to make sure they know about the tags they need for the DESCRIPTION file. For now, we've disabled extensions also for mini.html (see commit above). Hope to fix this up and merge to develop soon for 1.5. |
This replaces #1361.
Currently we are only deactivating rcloud extensions for notebook calls. We should allow each session to specify, when it is initialized, which types of extensions should be loaded.
I have resurrected an old branch for this, which was not stable enough for 1.3. The idea is to have a set of flags in the DESCRIPTION file of each RCloud extension, which say what kinds of functionality the extensions provides. Then, after doing the usual per-instance and per-user filtering, these flags are intersected with the flags specified for session.init.
This is _not ready for merge_, since it introduces an unnecessary extra flag which was changing function signatures and wreaking havoc everywhere. As suggested by @s-u, we already have a flag for this, but that one needs to be upgraded to a vector of flags. So far I've just merged develop into this branch, so that we have an active PR for 1.4.3.