Brain dump #2 - zope and grids and GUID's

[Joe Armstrong]

On Mon, 10 Feb 2003, Vlad Dumitrescu (EAW) wrote:

... cut ...

> >   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...
> 

No no no - perhaps I didn't emphasis this enough: it's a **hint**

How about

	guid://{m1,m2,m3}m/Date/Seq

m1,m2,... are hints to the machine which *might* contain a copy
of guid://m/Date/Seq

	m is the creation machine.

This could be re-written later as

	guid://{k1,k2}m/Data/Seq



> > guid://{my.home.machine,my.work.machine,a.permanent.machine}/Date/Seq
> 
> >   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! :-)

  I like the idea  of including the hint in the name  - you can change
the hint if it's wrong.

  Otherwise you have no idea how to find it - you *could* use chord or
a  distributed hash  table  etc. -  which  you have  to  fall back  on
*anyway* if the hint is wrong.

  Perhaps  my first server  should be  a GUID  server with  "chord" to
resolve unhinted GUIDs :-)


/Joe

> 
> regards,
> Vlad
>