Sunday, May 31, 2015

VOS : Running on Lua Server Pages

Well, it's not much to look at yet. I worked most of the day Sunday (today) getting my first Lua Server page to load and display with an LCARs theme. The navigation map links for the buttons are loaded from an SQLite3 database with LSP painting them down the left side. The Lua pages, resources and web font for the LCARs theme are all pulled from a .zip file which copies them to an in-memory SQLite table for caching.

The configuration is coming from a "vos.ini" file which specifies the port (12) to monitor and it also sets up a discovery service on port 1900 for UPNP messages from all other VOS servers running in the system.

The essential Javascripts are hard compiled into the executable so that nobody can corrupt the "basic kernel" of client scripting where I have found compatible versions of JQuery, Raphael, SVG Conversion and other client side logic that users should not be able to alter. For example, a client can write an all new page based on JQuery but they can't change versions of JQuery which would risk breaking things that are working with incompatible versions.

So the old VOS based on straight HTML is going to be replaced with a dynamic set of pages built by Lua LSPs using JQuery-UI plugins. I have tested all of these libraries on IE 6.0, one of the most common browsers you will find on a thin client you buy for a $1.00 off EBay or elsewhere.

Coming soon will be administrator editing of Lua Server Pages in-situ and archiving into .zip when ready, which will basically allow you to build the website or customize it using the website itself and no other tools but the website.

My testing environment for standalone instances is now Windows NT Embedded 6.0 SP with fat32 and USB plugins. I am running Crazy Browser, a full featured HTML5 compatible browser on NT. It is running pretty good and fast too on a 233mhz PC/104 box.

P.S. Everything you see above is running off a single 634 kb executable, with Lua, web server, SQLite3 and about 32 minimized Javascripts and web resources compiled binaries right into the exe file. This thing may still fit on a floppy when it reaches version 1.0 for release as open source.


Ave said...

The Star Trek theme looks good but in my experience (I have managed Technical Support for a while then designed e-banking front-ends for a year back in 2000) user interfaces must be as dead serious as possible.

People behave in a hostile way to any new object or interface. Any fancy stuff destroys your credibility and the confidence of users. They WILL NOT TRUST the device if it is fancy.

Your interface must be extremely easy to understand and navigate and have no decoration whatsoever. The variety in elements must be very tight : same police of characters, buttons, colors etc. Effects (change in colors, change in button shadows indicating it is pressed etc.) must also be sparse and meaningfull in a consistent way.

You'll also have to structure this the way people are used to : Windows-Explorer style arborescence etc. You know all this from your job, so do it.

As a side note, I also develop (undisclosed stuff) in a SHTF perspective. It is a hobby of mine, so I like to make prototypes and explore possibilities ("concept of proof" prototypes etc.)

But I do this only because I made sure I had a running version first, with a user guide and consumables all provided for. It is very crude and most stuff is not made by me but it works.

Eventually it'll be much better, OR NOT. We don't decide how the events unfold. If I abandon the project or time runs out, the first version is here.

This is why I'd like to say : roll out a very basic Vault OS first. An alternative would be to put all your existing attempts online, no matter the degree of completion. I did this for my book and although it's not finished some people like what they're reading.

( )

Texas Arcane said...


When I have daemons running in this I will post V1.0 to Github. That's my goal.

You may be right about a fancy interface. I do not like the pastels that are coming from the default .CSS at present.

Sam said...

One thing I've found that's a problem for most web developers to get is that not everyone can see small fonts. I have my fonts set to Large. If the titles run horizontally then many times they overwrite each other and you can't get to or tell what links to what. Your placing of the various categories on the left so they can expand without covering each other is a BIG plus. I hope you keep this design.

Ave said...

>>When I have daemons running in this I will post V1.0 to Github. That's my goal.

How much time would it take to make a very primitive, hurriedly programmed, looted from elsewhere, set of daemons ?

You know, the kind that still has bugs and errors, but is somewhat working.

Texas Arcane said...


I basically looted the daemons from PVBrowser, which is automatic support for about 30+ major protocols including Modbus, etc.

If I have a modbus, I2C, LPT and RS-485 daemon working, will put this up as V1 on Github.

Sam said...

This might interest you. An LCARS Android watch programmed in LiveCode. LiveCode may seem to be silly to you but being able to quickly put together software easily seems a noble pursuit to me. I've been looking at liveCode lately as it seems interesting and runs on most all platforms.

When you say you "looted the daemons from PVBrowser" how did you do that? Are the drivers stand alone dll's or other format libraries or did you have to separate out the programming code for the drivers and compile them yourself? Can they be called with other languages like any other compiled library?

Texas Arcane said...


I got the original source for all the daemons in the PVBrowser library ("rllib") and ported it from C++ to C.

Currently uses mailslots to send .ini format text with key-value pairs. I wanted it to simply use JSON as a far more structured message format.

If you look over the daemons there is a lot of duplication. Ideally they should all use a scripting language like PAWN or Lua and just load .DLLs for basic functions like accessing serial, parallel, USB ports as needed with the protocol specifics in the script.

The daemons will have their config files edited in the web server and be booted in the web server. This has been working for I2C in Windows, Linux and DOS-32 Causeway in my tests.

I have let the DOS version atrophy while I get it running on Windows. Will restore all the platforms once it is in GitHub. I have a version of PThreads that runs on DOS.

Russell (106) said...

"Everything you see above is running off a single 634 kb executable, with Lua, web server, SQLite3 and about 32 minimized Javascripts and web resources compiled binaries right into the exe file. This thing may still fit on a floppy when it reaches version 1.0 for release as open source."

This alone is impressive.

So what finally killed PHP for you?

Eric Green said...

I haven't looked at LCARS, but if it's styled with CSS then perhaps it wouldn't be much work to include an optional plain or "classic" interface with unstyled webform controls.

Remember the arguments of THE CATHEDRAL AND THE BAZAAR: 1) Release early, release often; 2) All bugs are shallow with enough eyeballs on them. It helps if your testers are developers themselves who can create fixes rather than just describing behavior like a corporate beta test group.

Incidentally I just saw this comparison of code-hosting sites. They're correct that Sourceforge has degenerated into a big crapware distribution system, I don't go there if there is an alternative.

Sam said...


Texas Arcane said...

@Eric Green

I really believed what I read in THE CATHEDRAL AND THE BAZAAR. It is true.

If I sketch the outlines and show the basic principles to be working, others can focus in on debugging CANBUS over RS-232, the intricacies of multinode I2C, etc.

Before I can upload to Github I have to prove the system is working and all the paradigms in it are very sound. Over the years it has gotten simpler and simpler with less to break. I would really like people to debug and add daemon support that is produced by their own hands-on testing.


I tried to build the first four pages with embedded PH7 PHP and the resulting scripts were really confusing. I extrapolated and decided by the time version one is finished it is going to be a spaghetti snark. Lua Server Pages read much cleaner already, I bet a person never even exposed to Lua could glance over the first couple of scripts I have written and instantly see what is going on there.