I'm not convinced that writing a servlet for this is necessary (though I'm willing to be proved wrong).
If we fixed the issues with Sling-Initial-Content that cause us to set ignoreImportProviders:=json all the config info could be loaded to sparse as data by Sling's native methods. Then you could change the individual properties just like we do on any other content in sparse (you could even make a config editing widget). None of this is meant to undermine the work that's been done. It's a great goal that I'm happy to see us working toward. I just hope we aren't introducing a lot of unneccesary infrastructure to do something that's already provided for us. On Thu, Apr 26, 2012 at 10:12:15AM -0700, Duffy Gillman wrote: > Nicolaas, > > Thanks for the thoughtful feedback. I'll respond to some points inline > below: > > > 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. > > Operations will have to maintain configuration somewhere - ultimately in some > file. So the question is whether JSON is worse than other options (XML, > .properties, ... ?). Javascript is certainly a bad idea: it opens the > possibility of including logic (as is currently done) in the configuration > file. > > It is reasonable to argue that some format other than JSON may be more > familiar to to operations staff. JSON was the easy choice for now since it is > the wire format transmitted to the UI. If we need to change to another format > we need to consider that some work needs to be done to convert from the input > format to JSON. That becomes work more complicated if we use a flat format > like .properties instead of a hierarchical format like XML. A flat format > would require that we develop a method to encode/decode hierarchy, which I > argue would be more trouble for operations than using JSON. > > Is there a preference against using JSON that is strong enough to argue for > the additional effort to transcode from XML or .properties to JSON for > transmission or storage? > > > I would definitely be interested in seeing your solution in action, perhaps > > a screencast could be really useful. > > Good idea! I'll see if I can pull something together. > > > 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) > > That is the goal! I have created the POST endpoint [1] in the dynamic > configuration servlet. I have created an API method [2] to handle merging the > POSTed JSON into the configuration. But the current implementation [3] does > not support the POST call since the configuration is read directly files on > the server. I do not want to alter the configuration files that operations > has deployed. So for the current implementation the service is read only from > REST calls. It is dynamic in the sense that any change to the files on the > server will be reflected in the configuration. > > An implementation which uses sparse or JCR to store the configuration would > be better and should be pursued soon. This would better support > implementation of the POST REST call. Initial configuration could still be > read from the filesystem and pushed into the store. Subsequently POST > operations could update the configuration in the store without concern for > changing the deployed files. > > > 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? > > I agree. This is needed. Both config.json and i18n files need to be > configurable. Technically these can be handled now by issuing curl POSTs. But > if you thought javascript/json were a bad idea for operations try telling > them they need to issue a bunch of curl commands! > > Presently I am handling this awkwardly. I created a > ConfigurationOverrideService [4]. You can register bundles with this service. > When Sling reports that one of these bundles has started, any files in a > configured path on the filesystem are read. If the files are newer than the > JCR content the files are read and will override the JCR content. > > This is *not* an elegant solution. But it works given the current function of > nakamura and 3akai-ux. I definitely think this could be made better with the > dynamic configuration service. It would require replacing the information > obtained from the WidgetServlet with dynamic configuration, or would require > altering the backend service that supplies the widget data to WidgetServlet. > > i18n files are another matter. Perhaps the Sakai javascript widget API could > be revised to use JSON data for i18n instead of .properties file and i18n > could be folded into dynamic configuration as well. Otherwise the dynamic > configuration service could be extended to handle the .properties extension > as well and could have parallel logic for managing that format. > > > 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. > > Yes. This is absolutely in the "annoying, but it works" column. I get itchy > when I consider this. It will have to change soon. > > Thank you for your feedback and questions. I will see what I can do to create > a screencast so it is easier for people to digest/review this work. > > Cheers, > > Duffy > > [1] > https://github.com/rSmart/nakamura/blob/develop/bundles/dynamicconfig/src/main/java/org/sakaiproject/nakamura/dynamicconfig/servlet/DynamicGlobalConfigurationServlet.java#L117 > > [2] > https://github.com/rSmart/nakamura/blob/develop/bundles/dynamicconfig/src/main/java/org/sakaiproject/nakamura/api/dynamicconfig/DynamicConfigurationService.java#L19 > > [3] > https://github.com/rSmart/nakamura/blob/develop/bundles/dynamicconfig/src/main/java/org/sakaiproject/nakamura/dynamicconfig/file/FileBackedDynamicConfigurationServiceImpl.java > > [4] > https://github.com/rSmart/nakamura/blob/develop/bundles/dynamicconfig/src/main/java/org/sakaiproject/nakamura/dynamicconfig/override/ConfigurationOverrideServiceImpl.java > > ------------------------------ > Duffy Gillman > Sr. Software Engineer > The rSmart Group, Inc. > > _______________________________________________ > oae-dev mailing list > [email protected] > http://collab.sakaiproject.org/mailman/listinfo/oae-dev -- D. Stuart Freeman Georgia Institute of Technology
signature.asc
Description: Digital signature
_______________________________________________ oae-dev mailing list [email protected] http://collab.sakaiproject.org/mailman/listinfo/oae-dev
