faerion-devel — Discussions about the developement of Faerion and subprojects

Re: Optional message handling

[Justin F. <vh...@us...>]

Alexey Zakhlestine wrote:
> I was thinking about such function during the last week. It would be
> useful for the startup-verifier, I was mentioning to you verbally.

I'm not sure if I understand how queue chaining could help ensure that 
all modules have loaded.

> On the other hand, parabellym is vulnerable to hijacking already, as
> there is no "official way" to identify the recipient. Parabellym,
> currently, is the system, where _anyone_ can give any command to the
> unknown _someone_. It's just the question of knowing the correct
> command, and being lucky to be the first subscriber.

Well, pb is not that much a hostile environment.  Like in any other 
application, any part of the code can call any other part of the code 
and you don't know who the caller is.  This is partially covered by the 
build-in C++ access restrictions, but it usually prevents one from 
making a call by mistake, not on purpose.  Same thing with pb: if you 
send a normal message now, it either arrives to the right target and 
everything works well, or it doesn't arrive at all.  If a module 
intercepts a message, it just won't come to the other module, and the 
system will fail to function.

Perhaps the best way out would be to use hooks.  That is, the previously 
discussed callback mechanism: you send the callback message id to the 
main handler and it then calls you when necessary.

Re: Optional message handling

[Alexey Z. <in...@in...>]

I was thinking about such function during the last week. It would be
useful for the startup-verifier, I was mentioning to you verbally.

But in my case, I, actually, found an even better solution, which
doesn't require parabellym modification.

So, theoretically, such functionality could be useful, but I don't like
the possibility of hijacking, just as you..

On the other hand, parabellym is vulnerable to hijacking already, as
there is no "official way" to identify the recipient. Parabellym,
currently, is the system, where _anyone_ can give any command to the
unknown _someone_. It's just the question of knowing the correct
command, and being lucky to be the first subscriber.

Optional message handling

[Justin F. <vh...@us...>]

I've been thinking about adding the ability for modules to refuse 
processing a message, passing it to the next listener.  This way known 
messages could be extended by modules, instead of introducing the new ones.

This would be mostly applicable to protocol handlers, such as IRC, where 
a message carries whatever the client said, only parsing it to a more 
readable binary structure.  Take IRC for example.  If the standard 
protocol handler does not support a command, say, "WHOWILLBE", it just 
reports an error to the client.  To support such command, a new module 
must be written which handless all commands including "WHOWILLBE".  Or 
passes "common" messages to another handler of the same kind.

So, it's all about chaining the subscribers.  This is not the case when 
notifications can be used: if a protocol command is unhandled, an error 
must be reported, it must not just be ignored (which would happen if we 
used notifications to deliver protocol commands).

Adding such a function would be a matter of one function (say, 
para_msg_bounce()), which, when called, would forward the message to the 
next subscribed queue, leaving the sender blocked.  When the end of the 
queue is reached, a PEC_MSG_NO_RECIPIENT error would be reported.  There 
is one side effect: messages could be hijacked, modules could spy one 
over another.  I currently don't know whether it's good or bad.

Also, the whole chaining stuff is somewhat specific to protocol 
handlers, I believe, and I'm not sure if it's not too specific to be 
added as a base function.

Also, if there are different ways of implementing this, which I have 
somehow missed, I'd like to know about them.

This is a call for comments, yes.

Re: multi-threaded modules in parabellym

[Justin F. <vh...@us...>]

The final change was made.  No longer modules are subscribed for 
messages, but queues.  The main module thread has a queue by default, 
other threads must be attached to a queue using para_msg_attach().  The 
queue id is passed to para_mod_body() instead of the old modid 
parameter.  The para_mod_signal() function was renamed as para_msg_signal().

Everything compiles, but I didn't test if it works yet.

I'm thinking of releasing version 1.0 after the current code proves to 
be working and bug free.

multi-threaded modules in parabellym

[Justin F. <vh...@us...>]

Wake up.

So I had to eliminate the limitation of only the main module thread 
(MMT) being able to exchange messages.  The module subsystem was 
rearranged and partially rewritten, it is now more lean and clean. 
Summary of the changes:

