Re: Web UI for NPF as a GSoC project

[Aleksej Saushev <asau%inbox.ru@localhost>]

  Hello!

coypu%SDF.ORG@localhost writes:

> On Sun, Mar 13, 2016 at 04:34:09PM +0000, Christos Zoulas wrote:
>> 
>> This looks good, but I am wondering if it is not going to be easier
>> and better for you to use one of the existing web-ui frameworks so
>> you can have more time to spend on functionality.
>> 
>> christos
>
> Qualifying again that I'm not familiar with most options...
>
> If you mean adapting pfSense (or one of its forks, or a similar project):
>
> I generally think adapting pfSense or a fork is one of the best options,
> as it gives us access to its extensions.
>
> However, many of those tools are written in PHP, and whoever wrote the
> project explicitly mentioned his dislike of the language.
>
> Viewing the alternatives I've also noted none of them seem mobile
> friendly right now, which is something that is easier to add on a
> brand new design.

After spending about a year on working with pfSense-derived code,
I strongly suggest that you don't do that.

pfSense carries a lot of code that comes from pre-rc.subr FreeBSD or OpenBSD.
It controls the system with scripts in PHP (running with superuser privileges!).
There're strong indications that you may convince it to run your PHP code
with superuser privileges.
It provides quite horrible and inconvenient web interface.
Its build system is horrible.

Given my experience, its build system is better rewritten from scratch.
Its control scripts are better rewritten from scratch too.

Given experience of my colleagues who worked on web interface, adapting
the code may take a lot longer than redesigning it from scratch.

I do suggest though that you look at pfSense still, but only to understand
what typical product of this kind is expected to provide.

> If you mean choosing another language to get better tools:
>
> I'm not too picky about Lua, I just figured it's a good choice for being
> in base. I'll check out what's the tool gain from picking one of the
> other languages.
>
> To be sure, my options are (given portability concerns): python, perl
> and lua, correct?
>
> Thanks for responding!

Given quite tight time frame, I'd suggest that you use Python.
At least you may be proficient in it already, and there's abundancy
of good tools to choose from. It's up to you to decide though.

At last. Given that the scope of web UI project is easy to grow and shrink,
I'd like to see it, the scope, defined better. It would be nice to see
proposal in a form that is reminiscent of canonical project documentation
like Russian "Tekhnicheskoe zadanie" per GOST or analogous ("product/technical
requirements document" or similar). I don't ask it for bureaucracy and don't
expect it in its bureaucratic glory, but I want to see the essense: project's
purpose and scope, wanted state, list of deliverables, acceptance criteria,
acceptance testing procedures, high-level plan with milestones.

Given the nature of project you aim at, it would be nice to see project
description with clearly defined stages like "absolutely minimal functionality,"
"more wanted functionality," "even more functionality which is less usual"
and so on. Probably, with dependency graph between stages, if you have
some that don't depend on each other. This would help both sides, you and us.


-- 
HE CE3OH...