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
Received on Thu Nov 29 2012 - 17:36:05 GMT