OpenWrt Forum Archive

Post #1

sam

28 Jun 2004, 12:56

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 ), but I'm definitely looking to move away from php.

Post #2

phil

28 Jun 2004, 17:14

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

Post #3

sam

28 Jun 2004, 19:10

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

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

Post #4

sam

29 Jun 2004, 00:21

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?

Post #5

Nico

29 Jun 2004, 07:57

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

Post #6

cnf

29 Jun 2004, 09:54

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)

Post #7

sam

29 Jun 2004, 11:35

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.

Post #8

_marc_

29 Jun 2004, 11:50

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

Post #9

sam

29 Jun 2004, 12:33

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.

Post #10

_marc_

30 Jun 2004, 07:25

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.

Post #11

sam

3 Jul 2004, 15:19

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 ideal.

Post #12

cnf

3 Jul 2004, 17:20

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 ...

Post #13

sam

3 Jul 2004, 18:01

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.

Post #14

rkuris

8 Jul 2004, 15:54

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.

Post #15

cnf

8 Jul 2004, 15:57

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

Post #16

koitsu

8 Jul 2004, 15:58

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.

Post #17

sam

8 Jul 2004, 16:22

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.

Post #18

rkuris

8 Jul 2004, 17:28

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.

Post #19

cnf

8 Jul 2004, 17:34

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 $

Post #20

rkuris

8 Jul 2004, 17:41

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.

Post #21

sam

8 Jul 2004, 17:55

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.

Post #22

kwesibrunee

9 Jul 2004, 04:12

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

Post #23

pzand

9 Jul 2004, 16:26

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?

Post #24

rkuris

9 Jul 2004, 20:04

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.

Post #25

rkuris

9 Jul 2004, 20:11

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.