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.