DevelopingWithFluidIDE
DevelopingWithFluidIDE
This document gives a quick overview of how FluidAE can be used for application development. This information is intended for those who already have a thorough understanding of the Euphoria programming language, version 4.0. If you do not, you can read the Euphoria Reference Manual here.
The kernel manages modules, user security, Fluid File System, connects to other kernels through the Fluid Network Protocol. Each CPU core can have an instance of a kernel, the kernel on Core 0 is in control of that machine. Each kernel has Modules running, which provide services for the system. Each Core can have a different set of modules, or in other words, modules can be distributed among multiple cores to spread out the workload.
This protocol allows kernels to link together and transfer messages between modules. This works between cores on a computer and between computers on the network. Modules are able to use this protocol to establish "sessions" with other modules and call "commands" on them. You can connect to a module in the same process, in a different process on another core, or on another computer. You can request a specific module at a specific location, or just request a specific type of module and let the system select which one to use from a list of available locations, based on distance, connection speed, connection reliability, cpu speed, cup load, etc. It is also easy to do distributed processing. You can request multiple instances of a specific kind of module, and the system will connect to as many as needed or available and split the workload among them.
FFS is a virtual file system that modules can access. It automatically handles network file transfers, synchronization, replication, etc. Remote or local files can be seen the same way by modules. FFS uses FNP to transfer files remotely. The Fluid File System is a very important feature of FluidAE because it lets you access files in a very simple way, without worrying about where the files are physically. It doesn't matter what physical server they are on, if they are in a certain place in the folder structure, that is where you will see them on any computer on the network. This will be explained in detail in another document.
When programming in FluidAE, you depend heavily on calling commands in modules. They are like dynamic include files. The syntax for this in pure euphoria would be difficult and time-consuming to type, so this is why modules and applications are written in Fluid Source Code syntax, which is euphoria syntax with a few modifications to make it simpler to refer to modules, sessions, and commands. Plus, the IDE is able to recognize when you are trying to refer to a module or command and can help you by displaying lists such as computers, modules, commands, or parameters. FluidAE has a built-in pre-processor and a specially-modified euphoria interpreter that can dynamically load and run multiple programs at same time within the same process.
Here is small example of what Fluid Source Code syntax looks like:
.gui.open("./gui") --local, default core
.gui.open("?/gui") --auto-location
.gui.open("./gui#1") --local, core 1
.gui.open("/projector/gui") --"gui" module on "projector" computer on current network
.gui.open("fnp://192.168.0.101:54321/projector/gui") --ip address and port to network's FNP server, internal computer name, module
.gui.open("fnp://fluidae.com/projector/gui") --domain name of network's FNP server
.gui.open("fnp://fluidae.com/?/gui") --domain name of network's FNP server, auto-location inside network
atom winMain
winMain = .gui.widget_create(0, "window", {
{"title", "Test Window " & sprint(w)},
{"position", {100, 100}},
{"size", {640, 480}}
})
.gui.widget_show(winMain)
.gui.close()
This special syntax has three different uses: modules, scripts, and applications.
Module source files have the extension ".m" When FluidAE starts up, it build a kernel from source for each CPU core. This means that .m files get converted to pure euphoria syntax and get included in the kernel build.
A script is a file that can be executed on-the-fly for a specific purpose within a module. Each module may have different requirements for what elements need to be in a script file. For example, scripts can be used to design themes for the Graphical User Interface module. A theme file may end in the extension ".th" and have specific required top-level variables and routines in it so that the module can interface with it correctly.
Applications are script files that are specifically designed to be executed by the Application Module. The Application Module is what you use to run and monitor all of the applications on the system. Technically, an application could be written as a module, but to run it, you would be required to rebuild and restart the entire system. An application can be written, tested, modified, and distributed within FluidAE without interrupting the entire system. Modules affect the entire system and should be written and managed by administrators. Applications, however are intended to be written and modified by any user to fit their own needs. Each user has his own environment so that he can't affect other users' environments. See FluidPrinciples for more information on this topic.
One interesting thing you may have noticed is that this allows the FluidAE software to edit parts of it's own source code and run it without restarting. This opens up the possibility of reflective programming!
When Fluid Application Environment 1.0 is completed, it will have some exciting features: a powerful development environment, a customizable graphical user interface, smart resource and file sharing, multi-core usage, easy distributed processing, scripting, reflective programming, and-of course-the satisfaction of using the elegant Euphoria programming language.