More namespacing woe ...

[Michael Meeks <michael helixcode com>]

Hi Martin,

On 28 Nov 2000, Martin Baulig wrote:
> What you are suggesting is doing a technically wrong thing just to
> get a very little bit more convenience.
  
        Thanks for your vote of confidance :-)

> By suggesting that we can leave away the UUID when activating an
> object, I was actually making a big compromise - of course it is
> technically wrong and broken to activate by the short form (without
> the UUID).

	I see, so my questions pointed out the anarchy in the middle
path ? so now you want the UUID always; fair enough. However, in no
way have you explained to my satisfaction why it is 'technically wrong
and broken', please be patient with me.

> We can clearly namespace our stuff, fix things, etc.

	Good fine. So you accept that clearly namespacing our stuff is
acceptable for the GNOME project, and for any major ISV. Excellent,
why not do that then ?

	So; then we are left with lots of random hackers:

> When you look at Windows, there are both the big programs and a
> very, very, very large number to shareware-like, user contributed
> stuff like games.

	We reccommend to these people that they either

		a) Register a Namespace as described
		b) Use their web address:
			Com_ShareWare_MyProject
		c) Use a UUID for all other cases

	Either way, these are only reccommendations, and there is no
way we can enforce them, until these people want their software
distributed, at which point they will have to do things right.

> I expect that the same will happen with GNOME when we're becoming
> successful, we will get a large number of small programs - and their
> authors don't know about each other nor do they want to do all this
> bureaucratic stuff of registering a namespace for their stuff, they
> just call their programs like they want.

	Well; I think mailing me ( or George ) is hardly beaurocratic,
I think so far I have only asked 1 chap to re-consider his name, and
he did. Either way, we still reccommend the UUID for all the cases
that you are worried about.

>    Also, I still think that clashes in IDL files won't cause any
>    problems here since they'll be in different .idl files and you'll
>    normally only include/use one of them, but not both.

	We live in a world of brokenness and pain WRT. scripting, this
has to be fixed soon in order to compete; it is 0% acceptable to have
IDL namespacing conflicts; anyone I personaly see doing this will be
nailed to the wall /me fingers nail gun.

> b) Clashes between such a program and a core GNOME component.
>
>    Even this can be solved with UUIDs - when you install such a
>    program, your GNOME system will still continue to work.

	Nothing is solved with UUIDs, the kind of totaly gormless
people we are trying to guard against will most likely copy the whole
oafinfo file from a working project and just replace the binary name,
and then copy the source, hack it slightly [ changing the "Help->About"
box ] and re-release it. People can still screw you, however much you
try to stop them. The only way round is good docs, and sensible
packagers. The same is true of eg. the RPM package namespace I
imagine.

	I don't see how the procedure for dealing with someone
duplicating an OAFIID is different from that of someone picking the
same OAFIID as someone else.

> Again, I don't see clashes in IDL files being such a big problem,
> not even for scripting languages (you should get an error when you
> try to load that IDL file, but you should still be able to use the
> core GNOME interfaces without problems if you don't include/use the
> clashing IDL).

	Why should you get an error loading the IDL file ? the IDL is
valid, it just doesn't match the component at the other end, or the
methods you have invoked on it: chaos.

> However, without UUIDs we'll be in big trouble when we get a clash.

	I just don't believe this, we can get clashes either way, and
they are very unlikely I maintain, but of similar probability either
way due to human nature, and general incompetance. However, I firmly
assert that someone who doesn't understand the oafinfo file and hasn't
read the docs, is not going to be re-generating a UUID, we'll be lucky
if they change the string part much.

	You seem to suggest that with a UUID we can resolve clashes
somehow; I don't understand how this could be; any clash is evil.

> It's hard to explain our users that after installing a broken
> component their whole core GNOME system will be screwed and that
> they must uninstall that component first.

	I find that very far fetched; however I can do it now if you
like; how about installing this oafinfo fragment:

[prefix/share/oaf/my-oaf.oafinfo]
<oaf_server
iid="OAFIID:nautilus_factory:bd1e1862-92d7-4391-963e-37583f0daef3"
type="exe" location="/bin/ls">

  <oaf_attribute name="repo_ids" type="stringv">
    <item value="IDL:GNOME/ObjectFactory:1.0"/>
  </oaf_attribute>
  <oaf_attribute name="name" type="string" value="Nautilus factory"/>
  <oaf_attribute name="description" type="string"
   value="Factory for Nautilus shell and file manager"/>
</oaf_server>

	So; in summary, people can screw us either way, so lets go for
a system that is pleasant, unified, human readable, easily typable,
non-scary for new users, and trivial to compare by eye.

	Regards,

		Michael.


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