Mail archive

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

From: Ted Trask <>
Date: Thu, 29 Nov 2012 10:44:03 -0800 (PST)

As part of the design of ACF, we have tried to keep it as simple as possible, so as to be compatible with as many browsers as possible. So, we have not used HTML5 or relied on javascript (as much as possible). Bootstrap relies on HTML5 and javascript, so I'm hesitant to include it. What makes Bootstrap appealing? Is it simply the responsive layout for mobile devices? From a technical standpoint, I'm not opposed to including it in a skin, just not in the core. I would like to keep the generated HTML as clean as possible, and allow skins to extend the functionality. V.Krishn had proposed creating a skin with the jquery-mobile framework ( for similar reasons of usability on mobile devices. He had made some progress, but he required changes to the ACF code to clean up the generated HTML. zelebar and I have also talked about cleaning up the HTML output, but have been too busy to make much progress. Hopefully it would be ready for Alpine Linux 2.6. Ted ________________________________ From: Jeremy Thomerson <> To: Jerry Jacobs <> Cc: Der Tiger <>; Natanael Copa <>; Alpine ACF <>; Alpine Developers <> Sent: Thursday, November 29, 2012 12:31 PM Subject: Re: [acf] Re: [alpine-devel] Ideas for a new config framework, ACF2 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 <> 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: > > > > >On 29 November 2012 17:36, Der Tiger <> 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@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: >>> >>> 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: >>> Help: >>> --- >>> >>> >> >> >> >> --- >> Unsubscribe: >> Help: >> --- >> > > >--- >Unsubscribe: >Help: >--- > >

Received on Thu Nov 29 2012 - 10:44:03 UTC