Links

• Rohan suggests TURN for client-to-client firewall traversal: http://www.ietf.org/internet-drafts/draft-rosenberg-midcom-turn-04.txt. Note that this requires a TURN server, which also does authentication and stuff.
• Rachel pointed out LionShare^? P2P file sharing: http://lionshare.its.psu.edu/main/

ExportableAddressesJun2004 discussions with Andi and Ted

• There probably should be one root for the exportable address namespace, identified as '/', which can name all its children. Address parsing starts there.
• At a more abstract layer, the repository doesn't care if there's one root or many. A root is just wherever address segments start from. There could be multiple roots, supported for different contexts. Tell the repository what your root is, and what attribute to find children in, and then the address hierarchy can be resolved.
• There might be a layer above the repository that does exportable address resolution from a single known root and with known attributes to find children in.
• The layer above the repository can probably be thought of as the content model subsystem. It includes exportable address resolution and parcel loading, for now. This is only one possible way to think about this... we'll see if this idea fits as we think about it more.
• We think the root must be a real item so it can be given its own attributes as necessary.
• We talked briefly about how users either have to choose addresses (names and locations) for everythign that's created, or allow the system to automatically generate those addresses and generally trust the system. In the latter case sometimes users won't be happy and will want to assign a new address.
• Lots of discussion on what eventualities might lead to having many address spaces. (E.g. one for WebDAV to name things, one for parcel developers to name the same things, and so on).
• Explanation of John's (and others' ) wishes that we unify address spaces where possible.

-- LisaDusseault - 21 Apr 2004