Mail archive
acf

Re: [acf] Re: [alpine-devel] Ideas for a new config framework, ACF2

From: Jeremy Thomerson <jeremy_at_thomersonfamily.com>
Date: Thu, 29 Nov 2012 11:31:00 -0600

I second the nomination for using Bootstrap for the HTML layout. I'd
highly recommend a responsive layout for management from mobile devices as
well.


On Thu, Nov 29, 2012 at 11:29 AM, Jerry Jacobs <
xor.gate.engineering_at_gmail.com> wrote:

> As a theme suggestion if people didn't already know the sleek and nice
> organised Twitter Bootstrap which saves the clutter from re-inventing
> the wheel again:
>
> http://twitter.github.com/bootstrap/
>
> On 29 November 2012 17:36, Der Tiger <der.tiger.alpine_at_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.
> >
> > - 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_at_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_at_lists.alpinelinux.org
> >> Help: alpine-devel+help_at_lists.alpinelinux.org
> >> ---
> >>
> >>
> >
> >
> >
> > ---
> > Unsubscribe: acf+unsubscribe_at_lists.alpinelinux.org
> > Help: acf+help_at_lists.alpinelinux.org
> > ---
> >
>
>
> ---
> Unsubscribe: acf+unsubscribe_at_lists.alpinelinux.org
> Help: acf+help_at_lists.alpinelinux.org
> ---
>
>



---
Unsubscribe:  acf+unsubscribe_at_lists.alpinelinux.org
Help:         acf+help_at_lists.alpinelinux.org
---
Received on Thu Nov 29 2012 - 11:31:00 GMT