X-Original-To: alpine-devel@lists.alpinelinux.org Delivered-To: alpine-devel@mail.alpinelinux.org Received: from nm39-vm6.bullet.mail.bf1.yahoo.com (nm39-vm6.bullet.mail.bf1.yahoo.com [72.30.239.150]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.alpinelinux.org (Postfix) with ESMTPS id 33FA0DC02FC for ; Thu, 29 Nov 2012 18:44:04 +0000 (UTC) Received: from [98.139.215.141] by nm39.bullet.mail.bf1.yahoo.com with NNFMP; 29 Nov 2012 18:44:03 -0000 Received: from [98.139.212.207] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 29 Nov 2012 18:44:03 -0000 Received: from [127.0.0.1] by omp1016.mail.bf1.yahoo.com with NNFMP; 29 Nov 2012 18:44:03 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 729461.59897.bm@omp1016.mail.bf1.yahoo.com Received: (qmail 56573 invoked by uid 60001); 29 Nov 2012 18:44:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1354214643; bh=8b/9ee/9cHSLBF9jqgl5q/uHKUFyed2YHq7u+r4Jc5o=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=U90hS8nEH/DtyyMa2CRKDZhJ9b8pPqC7YPOgf0NFaHCYQnJ+nyK0TFqw150sqswPSGdsyBGLWKKvgXlcXAMbb5uQyyl1xIZ9JN+GqK6UqG7BLkIg96HkgRkSp1ahiuXXc4lnmdd+Oac1xXgUzGmFsWacjr9OW3IEZeLTo83fnqY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=0cLJ6KMf2PMwkfYBnjMpsXVB0DKNN4HgTqM4/JpusSAU7rFfeCG7Ft9udht1qpgxzPs+PDqycLz5V3SojK0TRwPPyazvaGmktIkLmzP1ZI8b9S2fTYncp4QmVciwGdnyoDvN/3HASrVSxCnruSgJzYOH+m5If5XUoR93vKOzCYU=; X-YMail-OSG: D8ZpwB4VM1lHIVIGK.nlC8Dih.G7HeGqdj22fW6OJlgPQFR K2WvlJn1YYcxV2iDpSSvmHrCzaQvi8KY_q2l4G2378PxTy8i3kLlkstyqgMn pXlvM1_80bcPSvrcNx4J9Gi3DtoDgpLkIDgszn4dpF80naWeMOotV6DOaUZU HJQrbZs_okxAS9G9qfaz05bRwe40S51zGj2hKvap5cOlOg8AvL4X.wENkSNg FFh2LyYUrXVjX3FX.p6GOmP8cPRc78JXSGIC3IeFzu6xoGjnPBNUk1Atk_jK XSaLXPzCBnA_oH9Rmr.3xEP7x4gAaoxa2PdE_N2aA0IbqqySoA.h_PfrjKaU KJBevvnHUbaru9NkWXIl4vzMc6wHnlA1PPxkCfH2N3ZITahWTpgbVPeSG3GC 6._Zobo_jJGBLwzkvUyHlVoSyytLUJvz4PQj711O1tg3oKJNjGQ5NWTi8mjd pNJ_DoMN6emtVfJsyyR7mpzBAKa70XvHEYWoXrlLImQmMxEqhNWpQjPtK2eF 7DyrUlXGj4pdU0l8TTsDUDaMht92kzXcYuLsTUshL6nNr5gqx1nVqgoZdC3L PMTN3PO2S3WKqa0JycEoy_2zlR_y21rjaNCaJxxI.33xiIunEkmXJZaPT33j FAv6NaSfVlhYfGMrvSeBo5mCmSid1LQq0kKsMLXQFZ29ELpmQ.0WVycKG6a7 N7QPuXlPMhtPhAvj7j3t7h7c8k5dzrQ-- Received: from [129.188.33.25] by web162802.mail.bf1.yahoo.com via HTTP; Thu, 29 Nov 2012 10:44:03 PST X-Rocket-MIMEInfo: 001.001,QXMgcGFydCBvZiB0aGUgZGVzaWduIG9mIEFDRiwgd2UgaGF2ZSB0cmllZCB0byBrZWVwIGl0IGFzIHNpbXBsZSBhcyBwb3NzaWJsZSwgc28gYXMgdG8gYmUgY29tcGF0aWJsZSB3aXRoIGFzIG1hbnkgYnJvd3NlcnMgYXMgcG9zc2libGUuIFNvLCB3ZSBoYXZlIG5vdCB1c2VkIEhUTUw1IG9yIHJlbGllZCBvbiBqYXZhc2NyaXB0IChhcyBtdWNoIGFzIHBvc3NpYmxlKS4gQm9vdHN0cmFwIHJlbGllcyBvbiBIVE1MNSBhbmQgamF2YXNjcmlwdCwgc28gSSdtIGhlc2l0YW50IHRvIGluY2x1ZGUgaXQuIFdoYXQgbWEBMAEBAQE- X-Mailer: YahooMailWebService/0.8.127.475 References: <20121129152317.69585a4f@ncopa-desktop.alpinelinux.org> <50B78EF5.6040006@arcor.de> Message-ID: <1354214643.44872.YahooMailNeo@web162802.mail.bf1.yahoo.com> Date: Thu, 29 Nov 2012 10:44:03 -0800 (PST) From: Ted Trask Reply-To: Ted Trask Subject: Re: [acf] Re: [alpine-devel] Ideas for a new config framework, ACF2 To: "jeremy@thomersonfamily.com" , Jerry Jacobs Cc: Der Tiger , Natanael Copa , Alpine ACF , Alpine Developers In-Reply-To: X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1893461944-295100797-1354214643=:44872" --1893461944-295100797-1354214643=:44872 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable As part of the design of ACF, we have tried to keep it as simple as possibl= e, so as to be compatible with as many browsers as possible. So, we have no= t used HTML5 or relied on javascript (as much as possible). Bootstrap relie= s on HTML5 and javascript, so I'm hesitant to include it. What makes Bootst= rap appealing? Is it simply the responsive layout for mobile devices?=0A=0A= >From a technical standpoint, I'm not opposed to including it in a skin, jus= t not in the core. I would like to keep the generated HTML as clean as poss= ible, and allow skins to extend the functionality.=0A=0AV.Krishn had propos= ed creating a skin with the jquery-mobile framework (http://jquerymobile.co= m/) for similar reasons of usability on mobile devices. He had made some pr= ogress, but he required changes to the ACF code to clean up the generated H= TML. 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 A= lpine Linux 2.6.=0A=0A=0ATed=0A=0A=0A________________________________=0A Fr= om: Jeremy Thomerson =0ATo: Jerry Jacobs =0ACc: Der Tiger ; Na= tanael Copa ; Alpine ACF = ; Alpine Developers =0ASent: Thursday,= November 29, 2012 12:31 PM=0ASubject: Re: [acf] Re: [alpine-devel] Ideas f= or a new config framework, ACF2=0A =0A=0AI second the nomination for using = Bootstrap for the HTML layout. =A0I'd highly recommend a responsive layout = for management from mobile devices as well.=0A=0A=0A=0AOn Thu, Nov 29, 2012= at 11:29 AM, Jerry Jacobs wrote:=0A=0AAs = a theme suggestion if people didn't already know the sleek and nice=0A>orga= nised Twitter Bootstrap which saves the clutter from re-inventing=0A>the wh= eel again:=0A>=0A>http://twitter.github.com/bootstrap/=0A>=0A>=0A>On 29 Nov= ember 2012 17:36, Der Tiger wrote:=0A>> Hi Nata= nael,=0A>> Hi Kaarle,=0A>>=0A>> Thanks for the comprehensive project plan! = I fully agree, the current=0A>> ACF is good work, but needs overhauling, du= e to the problems stated in=0A>> the proposal. At this stage, I am just not= sure if using JavaScript and=0A>> introducing client-side GUIs would be wi= se choices.=0A>>=0A>> - ACF is a configuration framework. IMHO, the configu= ration of most=0A>> Alpine systems is usually done by a single admin or at = least a small=0A>> number of admins, who usually won't do administration wo= rk on a single=0A>> machine, simultaneously. Therefore, there is no signifi= cant server=0A>> performance benefit to be expected from outsourcing HTML p= age formatting=0A>> to the client side. ACF is not a "common user" interfac= e.=0A>>=0A>> - Using JavaScript would introduce another programming languag= e required=0A>> besides shell scripting and LUA to write ACF applications a= nd modules.=0A>> Not every programmer interested in Alpine Linux is capable= or willing to=0A>> handle an extensive number of programming languages in = order to write=0A>> packages for Alpine Linux. The higher the required numb= er of languages,=0A>> the fewer the number of people able and willing to co= ntribute.=0A>>=0A>> - JavaScript is considered by all internet security maj= ors to be a=0A>> potential security risk. This is not only due to security = bugs in=0A>> various browsers (e.g. Chrome), but also due to the complexity= of=0A>> JavaScript interaction with servers. Most companies filter JavaScr= ipt in=0A>> their local nets and allow it only on secure channels between c= lients=0A>> and the internet in order to make some websites work, where the= re is no=0A>> alternative method available than a client script (e.g. large= volume=0A>> data browsing). Using JavaScript for configuration of a local= =0A>> environment does compromise this security strategy.=0A>>=0A>> - JavaS= cript adds complexity to the HTML page transmitted and displayed.=0A>> It i= s likely, there are devices like PDAs or mobile phones, that won't=0A>> be = able to handle certain JavaScript initiated reformatting of web pages=0A>> = correctly. Admins do frequently use PDAs to reconfigure their servers=0A>> = and routers or to look up some configuration on these devices. Also=0A>> th= ere is the issue of DHTML incompatibilities between browsers.=0A>>=0A>> - K= ISS [1], as you certainly know. The more components are required for=0A>> t= he ACF to work, the higher the risk the next update will render the=0A>> sy= stem inoperable. And there are already JSON, LUA, minihttpd and=0A>> variou= s other components involved.=0A>>=0A>> I, admittedly, do have strong reserv= ations regarding both, Java and=0A>> JavaScript. A co-worker once eloquentl= y put it to: "Java and JavaScript=0A>> in 99% of all cases are used by prog= rammers to work around problems,=0A>> they either don't understand or don't= care to solve properly." I've=0A>> largely experienced this to be true.=0A= >>=0A>> Personally, I'd prefer a slim, slick and lean HTML-only configurati= on=0A>> GUI with pages generated by the host rather than the client. But th= an=0A>> again, I'm just an old f@rt, who has no appreciation for "modern",= =0A>> blinking, multi-layered and high colour pop-up interfaces, that are a= s=0A>> slow as a snail and close to indistinguishable from any given first= =0A>> person shooter action game.=0A>>=0A>> Kind Regards, Tiger=0A>>=0A>> [= 1] KISS =3D Keep it simple, stupid!=0A>>=0A>> Am 2012-11-29 15:23, schrieb = Natanael Copa:=0A>>> Hi,=0A>>>=0A>>> Me and Kaarle have been playing with t= he idea "what if we started with=0A>>> ACF from scratch today, how would it= be?".=0A>>>=0A>>> We collected some ideas and have now come up with a fair= ly detailed=0A>>> plan for an ACF2.=0A>>>=0A>>> Some of the goals:=0A>>> * = better security design=0A>>> * remove unnecessary complexity from modules= =0A>>> * organize the libs better=0A>>> * fix concurrency - no race conditi= ons=0A>>> * improve CLI interface=0A>>> * modernize web GUI (write the gui = in javascript)=0A>>>=0A>>> For web frontend we have been talking of using e= xisting frameworks like=0A>>> Backbone.js and RequireJS. For backend we hav= e been talking about using=0A>>> things like augeas and using Lua tables to= create data models.=0A>>>=0A>>> Kaarle has written are more detailed plan:= http://www.datakunkku.fi/acf/=0A>>>=0A>>> This will require some massive w= ork but I think we can do it. Hopefully=0A>>> it will be simpler to write m= odels once the basic framework is in place.=0A>>>=0A>>> What do you think?= =0A>>>=0A>>> -nc=0A>>>=0A>>>=0A>>> ---=0A>>> Unsubscribe: =A0alpine-devel+u= nsubscribe@lists.alpinelinux.org=0A>>> Help: =A0 =A0 =A0 =A0 alpine-devel+h= elp@lists.alpinelinux.org=0A>>> ---=0A>>>=0A>>>=0A>>=0A>>=0A>>=0A>> ---=0A>= > Unsubscribe: =A0acf+unsubscribe@lists.alpinelinux.org=0A>> Help: =A0 =A0 = =A0 =A0 acf+help@lists.alpinelinux.org=0A>> ---=0A>>=0A>=0A>=0A>---=0A>Unsu= bscribe: =A0acf+unsubscribe@lists.alpinelinux.org=0A>Help: =A0 =A0 =A0 =A0 = acf+help@lists.alpinelinux.org=0A>---=0A>=0A> --1893461944-295100797-1354214643=:44872 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
= As part of the design of ACF, we have tried to keep it as simple as possibl= e, so as to be compatible with as many browsers as possible. So, we have no= t used HTML5 or relied on javascript (as much as possible). Bootstrap relie= s on HTML5 and javascript, so I'm hesitant to include it. What makes Bootst= rap appealing? Is it simply the responsive layout for mobile devices?

From a technica= l standpoint, I'm not opposed to including it in a skin, just not in the cor= e. I would like to keep the generated HTML as clean as possible, and allow = skins to extend the functionality.

V.Krishn had pro= posed creating a skin with the jquery-mobile framework (http://jquerymobile= .com/) 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 generate= d HTML. zelebar and I have also talked about cleaning up the HTML output, b= ut have been too busy to make much progress. Hopefully it would be ready fo= r Alpine Linux 2.6.

Ted

From: Jeremy Th= omerson <jeremy@thomersonfamily.com>
To: Jerry Jacobs <xor.gate.engineering@gmail.com>= ;
Cc: Der Tiger <de= r.tiger.alpine@arcor.de>; Natanael Copa <ncopa@alpinelinux.org>; A= lpine ACF <acf@lists.alpinelinux.org>; Alpine Developers <alpine-devel@list= s.alpinelinux.org>
Sent: Thursday, November 29, 2012 12:31 PM
Subject: Re: [acf] Re: [alpine-devel] Ideas for a new= config framework, ACF2

I s= econd the nomination for using Bootstrap for the HTML layout.  I'd hig= hly recommend a responsive layout for management from mobile devices as wel= l.


On Thu, Nov 29, 2012 at 11:29 AM, Jerry Jacobs <xor.gate= .engineering@gmail.com> wrote:
=0A=0A
As a theme suggestion if people didn't already know = the sleek and nice
=0Aorganised Twitter Bootstrap which saves the clutte= r from re-inventing
=0Athe wheel again:
=0A
=0Ahttp://twi= tter.github.com/bootstrap/
=0A

=0AOn 29 November 2012 17:36, Der Tiger <<= a rel=3D"nofollow" ymailto=3D"mailto:der.tiger.alpine@arcor.de" target=3D"_= blank" href=3D"mailto:der.tiger.alpine@arcor.de">der.tiger.alpine@arcor.de<= /a>> wrote:
=0A> Hi Natanael,
=0A> Hi Kaarle,
=0A>
= =0A> Thanks for the comprehensive project plan! I fully agree, the curre= nt
=0A> ACF is good work, but needs overhauling, due to the problems = stated in
=0A> the proposal. At this stage, I am just not sure if usi= ng JavaScript and
=0A> introducing client-side GUIs would be wise cho= ices.
=0A>
=0A> - ACF is a configuration framework. IMHO, the c= onfiguration of most
=0A> Alpine systems is usually done by a single = admin or at least a small
=0A> number of admins, who usually won't do= administration work on a single
=0A> machine, simultaneously. Theref= ore, there is no significant server
=0A> performance benefit to be ex= pected from outsourcing HTML page formatting
=0A> to the client side.= ACF is not a "common user" interface.
=0A>
=0A> - Using JavaSc= ript would introduce another programming language required
=0A> besid= es shell scripting and LUA to write ACF applications and modules.
=0A>= ; Not every programmer interested in Alpine Linux is capable or willing to<= br>=0A> handle an extensive number of programming languages in order to = write
=0A> packages for Alpine Linux. The higher the required number = of languages,
=0A> the fewer the number of people able and willing to= contribute.
=0A>
=0A> - JavaScript is considered by all intern= et security majors to be a
=0A> potential security risk. This is not = only due to security bugs in
=0A> various browsers (e.g. Chrome), but= also due to the complexity of
=0A> JavaScript interaction with serve= rs. Most companies filter JavaScript in
=0A> their local nets and all= ow it only on secure channels between clients
=0A> and the internet i= n order to make some websites work, where there is no
=0A> alternativ= e method available than a client script (e.g. large volume
=0A> data = browsing). Using JavaScript for configuration of a local
=0A> environ= ment does compromise this security strategy.
=0A>
=0A> - JavaSc= ript adds complexity to the HTML page transmitted and displayed.
=0A>= It is likely, there are devices like PDAs or mobile phones, that won't
= =0A> be able to handle certain JavaScript initiated reformatting of web = pages
=0A> correctly. Admins do frequently use PDAs to reconfigure th= eir servers
=0A> and routers or to look up some configuration on thes= e devices. Also
=0A> there is the issue of DHTML incompatibilities be= tween browsers.
=0A>
=0A> - KISS [1], as you certainly know. Th= e more components are required for
=0A> the ACF to work, the higher t= he risk the next update will render the
=0A> system inoperable. And t= here are already JSON, LUA, minihttpd and
=0A> various other componen= ts involved.
=0A>
=0A> I, admittedly, do have strong reservatio= ns regarding both, Java and
=0A> JavaScript. A co-worker once eloquen= tly put it to: "Java and JavaScript
=0A> in 99% of all cases are used= by programmers to work around problems,
=0A> they either don't under= stand or don't care to solve properly." I've
=0A> largely experienced= this to be true.
=0A>
=0A> Personally, I'd prefer a slim, slic= k and lean HTML-only configuration
=0A> GUI with pages generated by t= he host rather than the client. But than
=0A> again, I'm just an old = f@rt, who has no appreciation for "modern",
=0A> blinking, multi-laye= red and high colour pop-up interfaces, that are as
=0A> slow as a sna= il and close to indistinguishable from any given first
=0A> person sh= ooter action game.
=0A>
=0A> Kind Regards, Tiger
=0A>
= =0A> [1] KISS =3D Keep it simple, stupid!
=0A>
=0A> Am 2012-= 11-29 15:23, schrieb Natanael Copa:
=0A>> Hi,
=0A>>
= =0A>> Me and Kaarle have been playing with the idea "what if we start= ed with
=0A>> ACF from scratch today, how would it be?".
=0A>= ;>
=0A>> We collected some ideas and have now come up with a fa= irly detailed
=0A>> plan for an ACF2.
=0A>>
=0A>>= ; Some of the goals:
=0A>> * better security design
=0A>>= * remove unnecessary complexity from modules
=0A>> * organize the= libs better
=0A>> * fix concurrency - no race conditions
=0A&g= t;> * improve CLI interface
=0A>> * modernize web GUI (write th= e gui in javascript)
=0A>>
=0A>> For web frontend we have= been talking of using existing frameworks like
=0A>> Backbone.js = and RequireJS. For backend we have been talking about using
=0A>> = things like augeas and using Lua tables to create data models.
=0A>&g= t;
=0A>> Kaarle has written are more detailed plan: http://www.d= atakunkku.fi/acf/
=0A>>
=0A>> This will require some = massive work but I think we can do it. Hopefully
=0A>> it will be = simpler to write models once the basic framework is in place.
=0A>>= ;
=0A>> What do you think?
=0A>>
=0A>> -nc
= =0A>>
=0A>>
=0A>> ---
=0A>> Unsubscribe: &= nbsp;alpine-devel+unsubscribe@lists.alpinelinux.org
=0A>> Help:         alpine-devel+help= @lists.alpinelinux.org
=0A>> ---
=0A>>
=0A>>=
=0A>
=0A>
=0A>
=0A> ---
=0A> Unsubscribe: &n= bsp;acf+unsubscribe@lists.alpinelinux.org
=0A> Help:   &n= bsp;     acf+help@lists.alpinelinux.org
=0A> ---
=0A>
=0A=
=0A
=0A---
=0AUnsubscribe:  acf+unsubscribe@lists.alpinel= inux.org
=0AHelp:         acf+help@lists.alpinelinux.org
=0A---
=0A
=0A

=0A
=

--1893461944-295100797-1354214643=:44872-- --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---