> 2) We probably need to come up with a strategy in which widgets can be configured/re-configured easily at runtime, so we don't need to centralize all of their configurations.
I think this can be done already, using the WidgetSettings property in config.js -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Nicolaas Matthijs Sent: Friday, 27 April 2012 1:17 AM To: Duffy Gillman Cc: [email protected] Production; OAE Development Subject: Re: [oae-production] [oae-dev] Dynamic Configuration - Code Contribution Hi Duffy, Yes, there is interest in this! Decoupling configuration from code has been on our wish-list for a long time, so this sounds like really valuable work, very much in line with what we were planning to do. Having to do a rebuild is not a great deployment solution for production deployment, and makes it harder/unfeasible to just pass jars around and then configure on top of that. De-coupling config_custom.js from the production build could have a similar effect, but asking operations to maintain their configurations in javascript/json files might not be ideal. I would definitely be interested in seeing your solution in action, perhaps a screencast could be really useful. In terms of the solution you describe, creating a rest-end point, as well as making it possible to load a default configuration from 3akai- ux make a lot of sense. A couple of quick initial questions/comments: 1) I'm assuming configuration changes can be made at runtime by doing a POST to this service? Because these don't happen regularly, it could be sufficient to give this URL a short caching lifetime (i.e. roughly 1 session) 2) We probably need to come up with a strategy in which widgets can be configured/re-configured easily at runtime, so we don't need to centralize all of their configurations. We'd also have to make sure that it's easy for widget developers (students, lecturers, etc.) to be able to add config options to their widgets. This is currently done in the widget config file (default configuration), and is then passed on to the widget when loaded. We should probably make it possible to adjust these configs at run-time as well. Have you given this any thought? 3) The fact that it's currently only possible to replace top level properties is slightly annoying, but I think that should do initially and can be solved further down the line. Hope that helps and thanks for sharing this. We should really try to get this incorporated, as it has the potential of making deployment a lot more straightforward. I'm CC'ing the oae-production list as they might have some useful input this as well ... Kind regards, Nicolaas On 26 Apr 2012, at 00:41, Duffy Gillman wrote: > Please forgive the long post. I've been working on new functionality > and realize it needs some daylight. I hope this format is digestible > and useful and that you will feel at liberty to ask questions to > help clarify anything that is made murky below... > > I'm looking to open a discussion about making configuration of 3akai- > ux more dynamic. I have done some work in this area and would like > to render it useful to the community.. That will require review and > discussion, and surely some revision to the work I've done. So let > me start with an introduction to the problems I am hoping I have > solved and a query to this list as to who needs to be involved in a > review. > > The goal of my work is to move away from per-customization revisions > to the 3akai-ux code base. If something truly is "configuration" it > would be nice to be able to apply it without requiring a rebuild of > 3akai-ux, without potentially rebuilding nakamura as well [1], and > without requiring a redeployment of new artifacts. There are good > reasons that configuration changes require a rebuild presently [2], > but as a long term strategy it would be best to separate > configuration from the build. Runtime configuration has additionally > been an expressed goal of many folks on this list. My work starts > down the path toward all of these goals. > > My work is comprised of a new nakamura bundle called dynamicconfig, > and alterations to the core Sakai API Javascript libraries in 3akai- > ux to take advantage of dynamicconfig. These modification are > presently based upon the 1.1 release but are available for review > publicly [3, 4]. I am willing to do the work to port this forward > and to issue appropriate PRs if there is interest among you folks. > The work presently functions and replaces config.js. I do have a > short list of known issues/directions for improvement that I include > in closing. > > Please share your thoughts and questions. I am eager for feedback > and hope this can benefit the project. > > How it Works > ------------------- > > Dynamicconfig creates a REST service that responds to requests at / > system/dynamic-config/config.json. It produces JSON output that is > digested by the UI code and is stitched into the Sakai API library. > In this way no widget code needs to change. The Javascript object > graph ends up looking precisely as it had before my dynamicconfig > work. > > The backend relies on a DynamicConfigurationService API that can be > implemented against whatever data store is suitable. I have made a > simple reference implementation that produces the in the following > manner: > > 1) A master configuration JSON file (path is configurable) is read > from the file system and is used as the basis for configuration. > 2) If the master configuration file is missing /dev/configuration/ > config.json is pulled from JCR and used. This allows a default > configuration to live in the 3akai-ux project. > 3) An overrides directory is processed. Any .json file in that > directory is merged into the configuration. > > The reference implementation is the simplest implementation I could > fathom that would meet the stated goals. There is plenty of room for > improvement. Ideally configuration would live in sparse of JCR. But > for now this is a usable implementation that I hope moves the bar > forward. > > Caching is still handled on the browser. Configuration will not > change frequently so it is desirable to let the browser use a cached > copy until a change occurs. To accomplish this the REST service > accepts GET requests for the configuration of the form: > > /system/dynamic-config/config.{hash value}.json > > No matter what the "hash value" is the result is the configuration > JSON object. But the "hash value" is reported by the dynamicconfig > service in response to a GET call, and it is guaranteed to stay > constant until the configuration changes. In this way the > configuration request can use the most recently reported "hash > value" and can be guaranteed fresh configuration if anything has > changed. The drawback is an additional GET with each page load. > > Additional methods have been stubbed out in the dynamicconfig > service to accept POST calls. These presumably would cause changes > to the configuration subject to authorization checks. At present > these methods preform no work but are available for override should > cycles be free to move beyond the reference implementation to a > richer, runtime dynamic, configuration service. > > Limitations/Known Issues > ----------------------------------- > > - [BUG] browser caching currently has zero net effect due to a > failure to respond to HEAD requests appropriately. Instead of > responding with header information HEAD requests presently return > *the entire configuration*. The browser still uses the cached copy, > but the data transmitted is equivalent to a full refresh of the > configuration. This should be a simple fix and would be expected > before issuing a PR to the community. > > - the reference implementation preforms a naive JSON merge which > replaces only top-level keys. This is not a bug, its just annoying. > This means override files may only presently replace top-level keys > in the configuration JSON, and must replace them in their entirety. > A better implementation would accept sparse paths to JSON keys deep > in a JSON object and would only override those keys leaving all > sibling data intact. This may be better undertaken as an improvement > when a Sparse or JCR implementation is pursued. > > - permitting GET/POST to individual configuration paths deep in the > configuration structure seems like an obvious extension to this work > which might permit finer grained loading and/or access control for > bits of configuration > > - review of the dynamicconfig work is needed to bring it into line > with community style and testing guidelines > > > * * * > > Thanks! I hope this is seen as a useful direction and I am pleased > for any attention folks can give it. > > -Duffy > > > [1] Technically one could get away without rebuilding nakamura, > though if one is managing revisions one might expect to rebuild > nakamura to ingest a new version of 3akai-ux. > > [2] Configuration currently requires a rebuild of 3akai-ux because > it is currently embodied in Javascript files which must be present > during the optimization and hashing phases of a release build. > > [3] > https://github.com/rSmart/nakamura/commit/5a8252eb1521da18dba87dd14db314eb6e2208d5 > > [4] > https://github.com/rSmart/3akai-ux/commit/6ffbbbb533a72f6b6bf325692cd338f308a20906 > > ------------------------------ > Duffy Gillman > Sr. Software Engineer > The rSmart Group, Inc. > > _______________________________________________ > oae-dev mailing list > [email protected] > http://collab.sakaiproject.org/mailman/listinfo/oae-dev _______________________________________________ oae-production mailing list [email protected] http://collab.sakaiproject.org/mailman/listinfo/oae-production Charles Sturt University | ALBURY-WODONGA | BATHURST | CANBERRA | DUBBO | GOULBURN | MELBOURNE | ONTARIO | ORANGE | PORT MACQUARIE | SYDNEY | WAGGA WAGGA | LEGAL NOTICE This email (and any attachment) is confidential and is intended for the use of the addressee(s) only. If you are not the intended recipient of this email, you must not copy, distribute, take any action in reliance on it or disclose it to anyone. Any confidentiality is not waived or lost by reason of mistaken delivery. Email should be checked for viruses and defects before opening. Charles Sturt University (CSU) does not accept liability for viruses or any consequence which arise as a result of this email transmission. Email communications with CSU may be subject to automated email filtering, which could result in the delay or deletion of a legitimate email before it is read at CSU. The views expressed in this email are not necessarily those of CSU. Charles Sturt University in Australia http://www.csu.edu.au The Chancellery, Panorama Avenue, Bathurst NSW Australia 2795 ABN: 83 878 708 551; CRICOS Provider Numbers: 00005F (NSW), 01947G (VIC), 02960B (ACT) Charles Sturt University in Ontario http://www.charlessturt.ca 860 Harrington Court, Burlington Ontario Canada L7N 3N4 Registration: www.peqab.ca Consider the environment before printing this email. _______________________________________________ oae-dev mailing list [email protected] http://collab.sakaiproject.org/mailman/listinfo/oae-dev
