Checkpoint for gRPC implementation

README.md

@@ -8,8 +8,11 @@ Instead of deserializing binary protobuf data into Rust structs, roto scans a me
 construction — recording the byte offset of each field — then reads fields on demand directly from
 the original bytes. No heap allocation, no data copying, no full deserialization upfront.
 
-Writing works the same way: you provide a fixed buffer and a builder writes fields directly into it,
-returning a slice of the bytes written.
+It also provides a first-class integration with the `tonic` gRPC framework via the `roto-tonic` crate,
+enabling zero-allocation request/response processing.
+
+Writing works the same way: you provide a fixed buffer (or a `bytes::BufMut`) and a builder writes
+fields directly into it, returning a slice of the bytes written.
 
 ## Design
 
@@ -28,10 +31,15 @@ This will generate a file, src/hackers.rs.
 
 ## Generated code
 
-For each protobuf message roto generates two types:
+For each protobuf message roto generates three types:
 
 - **Reader struct** `MessageName<'a>` — borrows the original byte slice, zero-copy.
-- **Builder struct** `MessageNameBuilder<'b>` — writes into a caller-provided `&mut [u8]`.
+- **Builder struct** `MessageNameBuilder<'b>` — writes into a caller-provided `&mut [u8]` or `BufMut`.
+- **Owned struct** `OwnedMessageName` — owns the byte buffer and implements `RotoOwned`, providing a bridge to the `Reader`.
+
+For each protobuf service, roto generates:
+
+- **Service Trait** `ServiceName` — a `tonic`-compatible async trait for gRPC service implementations.
 
 Nested message types are placed in a `pub mod message_name { ... }` module (snake_case of the
 parent message name) within the same generated file.
@@ -314,12 +322,4 @@ The goal is to validate roto's implementation against the Proto3 specification.
 ### Unsupported Features
 
 - **Reserved Fields**: `reserved` statements are ignored.
-- **Services**: `service` and `rpc` definitions are ignored.
 - **Options**: Field and message options are ignored.
-
-### Tasks
-
-- [x] Analyze `roto/codegen` to determine which protobuf constructs are supported during code generation.
-- [x] Analyze `roto/runtime` to determine which wire types and protobuf types are supported during reading and writing.
-- [x] Compare findings with the Proto3 spec (https://protobuf.dev/reference/protobuf/proto3-spec/).
-- [x] Document supported and unsupported features in the README.