References: <20121129152317.69585a4f@ncopa-desktop.alpinelinux.org>
In-Reply-To: <20121129152317.69585a4f@ncopa-desktop.alpinelinux.org>
Precedence: list
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii
Message-Id: <C4453D93-B8C1-40E9-8DE2-21C595C9F6D1@yahoo.com>
Cc: Alpine ACF <acf@lists.alpinelinux.org>,
 Alpine Developers <alpine-devel@lists.alpinelinux.org>
From: Ted Trask <ttrask01@yahoo.com>
Subject: Re: [alpine-devel] Ideas for a new config framework, ACF2
Date: Thu, 29 Nov 2012 10:57:48 -0500
To: Natanael Copa <ncopa@alpinelinux.org>

The proposed ACF2 seems to be a complete redesign to move from functional to=
 data-driven design. Unfortunately, the doc does not give any reasons why th=
is change is desired. What is the benefit? This change does not address any o=
f the goals listed below. Just as a style preference, I've always been a C/f=
unctional design guy, rather than C++/object-oriented guy. I find object-ori=
ented design more difficult to read and debug.

See further comments below.

On Nov 29, 2012, at 9:23 AM, Natanael Copa <ncopa@alpinelinux.org> wrote:

> Some of the goals:
> * better security design

What is wrong with the security of the existing ACF? What would you do diffe=
rently?

> * remove unnecessary complexity from modules

Can you give an example of the "unnecessary complexity" in the current ACF m=
odules?

> * organize the libs better

While I agree that the libs could be organized and, especially, documented b=
etter, what is the actual proposal here? There is nothing in the doc.

> * fix concurrency - no race conditions

This is a legitimate concern in the current ACF. The problem can be managed,=
 not solved, with a daemon in the same manner as proposed for ACF2. However,=
 there is nothing to prevent two users from overwriting each other's work.

> * improve CLI interface

I have done quite a bit of work for acf-core-0.15 to split out the web inter=
face from the ACF core. As far as I can tell, there is now nothing preventin=
g us from creating a functional CLI interface for ACF.

> * modernize web GUI (write the gui in javascript)

I don't agree that "The full client-side approach eliminates all possible HT=
ML-related security vulnerabilities". There is still a web server accepting t=
he same requests. Nothing prevents a malicious user from directly accessing i=
t.

I do agree that a single-page application has some advantages in user experi=
ence. However, there is nothing preventing us from creating a single-page ap=
plication based on the current ACF. Any action can return it's result as JSO=
N or as HTML without the surrounding skin/template.

> 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.

I have known about augeas for some time, and there is nothing preventing us f=
rom using it with the current ACF. However, I have not felt the need to, bec=
ause I have not created an ACF recently that could benefit from it. The exis=
ting ACF modules are working, so I have not felt the need to rewrite them.

This seems a good place to talk a bit more about the data-driven design, bec=
ause augeas seems to be the genesis of the idea. While augeas allows you to m=
odify the config files more safely, since it ensures the syntax is correct, I=
 think it is better suited as a backend underneath a functional front end.

The augeas.net/tour.html page gives the simple example of adding an entry to=
 the hosts file. The augeas user must know that a new entry can be added und=
er /files/etc/hosts/ and that it should have values for ipaddr, canonical, a=
nd alias[]. Isn't it easier to see a web page with an "Add entry" button and=
 an appropriate form? How can you automatically generate that button and for=
m based upon the augeas output? I think you would end up having to code the b=
utton and form into the model/view, which means you're going back to the fun=
ctional design of ACF.

I see no benefit to the data-driven design when it comes to a user-facing ap=
plication.

> 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.

I think it's pretty easy to write ACF modules.

As stated above, I think you would end up having to do the same work in ACF2=
 in order to get a user-friendly interface.

Sorry if the above sounds like a rant, but I legitimately don't understand t=
he benefits of the proposal.

Ted


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---