Beesnest ToDo List.
Not necessarily in prioritys order
Port Beesnest to Linux.
Although this is a very important task, I decided for now, to concentrate on
developing Beesnest for Windows. Better one working version then two incomplete
versions. Most of the classes that make Beesnest are pure C++. The classes that
are operating system dependent (I have 12 of these now), are in a separate folder
and need to be rewrite under Linux. Then just adding a make file, and the system
suppose to work (For the Windows version I use
Borland Command Line Compiler).
Adapters will probably have to run in a separate process. As for now,
adapters are DLLs that run inside the Beesnest process. Since any vendor will be
able to install adapters over the Beesnest framework, I have the problem of one
broken adapter crashes the entire system. Moreover, if an adapter is
running in a separate process, I can use any kind of language for it.
Even more, it will solve the problem of Firewall not "seeing" if the adapter
opens an independent connection to the Internet.
On the down side, we returning back to the CGI problem, too many
resources (even though an adapter process will run as long as the adapter is
"loaded"). Other problem will be to load two instances of the same adapter, at
the same time.
I need to work on it more...
Develop a scripting language specially for Beesnest.
I have this idea for a long time. If most of the work is done in the adapters, we
just need a very simple script to tie all the data together, and insert it to
HTML tags. No functions/classes are needed for this task. I want to create a
very simple scripting language BZB, everything is a string, and also non
programmer will be able to learn it without any problem.
This script will also create the separation between logic and presentation. The
logic will be executed using real scripts and adapters, and the HTML pages will
be generated using this new script.
Well... the main reason for this language is because it will be very
interesting to create.
Add the ability to save a compiled script.
As it is now, every part of a script that goes to a script engine, goes as a
pre-compiled text. No meter how many times the engine executes the script, it
will always have to compile it first (my initial thinking was that most of the
work will get done in the adapters). I have a way for Beesnest to get the
compiled code from the engine, and store it in a file. Then, in a second request
for this page, and if the source file hasn't been changed, Beesnest will pass
to the engine the already compiled code.
I will add the functions for this option to the engine interface as stubs, in
this version. But will implement this feature just in the next version.
Build other languages script engines.
Well, Beesnest can work with any script, I just need to build the script engine
that will connect between the interpreter and Beesnest. That is a lower priority
Applications Servers is a very well developed concept in the Java programming
language. I can have Beesnest use Enterprise Java Beans (next one), and maybe I
can write an engine for server side Java Script. But I cannot see how a
complete JSP page will work under Beesnest. Java took this stuff in a hole
different direction, and for big businesses, it has many advantages over the
Write a wrapper adapter to Enterprise Java Beans.
But, an Enterprise Java Bean class can be used by Beesnest, and also regular
Java classes. That will require the Java Virtual Machine to be installed on the
Write a wrapper adapter to Windows COM objects.
For hard core Windows users, Beesnest can talk also with COM objects. It will
require the use of a specific Beesnest-COM interface. Then any COM programmer
will be able to write Beesnest adapters.
Add SSL to Beesnest.
Most of the communication with Beesnest will be over the localhost, or over LAN.
However SSL encryption is an important option, and may be necessary in some cases.
I what the SSL to be an optional module to add to Beesnest, using the Open SSL
library. With it we should have an adapter-script to let the user configure SSL
from web pages, create a public/private keys pair, and sign it for themselves.
The Beesnest server itself is very well secured, but here are a few thoughts
about the relations between Beesnest and adapters or script engines.
I'm running Beesnest under the root (Administrator) account, but it is not ideal
from a security point of view. However it must have the permissions to run all
the adapters and the script engines. I guess that Linux will give me much harder
time with this issue then Windows.
For someone that uses a FireWall, Beesnest should be allowed to accept connections
from the Internet, but an adapter or script should not be able to open an Internet
connection, without an explicit permission. I think to add this kind of
permissions to the configuration files.
In any rate more work should be done on this subject.
Build an adapter-script that will let the user change the configuration from
Beesnest does not read the attributes of the "XML" tags in the configurations
files. I can use these attributes to instruct a script how to render the
configuration data into HTML forms. The user will be able to change and submit
these forms, in order to control Beesnest configuration. Every software vendor
that wants to use Beesnest, will have to add one or more configuration files.
But the attributes will be standard, and the script will be able to handle
these files no meter what is in them.
I want Beesnest to be able to listen also to a UDP port.
The application level protocol will still be HTTP (at least in the beginning),
but it will work over UDP. In some cases it will be more efficient to use UDP,
especially when we using the localhost. Moreover, when a script calls the
IdcResponse.Clear method, and then IdcResponse.Flush, it basically don't have to
use any more HTTP, and can transfer data with whatever protocol it wants. So a
script will be able to send any kind of UDP data to a client (but not a web
browser, maybe a web browser applet...)
Other software should be able to get some data about Beesnest.
I need to create a way for a software installer to find out what port Beesnest
listens to, which script engines are available and where is the Beesnest
configuration folder. I think I will use the HTTP OPTIONS query. Then a software
installer that is going to use Beesnest, will be able to know if it needs to
add a new script engine, where to save it's configuration files and how to build
the links to the application GUI (web pages). The idea is that every web
application will have it's domain name as "myapp.localhost", and it will be
mapped to a Beesnest host (with it's own root folder). In order to get
"http://myapp.localhost" to go to 127.0.0.1 we need to add an entry to the
system "hosts" file.
Script timeout. At first I wanted to do it with each script engine. It
turns out to be not a simple task, but I want the scripts engines to be relatively
simple to write. So I'm going to handle it from Beesnest itself. It is going to
make the execution of a script much more complicated, I need to run it from a
separate thread, and watch the time in the main thread. I need to think about it
a little more, maybe I will set a configuration option to run the scripts with
or without the timeout feature. I will deal with it in version 2. For now
Beesnest checks the timeout after the execution of each script, but it will not
help if the script enters an infinite loop.
Fix this web site, and write proper documentation for Beesnest.
That will be the hardest task of them all. I'm not a web site designer, and not
a very good English writer. I try to spend some time on writing a proper
documentation, but I'm way behind. However I keep the documentation in the code
itself on a high standard, and use Doxygen
to generate Java like documentation web pages.