1. Any thread can send messages.  Only the MMT can receive (and thus 
reply to) them, though.  The rest ("distrophic threads", DT) can only 
send messages at this moment.

2. Only the loader can load and unload modules.  The loader is the 
thread that was first to call the library.  It can not receive messages, 
too.

3. Modules can be loaded as many times as needed.  Modules that must 
only be loaded once must enforce this restriction on their own (a matter 
of a single static variable).

The documentation was also updated to represent the current state of 
affairs.  What has little to do with reality, such as notions of a 
"distributed environment", was censored out.  There is also less 
redundancy now.  The "library" section of function descriptions was 
replaced with "access".

What I'm thinking of now is an ability for multiple threads to receive 
messages from a single message queue.  This would make DTs and MMTs 
equal.  This way multi-threaded modules would actually make sense. 
(Imagine a module which spawns X threads, each connected to a database; 
DB connection pooling made easy.)

What I need is a good idea on how to authenticate threads to prevent 
message hijacking.  Perhaps I'll use the modid parameter of 
para_mod_body() and add a function, say, para_msg_attach(), but if 
anybody has a better idea, step out.

other important changes

[Justin F. <vh...@us...>]

Oh, and I forgot about two more important changes.

First, the debug version of the core now logs everything to 
parabellym.log, using libflog.

Second, signals sent to modules are now queueed.  This makes them work 
like messages, but with a higher priority and without the payload.:wq

para_core_load gone for good

[Justin F. <vh...@us...>]

It looks like the library have been loaded twice by the console stub. 
The library was already loaded during the process start-up, because 
functions like para_mod_load() were used in a regular manner, without 
looking them up using dlsym().

For some reason under Darwin this resulted in loading the same library 
twice, even though there was only one copy of it installed and the path 
was obviously the same.

This resulted in a "fresh" copy of all static variables, effectively 
deinitializing the library.  I don't think that the ability to load the 
core dynamically worths everything that has to be done to get past this 
problem.  Link using -lparabellym.  Normally you don't notice the 
difference.

There also was a deadlock when a message was sent to a module that is 
actively waiting for it.  Introduced seml::waitex() with a parameter not 
to lock the mutex (this actually goes to libfaeutil).

Re: FreiSein (parascriptum/parashell reincarnation)

[Justin F. <vh...@us...>]

komrades,

> Justin proposed to us LUA.. to be honest, I wasn't impressed with one
> the first time I saw it and I'm not impressed now. probably LUA's a
> good thing but we're gonna make much more lightweight, fast and
> extensible product.

Well, trying to find an argument why Lua should not be an option I've 
discovered what I was afraid of.  It is portable and runs on all known 
modern platforms.  It compiles the source to a byte code before 
executing it.  It is very small: the maximum size of the binary is 
around 41k (roughly the same on all platforms).  It is modular by 
design: you can disable modules responsible for source code translation, 
making the library even smaller (around 25k) and the execution will be 
even faster.  This is all explained in Technical Note 2 [1].

It allows writing custom extensions in form of operators, commands and 
variable types.  The more I read, the more I like it.  I'm not exactly 
sure why would we reinvent this wheel, anymore.  Neither am I sure that 
we can do it this good in an acceptable time slice.

So what exactly do you dislike in Lua and where exactly does it 
dissatisfy you?

1. http://www.lua.org/notes/ltn002.html

out.

Re: Unicode in libfaeutil

[Justin F. <vh...@us...>]

> Nothing overly complex.

Jany asked for a tool to extract parts of libfaeutil.  There is one now, 
a script called "pack".  It can be used to build packages that contain 
selected components, of which fileio and unicode are now available.  It 
adds the README file as a bonus.  However, I decided to maintain the 
library with a dual interface: you can extract necessary components, but 
you can still install it as a separate library.  This was inspired by a 
couple of other subprojects failing to compile due to the absence of the 
library.  However, less rules enforces means more freedom.  More freedom 
is good.  So it's good after all. ;)

Also, the emulated functions, such as strlcpy and strlcat, have lost the 
"faeutil_" prefix.

Unicode in libfaeutil

[Justin F. <vh...@us...>]

Back to life.

