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 Rust implementation status 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
-- strict thread matches above, loose matches on Subject: below --
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 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.