On Thu, 29 Nov 2012 17:36:05 +0100
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.
Performance is not really what we want to address.
> 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.
Yes, but what if you want contribute with your GUI expertise, know html
By separating the backend from the GUI you can contribute with one of
the parts without knowing the other. You can contribute with Lua
backend and let the GUI ppl do the GUI.
> 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.
that we need to also think about the client security.
> 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.
was a hot topic at that time). Back then we decided to not use it and
I think that the world looks different today than it did back then and
> - 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.
Well, part of the motivation for the rewrite is to have it more
modularized with clean and well defined APIs so that you can change
components without breaking stuff.
> 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.
its place - for the GUI.
> Personally, I'd prefer a slim, slick and lean HTML-only configuration
> GUI with pages generated by the host rather than the client.
I think that a page with multiple http requests for each component,
while still easliy being slow, adds value in form of separation. The
backend will not need to worry about html. Each request ask for smaller
pieces. Makes it easier to do privilege separation.
> 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.
To be honest, I think the value of experience is often underestimated
and I hope we don't get blinking multi-layered and high color pop-up
html5 interface that is slow as a snail :)
Thanks for your feedback!
> Kind Regards, Tiger
Received on Fri Nov 30 2012 - 15:40:31 GMT