Dear Nicolas, The review process for ELS17 is now complete. Your paper entitled "Radiance - A Web Application Environment" received a borderline score, and therefore we have not yet made a final decision about it. We kindly ask you to revise your paper according to the reviewers' comments that you will find attached to this email, and submit your revision by March 20th. On that date we will make the final decision and let you know whether your paper will be included in the symposium schedule. Please note the following: - If you are *not* interested in resubmitting your paper, please let me know as soon as possible so that I know not to wait for it (and that will free up a slot for other authors); - Should your paper not be accepted, you will still have the opportunity to present your work at ELS17 as a Lightning Talk. More details about this are going to be provided on the website soon. - The early-bird registration deadline for ELS17 is next Monday (3/13). The registration page can be found at http://2017.programming-conference.org/attending/registration. Note that if you are only going to attend ELS17 and not the rest of the conference you should select the "WS only" fee. Thank you for your interest in ELS17, I sincerely hope to see you in Brussels! Alberto Riva ELS17 Program Committee Chair ----------------------- REVIEW 1 --------------------- PAPER: 1 TITLE: Radiance - A Web Application Environment AUTHORS: Nicolas Hafner Overall evaluation: -1 (weak reject) ----------- Overall evaluation ----------- Radiance seems to be an interesting system. However, the paper doesn't detail it very much. It presents the concept of "interfaces", saying that it is easily implemented in Lisp, but doesn't tell how so. It is a topic worth expanding, especially in the context of the ELS. Similarly, resources are talked about very scarcely and it's hard to understand how they work from the paper. Finally, one of the supposed advantages of Radiance - the ability to have several applications coexist and share services, configured by a system administrator - is not explained at all. Are all applications forced to use the same implementation of a given interface or can each of them have its own implementation? How does the system avoid applications to interfere with each other, if it does at all? Is it possible to start, stop, update applications independently of each other? Which interface is offered to the administrator to manage the applications? Etc. Also the number of referenced works is very small, particularly works of other authors. Overall, I think the paper doesn't contain enough information to sufficiently explain Radiance to an unknowing audience. It should either be expanded to detail the points above, or it should focus on one specific aspect of Radiance and discuss it more thoroughly. Possibly, it should also compare Radiance or specific aspects of it to other known works. ----------------------- REVIEW 2 --------------------- PAPER: 1 TITLE: Radiance - A Web Application Environment AUTHORS: Nicolas Hafner Overall evaluation: 0 (borderline paper) ----------- Overall evaluation ----------- The area of "application frameworks" encompasses a lot -- from user interface templates to back-end server functions. While there are many out there, we still need better ones and deeper thinking about this kind of functionality. The author's system, Radiance, identifies an area which hasn't gotten much attention: frameworks appropriate for more than one application that runs in the same user environment, thereby encroaching onto the functionality that traditionally has been covered by operating systems, not by application frameworks. But the framework here is very, very narrow. It only provides functionality for configuring software modules to various hardware and software resources -- e.g. swapping one database for another in an application. And routing and dispatching for URLs. Fine if that's the functionality you need, but there's nothing beyond that. Two confusing aspects of the presentation: The section "Interfaces" leads one to expect some user interface facilities, but it is just talking about introducing a level of indirection to namespaces of functions. In the "Routing" section, it introduces "an internal representation, called a 'URI'", but it is completely unclear what relation that has, if any, to what the W3C calls a URI. ----------------------- REVIEW 3 --------------------- PAPER: 1 TITLE: Radiance - A Web Application Environment AUTHORS: Nicolas Hafner Overall evaluation: 1 (weak accept) ----------- Overall evaluation ----------- Probably worthy of presentation, after a few changes to make the case for this work stronger. For example: "even if you have two applications like a forum and a blog that were both written with the same framework, they are usually deployed in such a format, that you won’t feasibly be able to configure your system to allow both to share the same login and account information, or other kinds of data." This is not an example, it's a restatement of the (presumed) problem, why should the reader believe this? Are we really sure that there are no frameworks out there that solve this apparently simple problem? In section 2.1, it's not clear what the novelty of interfaces is. How are they different from generic functions? Figure 1: Why are some boxes rectangles and others diamonds? Diamonds are usually used to represent conditionals, but that doesn't seem to be the case here, since they have only one outgoing arrow. Section 2.3: again, what's the advantage of introducing URIs? It would seem that they are used to "abstract away" components of a web server, but the example in the paper suggests that the abstraction is not so transparent after all. The developer of the code in question would have to know that the server includes an authentication service identified by :AUTH, and that it includes a login page with the name "login". Where would the developer get all this information? And what happens if the authentication service is not present in a particular server instance? Overall, I think this could be an interesting demo, but the author should make an effort to show an example of a specific "real-world" problem and of how Radiance can solve it effectively.