Several functions for working with Unicode were added to libfaeutil. 
This includes simple functions for converting characters and string from 
UCS-2 to UTF-8 and back, and "heavier" functions to work with specific 
charset mappings.

The main part of the code was taken from Faerion, of course.  There are 
only four functions that work with mappings now, without any structures 
and constants.  Two functions to load/unload an encoding (identified by 
a void* handle), two functions to convert from the encoding to UCS-2 and 
back.  Note that the intermediate form is no longer UTF-8, which was 
rather ineffective.  Neither is UTF-8 a mapping, as it was treated in 
Faerion.  This means that applications that want to use this part of 
libfaeutil need to distinguish between UTF-8 and a generic mapping. 
They also need to implement transliteration on their own (which is, 
however, rather simple).

Libfaeutil is also not a stand-alone library anymore.  It is a 
collection of files to cut'n'paste from.  Just a heap of files collected 
in a single place.  The reason for this change is the fact that some 
developers dislike the idea of including a dependency for what was 
originally meant to be a collection of back-up functions (e.g., invoked 
when the dependant functions fail to exist).  Being a dependency itself 
kind of mitigates this revenue.

Libfaeutil now has a documentation, called README.  It's a RFC-like 
document with detailed descriptions and example.  Tired of DocBook at 
the moment. ;)

Back to Faerion, I think I'll try moving it to the new Unicode functions 
soon.  Perhaps I'lll be working on enabling national characters in 
nicknames.  This means that certain amount of data needs to be stored in 
Unicode now (UCS-2, not even UTF-8).  This also means we'll need a 
tranlation table to convert all similarly looking characters (e.g., the 
letter "e" exists in both English and Russian code pages, with different 
codes) to prevent abuses.

Nothing overly complex.

Some sleep now.

Re: modules for F2 (was: parabellym)

[Jany E. <je...@us...>]

> 5. HTTP back-end.

> We want to register nicknames using a web site only for the purpose of
> implementing a Turing test and otherwise introduce the user to the 
> services we provide and other spam.  This module would not directly 
> interact with users; it would only authenticate the sender and process
> specifically crafted requests.  The sender would be the web site that
> deals with the user interface and contacts the back-end.

> the logic of services will be implemented in SM, too, and this module

> 6. SMTP back-end.

SM, SM.. huh, kinda data base, yes? I don't think it really matters
whether data is dynamic or static (per-restart saved). it might be
config otherwise. any data'd be saved, though, some frames might be
stored as a dynamic structures for the blast access.

I also think SM'd deal with some real DB. this way, it becomes a
data-server, as you once said. and it sure should be xml-based.

especially in context of such amazing back-ends as http or smtp. which,
by the way, are dozens in future.

it comes so, internal modules use SM to store/get any data. SM's their
gate. though, something from the outside (like http back-end) adds
data to the storage with other gate. imo, the wise usage of xml, -
heterogeneous system comunications.

from the other side - any DB is obvious. any _real_ storage in fact.
SM could also be. we only provide different interfaces, then. I'm not
sure, your thoughts?

as about http back-end as is, - it may take less than two days to be
ready. nothing special, you know ;)

FreiSein (parascriptum/parashell reincarnation)

[Jany E. <je...@us...>]

good morning komrades!

I've decided to restart this project after some consultations with
Justin and due to that fact we need a scripting language yet.

Justin proposed to us LUA.. to be honest, I wasn't impressed with one
the first time I saw it and I'm not impressed now. probably LUA's a
good thing but we're gonna make much more lightweight, fast and
extensible product.

in fact, I have one more motivation to reanimate Parascriptum
[especially now, when I do have a matrix library ;) hehe, some of you
have seen that crap ;)], - an improved math calculator, where I can
easily add new types, expressions, functions, and see the result
just-right-now. you probably suggest me use any scripting language.
at present there're dozens. though, take a look at attach. I've put
demo script there, which's supposed to run under FreiSein.

It's extensibility is almost endless. you can use it like simple-shell
either raise up it's OO features to C++ level ;) the next step is
pre-compiler. so, as Justin said, we could programm logic with it.

and let me notice you, that we're gonna write linear parser!

I won't explain it's internal sructure now, you see it with first
commits. It's been changed several times, and even Justin's not a full
picture now.

