Re: [acf] Re: [alpine-devel] Ideas for a new config framework, ACF2
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 <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
> 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.
> 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.
> potential security risk. This is not only due to security bugs in
> various browsers (e.g. Chrome), but also due to the complexity of
> 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
> environment does compromise this security strategy.
> It is likely, there are devices like PDAs or mobile phones, that won't
> 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 , 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
> 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
>  KISS = Keep it simple, stupid!
> Am 2012-11-29 15:23, schrieb Natanael Copa:
>> 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
>> 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?
>> 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
Received on Thu Nov 29 2012 - 18:29:02 GMT