feat(builtins): impl srv.info, dist.get_blueprint #1468
Conversation
| @@ -187,6 +187,30 @@ impl ParticleAppServices { | |||
| Ok(service_id) | |||
| } | |||
|
|
|||
| pub fn get_service_info( | |||
| &self, | |||
| worker_id: PeerId, | |||
There was a problem hiding this comment.
Mb rename it to worker_peer_id?
There was a problem hiding this comment.
we call it worker_id everywhere, and there's no other id except peer id
There was a problem hiding this comment.
What's the difference between this worker_id and service.worker_id? I though service.worker_id is a service/spell id of a worker, no?
There was a problem hiding this comment.
There is no difference. service.worker_id indicates where is this service deployed
There was a problem hiding this comment.
it's the same thing. Services now can belong to worker_id, aka virtual peer.
service.worker_id is the PeerId of the worker aka virtual peer, same for worker_id
There was a problem hiding this comment.
Why do we start using the word "worker" (which isn't descriptive at all) and not "virtual peer" (which is self-explanatory) then?
There was a problem hiding this comment.
because worker comes from deals and is more workload and user-oriented. computation worker.
virtual peer is just some shenanigan inside rust-peer. it builds off the concept of peers. and it doesn't tell anything about computation or services. in other words, virtual peer is just one of the many pieces that make worker.
No description provided.