Brain dump #2 - zope and grids and GUID's
Vlad Dumitrescu (EAW)
Mon Feb 10 11:26:29 CET 2003
I have some comments/question marks, not sure all make sense.
> Central to a lot of ideas about zopes and workflow grids and things
> is the idea of a GUID (globally unique identifier).
> Most GUIDs are long random strings of junk - like this
> Of some weirdo Mac address + a time stamp + random number etc.
> The main point is *there is no indication HOW to find the resource
> referred to*
I am sure everybody already knows this. The "weird" looking GUIDs are so because they are meant to be generated automatically, by a machine, and we heve to be VERY sure that they are really unique. This is because they are used inside tha system, more than outside it: compare this with the reference type in Erlang, it's conceptually just the same!
> I think this is *fundamentally wrong* - I think the GUI should
> contain a *hint* as to HOW to find the GUID - I also think the GUID
> should be human readable and writable - so I can write it down on a
> sheet of paper and remember it.
This is true, if the GUID is designed to refer to *documents*, not memory objects, ActiveX interfaces or any other "weird" stuff.
> I work on several different machines so my GUIDs are
> composed of three
> fields (a hostname, a date, a sequence number). -
This really points to the location where the document was _created_. It might not be found there anymore, and there might exist duplicates... If the "owning" machine is not up or online, then one doesn't have any clue about where to look anyway...
> Could be used - my home machine is turned off for when I'm at work,
> my work machine is (in principle) always up but might crash,
> a.permanentt.machine is also (in principle) always up.
Maybe this will work, but again: what happens if you buy a new machine and want to move some or all of the stuff there? What if you change jobs and even if the machine may be the same, it gets a different name? What if a machine is part of two different networks, with two different names? You mention peer-2-peer backups, how to find the backed-up documents?
What I think I am trying to underline is that even if this scheme will help, I am not sure if it is complete. To quote you, I think this violates the principle of least surprise for me: a document's ID should refer to that document, not to the place where it happens to be stored at a particular time. These are two different issues and I think they should be handled separately. (No, I don't have any solution except that already in use: a distributed database with efficient search)
I don't say this is bad, I say I need more arguments to be convinced! :-)
More information about the erlang-questions