OpenWrt Forum Archive

Topic: Web-Interface Poll

The content of this topic has been archived between 21 Mar 2018 and 6 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

I was, I admit, a little stubborn when starting development on the web interface about using php.  I still think there are advantages in terms of widespread knowledge of php, but I'm quickly coming around to the point of view that it is overkill.

Possible languages as I see it are

Ash - the advantage is this is already built in, the disadvantage is that there is a little bit of a round peg square hole issue since, of course, it is a shell scripting language.  Not impossible, just possibly inefficient.

PHP - the advantages as I see it are universallity and a wide range of functions to use/backport in.  the disadvantage is size and the truth is -- as i've been coding the interface -- you don't really need very many functions to write a web interface, especially as you can tie in to shell tools for many things

Ember - this looks to be ideal. i'm hardly the first to suggest it.  my concern initially was that its not so widely known.  my current thinking is that (a) i may be wrong about that, (b) regardless, the syntax is so easy that anyone knowing c/java/php could pick it up in about 8 seconds, (c) its size makes it worth it. (full disclosure: i'm casting my vote for ember)

HTML - i guess it would be possible to write the entire thing in HTML. of course there would have to be hooks to cgi (c progs or shell scripts).  the big problem here is that it would be no fun.  who wants to rewrite html code all day, when we have scripting languages.

Other ?

I am merely summarizing things others have already said before.  But, hey, let's put it to a vote.

I won't swear I'll rewrite my interface in the winning language (I'm still a little stubborn wink ), but I'm definitely looking to move away from php.

Hi,

i voted for php.
I think that it's much easier to code than. Apart from that, there may be some functions missing when you code the stuff in ash. In php, i know no function which I may miss.
And last but not last: There are lots of people who know php, and could help you. The second language I would vote for, would be ember. It really looks great. But I think that most people aren't willing to learn a new language, just for this webinterface coding. So I guess you won't get as much support as you would get by using php.

Cheers,
phil

i guess if you vote for "Other" it might be helpful to post which "Other" you had in mind  smile

( Unless you meant - "anything but those horrible options your proposed"  wink )

one potential issue with ember (not that its huge) -- does ember support inlining html as in the following php example

<? if ($x==$y)
{
?>

<b>random html</b>
<?

}
<?

that's a pretty nice thing to be able to do.  can you do it in ember?

Hi Sam,

inlining seems to work

root@ap1:~# cat test.e
<HTML>
<BODY>
<!
 funct funct1(text $msg) {
  echo($msg);
 }
>
<TABLE BORDER=1>
<!
 $count = 0;
 while($count < 3) {
>
<TR><TD>
<!
  funct1("$count");
>
</TD></TR>
<!
  $count++;
 }
>
</TABLE>
</BODY>
</HTML>
root@ap1:~# /www/cgi-bin/w3e -f test.e
Status: 200 Output follows
Content-Type: text/html
Pragma: No-Cache

<HTML>
<BODY>

<TABLE BORDER=1>

<TR><TD>
0
</TD></TR>

<TR><TD>
1
</TD></TR>

<TR><TD>
2
</TD></TR>

</TABLE>
</BODY>
</HTML>

starting tags <! must be left alone on their lines, but it seems to be a limitation in the w3e interpreter.

--
Nico

Ember, or something better suited (still looking)

But no WAY i am wasting 500k just to have a web interface ^^; (php is just too big)

Hi Sam,

inlining seems to work

that's great.  if you can stand one more complaint ...

can you capture output of a process? in other words, is there the equivalent of backticks in ember?  i only see a system() function, which, of course, simply dumps output to html.

can you capture output of a process? in other words, is there the equivalent of backticks in ember?  i only see a system() function, which, of course, simply dumps output to html.

there is an open function with some extra args where eyou can handle pipes.


open ( ) int fd = open ( path , access ) text path text access open() opens the object (usually a file) pointed to by path for reading and/or writing as specified by the access argument, and returns a file descriptor for that newly opened file. The possible values for the access flags are: Flag Description

< File is opened for reading
> File is opened for writing
>> File is opened for appending
<> File is opened for reading and writing
<P Create a named pipe in the file system and open it for reading
>P Create a named pipe in the file system and open it for writing
<| The contents of the path argument is a shell command. The command is executed and the output of the new process is available to be read from the returned file descriptor
>| The contents of the path argument is a shell command. The command is executed and any data written to the returned file descriptor is passed as input to the new process

any way to include files to be parsed, like the php include()?  the includeFile() function doesn't parse.

it appears you can make libraries, but that's not quite the same.

any way to include files to be parsed, like the php include()?  the includeFile() function doesn't parse.

it appears you can make libraries, but that's not quite the same.

yes,

there should be a need for regex functions like in php, also we need to make a wrapper for nvram call.

ember seems to be winning.  but what about this?

http://www.mbedthis.com/products/appWeb … s/esp.html

of course, it looks like functions would have to be writtne in c/c++ which perhaps is not idea.

I had a little look at this, and it looks really interesting...
let's see if i can get it running on me test wrt ...

I had a little look at this, and it looks really interesting...
let's see if i can get it running on me test wrt ...

let us know. i'd be very interested to hear.  i've been pulled away from my wrt work, but hope to get back to it next week.

There seem like some significant advantages to this.  First, it's already built-in.  Second, it's fast.  Third, it doesn't use a lot of memory (important if you're using the box for other stuff).  Fourth, it supports functions so most of the dirty work can be hidden in there.

I spent about an hour this morning coming up with a template and a few nvram variables that can be edited with an ash cgi-bin.  Performance was fine.  And it fit in 12k.  It's ugly, but since it uses CSS you can clean it up.

You can check what I did out here: http://divdb.com/www.tar

BTW, I also know PHP extensively, having developed one large and several small projects in it.  PHP tends to balloon into something bigger than what I'd like on my router.

I am also sort-of surprised nobody said perl.  Yes, you'd have to strip the perl binary down, but you'd get nice modular code when you were done.

Dude, i love perl, but perl is HUGE!!!!
just check all the modules you need to get a halfway decent perl running...

Perl likely wasn't recommended for a slew of reasons.  First off, the CPU time for perl is high (one cannot deny this).  Secondly, most useful perl applications now rely on external modules, which would increase on-flash size immensely.  Thirdly, I think perl is overkill.

I've still been pluggin away in php.  Not because I think its the best, but because I have momentum.

That being said, I believe my work should be easily convertible to any other format, and I will take a shot at that pretty soon.  I'm still slightly undecided on which language I will try.  I think I may end up trying a few conversions and see which one I get the farthest in.

Ember has received a lot of votes, but, mostly for reasons given by other people, I think its problematic.  The main problem seems to be that it's a relatively untested codebase and so, as has been noted in another thread, people are uncovering bugs and missing features.

I'm starting to agree that ash makes a lot of sense.  Mostly for the reasons given by others, but also because -- as it turns out -- even in my php interface i'm doing a lot of hooking into ash scripts.

Another possibility is for someone to actually compile simply the php3 interpreter (i.e. no functions, just the syntax).  This should be pretty small and would have the advantages of (a) stability and (b) php compatibilty. Most of the functionality could be borrowed from ash hooks, but you'd still retain the "prettiness" of php. This was were I hoped to go with my lwhp project.  I still do hope to go there, but, given my lack of experience with bison, yacc, flex etc..., I'm going to need a bigger chunk of time then I have available now.

Anyway, I'm hoping to release an update to my interface (with support for dnsmasq dhcp) tonight.

If you think perl is huge, maybe you should look at php again.

On my linux box:

cleo:~> size /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so /usr/bin/perl
   text    data     bss     dec     hex filename
1157399   42176    8256 1207831  126e17 /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so
  10673     524       8   11205    2bc5 /usr/bin/perl
cleo:~> size /usr/bin/php
   text    data     bss     dec     hex filename
1831167  241576  108140 2180883  214713 /usr/bin/php

I think that ash functions can make the code simpler.  Not only that, but we can easily reuse the existing ash scripts that do all sorts of stuff.  /etc/functions.sh is very useful!

Sam - I realize you have momentum on this and I'd like to help.  If I set up a CVS repository for this project, would you use it?

I'm going to work on building a cvs binary so you can update directly from cvs.

If you think perl is huge, maybe you should look at php again.

On my linux box:

cleo:~> size /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so /usr/bin/perl
   text    data     bss     dec     hex filename
1157399   42176    8256 1207831  126e17 /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so
  10673     524       8   11205    2bc5 /usr/bin/perl
cleo:~> size /usr/bin/php
   text    data     bss     dec     hex filename
1831167  241576  108140 2180883  214713 /usr/bin/php

I think that ash functions can make the code simpler.  Not only that, but we can easily reuse the existing ash scripts that do all sorts of stuff.  /etc/functions.sh is very useful!

Sam - I realize you have momentum on this and I'd like to help.  If I set up a CVS repository for this project, would you use it?

I'm going to work on building a cvs binary so you can update directly from cvs.

Like said, perl is useless without the modules...
cnf@foritos cnf $ cd /usr/lib/perl5/
cnf@foritos perl5 $ du -sh
56M     .
cnf@foritos perl5 $ ls -lh `which perl`
-rwxr-xr-x    1 root     root         966K Dec 20  2003 /usr/bin/perl*
cnf@foritos perl5 $

I used perl4 for many years with no modules at all.  It isn't useless without modules.

However, I'm not convinced you even need perl.  I think ash will work fine, provided you set the functions up right.

The more I think about it, though, it would be awesome to make a small tweak to busybox's httpd to support some form of backtick-like statement when it serves the pages.  Something like <?`nvram show ...`?> which would expand into the output from that command.  The loop it uses now to display stuff is very simple.

The more I think about it, though, it would be awesome to make a small tweak to busybox's httpd to support some form of backtick-like statement when it serves the pages.  Something like <?`nvram show ...`?> which would expand into the output from that command.  The loop it uses now to display stuff is very simple.

See mbm's earlier thread on web development where he posted what is essentially an ash parser that provides this kind of functionality.

If ash ends up being the way to go, I suspect something like that (which is basically running web pages through eval to expand functions) will be simplests.

There is  a standalone Interpreter called NJS which seems full featured. Javascript is easy to program with  and it looks quite small. Possibly a good compromise.

anyhow, here is the link to a standalone Interpreter.

http://www.njs-javascript.org/

Comments?

Kwesi

Take rkuris' ash script and add a bunch of fields to it or put some long texts in the fields (say, 50 characters each). At some point, looks like about 128 characters in total for the post, basic.cgi just hangs.

Is there some busybox limitation that allows 'read' to only handle 128 characters and hang when things get larger? Or am I just missing something stupid here?

I think it has something to do with the 'read' in the script not doing what it is supposed to when posting.

I tried:

while read stuff
do
echo $stuff
done

but that didn't work either.

It DOES look like a 128-byte buffer limit (with exploit, perhaps).

line 1199 of httpd.c says:

      char wbuf[128];

There might be some code that tries to deal with larger sizes; it requires more inspection.