[Gambas-user] Idea for 3.17

[Tobias Boege]

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?

Best,
Tobias

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