All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Matveev <dpx.infinity@gmail.com>
To: "wireguard@lists.zx2c4.com" <wireguard@lists.zx2c4.com>
Subject: Re: Rust implementation status
Date: Mon, 13 Mar 2017 03:09:43 +0400	[thread overview]
Message-ID: <1489360183.27524.3.camel@gmail.com> (raw)
In-Reply-To: <E63B612D-BFAA-48FE-A352-25B4C11B8E05@icloud.com>

Hi, Sascha,

I'm a Rust programmer, and I really like that there is now a Rust
implementation of the Wireguard daemon!

I have a few question and suggestions.

1. Instead of hand-rolling your own error management implementation,
consider using the error-chain[1] crate. It seems that many popular
crates now depend on it[2]. It would make the Wireguard crate more
interoperable and more readable for those who is already accustomed
with error-chain. On the first glance, your custom implementation
resembles error-chain very much.

2. Consider publishing the project on some hosting service like Github
or Gitlab or something else, which would allow easier community
participation. I would very much like to help with its development, but
I never participated in any mailing-list based projects and I
personally find it very inconvenient, and I think that the pull
requests mechanics is greatly superior. Also, almost all Rust ecosystem
lives on Github, so lots of Rust developers are quite accustomed to it,
and you will most certainly attract more contributors that way.

3. On a related note, consider publishing a link to this project in the
Rust community, in particular, in the Rust subreddit[3] and maybe on
The Rust Programming Language Forum[4]. I think that many people there
will be very interested in a project like this, because it is network-
related, it is pretty low level, and it will probably depend on the
current "hot" crates in the Rust community, like tokio.

4. I think it would be quite idiomatic to split the interface to WG
into a separate library crate, which the main binary would depend on.

5. I wonder, is it really necessary to perform daemonization manually?
As far as I understand the current situation in the daemon writing and
init systems, it is expected that daemons won't fork themselves and
will continue working in foreground when started, while service
management systems like systemd or launchd will take care of keeping
them alive, collecting logs, starting, restarting, etc. Daemonizing
also seems quite unidiomatic on Windows. I also personally think that
avoiding manual daemonization will make the code and architecture
simpler and more manageable.

6. Have you decided which cryptographic libraries you are going to use?
Or are you planning to implement the necessary primitives in this
project?

I'm really looking forward to the further development of this project,
and I'm willing to participate in it if you're looking for
contributors.

Best regards,
Vladimir

  [1]: https://crates.io/crates/error-chain
  [2]: https://crates.io/crates/error-chain/reverse_dependencies
  [3]: https://www.reddit.com/r/rust/
  [4]: https://users.rust-lang.org/

  reply	other threads:[~2017-03-12 23:06 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-05 11:42 Rust implementation status Sascha Grunert
2017-03-12 23:09 ` Vladimir Matveev [this message]
2017-03-13 16:58   ` Sascha Grunert
2017-03-14 10:11     ` Vladimir Matveev
2017-03-15 15:59       ` Jason A. Donenfeld
2017-03-15 16:51         ` Vladimir Matveev
2017-03-15 17:03           ` Jason A. Donenfeld
2017-03-13  7:04 ` sopium
     [not found]   ` <CAHmME9oFbpNBTszO_Q5m8EwiG0F0SH6BUd+1SFZGUDGH0wQ0gg@mail.gmail.com>
2017-03-13 14:39     ` Jason A. Donenfeld
2017-03-14 13:08       ` sopium
2017-03-14 16:29 ` sopium
2017-03-14 18:49   ` Sascha Grunert
2017-03-18 10:51     ` Sascha Grunert
2017-03-13 17:00 Sascha Grunert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1489360183.27524.3.camel@gmail.com \
    --to=dpx.infinity@gmail.com \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.