Date: Fri, 30 Nov 2012 15:40:31 +0100
From: Natanael Copa <ncopa@alpinelinux.org>
To: Der Tiger <der.tiger.alpine@arcor.de>
Cc: Alpine ACF <acf@lists.alpinelinux.org>, Alpine Developers
 <alpine-devel@lists.alpinelinux.org>
Subject: Re: [alpine-devel] Ideas for a new config framework, ACF2
Message-ID: <20121130154031.0b4de943@ncopa-desktop.alpinelinux.org>
In-Reply-To: <50B78EF5.6040006@arcor.de>
References: <20121129152317.69585a4f@ncopa-desktop.alpinelinux.org>
	<50B78EF5.6040006@arcor.de>
Precedence: list
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Thu, 29 Nov 2012 17:36:05 +0100
Der Tiger <der.tiger.alpine@arcor.de> wrote:

> Hi Natanael,
> Hi Kaarle,
> 
> Thanks for the comprehensive project plan! I fully agree, the current
> ACF is good work, but needs overhauling, due to the problems stated in
> the proposal. At this stage, I am just not sure if using JavaScript and
> introducing client-side GUIs would be wise choices.
> 
> - ACF is a configuration framework. IMHO, the configuration of most
> Alpine systems is usually done by a single admin or at least a small
> number of admins, who usually won't do administration work on a single
> machine, simultaneously. Therefore, there is no significant server
> performance benefit to be expected from outsourcing HTML page formatting
> to the client side. ACF is not a "common user" interface.

Performance is not really what we want to address.
 
> - Using JavaScript would introduce another programming language required
> besides shell scripting and LUA to write ACF applications and modules.
> Not every programmer interested in Alpine Linux is capable or willing to
> handle an extensive number of programming languages in order to write
> packages for Alpine Linux. The higher the required number of languages,
> the fewer the number of people able and willing to contribute.

Yes, but what if you want contribute with your GUI expertise, know html
and javascript, but have no idea of Lua, nor any interest in it?

By separating the backend from the GUI you can contribute with one of
the parts without knowing the other. You can contribute with Lua
backend and let the GUI ppl do the GUI.
 
> - JavaScript is considered by all internet security majors to be a
> potential security risk. This is not only due to security bugs in
> various browsers (e.g. Chrome), but also due to the complexity of
> JavaScript interaction with servers. Most companies filter JavaScript in
> their local nets and allow it only on secure channels between clients
> and the internet in order to make some websites work, where there is no
> alternative method available than a client script (e.g. large volume
> data browsing). Using JavaScript for configuration of a local
> environment does compromise this security strategy.

I don't think we want any javascript on server. But you do have a point
that we need to also think about the client security.

> - JavaScript adds complexity to the HTML page transmitted and displayed.
> It is likely, there are devices like PDAs or mobile phones, that won't
> be able to handle certain JavaScript initiated reformatting of web pages
> correctly. Admins do frequently use PDAs to reconfigure their servers
> and routers or to look up some configuration on these devices. Also
> there is the issue of DHTML incompatibilities between browsers.

I think all smartphones today supports javascript? When we started with
ACF there was a discussion about using javascript and ajax. (web 2.0
was a hot topic at that time). Back then we decided to not use it and
we wanted it to be able to run on any without javascript. Some
javascript was bolted on later.

I think that the world looks different today than it did back then and
now is the time to embrace javascript - for client only.
 
> - KISS [1], as you certainly know. The more components are required for
> the ACF to work, the higher the risk the next update will render the
> system inoperable. And there are already JSON, LUA, minihttpd and
> various other components involved.

Well, part of the motivation for the rewrite is to have it more
modularized with clean and well defined APIs so that you can change
components without breaking stuff.

> I, admittedly, do have strong reservations regarding both, Java and
> JavaScript. A co-worker once eloquently put it to: "Java and JavaScript
> in 99% of all cases are used by programmers to work around problems,
> they either don't understand or don't care to solve properly." I've
> largely experienced this to be true.

Java is completely out of the question. I believe that javascript has
its place - for the GUI.

> Personally, I'd prefer a slim, slick and lean HTML-only configuration
> GUI with pages generated by the host rather than the client. 

I think that a page with multiple http requests for each component,
while still easliy being slow, adds value in form of separation. The
backend will not need to worry about html. Each request ask for smaller
pieces. Makes it easier to do privilege separation.

> But than
> again, I'm just an old f@rt, who has no appreciation for "modern",
> blinking, multi-layered and high colour pop-up interfaces, that are as
> slow as a snail and close to indistinguishable from any given first
> person shooter action game.

To be honest, I think the value of experience is often underestimated
and I hope we don't get blinking multi-layered and high color pop-up
html5 interface that is slow as a snail :)

Thanks for your feedback!
 
> Kind Regards, Tiger


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---