Mailing-List: contact hdfs-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-dev@hadoop.apache.org
Received-SPF: pass (athena.apache.org: domain of stevel@hortonworks.com
 designates 209.85.223.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <E1003598-AB83-4AC1-8D4A-1DB2610E0C44@altiscale.com>
References: 
 <CABbyifOadQ77tuU3LvGPEVo=xUrCo4UijQVC0QOaZaqqmaySvg@mail.gmail.com>
	<CADdVdVFLdEsiG4d2n_rXuRDNOpyxwO-L0XNTq8rib3j4fUH6YQ@mail.gmail.com>
	<CABbyifN4RLY_gV0Kc7iMTF17nd8fuKOQMZO=vnoBUCkzabSG4Q@mail.gmail.com>
	<6E267278-58B9-43D6-A161-8727804E9581@altiscale.com>
	<A7741F40-C4FF-47FB-B023-C2BAFCC23939@hortonworks.com>
	<E1003598-AB83-4AC1-8D4A-1DB2610E0C44@altiscale.com>
Date: Thu, 2 Oct 2014 10:01:54 -0700
Message-ID: 
 <CA+4kjVsXK4Tw7baF3hkAr4DnQLhKamEnQZPdEy5K958fXJw8vw@mail.gmail.com>
Subject: Re: [DISCUSS] Resolving the divergences for web-related code between
 branch-2 and trunk
From: Steve Loughran <stevel@hortonworks.com>
To: "hdfs-dev@hadoop.apache.org" <hdfs-dev@hadoop.apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 1 October 2014 17:25, Allen Wittenauer <aw@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=E2=
=80=A6.).  Are we really ready to open the floodgates?


http://hadoop.apache.org/docs/r2.5.1/hadoop-project-dist/hadoop-common/Comp=
atibility.html#Web_UI

Web UI
=3D=3D=3D=3D=3D=3D
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
=3D=3D=3D=3D=3D

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)

--=20
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to=
=20
which it is addressed and may contain information that is confidential,=20
privileged and exempt from disclosure under applicable law. If the reader=
=20
of this message is not the intended recipient, you are hereby notified that=
=20
any printing, copying, dissemination, distribution, disclosure or=20
forwarding of this communication is strictly prohibited. If you have=20
received this communication in error, please contact the sender immediately=
=20
and delete it from your system. Thank You.