Beesnest ToDo List.

Not necessarily in prioritys order

1. 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).


2. 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...


3. 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.


4. 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.


5. 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 task though.


6. Java ??? 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 Beesnest way.


7. 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 computer.


8. 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.


9. 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.


10. Security. 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.


11. Build an adapter-script that will let the user change the configuration from web pages. 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.


12. 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...)


13. 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.


14. 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.


15. 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.