Replies: 3 comments 4 replies
-
|
I don't have the full picture yet, so I'm going to leave notes here before I jump to conclusions/PRs. Generic thoughts:
Side note: I feel that we should strive to use ractor internally but provide interfaces (crates, structs, etc) that don't depend on them so the user can choose to use a different framework. I'm not sure how feasible that is, but it's a good stretch goal. Back to the Host trait: If the topic is the Host trait defined in
Regarding the open questions:
|
Beta Was this translation helpful? Give feedback.
-
Agreed, it's a bit generic but it's short which is useful since it's present in pretty much every type bound ever in the codebase. expose it under a more explicit name from the
Yeah host is the most overloaded term here. Right now it denotes three things:
This is exactly the point of exposing a channel-based interface, which hides the whole actor framework behind regular Tokio channels. Users not wanting to implement a full blown actor would instead be able to depend on the
In the context of this proposal, the host is related the Malachite <-> application interface and not to the Starknet sequencer interface. The latter is indeed defined by Starknet and not under consideration in this proposal.
That's a very good definition!
That's a good observation. I feel like the client-server paradigm applies here but in reverse, where consensus is the client and the application is the server. That said, I too am not particularly fond of this nomenclature, and I like your "connector" idea better!
Glad we agree on that :)
No it would not use the
Just leaving a note here that will need to freeze the codebase for a few days so that I can proceed with the renaming without creating humongous merge conflicts.
Alternatively, we could introduce a
Agreed.
Much like with the channel-based interface, it should be possible to expose a trait-based interface, where users implement a single trait, with a method corresponding to each message to be handled. This would also hide all the actor-based internals, much like with the channel based interface. The tradeoff between channel-based and trait-based, is that the former gives you more flexibility for processing messages, by allowing the user to write their own event loop and deal with messages however they like (potentially handling them concurrently or queuing them somewhere), whereas with a trait-based implementation, you typically relinquish that flexibility. I think this type of interface is not strictly needed and can be done at a later stage, as you suggest. |
Beta Was this translation helpful? Give feedback.
-
|
One more thing we could do to streamline this process further is to provide a default implementation of the Here is how it might work: Because default type members are still unstable, we cannot do the obvious: use core::marker::PhantomData;
struct SignedMessage<Msg>(PhantomData<Msg>);
enum DefaultVote {
Prevote
}
struct DefaultProposal {}
trait Context {
type Vote = DefaultVote;
type Proposal = DefaultVote;
type Value;
fn new_prevote(&self) -> Self::Vote {
DefaultVote::Prevote
}
fn sign_vote(&self, vote: Self::Vote) -> SignedMessage<Self::Vote>;
// etc.
}Instead we might be able to do something like this, at the expense of a bunch of boilerplate: use core::marker::PhantomData;
struct SignedMessage<Msg>(PhantomData<Msg>);
enum DefaultVote {
Prevote
}
struct DefaultProposal {}
trait Context {
type Vote;
type Proposal;
type Value;
fn new_prevote(&self) -> Self::Vote;
fn sign_vote(&self, vote: Self::Vote) -> SignedMessage<Self::Vote>;
// etc.
}
trait DefaultContext {
type Value;
fn sign_vote(&self, vote: DefaultVote) -> SignedMessage<DefaultVote>;
// etc.
}
impl<T> Context for T where T: DefaultContext {
type Vote = DefaultVote;
type Proposal = DefaultProposal;
type Value = T::Value;
fn new_prevote(&self) -> DefaultVote {
DefaultVote::Prevote
}
fn sign_vote(&self, vote: DefaultVote) -> SignedMessage<DefaultVote> {
<T as DefaultContext>::sign_vote(self, vote)
}
}Applications would then only need to implement the One open question is whether or not to also provide a default Protobuf-based implementation of |
Beta Was this translation helpful? Give feedback.
-
|
Whoah, that's some excellent stuff with type message defaults. Since it mostly touches the I've created a list of proposed steps that provides more details and tries to show the dependencies of each task. You can see it here. (I can move it to GitHub, if needed, but it was cleaner to work in a doc.) I've integrated all that we discussed so far. Legend:
In the doc, tasks after each other usually depend on each other. (Except if they are highlighted green.) Some new proposals coming from the doc:
Edit: the tasks in the doc can be easily correlated to one task = one PR. |
Beta Was this translation helpful? Give feedback.
-
|
Hi guys, I was just going through all the discussion. I don't have much too add on top of what that has been discussed. Just a few comments:
I agree, we should avoid renaming things using client or server names. Using an actor model it is more related to messaging paradigms if that's what we want. The question should be, if we try to force this into a client/server paradigm will it add constraints on future uses cases that could open up if we stick with the actor model paradigm ? If so, we should consider this fact on renaming things and structuring. I couldn't access Greg's doc, but what I could help in the future is to go over the refactoring and try to implement an app and provide feedback if there are still pain points or not so clear or brittle design patterns. |
Beta Was this translation helpful? Give feedback.
-
Yeah that would be really helpful, thanks :) |
Beta Was this translation helpful? Give feedback.
-
|
I gave you access when you sent the request e-mail, please check again. Edit: the disadvantages of using Google Docs... :( |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
This proposal outlines a strategy to streamline the process of defining and running applications on top of Malachite.
Background
Currently, implementing a Malachite application requires multiple manual steps and detailed knowledge of the framework's internals.
This creates unnecessary complexity and potential barriers to adoption.
Current implementation
To develop an application on Malachite, the following steps are currently required:
malachite_common::Contextand associated traitsmalachite_actors::util::codec::NetworkCodecHostactor that can receivemalachite_actors::host::HostMsg<_>messagesmalachite_node::NodeProposed solution
The solution introduces three distinct integration patterns (actor, channel, and gRPC) through four new crates:
Common functionality (
malachite-app)malachite-appcrate providing core functionality:malachite-commonundercommonmoduleNetworkCodectraitmalachite_node::Nodetrait toApplicationand move it to themalachite-appcrateActor-based apps (
malachite-app-actor)malachite-app-actorcratemalachite_actorscrate underactorsmodulerunfunction inmalachite-app-actorwhich:ContextandNetworkCodecChannel-based apps (
malachite-app-channel)malachite-app-channelcrateHostactor which forwards messages through channel(s)runfunction which returns the channel(s) for the app to make use ofgRPC-based apps (
malachite-app-grpc)malachite-app-grpccrateHostactor which performs gRPC calls to a serverrunfunction which takes the gRPC server address and starts the hostBenefits
Open Questions
Hostactor be renamed toApplication?Applicationtrait as well.Applicationtrait stay named Node so that we can useApplicationfor what is now the host?NetworkCodectrait be moved tomalachite-common?malachite-actorscrateContextandApplicationtraits on the same struct? Or is it more flexible to define two structures, one for the context and one for the app?Related concerns
malachite-consensus, we should ensure that the crate re-exports everything needed, without users having to pull multiple crates.Next Steps
Beta Was this translation helpful? Give feedback.
All reactions