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

[Joe Armstrong]

Brain Dump 2

Central to a lot of ideas about zopes and workflow grids and things
is the idea of a GUID (globally unique identifier).


Recall that my second problem was

	"finding things"

<aside>

  My  New Year's resolution  was to  put a  GUID in  every text  file I
created or edited (I didn't manage this :-)

  My GUI's look like this:

  If the GUI is in the top of a Erlang file I write it like this:

  %% guid://enfield.sics.se/2003-01-08/6

  If it's in a C file I'd write 

  /* guid://enfield.sics.se/2003-01-08/6 */

  If it's in XML

  <?xml version="1.0"?>
  <? guid://enfield.sics.se/2003-01-08/6 ?>

  etc.

  This is  always as near  as possible  to the top  of the file  as is
allowed by the syntax.

  A crontab  job periodically  checks all my  new files and  logs the
GUIDs in a data base - the program warns me if I accidentally have the
same GUID in two files.

</aside>

I assume here, that if you have a GUID, you can find the thing that
is being referred to.

  Most GUIDs are long random strings of junk - like this

	"sadjgfsagfjashfkgasvasjgjsgfjgfjgsafhebutaskhfefjhbdjb"

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

  I work on several different machines so my GUIDs are composed of three
fields (a hostname, a date, a sequence number). -

  This mail, for example, might have a GUID

  guid://enfield.sics.se/2003-02-10/2

  This  is the  2'nd file  I've created  today -  Note -  there  is no
guarantee that this *is* a GUID - somebody else might deliberately try
to break the system by giving their document the same GUID.

  The  responsibility for  assigning  unique sequence  numbers is  mine
alone - and is local to this particular host (enfield.sics.se)

  Since the  GUID contains a *hint*  as to where it's  located I could
easily make system of servers on some well-known port that responds to
requests for GUIDS - these could be organized into pairs of servers (a
la DNS) for fault tolerance  and high availability - and would respond
to a simple {get, GUID} message.

  I think this might be a  nice program to write - several people have
got non-firewalled machines  - I think it would be  *very* nice to set
up a  distributed fault-tolerant  network of GUIDO  servers on  top of
this - I will even volunteer to write the server (unless anybody beats
me to it)

  ----

  Any ideas about the GUID is the GUID *too* simple - do we need more
hinting about the location?

  guid://{enfield.sics.se,r2d2.sics.se}//2003-02-12/6

  For example - this might be very nice.

  a Guid like

  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.

  ----

BTW - seems like we need a number of small dedicated servers - here are
three small servers to get us started:

	- GUID server
	- Data Store
	- Relay

 GUID server is part of the "finding things" problem 

 Data store is part of the "storing things" problem

  (A lookup on  a GUID server would result in  a storage location, the
Data  store would  have the  data -  replicated *forever*  -  the GUID
server and  the data store *might*  but do not necessarily  have to be
co-located)

  Relay is  a simple "relay machine"  - for the benefit  of people who
are "firewalled in". If A and B want to talk to each other and if both
are "firewalled  in" they both connect  to C (a Relay)  and relay data
though C - the relay should not be the same as the data store and GUID
server.

 ----

 So here we are three little "infrastructure" servers - this is the basis
of many apps, like peer-2-peer backup, ... etc.

 Comments, Thoughts, Improvments?????

 /Joe