How can I integrate my component into the stack

[streetycat]

I implemented a component named cyfs-group, and I want to integrate it into the cyfs-stack and output the similar entry as other modules(NON, router_handles, eg):

cyfs_stack.group_manager();

but it depends the NON in cyfs-stack, Now, I can only define a trait, and implement that in cyfs-stack. It looks strange with other modules.

example:

// in my module
struct MyModule {}

impl MyMoudle {
    pub fn open(non: Box<dyn NONDriver>) {
        ...
    }
}

pub trait NONDriver {
    ...
}

// in cyfs-stack
struct CyfsStack {}

impl CyfsStack {
    pub fn open() {
        let non = create_non_service();
        let non_driver_for_my_module = NonForMyModule::new(non);
        let my_module = MyMoudle::open(non_driver_for_my_module);
    }
}

struct NonForMyModule {}
impl NONDriver for NonForMyModule {
    ...
}

impl NonForMyModule {
    fn new(non: NONService) {
        ...
    }
}

I think it's a good idea to separate each service(NON,NDN,BDT,RouterHandle, eg.) from the stack, the stack seems too large now, it should be a shell to integrate all modules, but not include those.

[streetycat]

I think I have known it.

The stack include 2 parts:

1. Server: it's named with CyfsStack, and implement in cyfs-stack, It's running in a service named gateway as a process, any client will call the functions through the http/ws session.
2. Client: it's named with SharedCyfsStack, It provided for DecApp used as a proxy for the CyfsStack, and implement in cyfs-lib;

The 2 parts looks seem in interface, So, there a many same Structures for them, and the Structures is implemented in the cyfs-lib.

We can depend the cyfs-lib instead of cyfs-stack.

By the way, the Structures for DecApp must be implemented in the cyfs-lib.

[streetycat]

I have do it, let me talk about my solution. I hope you can follow it step by step to complete your work without understood the theory, and I haven't fully understood the theory. You can study the detail from the source code.

1. Define the interface for DecAPP developers
   Module entry
   Interface for service customers
   Interface for service developers
   Delegate handler for service developers

2. Create 2 modules as client/server for Stack and 2 submodules in cyfs-stack:
   Client for Stack that will be integrated with SharedCyfsStack in cyfs-lib
   Server for Stack that will be integrated with CyfsStack in cyfs-stack
   Submodule of traits in cyfs-stack that will provide the abstract interface to process or forword the calling from Client
   Submodule of traits in cyfs-stack that will listen and forword the calling from Client
   The name rule:

   • Server: cyfs-${name}
   • Submodule of traits in cyfs-stack: ${name}
   • Submodule listening the Client: ${name}-api
   • Client: cyfs-${name}-lib
   • ${name} is some words expressing component functions;

3. Distinguish interface data, basic data and inner local data

   • The interface data will be public to developers, It should be implemented in cyfs-${name}-lib
   • The basic data will be used by cyfs-${name}-lib and cyfs-${name}, It should be implemented in cyfs-${name}-lib, and the cyfs-${name} will depend on cyfs-${name}-lib
   • The inner local data should be implemented as private in cyfs-${name} or cyfs-${name}-lib

4. Define the protocol between cyfs-${name}-lib and cyfs-${name} for each interface, Usually it's http protocol, you can set parameters in the headers or body;

5. Implement your core module cyfs-${name}, I has complete it, and I'll describe how to integrate it into the stack without the specific module logic(It's different each other).
   And I strongly recommend that you complete the core module without integrated stack, because It'll bring great complexity.

6. Implement the requestor in cyfs-${name}-lib, It's fixed structure most of the time, so we can imitate the old module. I'm following the trans module.
   Following the requestor entry, we will fill the other depended structs:

   • requestor: The entry and the logic of the protocol to server(cyfs-${name}). We need the HttpRequestorRef from the SharedCyfsStack, it's used to communicate with the server(cyfs-${name}),
   • output_request: structs to server(cyfs-${name}) following the protocol.
   • input_request: structs received by server(cyfs-${name}) following the protocol, the content is same as output_request, but you can make a different form(eg. add some fields about the network). I think it will be same as output_request most of the time.
   • request_codec: Encoder and Decoder for output_request or input_request.
   • GroupOutputProcessor: The trait calling the remote peer(OOD or devices of the targets).
   • Following the trans module, I found some useful component:
     • RequestorHelper: Codec for various common fields in http.
     • JsonCodecHelper: Codec for customize body as JSON in http.
     • HttpRequestorRef: It's used to communicate with the server(cyfs-${name}).

7. Implement the ${name} and ${name}-api in cyfs-stack. as the cyfs-${name}-lib, It's fixed structure most of the time, so we can imitate the old module. I'm following the trans module.

   • We can begin from implement the listener of the http, you can implement the trait tide::Endpoint<State>. This is the entry from the cyfs-stack, it will be called at the ObjectHttpListener in file http_listener of cyfs-stack.
     Http listener
   • Handler for http, decode the http request and process or forward it.
     Http handler
   • Wrap your core module to be GroupInputProcessorRef
     Wrap the service
     As a local processor, it will call your core module
     As router, maybe the request will be forward to another peer
   • ACL for permission, it's a processor on the forward chain. You can abort the request for BuckyErrorCode::PermissionDenied.
     ACL processor
   • The processor for forward the request, It tranform requests from the OutputProcessor to InputProcessor
     Transformer for OutputProcessor to InputProcessor

   Note: There a several processor, they are chained as a link from the caller to the endpoint processor, so we can abort the request in any processor, and we can add any filter processor as needed.