On Thu, Nov 29, 2012 at 12:44 PM, Ted Trask <ttrask01@yahoo.com>= wrote:

As part of the design of ACF, we have tried to keep it as simple as p= ossible, so as to be compatible with as many browsers as possible. So, we h= ave 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 ma= kes Bootstrap appealing? Is it simply the responsive layout for mobile devi= ces?

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 al= low skins to extend the functionality.

V.= Krishn had proposed creating a skin with the jquery-mobile framework (http://jquerymobile.com/<= /a>) for similar reasons of usability on mobile devices. He had made some p= rogress, 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 Thomer= son <jer= emy@thomersonfamily.com>
To: Jerry Jacobs <xor.gate.engi= neering@gmail.com>
Cc: Der Tiger <der.tiger.alpine@arcor.de>; Natanael Copa <ncopa@alpinelinux.org>;= Alpine ACF <acf@lis= ts.alpinelinux.org>; Alpine Developers <alpine-devel@lists.alpinelin= ux.org>
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 Bootstra= p for the HTML layout. =A0I'd highly recommend a responsive layout for = management from mobile devices as well.

On Thu, Nov 29, 20= 12 at 11:29 AM, Jerry Jacobs <xor.gate.engin= eering@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@arcor.de= > wrote:
> Hi Natanael,
> Hi Kaarle,
>
> Thanks for the comprehensive project plan! I fully agree, the current<= br> > 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 an= d
> 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 si= ngle
> machine, simultaneously. Therefore, there is no significant server
> performance benefit to be expected from outsourcing HTML page formatti= ng
> to the client side. ACF is not a "common user" interface. >
> - Using JavaScript would introduce another programming language requir= ed
> 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<= br> > 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<= br> > and the internet in order to make some websites work, where there is n= o
> 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 displaye= d.
> It is likely, there are devices like PDAs or mobile phones, that won&#= 39;t
> be able to handle certain JavaScript initiated reformatting of web pag= es
> correctly. Admins do frequently use PDAs to reconfigure their servers<= br> > 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 fo= r
> 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 Java= Script
> 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.&= quot; I've
> largely experienced this to be true.
>
> Personally, I'd prefer a slim, slick and lean HTML-only configurat= ion
> GUI with pages generated by the host rather than the client. But than<= br> > again, I'm just an old f@rt, who has no appreciation for "mod= ern",
> 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 =3D 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 sta= rted with
>> ACF from scratch today, how would it be?".
>>
>> We collected some ideas and have now come up with a fairly detaile= d
>> 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. Hope= fully
>> it will be simpler to write models once the basic framework is in = place.
>>
>> What do you think?
>>
>> -nc
>>
>>
>> ---
>> Unsubscribe: =A0alpine-devel+unsubscri= be@lists.alpinelinux.org
>> Help: =A0 =A0 =A0 =A0 alpine-devel+help@lists= .alpinelinux.org
>> ---
>>
>>
>
>
>
> ---
> Unsubscribe: =A0acf+unsubscribe@lists.alpinelinux.o= rg
> Help: =A0 =A0 =A0 =A0 acf+help@lists.alpinelinux.org > ---
>

---
Unsubscribe: =A0acf+unsubscribe@lists.alpinelinux.org
Help: =A0 =A0 =A0 =A0 acf+help@lists.alpinelinux.org
---