::address deficiencies worth to consider with 5.0 break

[elmarco]

• zbus shouldn't provide zbus::address. zbus itself needs to parse dbus addresses, but 99% of users simply use the default buses, or connect with a string.
• builder APIs are mostly useless, since typically an address is built from string
• it doesn't provide ;-separated list handling
• transport parsing should be comprehensive and independent from the host
• it could reference string slice, rather than being an owned type
• implementation is mixed with host & connection details, clean standalone implementation is highly desirable
• there are improvements desirable, such as const parsing, although this is not yet doable without a proc macro, afaik.

[zeenix]

• zbus shouldn't provide zbus::address.

Again you start with pushing for a separate lib of yours. :facepalm:

• zbus itself needs to parse dbus addresses, but 99% of users simply use the default buses, or connect with a string.

Actually, most people never ever touch this API directly. They just connect to session or system bus through our convenience Connection methods. So splitting it into a separate crate, that we maintain, isn't going to give user anything at all. The only real benefit of a separate crate, is if anyone needs to use the address API only (w/o ever connecting). This is an extreme niche case IMO. So I'm baffled why this is so extremely important to you.

• builder APIs are mostly useless, since typically an address is built from string

Yes but we don't really have a dedicated builder type or anything and if we're basing this on typical case only, then we don't even need a public Address API for the typical case. The builder pattern is just a nice way to construct the address. I don't really see why it's a problem?

• it doesn't provide ;-separated list handling

Sure but I find that a niche-case that can be added on top.

• transport parsing should be comprehensive and independent from the host

Can you clarify what exactly are you proposing? There is a reason I asked you to specify the API.

• it could reference string slice, rather than being an owned type

Given that 99.99% of folks will use a single connection in their app, I don't see this improving any performance benchmarks but sure, why not.

• implementation is mixed with host & connection details, clean standalone implementation is highly desirable

Again, very vague. In theory, I agree and I already said so many times. API proposal please!

• there are improvements desirable, such as const parsing, although this is not yet doable without a proc macro, afaik

Not to mention, given how an address is parsed just once in a typical app or service's lifetime, I don't think this is worth any efforts but go ahead.

[zeenix]

Since you wouldn't budge, I had a look into dbus-addr. Looks mostly good so let's use it. However, I'll want:

• co-ownership so I can maintain it when you disappear for months. :)
• move into zbus space (we'll need to coordinate that).
• renamed to zbus-address, so it's clear that it's part of the project and people don't hate us for having yet another dep. :)

Also some comments:

• Can you please make use of doc-comment crate to keep the README and crate-level docs in sync, like we do in zbus crates?
• Add an example code in the README, with a few different examples.

[zeenix]

Based on the last comment, I'm closing this in favor of #982, which I'll reopen now.