refactor: RSP -> rRPC

README.md

@@ -1,2 +1,2 @@
-## RSP Documentation
-This repository contains documentation for the RSP framework written with Writerside. Link for documentation – https://rsp.timemates.org
+## rRPC Documentation
+This repository contains documentation for the rRPC framework written with Writerside. Link for documentation – https://rsp.timemates.org

Writerside/in.tree

@@ -3,7 +3,7 @@
         SYSTEM "https://resources.jetbrains.com/writerside/1.0/product-profile.dtd">
 
 <instance-profile id="in"
-                 name="RSP Documentation"
+                 name="rRPC Documentation"
                  start-page="Section-Starting-Page.topic">
 
     <toc-element topic="Section-Starting-Page.topic"/>

Writerside/topics/Compatibility-with-ProtoBuf.md

@@ -43,6 +43,6 @@ Our implementation of ProtoBuf serialization supports a subset of ProtoBuf featu
 7. **Generated Protos**:
     - Protos generated from `.proto` files are supported similarly to user-defined protos.
 
-For features not supported or additional requirements, please [open an issue](https://github.com/timemates/rsp/issues/new/choose) to discuss potential support or contributions. This will help us understand and potentially address your use cases.
+For features not supported or additional requirements, please [open an issue](https://github.com/timemates/rrpc/issues/new/choose) to discuss potential support or contributions. This will help us understand and potentially address your use cases.
 
 You may also want to learn more about options and how they're handled [here](ProtoBuf-Options.md).

Writerside/topics/Getting-started.md

@@ -1,9 +1,9 @@
 # Getting started
 
-So you decided to go with RSP, let's make it quick. What do you need?
+So you decided to go with rRPC, let's make it quick. What do you need?
 
 <warning>
-RSP is still under development, backward compatibility for communication model is not guaranteed until 1.0. For now,
+rRPC is still under development, backward compatibility for communication model is not guaranteed until 1.0. For now,
 existing API is more likely to be as-is, but we need more feedback.
 </warning>
 
@@ -13,20 +13,20 @@ First of all, you need a gradle plugin and the following dependencies:
 
 ```Kotlin
 plugins {
-   id("org.timemates.rsp") version ("%lib-version%")
+   id("org.timemates.rrpc") version ("%lib-version%")
 }
 
 // ...
 
 dependencies {
     // for server (jvm, js, native)
-    commonMainImplementation("org.timemates.rsp:server-core:$version")
+    commonMainImplementation("org.timemates.rrpc:server-core:$version")
 
     // for client (jvm, js, native)
-    commonMainImplementation("org.timemates.rsp:client-core:$version")
+    commonMainImplementation("org.timemates.rrpc:client-core:$version")
 
     // for server & client (jvm, js, native)
-    commonMainImplementation("org.timemates.rsp:common-core:$version")
+    commonMainImplementation("org.timemates.rrpc:common-core:$version")
 }
 ```
 
@@ -35,50 +35,42 @@ for [`rsocket-kotlin`](https://github.com/rsocket/rsocket-kotlin?tab=readme-ov-f
 
 ## Initialization
 
-RSP generates code depending on the schema you specify in `.proto` files,
+rRPC generates code depending on the schema you specify in `.proto` files,
 similar to gRPC. You can learn more about protobuf [here](https://protobuf.dev/).
 
 ### Gradle Plugin
 
-Let's start with configuring RSP gradle plugin:
+Let's start with configuring rRPC gradle plugin:
 
 ```Kotlin
-rsp {
+rrpc {
    // you might need to specify your main 
    // source set (if its name is not commonMain / main)
    targetSourceSet = "commonMain"
 
-   profile {
-      // enables code-generation for client
-      client = true
-
-      // enables code-generation for client
-      server = true
-   }
-
-   paths {
-      // folder with .proto schema files
-      protoSources = "src/commonMain/proto"
-
-      // folder where generated code will be put
-      generationOutput = "generated/rsp/src/commonMain"
-   }
+   // folder with .proto schema files (it may have multiple sources)
+   protoSources.add("src/commonMain/proto")
 
+   // global options
    options {
-      // indicates what builder types should be generated
-      // CLASSIC – means plain java builder, mainly for compatibility
-      // with Java
-      builderTypes = setOf(
-         MessageBuilderType.CLASSIC, 
-         MessageBuilderType.DSL,
-      )
+    permitPackageCycles = true
+   }
+
+   configurations {
+    kotlin {
+        // kotlin-specific options
+        options {
+            generateServer = true
+            generateClient = true
 
-      // if java is specified, it'll generate bridge for java
-      // for now, it's not supported, but will be soon.
-      targetLanguages = setOf(
-         TargetLanguage.JAVA, 
-         TargetLanguage.KOTLIN,
-      )
+            // folder where generated code will be put
+            generationOutput = "generated/rrpc/src/commonMain"
+        }
+    }
+
+    // or other languages (configurations)
+    typescript {/* ... */}
+    getByName("php") {/* ... */}
    }
 }
 ```
@@ -102,7 +94,7 @@ service BarService {
 After you finished with your ProtoBuf definitions, you can use the following:
 
 ```Bash
-./gradlew :rsp:generateCode
+./gradlew :rrpc:generateCode
 ```
 
 ### Server
@@ -127,7 +119,7 @@ And then you can use it whether with WebSockets or Sockets (via Ktor):
         <code-block lang="kotlin">
     fun Application.configureServer() {
         routing {
-            rspEndpoint("/rsp") { // this: RSPModuleBuilder
+            rrpcEndpoint("/rrpc") { // this: rRPCModuleBuilder
                 service(BarServiceImpl())
             }
         }
@@ -139,7 +131,7 @@ And then you can use it whether with WebSockets or Sockets (via Ktor):
         <code-block lang="kotlin">
     val server: TcpServer = server.bind(transport) {
         RSocketRequestHandler {
-            RSPModuleHandler(module).setup(this)
+            rRPCModuleHandler(module).setup(this)
         }
     }
     server.handlerJob.join() //wait for server to finish
@@ -150,7 +142,7 @@ And then you can use it whether with WebSockets or Sockets (via Ktor):
 ### Client
 For client, you simply initialize the class with the name of service + 'Client':
 ```Kotlin
-val configuration = RSPClientConfig {
+val configuration = rRPCClientConfig {
     // assume we have a rsocket client instance
     // for obtaining a right one, please refer to the
     // rsocket-kotlin documentation.
@@ -165,6 +157,6 @@ All other things, like ability to reconnect automatically, you can find
 at [the official documentation](https://github.com/rsocket/rsocket-kotlin/blob/master/README.md).
 
 <seealso>
-            <a href="" type="start" summary="Install and start quickly with RSP">Getting started</a>
-            <a href="" type="idea" summary="The idea and motivation behind RSP development">Why RSP?</a>
+            <a href="" type="start" summary="Install and start quickly with rRPC">Getting started</a>
+            <a href="" type="idea" summary="The idea and motivation behind rRPC development">Why rRPC?</a>
 </seealso>

Writerside/topics/Implementation.md

@@ -1,5 +1,5 @@
 # Implementation Details
-If you're interested, how RSP works internally, but don't want to browse code, this section is for you.
+If you're interested, how rRPC works internally, but don't want to browse code, this section is for you.
 
 ## Metadata
 As you already know, code is generated and then serialized using ProtoBuf. In RSocket requests, there's two parts that
@@ -40,7 +40,7 @@ For now, we support only Request-Response, Request-Stream and Request-Channel:
 | `rpc(stream T) return (stream R)` | Request-Channel  |
 
 Client-only streaming is not supported by transport (RSocket), so we don't support it either. We may support other
-request types by annotation type called `Ack`, here's [an issue](https://github.com/timemates/rsp/issues/9) to discuss.
+request types by annotation type called `Ack`, here's [an issue](https://github.com/timemates/rrpc/issues/9) to discuss.
 
 
 ___________________________________

Writerside/topics/Instances.md

@@ -39,7 +39,7 @@ To provide your instance, just simply add it into your client / server configura
 <tabs>
     <tab title="Server">
         <code-block lang="kotlin">
-    val module = RSPModule { // this: RSPModuleBuilder
+    val module = rRPCModule { // this: rRPCModuleBuilder
       // services and other ...
       instances {
         register(MyInstance())
@@ -49,7 +49,7 @@ To provide your instance, just simply add it into your client / server configura
     </tab>
     <tab title="Client">
         <code-block lang="kotlin">
-    val configuration = RSPClientConfig {
+    val configuration = rRPCClientConfig {
       instances {
         register(MyInstance())
       }

Writerside/topics/Overview.md

@@ -1,9 +1,9 @@
 # Overview
 
-## What is RSP?
+## What is rRPC?
 
-RSP abbreviation stands for RSocket + ProtoBuf. This framework is designed to expose APIs as RPC (Remote Procedure Call)
-Services, enabling the creation of gRPC-like services directly from `.proto` files through code generation. RSP provides
+rRPC abbreviation stands for RSocket + ProtoBuf. This framework is designed to expose APIs as RPC (Remote Procedure Call)
+Services, enabling the creation of gRPC-like services directly from `.proto` files through code generation. rRPC provides
 essential core components for both server and client-side development, making it easier to build scalable and efficient
 RPC services.
 
@@ -17,21 +17,21 @@ although easier than managing entirely separate codebases, still presents challe
 Additionally, gRPC has several limitations, especially in web environments where it lacks support for bidirectional
 streaming. This limitation complicates the development process when full-duplex communication is needed.
 
-RSP, on the other hand, is designed with simplicity in mind. Unlike gRPC, it does not require inventing new
+rRPC, on the other hand, is designed with simplicity in mind. Unlike gRPC, it does not require inventing new
 communication mechanisms or dealing with complex request schemas. It reuses existing communication model (RSocket), what
 makes it easier in adopting and supporting.Developers can even write clients using plain RSocket and Protobuf
 serialization libraries, making the framework more accessible and easier to implement.
 
-## Why Choose RSP?
+## Why Choose rRPC?
 
-The primary goal of RSP is to support a wide range of platforms and languages. Currently, the framework supports
+The primary goal of rRPC is to support a wide range of platforms and languages. Currently, the framework supports
 Kotlin (at the moment of prototyping, for convenience), with plans to extend support to Java (via a bridge), JavaScript,
-and Python in the near future. The RSP team is actively seeking feedback before the 1.0.0 release to refine the
+and Python in the near future. The rRPC team is actively seeking feedback before the 1.0.0 release to refine the
 framework's mental model and deliver a stable, user-friendly solution.
 
 ## Why Protobuf?
 
-RSP is tightly integrated with Protobuf for serialization. We believe it's the most efficient in terms of compactness
+rRPC is tightly integrated with Protobuf for serialization. We believe it's the most efficient in terms of compactness
 and versioning for now. In addition, it's one of the most popular formats. While supporting other serialization
 mechanisms could be
 beneficial, the team believes that sticking with Protobuf ensures better compatibility and understanding across

Writerside/topics/ProtoBuf-Options.md

@@ -1,6 +1,6 @@
 # ProtoBuf Options Support
 
-The RSP code-generation supports ProtoBuf options on service and method levels.
+The rRPC code-generation supports ProtoBuf options on service and method levels.
 
 <note>
 For now, option's retention is not supported. The same applies to the file-level options or

Writerside/topics/Request-Response-Interceptors.md

@@ -1,6 +1,6 @@
 # Request/Response Interceptors
 
-In the RSP framework, interceptors are a powerful mechanism that allows you to modify or augment the behavior of request
+In the rRPC framework, interceptors are a powerful mechanism that allows you to modify or augment the behavior of request
 processing in a modular and reusable manner. Interceptors can be applied both to requests (input) and responses (output).
 They operate on the `InterceptorContext`, which carries data, metadata, options, and instances related to the
 request or response.
@@ -95,7 +95,7 @@ public class SimpleLoggingResponseInterceptor : ResponseInterceptor {
 ```
 
 ## Registering interceptors
-To register your interceptor, just add it to your RSPClientConfig / RSPModule:
+To register your interceptor, just add it to your rRPCClientConfig / rRPCModule:
 <warning>
   The order of interceptors is important – it's applied strictly by how they're added. If you have some kind of
   exception handler or logging mechanism, ensure that you have it as a last one.
@@ -104,7 +104,7 @@ To register your interceptor, just add it to your RSPClientConfig / RSPModule:
 <tabs>
     <tab title="Server">
         <code-block lang="kotlin">
-    val module = RSPModule { // this: RSPModuleBuilder
+    val module = rRPCModule { // this: rRPCModuleBuilder
       // services and other ...
       requestInterceptor(MyRequestInterceptor())
       responseInterceptor(MyRequestInterceptor())
@@ -113,7 +113,7 @@ To register your interceptor, just add it to your RSPClientConfig / RSPModule:
     </tab>
     <tab title="Client">
         <code-block lang="kotlin">
-    val configuration = RSPClientConfig {
+    val configuration = rRPCClientConfig {
       requestInterceptor(MyRequestInterceptor())
       responseInterceptor(MyRequestInterceptor())
     }

Writerside/topics/Section-Starting-Page.topic

@@ -3,7 +3,7 @@
         SYSTEM "https://resources.jetbrains.com/writerside/1.0/xhtml-entities.dtd">
 <topic xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="https://resources.jetbrains.com/writerside/1.0/topic.v2.xsd"
-       title="RSP" id="Section-Starting-Page">
+       title="rRPC" id="Section-Starting-Page">
 
 <!--    A section combines multiple topics dedicated to a specific subject.
             Add a starting page to provide an overview of the topics in the section.
@@ -16,26 +16,26 @@
             For other groups, try to keep the number between 2 and 6, but you can add more if necessary.-->
 
     <section-starting-page>
-        <title>RSP Documentation</title>
+        <title>rRPC Documentation</title>
         <description>
-            These topics will help you get started with RSP.
+            These topics will help you get started with rRPC.
         </description>
 
         <!--    Add up to 2 topics that you want to promote. Use the "type" attribute to select an icon.    -->
         <spotlight>
-            <a href="Overview.md" type="idea" summary="The idea and motivation behind RSP development">Overview</a>
-            <a href="Getting-started.md" type="start" summary="Install and start quickly with RSP">Getting started</a>
+            <a href="Overview.md" type="idea" summary="The idea and motivation behind rRPC development">Overview</a>
+            <a href="Getting-started.md" type="start" summary="Install and start quickly with rRPC">Getting started</a>
         </spotlight>
 
         <primary>
             <title>FAQ</title>
             <a href="Compatibility-with-ProtoBuf.md" summary="Check what features of ProtoBuf is supported and which is not">Compatibility with Protobuf</a>
-            <a href="Plans.md" summary="Our near-future plans for RSP">Plans</a>
+            <a href="Plans.md" summary="Our near-future plans for rRPC">Plans</a>
         </primary>
 
         <secondary>
             <title>Explore advanced stuff</title>
-            <a href="Implementation.md" summary="Learn more about how RSP is built internally">Implementation Details</a>
+            <a href="Implementation.md" summary="Learn more about how rRPC is built internally">Implementation Details</a>
         </secondary>
 
 <!--        &lt;!&ndash;    Optionally add additional cards and links to topics that are not in this section but may be relevant.    &ndash;&gt;-->