~radicle-link/dev

11 3

What Should Happen Next?

Details
Message ID
<CFTXEY192Z6B.3MMX9QBR4991N@haptop>
DKIM signature
pass
Download raw message
Recently, I worked on the diff & accept code. It was at that point
that I realised that I had no way of quickly messing around with the
CLI commands that required peers. I was able to setup an org node and
play with the projects replicated from there, but I was left with the
thought, "Oh ya, Application Architecture." The road to using link in
happiness and anger is mired in fleshing out the components mentioned
in that RFC.

So, I thought to myself, "What do _we_ (link team) need to start
working on `radicle-link` in our peer-to-peer world?" The story went
something like this:

One of the radicle-link maintainers will create their profile, person,
and the radicle-link project from the CLI. Each of the other
maintainers will also create profiles and persons, sharing the URNs
for their persons out-of-band. The initial maintainer will add these
URNs to the delegates set of the radicle-link project using the CLI's
update command. So far, all of this can easily be accomplished
today. The next step will, however, require us to have a running seed
linkd node. We should all be able to connect to this seed and the
initial maintainer's actions incur an *announcement* to the seed. The
other maintainers receive the project URN out-of-band, and *track* the
URN for *replication*. Once all of this is done, naturally we COB our
way to open software freedom b(^_^)

So I went back through the RFC 0682[0] and RFC 0696[1], to familiarise
myself with what needs to be done to achieve the above
vision. Natually, it's quite a bit (: I explored them by their headers
and jotted down some notes.

== PubSub

The PubSub component seems like a linchpin of interaction between
other components in link, ie. the peer-to-peer node, the git daemon,
the CLI.

It's currently undefined (modulo some assumed requirements in [0]) and
the conversation needs to be kicked off on what it looks like. I can
start an email thread after doing some of my own research, or if
anyone has a clear idea of what it should look like feel free to beat
me to it :)

== Peer-to-Peer Node

This was started with [1] and there's some code that exists, but
unfortunately, has plent of TODOs laying around the place. With xla
escorting life into this world, Alex and I have said that we would
like to pick up on this portion of the work.

Something noteworthy from [0] is that it specifies:

> Events emitted by the node cannot be subscribed to directly over the
> RPC API, but only indirectly over the pub-sub bus. The node shall
> itself listen for pub-sub messages related to publishable updates of
> the repository state (eg. after a git push).

This further puts the PubSub in the hotseat in the priority list.

== Announcements and Synchronisation

The currently proposed way of making announcements is storing seen
announcements and periodically checking if there are new ones to
make. These are then advertised over gossip. While synchronisation
worked in a similar shotgun-fashion, but was removed from the daemon
code. I am unsure what the applications are using to synchronise.

In [2], it's pointed that these were/are awful workarounds. The
synchronisation is proposed to be handled by grafting, which Kim has
been diligently carving out, overcoming plenty of roadblocks along the
way :)

But something I'm not seeing is when a peer *should* make
announcements. I believe that they can be made during interesting
events, such as `git push`, or CLI commands like `rad identities
project update`. I just wanted to check that this is correct?
Again, this requires the PubSub component for communication back to
the peer-to-peer node.

== Replication Requests

The initial phase of this is implementation of RFC 0699[3]. I have
drafted some of the code up but stopped when trying to make a decision
about what storage backend we should use[4]. This can be picked back
up after that decision is made.

The second phase would be a further RFC (or RFCs) to decide on a more
dynamic way of requesting resources from the network (akin to the
waiting room :)). For example, a provider cache has been mentioned,
and fleshing out what this looks like would help this dynamic
replication.

== git

This seems like one of the more straightforward components to flesh
out, but fleshing out would still be nice to understand the scope and
hurdles. We might also be aided here by the alt-clients team since
they have played around with something similar already.

I read that it's meant to be socket activated in [0]. This is similar
to the peer-to-peer node, so perhaps we can reuse logic for both of
these, feeding two birds with one scone. Another note is that it is to
publish new pushes to the PubSub component. Yes, there it is again!

