bq. If it cost nothing, I'd be in favour, but if the ongoing maintenance is high then I think that it has to be retired at some time. All that's being argued about is "when".
There are several types of costs associated with the JSP UIs. For example, fixing security issues (HDFS-4901), and fixing webhdfs issues twice due to the divergences between trunk and branch-2. I have been one of the people maintaining JSP UI and webhdfs since 2.2, personally I think it is nice to get rid of the extra costs when it is appropriate. I think this is the right time to retire the old UI to reduce the costs of maintenance. The new UI has been around since 2.3 and it has stabilized through several releases. ~Haohui On Thu, Oct 2, 2014 at 10:01 AM, Steve Loughran <ste...@hortonworks.com> wrote: > On 1 October 2014 17:25, Allen Wittenauer <a...@altiscale.com> wrote: > > > > This is also an interesting precedent: Are we declaring that UIs are > defacto non-stable? Does this mean we can break the output of, e.g., count > or ls or whatever because they don't have stabilities associated with > them? What line is to be drawn here? IMO, difficulty in moving code is > NOT a sufficient reason to throw out the compatibility guarantees. It is > only an indicator that we as a community are taking too long getting out > releases. > > > > If we do this change, then it's pretty much open season on all > of other UI-incompatible changes sitting in trunk (and there are a > bunch….). Are we really ready to open the floodgates? > > > > > http://hadoop.apache.org/docs/r2.5.1/hadoop-project-dist/hadoop-common/Compatibility.html#Web_UI > > Web UI > ====== > Web UI, particularly the content and layout of web pages, changes > could potentially interfere with attempts to screen scrape the web > pages for information. > > Policy > ===== > > Web pages are not meant to be scraped and hence incompatible changes > to them are allowed at any time. Users are expected to use REST APIs > to get any information. > > > we're saying "REST is stable; UI flexible" > > w.r.t browser simulation; HtmlUnit even handles javascript in its > inside-JUnit4 test runs, negotiated connections &c. It can assess > basic functionality. Real browser testing can be done with Selenium > > the risk that AW is pointing out on the NN UI is that it has been > around and stable long enough that it predates webhdfs, and because > of its JSP-free view, has been amenable to scraping. Some people > probably are still using it. Does that mean we should keep it? If it > cost nothing, I'd be in favour, but if the ongoing maintenance is high > then I think that it has to be retired at some time. All that's being > argued about is "when". > > (BTW, this pushes for a REST-first policy on all future web work. Do > the stable API then make the human-friendly view a thin layer in front > of it) > > -- > CONFIDENTIALITY NOTICE > NOTICE: This message is intended for the use of the individual or entity to > which it is addressed and may contain information that is confidential, > privileged and exempt from disclosure under applicable law. If the reader > of this message is not the intended recipient, you are hereby notified that > any printing, copying, dissemination, distribution, disclosure or > forwarding of this communication is strictly prohibited. If you have > received this communication in error, please contact the sender immediately > and delete it from your system. Thank You. > -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
