What would be a valid D-Bus interface name for a project without domain?
Simon McVittie
smcv at collabora.com
Thu Jan 25 14:09:16 UTC 2018
On Thu, 25 Jan 2018 at 08:16:29 +1300, Lawrence D'Oliveiro wrote:
> On Wed, 24 Jan 2018 19:26:37 +0100, rony wrote:
> > If your aim is to come up with a unique domain name that is unlikely
> > to be name-clashed, then why not use your own name as part of such a
> > domain, maybe something like "personal....”
>
> The problem with any TLD is we can’t be sure it won’t be allocated in
> future. Hence the suggestion of a subdomain that is already under the
> control of somebody likely to be sympathetic to this need.
If someone is handing out names within a namespace by some automated
or manual "claiming" process, that's essentially a service providing
a tiny subset of the functionality of GitHub (or GitLab, or Sourceforge,
or debian.net, or whatever). If that's what you're looking for, purl.org
might be what you want? Creating a PURL "domain" like
"http://purl.org/example" via https://archive.org/services/purl/ and using
a namespace like org.purl.example.YourProject seems like a plausible
approach (and you can configure http://purl.org/example to redirect to
your project's actual website, assuming it has one).
This would "tie" your project to purl.org, but the entire point of
purl.org is to provide permanent URLs for resources, so perhaps that
addresses the objection of not wanting to be "tied" to GitHub?
freedesktop.org is sufficiently undermaintained that its sysadmins
probably don't want to take on responsibility for running a name registry
service (beyond the project registration facilities that already exist,
which are somewhat heavy-weight). Also, freedesktop.org is an
inconveniently long namespace :-)
On the other hand, if people are just using the names they want to use
within a namespace without any particular registration or "claiming"
process, then that has exactly the same issues as using a nonexistent
TLD (name might be used by someone else at any time), except that the
names are (most likely) significantly longer. That doesn't seem a great
trade-off.
smcv
More information about the dbus
mailing list