What can a RouterStation handle?

[riskable]

I entered the contest in the hope that a webserver written in Python wouldn't be too much for the RouterStation (there's certainly enough storage with 16MB of flash). Anyone care to do an "opkg install python-mini" and do some speed/responsiveness tests?

I had an extensive look at LuCI and the X-WRT offerings... I don't know a damned thing about Lua so that put me off and webif (X-WRT uses it) is severely limited in what it can do and to extend it requires C programming (which I don't do).

Maybe I should just request a RouterBoard (if they're still available for contestants)?

I've already got some preliminary stuff written but I don't want to give away too much =). I'd be more than happy to email a python script to a Ubiquiti employee for testing, however.

[UBNT-Mike.Ford]

Hello Risk,

Please visit the contest page and you can put your submission in there.

Thanks,

Mike

[sirukin]

I had much the same idea, specifically binding as much functionality into a single executable similiar in nature to busybox, then extending with python.

[riskable]

I had much the same idea, specifically binding as much functionality into a single executable similiar in nature to busybox, then extending with python.

I've been pondering this (packaging) in my head lately. Should I release it as a single opkg or should I separate everything out into individual opkgs? What about dependencies?

I'm thinking that the first step is to make sure I put together opkgs for the dependencies of CherryPy (http://www.cherrypy.org/) and then one opkg for CherryPy itself. The base python-mini package for OpenWRT is missing the following:

BaseHTTPServer
cgi
rfc822
mimetools
SocketServer
urllib
urlparse
(these total 400k uncompressed, 111k in a zip file)

Also, to get hashlib working Python needs libopenssl installed.

Furthermore, a lot of the standard modules can be zip-compressed when they aren't presently. To do this would require modifying the base python-mini packages and creating a whole slew of python-<whatever> opkgs. I'm thinking it might be worth it to just put all the dependencies (except for libopenssl) in a zip file and append that to the PYTHONPATH variable at runtime (for the initial release anyway).

I could also create a full-blown package that has it's own minimal python interpreter but I really don't want to do that since it wouldn't work very well with existing python-<whatever> opkgs. That would make it harder to extend my web tool with additional features.

[saneeek55]

its very interesting

[sirukin]

riskable, I'd keep them seperate for development however packaging it into a single pkg seems likely a simple method for deployment/provision.

[saneeek55]

thank you for this theme

[Ella]

:)

[adrianatkins]

Simple is good.

If you keep it to needing just the basics, then it should work on anything that OpenWRT supports.

That's what i did.

It's a bit slow (my UI) at the mo, so maybe i need a bit of a re-think.

Works really fast on an ALIX 800.

Still, i want it to be fast on a UBNT NS2/5 and an RT210W, which have a lot less CPU juice.

[riskable]

My thinking was a bit of the opposite: If my contest entry was too slow or too large on the RouterStation I wanted it to be able to work on regular Linux systems. The plugin architecture I developed should work great for managing just about any application or dealing with any sort of tabular data.

Consider the following code: It is all you need to write (using my framework) to serve up /etc/passwd to jqGrid (http://www.trirand.com/blog/)...

@require(has_read(self.__name__))
def users_json(self,
rows=None,
sidx=None,
_search=None,
searchField=None,
searchOper=None,
searchString=None,
page=None,
sord=None,
nd=None):
"""Returns all users from /etc/passwd in a json format that's compatible with jqGrid."""
header = ["user", "password", "uid", "gid", "gecos", "homedir", "shell"]
passwd_list = list_etc_passwd()
return jqgrid_json(self,
passwd_list,
header,
rows=rows,
sidx=sidx,
_search=_search,
searchField=searchField,
searchOper=searchOper,
searchString=searchString,
page=page,
sord=sord)

That's just six lines of code (I added the line breaks for this forum to make it easier to read). Four lines if you don't count the permissions decorator and the docstring.

I could have severely limited the number of arguments in PyCI's supporting functions--skipping the ability to sort by column or not supporting jqGrid's search functionality. I thought about it at great length... Is it worth it to save a few bytes and CPU cycles here and there just to open the possibility to run on smaller systems?

I came to the conclusion that the more capable I make the framework itself, the easier it will be for me (and others) to extend it. Also, with a language like Python there's always room to refactor code to make it faster or use less memory without having to re-write everything.

I actually had to do a bit of refactoring already with the internationalization stuff (I really should have thought more about it at the get-go).

[adrianatkins]

I dunno.

You sem to have had a similar idea to mine, but at a much higher level.

I'm happiest at the low level - assembler being my favourite. When it comes to N-level abstractions, i can't help thinking of the poor old CPU banging away to re-process stuff just so it can write a 1 somewhere.

Modular has gotta be good, but must it be a new abstraction language that you make (a bit like the UCI framework), or do the punters out there have to learn Python (or some other reptile) in order to play ?