I've mentioned the huge experimental pet project of mine a few times around here. A recent commit prompted me to mention one part of it, in case it might be useful somehow.
SledjHamr is my reboot of Second Life / OpenSim style 3D virtual worlds, only written sanely. The basic GUI system is itself a reboot of my ancient matrix-RAD networked GUI system, that was in Java over a decade ago, when Java made sense in web browsers. SledjHamr is based on EFL, written in C and Lua, with threats of assembler if it's not fast enough. Obviously simulating an entire world, across a network, in 3D, with sound, and avatars building the world from inside it, is gonna involve a hell of a lot of different parts. The GUI is one of the parts. The GUI has to work across the Internet, both usable, editable, and scriptable from in world and out. The basic philosophy is that there are tiny files written in a language I called skang (SKin lANGuage), that describe the GUI, and the data the GUI widgets display. These files are blasted across the Internet between a Java servlet running on the web server and a Java applet running in your browser. In fact, the applet and the servlet are exactly the same code. On top of that, you could write most of your Java as a boilerplate three lines, some annotated variable definitions, and some annotated function definitions. These only have to define the data and functions behind the GUI, the three lines of boiler plate take care of EVERYTHING else. By naming things the same, widgets, variables, functions, etc. all get matched up and synced across the network automatically. That's why Java introspection was heavily used, though I've had to come up with another method in EFL. So this happens - User opens web page. Server sends web page, with a copy of the Java applet / servlet embedded. Java applet runs in users browser. Java pulls across the matrix-RAD library if they don't already have it in cache. It's small. Ish. The Applet requests the matching skang file from the servlet copy running on the web server, then runs it, displaying the GUI. Servlet, knowing there's a new user, sends them initial data to populate the GUI. Applet displays data. Applet sends skang with the data changes in response to the users widget twiddling, to the servlet. Servlet calls functions with the same names as the widgets being twiddled, passing them the new data. Servlet does stuff with the data, then sends more skang, for different data, or different GUI stuff, or even does it's own widget twiddling. Some of the processing could be done browser side if that made more sense to the developer. Typically basic data validation for example. Though if the GUI was complex, it could change itself with no server intervention. There where lots of tricks like that with the goal of making things as easy and network transparent as possible. The exact same code could also run locally as a full blown application, or run the skang file directly if your OS supported that sort of thing. There was even a built in GUI editor that was easy to use, or at least plans for one, I skimped initially and just pop up a text editor with the skang in it. That was matrix-RAD, SledjHamr's gonna be different. For a start, it's not written in Java. This time around I'm using Lua's ability to emulate the features of other languages to morph skang into Lua. Hence this being a reboot, same ideas, similar mechanism, attempt to get the syntax as close as possible, but not gonna be possible to do a complete syntaxectomy. I had great results last time, looking like I might get similar results this time. Though now, a decade later, something designed to be moderately resource friendly would have to gain a heck of a lot of weight to even be noticeable amongst today’s inner-toobs'O'bloat. Also, the virtual world itself has other parts that impact on this. There's an internal virtual world protocol / file format that I haven't finished inventing yet. A legacy scripting language (LSL, or Linden Scripting Language) that is translated to Lua, before running in LuaJIT (it's faaaaaaaaaaaaaaaaast, many orders of magnitude faster than SL/OS). I have already written from scratch an implementation of one of LSL's three GUI widgets, the actual hard one, in Lua instead of the original C++ using this new GUI system I call GuiLua. Somehow I hope to smoothly combine all of this into something that is, .... , sane? Or at least easy to use, and entertaining to tweak. The point of all this is that I'm developing a networked GUI that is based on EFL, written in C + Lua, and some parts might be useful for EFL itself. In fact, some parts of it are things I wrote for Edje_Lua v2, only expanded upon. Raster mentioned sending Lua tables as, er, what ever the internal EFL messages are called this month. Not sure if that is being worked on here in EFL, but I am working on it in SledjHamr. Coz at some point, the entire protocol must be able to be done as Lua sent over the network, as well as some yet to be determined binary based protocol. Eet is in the running there, as wall as a different design I haven't finished inventing yet, or sending complied Lua files across the nets. I've seen two efforts that result in Lua running in the web browsers (one even worked for me in my normal browser), so that might expand my scope a bit. B-) Let me know if any of that ramble is interesting, or being worked on in EFL already. It was Rasters recent loop commit that got me thinking, this stuff I'm doing could be used to communicate between loops. Unless I have that completely arse backwards. It's already using EFL threads to get the scripting engine faaaaaaaaaaaaaaaaaaaaaaaaaaaaaast. Passing LSL messages between LSL scripts, as well as up and down the chain to the client. I've recently converted most of those internal LSL messages to Lua and GuiLua based messages. There's a bit more C integration than was in Edje_Lua v2 as well, and working on more. /ramble -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
