Message-ID: <50B78EF5.6040006@arcor.de>
Date: Thu, 29 Nov 2012 17:36:05 +0100
From: Der Tiger <der.tiger.alpine@arcor.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
Precedence: list
MIME-Version: 1.0
To: Natanael Copa <ncopa@alpinelinux.org>
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
References: <20121129152317.69585a4f@ncopa-desktop.alpinelinux.org>
In-Reply-To: <20121129152317.69585a4f@ncopa-desktop.alpinelinux.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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.

- 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.

- 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.

- 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.

- 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.

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.

Personally, I'd prefer a slim, slick and lean HTML-only configuration
GUI with pages generated by the host rather than the client. 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.

Kind Regards, Tiger

[1] KISS = Keep it simple, stupid!

Am 2012-11-29 15:23, schrieb Natanael Copa:
> Hi,
>
> Me and Kaarle have been playing with the idea "what if we started with
> ACF from scratch today, how would it be?".
>
> We collected some ideas and have now come up with a fairly detailed
> plan for an ACF2.
>
> Some of the goals:
> * better security design
> * remove unnecessary complexity from modules
> * organize the libs better
> * fix concurrency - no race conditions
> * improve CLI interface
> * modernize web GUI (write the gui in javascript)
>
> For web frontend we have been talking of using existing frameworks like
> Backbone.js and RequireJS. For backend we have been talking about using
> things like augeas and using Lua tables to create data models.
>
> Kaarle has written are more detailed plan: http://www.datakunkku.fi/acf/
>
> This will require some massive work but I think we can do it. Hopefully
> it will be simpler to write models once the basic framework is in place.
>
> What do you think?
>
> -nc
>
>
> ---
> Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
> Help:         alpine-devel+help@lists.alpinelinux.org
> ---
>
>



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---