p.s. somebody says I do some shoot, instead of doing something really
useful.. well, may be he's right ;) but I won't ever give it to KPI ;P
FreiSein's a true OpenSource subproject, which groves under F2
machine ;)

p.s. we probably don't need Lane in futue at all. FreiSein can be
configured so, it would work like Lane. have to think about it too...

p.s. any syntax means nothing at all, we can easily replace []
brackets with . (just point), frei..?

last comments and thoughts before coding, deep from the night, jeteir.

modules for F2 (was: parabellym)

[Justin F. <vh...@us...>]

> The nightly 
> script runs this test after rebuilding the source tree, so it should be 
> seen here at midnight MSD, if the nightly script does not break.

It is broken.  I can't do anything about it now -- the CVS repository is 
damaged, I'll be taking actions this night.

> This means that the infrastructure for other projects (namely F2) is now 
> ready for being used.

I have once promised to write a list of required modules for F2.

1. Networking stack.

We obviously do not want to deal with parsing the RFC1459 protocol in 
each module.  So, this will be the module that maintains network 
connections and deals with the RFC1459 protocol (split messages to 
attachments and combine attachments to messages).  It will accept 
incoming connections and establish outgoing ones (using SRV only).  It 
will perform hostname resolution and reverse mapping check for incoming 
connections.  I have written a documentation for this module, proposed 
name is "cetb" [2].

The proposed version only parses the protocol and sends one callback 
message for all events on a connection.  Kind of a dispatcher.  The 
proposed version is kind of a wrapper around RASCAL.  However it can be 
enhanced to send a message per command to allow handling different 
protocol commands by different modules.

I do remember all previously circulating talks about having a more 
generic networking interface which would not be directly connected to 
the RFC1459 protocol, but I think the proposed idea of building a 
message from a set of attachments is extensible enough.  The module can 
be easily modified to work with a custom binary protocol, which would 
send every attachment as a true Pascal string, instead of using the 
RFC1459 schema.  I can not imagine a higher level of extensibility right 
now; even named parameters can be implemented without much effort 
(however I think that that would hadrly be efficient on high-scale neworks).

2. Storage maintainer (SM).

I still think that separating the data worths separating from the 
unrelated logic.  One module would maintain both the static (saved 
between F2 restarts) and dynamic (in-memory) data.  It would use disk 
storage when necessary and it would maintain consistency of the data.

This means that SM is, actually, the main module which resembles the 
most important part of the current ircd, but which is freed from 
interface operations.

The module would send various notification messages when things change, 
so that other interesting post-processing could be done without 
modifying the SM code.

3. RFC1459 protocol handler.

This module would handle all standard protocol commands like NICK, USER, 
JOIN, PART and so forth.  Nothing special.  For example, the handler of 
the JOIN command would split process the parameters and split 
multi-channel joins into series of atomic joins which are served and 
validated by SM.  If SM reports a failure, all necessary actions are 
taken and events are reported by the JOIN command handler.

4. Services.

In F2 services are merged with the server, so the interaction is not 
performed by by sending messages, but with NICKSERV and similar 
commands.  Or otherwise, not yet sure.  What is already known is that 
the logic of services will be implemented in SM, too, and this module 
would be yet another protocol parser which enables several commands and 
does not really implement anything new.

5. HTTP back-end.

We want to register nicknames using a web site only for the purpose of 
implementing a Turing test and otherwise introduce the user to the 
services we provide and other spam.  This module would not directly 
interact with users; it would only authenticate the sender and process 
specifically crafted requests.  The sender would be the web site that 
deals with the user interface and contacts the back-end.

6. SMTP back-end.

