This isn't really a formal announcement, but more of a point-out to the formal announcement.

This is a project I've been working on for nearly a year and it's finally to the point where I feel comfortable releasing it to the public. 99% of my posts over the last year on LQ were related to this project, so a lot of my ideas and troubleshooting fixes were inspired here.

Keeping it short, Resourcerver is an IPC infrastructure used to facilitate well-defined communication between processes. The system is designed to host numerous client processes on a central server process that routes the IPC between clients. The central server is meant to be a nearly-invisible component of a system of client processes commonly bound to it. These processes come together via IPC to form some sort of larger application.

Each client process, designed by a third-party developer, ideally has a specific purpose within the system. For example, a system designed to perform mass data calculations might have a client process for data retrieval, one for data processing, and one for a user interface. Each being a separate process, all can run under different user and group IDs.

Incidentally, and perhaps as its most important feature, the application itself becomes somewhat organic in that it can be assembled incrementally, can be modified while running, and can have an entirely different structure every time it's run.

Each cluster of clients bound to a server is considered a "system." Multiple systems can be linked either locally or across a network. These connections allow client processes to exist on separate machines, yet still be as much a part of the application as they would be on the same machine.

This is a system I envisioned in my head about a year ago, and it's been haunting me in my sleep for about that long. Though I have it working in binary form, I'm no judge of the quality of its documentation because it's been coursing through my veins for as long as I can remember.

Please take a look at the project's site if you're interested in high-level IPC. This is the very first release and it has a long way to go, but hopefully it will evolve quickly with the input of other developers and users. Thanks!

Resourcerver - *nix Resource Server

ta0kira

I haven’t taken a look at it yet, but what advantages does this have over dbus (or am I way off base)?

While the concepts are quite similar, Resourcerver exchanges executable objects rather than messages. Each IPC "segment" is a command, and each command has a specific action it takes when executed by its target. Some just register messages in a queue, but others execute some sort of operation, to include locally-defined actions like making a network connection.

Resourcerver uses 4 well-defined client types which correspond to 4 distinct roles within any given system. The command-based IPC system is regulated based on these types, meaning that not all clients can send, receive, or execute all given commands.

The built-in set of IPC commands is highly expandable. Developers can easily create new commands that perform unique actions when executed and can define required client attributes for using them.

Rather than being a facility for stand-alone programs like dbus, Resourcerver is intended to be the "glue" of large, multi-process applications. The main advantage of this is that the application's structure is never final, even when it's running. Components can be added and removed while the application is running, or can be expanded using clients made newly-available through a network connection.
ta0kira

Additionally, the entire framework is designed with room for expandability. I've strategically designed the system so that developers can create their own extensions easily rather than waiting for the project itself to come up with one they need. I envision the project becoming an organic system of extensions, with a significant portion of those coming from third-party developers.

This is still a fairly fresh project, so its ideal and optimal implementations aren't known yet.
ta0kira

While we're on the subject of dbus, I'll mention that the protocol used by Resourcerver is arbitrary and replaceable. It currently uses a line-based text protocol that allows embedded binary sections, so it easily transmits all types of data, to include structures taken straight from memory. It uses standard network protocols and has a plug-in interface for application-level (level 5) network security filters (since I'm no network security expert, I made it easy for those who are to create their own.)

Resourcerver is a high-level IPC system, whereas dbus is low-level. Resourcerver will therefore never have a protocol specification or definition because all of its IPC concepts are component-based. In other words, Resourcerver IPC commands assemble themselves, and therefore parse themselves, based on conceptual components and those components are 100% replaceable, often without recompilation of the client themselves.
ta0kira

Sorry, I didn't realize I had so much to say about it! Here's something interesting about the command-based IPC.

Though not currently documented, commands are created and parsed using the hparser library. This library incidentally allows a developer to create plug-in Resourcerver commands that contain an arbitrary XML structure when transmitted, and expand into an object tree (such as embedded GUI components) when parsed. The format itself will allow the server to parse the command "inertly" for forwarding, but will allow those clients with the plug-in loaded to assemble an "active," executable version when parsing. The effect of this is the ability to transmit structured data (going far beyond individual struct and class instances) that can be reassembled on the receiving end.

This latent feature isn't documented yet, but is implicitly supported. I'll add it to the Resourcerver documentation once I finally get some hparser documentation put together.
ta0kira