[Gambas-user] Idea for 3.17
tobs at taboege.de
Fri May 7 23:38:02 CEST 2021
On Thu, 06 May 2021, Bruce wrote:
> > Yes, parts of. These are Gambas libs we use here, they reside in the
> > "Gambas vendords namespace" 'deganius':
> > > christof at tof-x230 /usr/lib/gambas3/biz1 » ls /usr/lib/gambas3/deganius
> > > deg-betrieb:1.1.gambas
> > > deglib-basic:1.6.gambas
> > > deglib-gb:1.6.gambas
> > > deg-models-degdaten:1.0.gambas
> > > deg-report:1.0.gambas
> > > deg-statistik:1.0.gambas
> > > deg-tabpanel:1.0.gambas
> > > deg-telefon:1.1.gambas
> > Dependencies seem to be managed well, also versions!
> > But I cannot use '.' in a vendor name, so domain names are not allowed.
> Ah yes, but not everyone has a domain name registered. In fact the farm
> neatly gets around that by allowing anyone (registered) to publish gambas
> software. I am not aware of any name collisions in the farm?
I never thought about this before when Christof brought it up, but now
re-using the internet domain name registrars for Gambas namespaces seems
to have some undesirable consequences, next to the problems it solves
(I do acknowledge that and think it's a clever idea to re-use *something*
that already exists and works reasonably well in practice):
- Using the (future) namespace feature of the Gambas language really
should not require a domain, which is also a *continuous* monetary
drain on the developer (yes, possibly a small one).
- I suppose Christof doesn't intend for the *language* feature,
which consists of adding more symbol tables and amending the
symbol resolution process, and should not care about any meaning
attached to the namespace string, to be blocked by the *ecosystem*
library publishing registry, which exists for social reasons of
trust and conflict prevention. But anyway, I want to go on record
here saying that I want to be able to write libraries with *any*
namespace, share them with others via email and use them without
the need to register and keep a domain. If the (future) library
installer cannot deal with local .tar.gz archives in a "trust-me"
offline fashion and has to make and verify(?) a DNS query before
it permits the installation or usage of a library written by myself,
then namespaces will fail. If anything, I can promise you that
my personal version of Gambas would always have this kind of
arbitrary restriction patched out.
- Theoretically, gambas-basic.org could be used to give the
"starving hacker" class of Gambas users a namespace for
their work, but I do think even that may be too much hassle
for those who just want to write some orderly namespaced
code for themselves or their company's toolbox. I certainly
know that I wouldn't use anything which requires more than
writing "Export MyNamespace" in a class file to make the
*interpreter* happy. If(!) this kind of centralization is
even deemed a good idea (who here remembers gambasdoc.org?).
- Domain squatting and hijacking are well-recognized nuisances of the
internet domain registration system. Suppose I publish my library
under boege.com but then let that domain expire. Someone else
registers it and pushes malicious updates to my libraries.
The squatter offers me the domain for 1,000,000,000,000,000€.
Do we have an overlay registry of our own to correct issues like
this or would we tell everyone to only use libraries from boege.com
of version <= 1.16 because unfortunately we lost the rights to that
namespace to a malicious actor? (Note that, even if I were to have
better standing, I would _not_ go to court for the privilege of
updating my Gambas libraries.)
And I wonder what would effectively prevent me from publishing a library
using the deganius.de namespace in case domain-based namespaces are used.
What I said under point 1 above amounts to «I _want_ to be able to write
and use classes under deganius.de and share them with people "unofficially"».
So my question is basically: what is the "official" way then that verifies
domain ownership and enforces the trust and collision prevention advantages
of internet domains?
PS: I have *not* re-read the thread from November 2018 that has been linked
a couple of times in this thread. If my question is answered there, I would
ask you to redirect me there.
And I apologize already for the strawmen I built above out of misunderstanding
where and how domain-based namespaces should be implemented.
"There's an old saying: Don't change anything... ever!" -- Mr. Monk
More information about the User