== CLI

Finally, there's some missing work around the CLI that's mentioned in
[0] and [5]. The `request` and `daemon` commands are not
implemented. The former is pending [Replication Requests] from above
and will be useful for our "user story". The latter is less
important. There is also no CBOR I/O or IPC interface, but that is
required for the CLIaaS mentioned in [0]. Important in the long-term
but not immediately important.

== Conclusion

From my point of view it seems like our biggest priority is
understanding what we want for PubSub and to get an implementation
underway. The git daemon and peer-to-peer daemons can worked on in
parallel. However, both need a socket activation backend to function
so that could be improved on and reused from the existing
`node-lib`. The git daemon could use an RFC to delve into the finer
details, hopefully getting some support from the alt-clients team to
glean some learnings from their experiences. Announcements are
essentially serialised by the need for the PubSub component to be in
place. While synchornisation is a work-in-progress, perhaps
workarounds are needed but should be marked strictly as experimental
and should not be relied on. Finally, tracking for replication
purposes can realistically be done today and integrated into a CLI
subcommand, however, for the link team it requires a working seed to
relay gossip so that we can achieve "passive" replication.

[0]: https://github.com/radicle-dev/radicle-link/blob/master/docs/rfc/0682-application-architecture.adoc#rfc-application-architecture
[1]: https://github.com/radicle-dev/radicle-link/blob/master/docs/rfc/0696-p2p-node.adoc#rfc-peer-to-peer-node
[2]: https://lists.sr.ht/~radicle-link/dev/%3CrTbVAfR8mHmzNYdSHl4r2Hl9hh5EgCv_9SuHoSiMS4HhHJiWSB1v0noahMMhjTKUuvIO82sFrWZLVnXDjJhSAWMLC7-LpJFqjc3fQEnYje0%3D%40radicle.foundation%3E#%3C20211111093451.GB7438@schmidt.localdomain%3E
[3]: https://github.com/radicle-dev/radicle-link/blob/master/docs/rfc/0699-tracking-storage.adoc#rfc-tracking-storage
[4]: https://lists.sr.ht/~radicle-link/dev/%3CCFEF7YR7BZMZ.1O16MJ37ESB2F%40haptop%3E
[5]: https://github.com/radicle-dev/radicle-link/blob/master/docs/rfc/0698-cli-infrastructure.adoc#rfc-radicli
Details
Message ID
<CFUKI7JXU1CE.C0XCMRUK9Q3Q@haptop>
In-Reply-To
<CFTXEY192Z6B.3MMX9QBR4991N@haptop> (view parent)
DKIM signature
pass
Download raw message
On Fri Nov 19, 2021 at 5:18 PM GMT, Fintan Halpenny wrote:
> == Peer-to-Peer Node
>
> This was started with [1] and there's some code that exists, but
> unfortunately, has plent of TODOs laying around the place. With xla
> escorting life into this world, Alex and I have said that we would
> like to pick up on this portion of the work.

I wonder if we could you [0] for the socket code needed by the
peer-to-peer node, the git daemon (I think?), and the CLIaaS. The
benefit of it is that it seems to support both Unix and Windows systems.
That and we won't have to maintain our own socket code :)

[0]: https://docs.rs/interprocess/1.1.1/interprocess/index.html
Details
Message ID
<CFW8L7HW7QFF.2KV4UL8WM6AJ@haptop>
In-Reply-To
<CFTXEY192Z6B.3MMX9QBR4991N@haptop> (view parent)
DKIM signature
pass
Download raw message
On Fri Nov 19, 2021 at 5:18 PM GMT, Fintan Halpenny wrote:
> == PubSub
>
> The PubSub component seems like a linchpin of interaction between
> other components in link, ie. the peer-to-peer node, the git daemon,
> the CLI.
>
> It's currently undefined (modulo some assumed requirements in [0]) and
> the conversation needs to be kicked off on what it looks like. I can
> start an email thread after doing some of my own research, or if
> anyone has a clear idea of what it should look like feel free to beat
> me to it :)
>
> [..]
>
> [0]:
> https://github.com/radicle-dev/radicle-link/blob/master/docs/rfc/0682-application-architecture.adoc#rfc-application-architecture

