Community-based urld:

How can urlds running on AP/servers communicate with urlds
running on APs elsewhere in a local wireless mesh?  Here
is one simple architecture that takes advantage of the web itself.

1. assume all APs have a web server, closely coupled (same linux box)
or at least on the same ethernet link behind the AP.

2. assume all web servers have an urld page, with a well-known name,
	at least for the last part (urld/index.html).  Assume
	we have a list of those urls.

	http://www.josejavacoffee.com/urld/index.html
	http://www.pieareus.com/urld/index.html
	http://www.redhotpizza.com/urld/index.html
	http://jrbshomeap/urld/index.html

3. assume all AP web servers cache client wireless node urld
	broadcasts so others on the same link (and all other APs too)
	can see them.  (which is what urld does anyway by default).

Remember that urld just sends out a set of urls from one system
that end up on one web page:

	system label
		url1
		url2
		url3

and that urls can point anywhere.

For the sake of argument we will assume 26 web servers, A-Z, and
will designate servers A, and B, as master servers.  There
are two additional community server pages on A, B, therefore
A and B can be said to minimally have two pages each.  One
created by urld.  One that serves as a master community page.
(Why A and B, redundancy ...).

Master server setup:

A:
	label: community server page

	urls:
		A urld page
		B urld page
		C urld page
		D urld page
		...
		Z

B:
	same as B.  possibly auto copied from A with wget
	every day.

A user at server C, should be able to see C's page.  C's page
includes urls for A and B.  Thus that user can find pages
in a 2-step hierarchy, local (C), and community (A, B).

All of the above is a mere matter of IT organization.  Of course,
more fancy schemes might be envisaged.

Benefits:
Any www.josejavacoffee.com that uses urld, now has both local wireless
advertising, and cross-community advertising.

In addition, users can find each other.  Which isn't the worst idea.