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

Joe Armstrong <>
Mon Feb 10 10:52:14 CET 2003

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"


  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://

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

  /* guid:// */

  If it's in XML

  <?xml version="1.0"?>
  <? guid:// ?>


  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.


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


  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


  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 (

  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?


  For example - this might be very nice.

  a Guid like


  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

  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


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

 Comments, Thoughts, Improvments?????



More information about the erlang-questions mailing list