In [0] there's two properties stated that I'm not sure I quite
understand.

> Subscription is explicit, ie. we don’t assume process activation upon
> matching events

Does this mean that subscribers are essentially running when wanting to
listen to events? As in, they can't be activated as a result of some
event being published. Or am I misunderstanding that?

> There is a way to apply buffering on a per-topic basis, in order to
> cater for subscriber restarts

Does this mean that there's a certain amount of messages kept in the
buffer for a subscriber to restart and start off from where it might
have restarted?
Details
Message ID
<CAH_DpYSP=ezOKcJwyTTHG6+YJ0450QTHqzn10sq_8d65rU67Sw@mail.gmail.com>
In-Reply-To
<CFTXEY192Z6B.3MMX9QBR4991N@haptop> (view parent)
DKIM signature
missing
Download raw message
On 19/11/21 05:18pm, Fintan Halpenny wrote:
> Recently, I worked on the diff & accept code. It was at that point
> that I realised that I had no way of quickly messing around with the
> CLI commands that required peers. I was able to setup an org node and
> play with the projects replicated from there, but I was left with the
> thought, "Oh ya, Application Architecture." The road to using link in
> happiness and anger is mired in fleshing out the components mentioned
> in that RFC.
>
> So, I thought to myself, "What do _we_ (link team) need to start
> working on `radicle-link` in our peer-to-peer world?"

I had a similar experience with thinking about the patches. I wanted to
start playing with patch cobs, but the setup I'm using involves running
multiple upstreams and then the upstream seed node and then various
other hacks. I spend most of my time fiddling with upstream rather than
actually working on the patch stuff.

> == Conclusion
>
> >From my point of view it seems like our biggest priority is
> understanding what we want for PubSub and to get an implementation
> underway. The git daemon and peer-to-peer daemons can worked on in
> parallel. However, both need a socket activation backend to function
> so that could be improved on and reused from the existing
> `node-lib`. The git daemon could use an RFC to delve into the finer
> details, hopefully getting some support from the alt-clients team to
> glean some learnings from their experiences. Announcements are
> essentially serialised by the need for the PubSub component to be in
> place. While synchornisation is a work-in-progress, perhaps
> workarounds are needed but should be marked strictly as experimental
> and should not be relied on. Finally, tracking for replication
> purposes can realistically be done today and integrated into a CLI
> subcommand, however, for the link team it requires a working seed to
> relay gossip so that we can achieve "passive" replication.

The following is all predicated on prioritising getting to dogfooding.
Whilst dogfooding I think we can tolerate a bunch of sharp edges, as
long as it let's us start actually using this stuff.

I agree that pubsub seems to be the major missing piece in terms of
specification here and I think we should get started on specifying that.
To me it looks like it should be some kind of log - but Kim has
mentioned the dangers of "yolokafka" and I've certainly been burned by
this too.

I'm not sure I agree that we need socket activation or a real pubsub
implementation to make progress on the node-lib and git daemon. We can
develop them as long running processes initially and manually start and
stop them. In this context we can hack pubsub as a socket to known
running processes. Provided we are careful not to assume anything other
than whatever we specify as the semantics of the pubsub this should not
be a problem in future once we have real implementations.

Last week I spent a bunch of time looking at the org-node codebase
because they are the only people maintaining a long running seed right
now and they _also_ need a pubsub. Specifically they need to dynamically
change the set of tracked URNs and they need to tell the seed when
something has changed in the monorepo to trigger announcements.
Currently they implement pubsub by just listening on a socket to a
custom git daemon which tickles the socket whenever anything interesting
happens. I think this is probably going to be quite common, people
building web interfaces or other kinds of bridges will need to talk to
ther seed node. I see the fact that this should fit well with the design
of the p2p node as a vindication of the modularity and extensibility
focused design in the application architecture RFC.