Changing passwords requires email confirmations ("use this activation 
code to change your password").  We could also send offline messages to 
the user's email address as they are stored.  This would also require 
SMTP.  The interface would be quite simple: receives the formatted 
RFC822 messages and sends it.  Deals with the SMTP protocol.  Simple.

That's almost it.  Tell me if I have forgot anything.

=== References: ===

1. "Perspectives of Faerion"
    <http://hex.forestnet.org/feed/dev.html.var#9>

2. "Faerion, iteration 2.  Cetb." -- a documentation on the networking 
module.  It also serves as a proposed standard for Parabellym module 
documentation.  Reviews welcome.
    <http://faerion.sourceforge.net/doc/parabellym/mod/cetb/>

parabellym

[Justin F. <vh...@us...>]

Now it seems to be fully working.  There is a pair of test modules, 
libtest-send and libtest-wait, which exchange several messages, of both 
notification and response-requiring types.  Seems to work.  The nightly 
script runs this test after rebuilding the source tree, so it should be 
seen here at midnight MSD, if the nightly script does not break.

This means that the infrastructure for other projects (namely F2) is now 
ready for being used.  Everyone thinking of using either rascal or pb is 
welcome to do so more than ever.  I need to prove the sufficience of 
both APIs and the possibility to introduce to wider masses.

Thoughts and comments.

R2_0_M2

[Justin F. <vh...@us...>]

Hello, world.

Three days of intensive bug tracking resulted in fixing a bad type cast, 
adding back a forgotten mutex unlock (was causing deadlocks), adding a 
forgotten per-connection mutex in BSD mode, corrections of the DNS 
packet resend time calculation algorythm (there was a typo, actually). 
Also, `pobject' was made a template class to simplify working with it.

Generally, it works now.  It doesn't hang, it doesn't crash.  Test 
programs 04 and 05 work fine, I'm quite happy with the result.

Testers are already welcome as this is a fully working version with only 
one exception: rascal_gethost needs to be tested and enabled.

Re: nightly builds at -commits@

[Justin F. <vh...@us...>]

> 1) I have sent a request to add -commits@ to gmane.

Works now.  Should save significant mailbox space.  At least mine.

Re: nightly builds at -commits@

[Justin F. <vh...@us...>]

> I can set up linux machine, I think..

That'd be useful, I think.

> You are thinking about something like this: 
> http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox
> aha?

Wow, that looks scary.

Actually, I was thinking of a periodical source tree consistence check 
and, as an added bonus, the script could (later) produce source/binary 
packages and upload them somewhere.  Tinderbox serves a different 
purpose I think.

Re: nightly builds at -commits@

[Alexey Z. <in...@in...>]

Justin Forest wrote:

> 1) I have sent a request to add -commits@ to gmane.
> 
> 2) The script for performing nightly builds seems to be working well 
> now.  I have redirected it to send mail to -commits@.  I now want 
> systems other than OpenBSD to do the same.  If anyone has a machine that 
> can spare some ten minutes each night, I'd like to hear from you.  The 
> script will need access to cvs.sourceforge.net over pserver (port 2401). 
>  I'm using the following crontab entry:
> 
> 0 0 * * * cd /home/hex/.nightly && test -x nightly && (sh nightly 
> 2>&1|mail -s "`date +'%Y/%m/%d'`: faerion tree periodic build (`uname`)" 
> fae...@li...)
> 
> The script requires no human interaction (however, if that's possible -- 
> I'd like to have (restricted) access to the machine to perform necessary 
> testing and patching if anything breaks down and I can't resolve the 
> problem on a different system).

I can set up linux machine, I think..
You are thinking about something like this: http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox
aha?

Re: rascal vs. librascal

[Alexey Z. <in...@in...>]

Justin Forest wrote:

> Oh, btw, there seems to already exist a project named RASCAL (even at 
> SourceForge), it's a scientific calculator.  What all of you think about 
> renaming "RASCAL" to "librascal", kind of officially?

sounds ok, for me.

rascal vs. librascal

[Justin F. <vh...@us...>]

Oh, btw, there seems to already exist a project named RASCAL (even at 
SourceForge), it's a scientific calculator.  What all of you think about 
renaming "RASCAL" to "librascal", kind of officially?

nightly builds at -commits@

[Justin F. <vh...@us...>]

1) I have sent a request to add -commits@ to gmane.

2) The script for performing nightly builds seems to be working well 
now.  I have redirected it to send mail to -commits@.  I now want 
systems other than OpenBSD to do the same.  If anyone has a machine that 
can spare some ten minutes each night, I'd like to hear from you.  The 
script will need access to cvs.sourceforge.net over pserver (port 2401). 
  I'm using the following crontab entry:

0 0 * * * cd /home/hex/.nightly && test -x nightly && (sh nightly 
2>&1|mail -s "`date +'%Y/%m/%d'`: faerion tree periodic build (`uname`)" 
fae...@li...)

The script requires no human interaction (however, if that's possible -- 
I'd like to have (restricted) access to the machine to perform necessary 
testing and patching if anything breaks down and I can't resolve the 
problem on a different system).

Re: stack before

[Justin F. <vh...@us...>]

> JF> How interesting!  I must find a copy of the standards.  Got some?
> 
> no.. I just read C unleashed by R. Heathfield and L. Kirby. there were
> some references to the standard. indeed, we ought to visit either
> C-standard association site or ANSI site. they'ma have ;) to lazy to
> ;)

Anyway, I'm more and more moving towards "prefix_name" style (like, 
"faeutil_strlcpy"), so this problem should go.

> JF> Have fun!  Must be an interesting read.
> 
> honestly, I'm not impressed. probably it's a good language... too. as
> for me, it's syntax's a bit... I think JavaScript's much more elegant
> solution. you may only want hashes, though, this is not a problem,
> too. the only fact which surprised me - it's lightweightness. it's
> usage is damned easy, JS'' not

JavaScript is much more complicated and includes too many features that 
we don't use now and won't use later.  But if you look at Lua as an 
already available implementation of what you would otherwise need to do 
from scratch, it's quite good.  Isn't it.

Re: stack before

[<je...@fo...>]

JF> Is this a false positive on my sarcasm detector?..  Garbage collectors

yeah ;) the black UNIX humor. since I have UID eq -1, hehe ;)))

JF> How interesting!  I must find a copy of the standards.  Got some?

no.. I just read C unleashed by R. Heathfield and L. Kirby. there were
some references to the standard. indeed, we ought to visit either
C-standard association site or ANSI site. they'ma have ;) to lazy to
;)

>> P.S. I can't say something about Lua, yet. I've to read about it
>> more..

JF> Have fun!  Must be an interesting read.

honestly, I'm not impressed. probably it's a good language... too. as
for me, it's syntax's a bit... I think JavaScript's much more elegant
solution. you may only want hashes, though, this is not a problem,
too. the only fact which surprised me - it's lightweightness. it's
usage is damned easy, JS'' not

FASD project: Online survey launched

[<ben...@id...>]

Dear Open Source developer

I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate.
You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it.

With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development.


With many thanks for your participation,
Benno Luthiger


PS:
The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/.
We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list.

_______________________________________________________________________

Benno Luthiger
Swiss Federal Institute of Technology Zurich
8092 Zurich

Mail: benno.luthiger(at)id.ethz.ch
_______________________________________________________________________

Re: stack before

[Justin F. <vh...@us...>]

> JF> with optional thread safety, so it's "fast enough", too.
> 
> sure. but once you asked me to write a simple stack for faestarter.
> which is now needed due to Lua.

That was when?  Long before I decided to create libfaeutil.  I thought 
we were sleeping for enough time already.

> JF> structures larger than "four byte integers".
> 
> and it ties you to C++ only.

Who cares?  Stack isn't what you want to use in other languages.  Other 
languages are typically interpreted and don't achieve speeds at which 
you benefit from the low-level-optimized code.

> or you gotta make interfaces. indeed, I
> had this idea too, it's very usefull, yes. but I wanted faestack to be
> as close to the real stack as possible.

It should function as close to the real stack, yes.  So does list<>.

> JF> issue has the lowest priority so far.
> 
> we'd even write our own garbage collector, as well.

Is this a false positive on my sarcasm detector?..  Garbage collectors 
have nothing to do with the concept of allocators in STL whatsoever.

> JF> That depends.  Never seen a "CONSTANT__", so I quite got used to the
> JF> "__CONSTANT" style.
> 
> yeah, like most people do. though, ANSI C forbids this, due to all
> identifiers start with "__" are reserved for compiler use. I'm not
> sure, but I think C++ standard does too, at least in global namespace.

How interesting!  I must find a copy of the standards.  Got some?

> P.S. I can't say something about Lua, yet. I've to read about it
> more..

Have fun!  Must be an interesting read.