[ Home | Articles | Account | People | Projects | FAQ ] 
Created 19 Feb 2009 at 14:19 UTC by ta0kira, last modified 21 Feb 2009 at 05:15 UTC by ta0kira.
Notes:
|
|||||||||||
Resourcerver is a set of libraries
and programs used as the control infrastructure of
multi-process applications. An instance of an application
consists of the rservr server daemon and the
processes that server binds together. The server is the
starting point of the application, which in turn spawns each
of the application's component processes, referred to as
"clients." Clients are the 3rd-party functional components
of the application written with the Resourcerver
API to allow them to interface with the rest of the
system. |
|||||||||||
 |
|||||||||||
Although the diagram above makes
rservr appear to be an IPC server like many
others, its purpose is to bind the application together and
regulate its operation. The server daemon regulates the
control IPC of the application by enforcing several
permission sets. Each client process must select a
permission set defining what that client's general purpose
is. These permissions restrict which other types of client
one can communicate with and what actions it can perform on
the server daemon. The system defines permissions for three
main types of client: admin clients, to control the
structure of the application; control clients, to actively
control the processes carried out; and resource clients, to
actually carry out those processes. |
|||||||||||
| Client processes communicate with
each other using well-defined data bursts referred to as
"commands." Each command has creation and execution
permissions associate with it, as well as compiled-in
actions that are executed at the final destination. The
emphasis here is that the IPC system isn't intended
for data transfer; it's intended for communication to
control the operations of the application as a whole. |
|||||||||||
| Resourcerver has an expandable IPC
system to allow 3rd-party command plug-ins. A plug-in is
loaded at run time by both the originator of the command and
the target; by loading a plug-in, potential targets consent
to execution of the associated commands when they arrive.
The core system contains several plug-ins, all of which rely
on hook functions being defined by potential targets.
Commands execute their respective hook functions when they
arrive at a target, providing the function with the
parameters sent with the command. One of the more
illustrative examples is a plug-in library to request
networking actions. One command in the plug-in is a request
for a target to connect to a host; however, the plug-in
doesn't define how that will happen. The implementation of
the action is left up to the target when the plug-in
provides the hook function with the requested parameters of
the connection (such as the address and port.) |
|||||||||||
| Resourcerver has many other
features and capabilities not given here. It has extensive
documentation at the main page listed above. This is more of
a random summary of the project as a whole; therefore, it
might not accurately reflect the project's purpose. This is
a large project that can't be explained well in one page.
|
License: BSD License
This project has the following developers:
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!
del.icio.us
Digg
Google bookmark
reddit
Simpy
StumbleUpon
Furl
Newsvine
Technorati
Tailrank