Crate romp

Romp

romp is a messaging server that uses the STOMP protocol, and STOMP over WebSockets.

romp can run as a standalone server, hosting queues and/or topics to which clients can subscribe or send messages. It can also host bespoke filters (handlers) to programmatically respond to incoming messages. This enables romp servers to act as app servers, using asynchronous messaging model.

Custom filters can be added as follow...

    // Filter structs have an init() method
    use romp::bootstrap::romp_bootstrap;
    use romp::workflow::filter::ping::PingFilter;
    use romp::prelude::{romp_stomp_filter, romp_http_filter, romp_stomp, romp_http};
    use romp::workflow::filter::http::hello::HelloFilter;
    use romp::message::response::{get_response_ok, get_http_ok_msg};
    use std::sync::Arc;

    romp_stomp_filter(Box::new(PingFilter {}));

    // Http Filter structs different error handling
    romp_http_filter(Box::new(HelloFilter {}));

    // STOMP filters can be written as closures
    romp_stomp(|ctx, msg| {
        if let Some(hdr) = msg.get_header("special-header") {
            let mut session = ctx.session.write().unwrap();
            session.send_message(get_response_ok("howdy".to_string()));
            return Ok(true);
        }
        Ok(false)
    });

    // as can HTTP filters
    romp_http(|ctx, msg| {
        if "/pingerooni".eq(ctx.attributes.get("romp.uri").unwrap()) {
            let mut session = ctx.session.write().unwrap();
            session.send_message(Arc::new(get_http_ok_msg()));
            return Ok(true);
        }
        Ok(false)
    });

    // Then bootstrap the server, this is commented out in the docs, because of some bug in the cargo test when this comment is uncommented.
    // There is no bug in the code below its used like that in main.rs that compiles.
    // tokio::run(bootstrap_romp());

Modules

body_parser	Code related to parsing STOMP message bodies, either fixed content-length or \0 terminated.
bootstrap	Bootstrapping, i.e. initializing, a romp server.
config	Configuration code, for parsing server config romp.toml, logging config, and romp.passwd usernames.
downstream	upstream/downstream features i.e. handling MESSAGE requests for a downstream "edge" server. i.e. xtomp. Upstream STOMP servers should CONNECT to a downstream SUBSCRIBE to memtop/up destination and handle incoming SEND requests returning MESSAGE responses to memtop. Upstreams should perform some bespoke business logic based on messages.
errors	Common error definitions returned by the romp server.
init	Contains global objects started during bootstrap, this is principally the CONFIG which provides access to data in romp.toml, SERVER which contains the destinations (queues and topics) and USER which contains configured users and functions to authenticate users.
message	STOMP message representation and utils for generating responses and serialing STOMP messages.
parser	STOMP protocol push parser, parses command and headers, not the body.
persist	Persistence of received STOMP messages.
prelude	A "prelude" for users of the romp crate.
session	Code related to maintenance of the underlying TCP connection.
system	Linux specifics.
util	Utility methods.
web_socket	HTTP WebSockets protocol parsers and related functions.
workflow	Workflow concerns application logic, either in built STOMP message handling, admin functions or bespoke application specific functions.