This suggests to me that we could get to dogfood by building the
`node-lib` crate to the point where it functions as a long running seed.
We hack together a pubsub by just listening on a socket. We build a tool
to _manually_ prod the socket from the command line when something new
has happened in the monorepo. Then I think the only thing missing is the
replication requests stuff. I can't think of a hack around that.

One nice outcome of this is that the `node-lib` would then be usable by
the alt-clients team as their seed node.

So yeah, I think we need to _specify_ the pubsub semantics and wire
format, but I don't think we need to implement it properly to get to the
dog bowl. Instead we should focus on building the p2p node out.
Details
Message ID
<20211122161404.GJ19039@schmidt.localdomain>
In-Reply-To
<CAH_DpYSP=ezOKcJwyTTHG6+YJ0450QTHqzn10sq_8d65rU67Sw@mail.gmail.com> (view parent)
DKIM signature
pass
Download raw message
> I agree that pubsub seems to be the major missing piece in terms of
> specification here and I think we should get started on specifying that.
> To me it looks like it should be some kind of log - but Kim has
> mentioned the dangers of "yolokafka" and I've certainly been burned by
> this too.

It is potentially the case that this all appears more complicated than it really
is: the difficulty is mainly to control when which process needs to be running,
and what to do if it doesn't.

This is why I initially thought of D-Bus, because there the _sender_ can request
some process to be activated. That's handy and dandy, but not too portable.

We only need to concern ourselves with the "linkd" process, and there are only
two cases to consider, so perhaps let's walk through them:

1. The peer-to-peer node is running, and has modified the storage state
   unattended.

   Others might be interested in these events, but we can not afford to do any
   buffering or retrying (or if we could, it's just too much of a hassle). I
   also don't think it's a good idea to multiplex events (which may occur at
   relatively high frequency) over the same channel as a command socket.
   Furthermore, I'm absolutely not okay with TCP sockets even if they bind to
   127.0.0.1. I am totally okay with publishing events on a UNIX socket, where
   we can know if there are any subscribers at all. It's a little more
   complicated to detect slow consumers, but we can just drop messages then.

   Consumers would have to deal with this not being reliable.

   Note the significance of socket activation for this use-case: if the node
   process is managed, there will _always_ be a socket file at a well-known
   location on disk. A subscriber can just open the socket, which also signals
   the intent that the process should be running (which the process management
   takes care of). If the process is not managed, the subscriber needs to deal
   with the situation that there might be no socket.

2. The peer-to-peer node may or may not be running, and some _other_ process
   has modified the storage.

   Legit ways this can happen are `git push`, or manipulating identities or cobs
   directly in the repo. Generally, such modifications are only interesting from
   the peer-to-peer node's view if they result in updates of the `rad/` refs
   hierarchy (either `id` or `signed_refs`) -- otherwise, they are not picked up
   by other nodes anyway.

   One question here is: do we expect that such a significant modification
   results in network propagation immediately? For simplicity, we can answer
   this with "yes" for now (`git push` is like, you know, networking, rite?).
   But then the second question is: what if that fails?

   There are obviously many reasons it can fail, including the node not running,
   not connected, cannot tell if someone else actually got the changes, etc. But
   the problem is that we already made the change, and we can not reliably roll
   it back (because there can be other changes on top made by unattended
   operations).

   So how do we recover from that? Should be employ a WAL which gets replayed by
   the node when it starts up?

   No I don't think so. The git protocol already performs negotation of the
   state, and the only thing we're really interested in is if someone else pulls
   what we've got. So the only thing we really need is a `rad sync` command
   which attempts to request pulls from peers the node knows are interested in
   our state. This is still asynchronous and unreliable, so subscribers from 1.
   should not expect to receive corresponding events (they will try anyway, but
   we've made it obscure enough to report issues har har).

   Socket activation has the same role as in 1.: the socket is "guaranteed" to
   be present, and it is "guaranteed" that someone will eventually listen on it.
   If the process is not managed, the sender will just need to print an error
   when it can't connect.
Details
Message ID
<CFX11ME35KF6.3R65IHXBE97SH@haptop>
In-Reply-To
<CAH_DpYSP=ezOKcJwyTTHG6+YJ0450QTHqzn10sq_8d65rU67Sw@mail.gmail.com> (view parent)
DKIM signature
pass
Download raw message
On Mon Nov 22, 2021 at 1:44 PM GMT, Alex Good wrote:
> > == Conclusion
> >
> > >From my point of view it seems like our biggest priority is
> > understanding what we want for PubSub and to get an implementation
> > underway. The git daemon and peer-to-peer daemons can worked on in
> > parallel. However, both need a socket activation backend to function
> > so that could be improved on and reused from the existing
> > `node-lib`. The git daemon could use an RFC to delve into the finer
> > details, hopefully getting some support from the alt-clients team to
> > glean some learnings from their experiences. Announcements are
> > essentially serialised by the need for the PubSub component to be in
> > place. While synchornisation is a work-in-progress, perhaps
> > workarounds are needed but should be marked strictly as experimental
> > and should not be relied on. Finally, tracking for replication
> > purposes can realistically be done today and integrated into a CLI
> > subcommand, however, for the link team it requires a working seed to
> > relay gossip so that we can achieve "passive" replication.
>
> The following is all predicated on prioritising getting to dogfooding.
> Whilst dogfooding I think we can tolerate a bunch of sharp edges, as
> long as it let's us start actually using this stuff.
>
> I agree that pubsub seems to be the major missing piece in terms of
> specification here and I think we should get started on specifying that.
> To me it looks like it should be some kind of log - but Kim has
> mentioned the dangers of "yolokafka" and I've certainly been burned by
> this too.
>
> I'm not sure I agree that we need socket activation or a real pubsub
> implementation to make progress on the node-lib and git daemon. We can
> develop them as long running processes initially and manually start and
> stop them. In this context we can hack pubsub as a socket to known
> running processes. Provided we are careful not to assume anything other
> than whatever we specify as the semantics of the pubsub this should not
> be a problem in future once we have real implementations.
>
> Last week I spent a bunch of time looking at the org-node codebase
> because they are the only people maintaining a long running seed right
> now and they _also_ need a pubsub. Specifically they need to dynamically
> change the set of tracked URNs and they need to tell the seed when
> something has changed in the monorepo to trigger announcements.
> Currently they implement pubsub by just listening on a socket to a
> custom git daemon which tickles the socket whenever anything interesting
> happens. I think this is probably going to be quite common, people
> building web interfaces or other kinds of bridges will need to talk to
> ther seed node. I see the fact that this should fit well with the design
> of the p2p node as a vindication of the modularity and extensibility
> focused design in the application architecture RFC.
>
> This suggests to me that we could get to dogfood by building the
> `node-lib` crate to the point where it functions as a long running seed.
> We hack together a pubsub by just listening on a socket. We build a tool
> to _manually_ prod the socket from the command line when something new
> has happened in the monorepo. Then I think the only thing missing is the
> replication requests stuff. I can't think of a hack around that.
>
> One nice outcome of this is that the `node-lib` would then be usable by
> the alt-clients team as their seed node.
>
> So yeah, I think we need to _specify_ the pubsub semantics and wire
> format, but I don't think we need to implement it properly to get to the
> dog bowl. Instead we should focus on building the p2p node out.

My worry here is that this approach seems like, "Get to the dog bowl, no
matter the cost!" I understand the want to get there quicker for
iteration, but I would ask do we *need* to get there quicker? Or at
least, can we strike a balance of providing useful functionality while
also carving out what we set out to implement?

For example, in [0], it specifies that:

> All daemon processes SHALL be started on-demand using the platform
> socket activation protocol. Unless otherwise noted, daemons SHALL
> terminate after a configured period of idle time (in the order of 10s
> of minutes).

So if we're developing for long-running seeds, I think we should also be
tackling spinning up short-lived clients because we'll be using those
for ourselves too. And we should be aiming to do this via socket
activation as much as possible (again this seems to aid in the
development of the git daemon).

Regarding pubsub, I think Kim's response to this thread might be the
place to continue that conversation.

[0]:
https://github.com/radicle-dev/radicle-link/blob/master/docs/rfc/0682-application-architecture.adoc#process-orchestration
Details
Message ID
<CFX1QYK3QQFN.2MKTO0Q8WCJTM@haptop>
In-Reply-To
<20211122161404.GJ19039@schmidt.localdomain> (view parent)
DKIM signature
pass
Download raw message
On Mon Nov 22, 2021 at 3:14 PM GMT, Kim Altintop wrote:
> > I agree that pubsub seems to be the major missing piece in terms of
> > specification here and I think we should get started on specifying that.
> > To me it looks like it should be some kind of log - but Kim has
> > mentioned the dangers of "yolokafka" and I've certainly been burned by
> > this too.
>
> It is potentially the case that this all appears more complicated than
> it really
> is: the difficulty is mainly to control when which process needs to be
> running,
> and what to do if it doesn't.
>
> This is why I initially thought of D-Bus, because there the _sender_ can
> request
> some process to be activated. That's handy and dandy, but not too
> portable.
>
> We only need to concern ourselves with the "linkd" process, and there
> are only
> two cases to consider, so perhaps let's walk through them:
>
> 1. The peer-to-peer node is running, and has modified the storage state
> unattended.
>
> Others might be interested in these events, but we can not afford to do
> any
> buffering or retrying (or if we could, it's just too much of a hassle).
> I
> also don't think it's a good idea to multiplex events (which may occur
> at
> relatively high frequency) over the same channel as a command socket.

I may need more explaining for this. What would multiplexing over a
socket look like? Why would it not be a good idea? And what would you
envision as the alternative?

> Furthermore, I'm absolutely not okay with TCP sockets even if they bind
> to
> 127.0.0.1. I am totally okay with publishing events on a UNIX socket,
> where
> we can know if there are any subscribers at all. It's a little more
> complicated to detect slow consumers, but we can just drop messages
> then.
>
> Consumers would have to deal with this not being reliable.
>
> Note the significance of socket activation for this use-case: if the
> node
> process is managed, there will _always_ be a socket file at a well-known
> location on disk. A subscriber can just open the socket, which also
> signals
> the intent that the process should be running (which the process
> management
> takes care of). If the process is not managed, the subscriber needs to
> deal
> with the situation that there might be no socket.

This does seem v nice!

So, just to see if I'm understanding correctly, you're saying that
simple UDP socket or set of sockets could act as the PubSub for us?

> 2. The peer-to-peer node may or may not be running, and some _other_
> process
> has modified the storage.
>
> Legit ways this can happen are `git push`, or manipulating identities or
> cobs
> directly in the repo. Generally, such modifications are only interesting
> from
> the peer-to-peer node's view if they result in updates of the `rad/`
> refs
> hierarchy (either `id` or `signed_refs`) -- otherwise, they are not
> picked up
> by other nodes anyway.

So I suppose this means that there also needs to be a well-known socket
or set of sockets the peer will listen to? And applications can publish to
these sockets.

> One question here is: do we expect that such a significant modification
> results in network propagation immediately? For simplicity, we can
> answer
> this with "yes" for now (`git push` is like, you know, networking,
> rite?).
> But then the second question is: what if that fails?
>
> There are obviously many reasons it can fail, including the node not
> running,
> not connected, cannot tell if someone else actually got the changes,
> etc. But
> the problem is that we already made the change, and we can not reliably
> roll
> it back (because there can be other changes on top made by unattended
> operations).
>
> So how do we recover from that? Should be employ a WAL which gets
> replayed by
> the node when it starts up?
>
> No I don't think so. The git protocol already performs negotation of the
> state, and the only thing we're really interested in is if someone else
> pulls
> what we've got. So the only thing we really need is a `rad sync` command
> which attempts to request pulls from peers the node knows are interested
> in
> our state. This is still asynchronous and unreliable, so subscribers
> from 1.
> should not expect to receive corresponding events (they will try anyway,
> but
> we've made it obscure enough to report issues har har).
>
> Socket activation has the same role as in 1.: the socket is "guaranteed"
> to
> be present, and it is "guaranteed" that someone will eventually listen
> on it.
> If the process is not managed, the sender will just need to print an
> error
> when it can't connect.

The "interested in our state" has me stumbling a bit. So we track peers
and we can attempt to pull from them, but we can't be sure those peers
are reciprocally tracking, right?

Also, if those peers are offline, what do we do? We would also want to
pull from seed nodes, but we may not want to track them? Or maybe we do
but with `data = false` in our soon-to-be tracking scheme? :)
Details
Message ID
<CAH_DpYSLriKHkDbqFx6JB=oj2Pw2mTpeQEYg7AiyxYC-7zAsfw@mail.gmail.com>
In-Reply-To
<20211122161404.GJ19039@schmidt.localdomain> (view parent)
DKIM signature
missing
Download raw message
We (Fintan, Kim, and I) discussed this on a call this morning. Here are my notes

Regarding pubsub. From the two scenarios above, the one we have a usecase for
right now is the lattter, where some process (e.g. git push) has made
modifications to the storage which the peer to peer node needs to know about.
For this usecase a well known socket should do the trick. The p2p node sitting
behind this socket can be socket activated, but that's transparent to the
producer which must throw an error if the socket file is not where it is
expecting it to be. This socket will be a separate socket to the command socket
specified in RFC-696. The payload of the events pushed to this socket will be
some sort of CBOR encoding of the payload of a post-receive hook (i.e. the refs
being updated). I'll get some experimental code up and running which implements
this and then submit an RFC.

The socket activation plumbing is already present for Linux, and we are all
currently running Linux so for the purposes of dogfooding there is no need to
do any kind of hacking around with long running processes. We will need to
implement the OSX version at some point.

We decided that for now the offline tracking storage implementation will use
libgit. With this decision made Fintan will be working on finishing the offline
tracking implementation.

Did I miss anything?
Details
Message ID
<CFX4X8OHJLAA.3E6ZSC0MCWD1N@haptop>
In-Reply-To
<CAH_DpYSLriKHkDbqFx6JB=oj2Pw2mTpeQEYg7AiyxYC-7zAsfw@mail.gmail.com> (view parent)
DKIM signature
pass
Download raw message
On Tue Nov 23, 2021 at 11:34 AM GMT, Alex Good wrote:
> We (Fintan, Kim, and I) discussed this on a call this morning. Here are
> my notes
>
> Regarding pubsub. From the two scenarios above, the one we have a
> usecase for
> right now is the lattter, where some process (e.g. git push) has made
> modifications to the storage which the peer to peer node needs to know
> about.
> For this usecase a well known socket should do the trick. The p2p node
> sitting
> behind this socket can be socket activated, but that's transparent to
> the
> producer which must throw an error if the socket file is not where it is
> expecting it to be. This socket will be a separate socket to the command
> socket
> specified in RFC-696. The payload of the events pushed to this socket
> will be
> some sort of CBOR encoding of the payload of a post-receive hook (i.e.
> the refs
> being updated). I'll get some experimental code up and running which
> implements
> this and then submit an RFC.
>
> The socket activation plumbing is already present for Linux, and we are
> all
> currently running Linux so for the purposes of dogfooding there is no
> need to
> do any kind of hacking around with long running processes. We will need
> to
> implement the OSX version at some point.
>
> We decided that for now the offline tracking storage implementation will
> use
> libgit. With this decision made Fintan will be working on finishing the
> offline
> tracking implementation.
>
> Did I miss anything?

I'll add the other two points that came up, but perhaps they also
deserve they're own email thread:

* We'll need more `git gc` to be happening -- the off-the-cuff
  suggestion was a systemd file for scheduling it
* The RequestPull RPC is up-for-grabs -- this is necessary for the `rad
  sync` command discussed, I believe.
Details
Message ID
<CAH_DpYQVngN8i8u_QYrSxg6xzh5pLnBHoBFxw3=7BcMNHSNOLA@mail.gmail.com>
In-Reply-To
<CFX4X8OHJLAA.3E6ZSC0MCWD1N@haptop> (view parent)
DKIM signature
missing
Download raw message
On 23/11/21 11:49am, Fintan Halpenny wrote:
> On Tue Nov 23, 2021 at 11:34 AM GMT, Alex Good wrote:
> > Did I miss anything?
>
> I'll add the other two points that came up, but perhaps they also
> deserve they're own email thread:
>
> * We'll need more `git gc` to be happening -- the off-the-cuff
>   suggestion was a systemd file for scheduling it
> * The RequestPull RPC is up-for-grabs -- this is necessary for the `rad
>   sync` command discussed, I believe.

Ah good points, thanks. I think you're right they probably need their
own thread. Especially the request-pull stuff.

A pubsub related question I have. Is pubsub the right term at this
point? It's really just a way for people to send events to the peer to
peer node, there's no real concept of subscribing. Should we just call
it pub? Or notify? Or even post-receive given that as Kim said, it's
basically a post-receive hook?
Details
Message ID
<CFX820WRE4GG.3BO6BO3OO03I3@haptop>
In-Reply-To
<CAH_DpYQVngN8i8u_QYrSxg6xzh5pLnBHoBFxw3=7BcMNHSNOLA@mail.gmail.com> (view parent)
DKIM signature
pass
Download raw message
On Tue Nov 23, 2021 at 2:14 PM GMT, Alex Good wrote:
> On 23/11/21 11:49am, Fintan Halpenny wrote:
> > On Tue Nov 23, 2021 at 11:34 AM GMT, Alex Good wrote:
> > > Did I miss anything?
> >
> > I'll add the other two points that came up, but perhaps they also
> > deserve they're own email thread:
> >
> > * We'll need more `git gc` to be happening -- the off-the-cuff
> >   suggestion was a systemd file for scheduling it
> > * The RequestPull RPC is up-for-grabs -- this is necessary for the `rad
> >   sync` command discussed, I believe.
>
> Ah good points, thanks. I think you're right they probably need their
> own thread. Especially the request-pull stuff.
>
> A pubsub related question I have. Is pubsub the right term at this
> point? It's really just a way for people to send events to the peer to
> peer node, there's no real concept of subscribing. Should we just call
> it pub? Or notify? Or even post-receive given that as Kim said, it's
> basically a post-receive hook?

What about event-socket? This doesn't preclude the future potential of
it going the other way, but also doesn't imply a broker :)
Details
Message ID
<20211125074114.GC3029@schmidt.localdomain>
In-Reply-To
<CFX820WRE4GG.3BO6BO3OO03I3@haptop> (view parent)
DKIM signature
pass
Download raw message
On Tue, 23 Nov 2021 14:17:08 +0000 "Fintan Halpenny" <fintan.halpenny@gmail.com> wrote:
> On Tue Nov 23, 2021 at 2:14 PM GMT, Alex Good wrote:
> > A pubsub related question I have. Is pubsub the right term at this
> > point? It's really just a way for people to send events to the peer to
> > peer node, there's no real concept of subscribing. Should we just call
> > it pub? Or notify? Or even post-receive given that as Kim said, it's
> > basically a post-receive hook?
>
> What about event-socket? This doesn't preclude the future potential of
> it going the other way, but also doesn't imply a broker :)

- lolek (pub) & bolek (sub)
- /var/run/pub.sock & /var/run/sub.sock
- /var/run/not.sock & /var/run/hot.sock
Reply to thread Export thread (mbox)