non-human readable naming ...

[Michael Meeks <michael helixcode com>]

Hi,

	I sympathise deeply with Gergo's comments, and furthermore with
the current discussion about moniker based activation it would seem that
putting what is essentialy a non-human-readable number on the end of a
component is a terrible idea if as hackers we ever want to assemble our
own moniker.

On 23 May 2000, Maciej Stachowiak wrote:
> 1) Not every component _has_ a vendor. What if I write my own
>    open source component just for fun?

	Right; but there is luckily a free software foundation, a gnome
foundation, helix code, eazel etc. to adopt these projects, I see no
problem finding a vendor name for an open source component.

> 2) Company names collide.
> 
> Once there are enough people out there writing components, we will
> need a serious way to prevent OAFIID's from colliding. People write a
> _lot_ of COM objects today (just go to a technical bookstore and look
> at how many COM books you see) and I think many people here would like  
> Bonobo to be as big as COM someday. So we must be prepared for the day
> when huge numbers of people are writing Bonobo objects.

	Sure, no one wants conflicts, all that is being discussed is the
possiblity of combining several human readable namespaces to make the
likelyhood of conflict as small as the current random number namespace
which has to my mind this crippling disadvantage of requiring excessive
cutting and pasting and nasty verification problems. I have already fallen
over this whilst converting gnumeric.gnborba to gnumeric.oafinfo with the
script and not noticed the difference between the factory and component
location's magic numbers.

> The only two real alternatives are a central registration authority,
> or a distributed scheme to generate identifiers that are still   
> globally unique. I think the latter is much more in the spirit of free
> software, and much less likely to be ignored just out of
> laziness. This is why I picked the scheme of appending a uuid to
> guarantee uniqueness of OAFIIDs.

	Ok; it works, but I don't think it is at all good, I think we
should pick the intersection of sufficient readable namespaces to be
acceptable.

	eg. We could encode the magic number thusly; work out how many
words there are in a dictionary, my words file has 32768+ this maps to
15bits of data. Hence we could get 120 bits of random data via 8 random
words [ ok so we would have to ship a trivial program to generate them ]

	kippers:penguin:night:see:foo:bar:attain:chartroom

	This would be IMHO better than,

	0fbc844d-c721-4615-98d0-d67eacf42d80

	And not much longer, but I think this is a horribly banal problem.
Consider eg. 'SawFish' has had to recently change its name because another
software product uses that name. I can think of very few software products
with identical names, so that is 1 space good for uniqueness, a second one
is company name, I know of extremely few companies with the same name, and
even fewer that make software, [ lastly we could reccommend a random key
word perhaps ].

	Either way, I know of no combination of 'same company name', 'same
product name' anywhere in the known universe, can someone point me to one
? clearly if a product is made of many components then 'component name'
can further specify the mix, we merely have to reccommend an ordering.

	In summary I really dislike huge numbers even if we put '-'s in
them to make them more readable, can we reccommend something more
aestheticaly pleasing ?

	Regards,

		Michael.

-- 
 mmeeks@gnu.org  <><, Pseudo Engineer, itinerant idiot