From: Vladimir Matveev <dpx.infinity@gmail.com>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: Rust implementation status
Date: Wed, 15 Mar 2017 20:51:15 +0400 [thread overview]
Message-ID: <1489596675.18476.2.camel@gmail.com> (raw)
In-Reply-To: <CAHmME9oaJA6xTwATpc0q=h9NO_F=ae-NveccSQpw-M4i-cF5Sw@mail.gmail.com>
В Ср, 15/03/2017 в 08:59 -0700, Jason A. Donenfeld пишет:
> On Tue, Mar 14, 2017 at 3:11 AM, Vladimir Matveev
> <dpx.infinity@gmail.com> wrote:
> > I see. I think that joining efforts would be nice, but, if I
> > understand
> > it correctly, that project is intended to provide a different
> > interface, using WG as an underlying protocol. I personally think
> > that
> > it would be better to separate these layers, providing the
> > connectivity
> > daemon and higher-level features separately. I may be wrong though,
> > it
> > is quite possible that the combined approach will be more useful.
>
> The objective of all wireguard implementations is to provide a simple
> and uniform interface. Unity is very important. I have no interest
> debating that point further. It is a stated project goal and a core
> design consideration that drives discussion on this list forward.
Sorry, I don't understand what exactly wrong with my statement here; if
anything, I do agree with the goal of making Wireguard implementations
as slim as possible (i.e. following the guideline on https://www.wiregu
ard.io/xplatform/). My thoughts in this paragraph were about the
implementation here: https://github.com/sopium/titun, which, on the
first glance (and I may be wrong here, too) appeared to provide a much
more complex interface than the one declared in https://www.wireguard.i
o/xplatform/. And my point was that it is probably better to have
something simpler, on top of which a more complex interface could be
built by someone else. This was not even related to the way the
*official* Wireguard implementation should be done.
>
> > This is understandable, I think. But still, maybe doing development
> > on
> > Github and publishing the contents of the repository there to the
> > main
> > repository is possible? I believe that taking advantage of the
> > issue
> > tracker and the pull requests system there would be very useful and
> > convenient.
>
> The main repository is on git.zx2c4.com, but if people want to use
> PRs
> and issues, and Sascha wants to review those, then that's of course
> fine. Use whatever tools necessary. The important aspect is that the
> canonical location for all WireGuard projects remains the same.
Yes, I do agree with this, and I saw your answer on Github already and
I'm really glad that you are not against this approach.
>
> > I'm pretty sure that when WG get popuar, differences in behavior
> > will
> > be unavoidable.
>
> You are so very wrong. If you start with this stupidity, sure, you'll
> get brokenness. But if you actually attempt to carry out something
> worthwhile, then each and every such difference will be squashed and
> unified. I certainly intend to toil away to achieve this goal.
If you mean official implementations, sure, I totally agree, and I
agree that it is right. I was talking about unofficial implementations
- I don't believe it is possible to force someone not to create a
Wireguard implementation with a different interface, if they do decide
to do so.
>
> By the way, are you actually intending to contribute anything here,
> or
> are you just on this list to bikeshed about procedural issues?
I'm very sorry if I said something which made you think so. I totally
do not intend to discuss any procedural issues, I do not have a right
to do so and I don't think I'm really competent. If I recall correctly,
the only thing I said about procedures is that doing development on
Github (in the sense of accepting PRs and tracking issues there) would
be benefitting for the Rust implementation of Wireguard. I really like
Wireguard, and I also like Rust, so I do want to participate in the
development of the Rust implementation of it to the best of my ability
to do so. Again, I'm sorry if I made a wrong impression here.
next prev parent reply other threads:[~2017-03-15 16:48 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-05 11:42 Sascha Grunert
2017-03-12 23:09 ` Vladimir Matveev
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 [this message]
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=1489596675.18476.2.camel@gmail.com \
--to=dpx.infinity@gmail.com \
--cc=Jason@zx2c4.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).