From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <pve-devel-bounces@lists.proxmox.com>
Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9])
by lore.proxmox.com (Postfix) with ESMTPS id 772711FF189
for <inbox@lore.proxmox.com>; Fri, 4 Apr 2025 13:42:03 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
by firstgate.proxmox.com (Proxmox) with ESMTP id 7DEF71D3BD;
Fri, 4 Apr 2025 13:41:49 +0200 (CEST)
Date: Fri, 4 Apr 2025 13:41:15 +0200
From: Wolfgang Bumiller <w.bumiller@proxmox.com>
To: Stefan Hanreich <s.hanreich@proxmox.com>
Message-ID: <26i4ffree7x33g54u5xkrr4gmrbemmabvuhe6ymo3er77mwbww@thzarnrvw4kw>
References: <20250401145246.395459-1-s.hanreich@proxmox.com>
<20250401145246.395459-2-s.hanreich@proxmox.com>
<n2stwbny2bmilkupg6y5q2nm4h4ksiu3yerg4zfo6qrbccnm2f@seaf4obanaar>
<77727bc6-1cac-433d-baa4-131232952d3d@proxmox.com>
<407c30ee-462b-4649-a415-a9f7a4c0c7b4@proxmox.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <407c30ee-462b-4649-a415-a9f7a4c0c7b4@proxmox.com>
X-SPAM-LEVEL: Spam detection results: 0
AWL 0.081 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DMARC_MISSING 0.1 Missing DMARC policy
KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record
SPF_PASS -0.001 SPF: sender matches SPF record
Subject: Re: [pve-devel] [PATCH proxmox v3 2/2] network-types: add hostname
type
X-BeenThere: pve-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>,
<mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>,
<mailto:pve-devel-request@lists.proxmox.com?subject=subscribe>
Reply-To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Cc: pve-devel@lists.proxmox.com
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: pve-devel-bounces@lists.proxmox.com
Sender: "pve-devel" <pve-devel-bounces@lists.proxmox.com>
On Fri, Apr 04, 2025 at 01:26:46PM +0200, Stefan Hanreich wrote:
>
>
> On 4/4/25 09:51, Stefan Hanreich wrote:
> >>> +///
> >>> +/// It checks for the following conditions:
> >>> +/// * At most 63 characters long.
> >>> +/// * It must not start or end with a hyphen.
> >>> +/// * Must only contain ASCII alphanumeric characters as well as hyphens.
> >>> +/// * It must not be purely numerical.
> >>> +#[derive(Debug, Deserialize, Serialize, Clone, Eq, Hash, PartialOrd, Ord, PartialEq)]
> >>> +pub struct Hostname(String);
> >>> +
> >>> +impl std::str::FromStr for Hostname {
> >>> + type Err = HostnameError;
> >>> +
> >>> + fn from_str(hostname: &str) -> Result<Self, Self::Err> {
> >>> + Self::new(hostname)
> >>> + }
> >>> +}
> >>> +
> >>> +impl AsRef<str> for Hostname {
> >>> + fn as_ref(&self) -> &str {
> >>> + &self.0
> >>> + }
> >>> +}
> >>> +
> >>> +impl Display for Hostname {
> >>> + fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
> >>> + self.0.fmt(f)
> >>> + }
> >>> +}
> >>> +
> >>> +impl Hostname {
> >>> + /// Constructs a new hostname from a string
> >>> + ///
> >>> + /// This function accepts characters in any case, but the resulting hostname will be
> >>> + /// lowercased.
> >>> + pub fn new(name_ref: impl AsRef<str>) -> Result<Self, HostnameError> {
> >>
> >> Nit: I'd recommend using a `check()` function which does not create the
> >> `Hostname` itself, because then:
> >>
> >> - in `FromStr` we know we have a reference (&str) and need to clone.
> >> - We could add a `TryFrom<&str>` wich just uses `.parse()`
> >> - We could add a `TryFrom<String>` which avoids the clone.
>
> What about a constructor that just takes String (if a function needs to
> own the value it should demand a String anyway) and then calling that
> constructor from the proposed trait implementations? Maybe something
> more generic than String as a param, but that could usually be tacked on
> later without breaking the API.
I suppose that's fine. We'd clone in the error case, but that's not the
expected case anyway.
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel