|
Thoughts about Xanadu addressing (and other things) These are some of my thoughts after listening to "Weaving The Web". March 15, 2008 1.1.1.1 server.document.version.format If version and or format are omitted, the newest version and author's default format are used. 1.1 Each computer using Xanadu is a server (unless it's a terminal) and obtains it's own unique number. That way, it can assign numbers serially to each document and version it creates (even while offline). If 1.1..1 is the address, the version used is the newest. Links can contain a visible portion (a domain name) that looks up the numerical address and encodes that in the link immediately. The next time the link is used, it uses the numerical address. That way, if the domain name expires, the link will still work, finding the document in the correct place. Xanadu authors can of course just use the numerical address, or both, when they create a link. The numerical lookup occurs automatically when the link is written (if online) or as soon as the document is put online. The server and document numbers are used to look up the author(s) in an online database. This will allow that information to change without breaking links. That way, if the authors who contribute changes in later versions, they will get credit and/or royalties. Why not just leave off the server number, and just use unique doc numbers? Because by obtaining a unique server number, each computer can create documents offline and the two numbers together will be unique identifiers. If a person has several computers, each should have it's own server number, so each can create document numbers independently. The author database will keep track of authorship, and optional royalty assignment. Since more than one person may use a certain computer, authorship needs to be able to be assigned at the document or version level if needed. Authorship will resolve in a cascading manner. If only the server is registered in the author database, all documents created on that computer will have the same author. If more than one author uses that computer, authorship will be looked up on a document basis. When publishing, the author will be asked which user of the computer they are. And if authorship changes through versions, they will also be registered. Since some documents will be copyrighted music, books, and movies, all documents will need to be transmitted encrypted and signed. This will also cut down or eliminate spam by making everyone accountable. If someone needs to publish anonymously for safety or privacy reasons, servers could be set up for that purpose, or a reporter could publish for them. Why not just put the author information in the content of each document? Because if a portion of a document is transcluded into another document, the author can still be credited if the transcluded portion's address is looked up. Upon publishing, a document will automatically be placed on at least three servers for safe keeping. It will still retain the server address it was created on. A Linda language could be used to find documents on the distributed network, or a suitable alternative. The preferred browser/editor might resemble Freeway or Amaya. An option might be to also allow adding to the address: dimensions, views, link sets(s), and filters, although this will be best determined by the programmers. Although it may look like to the author that links are embedded in the document, they should always be in a separate "layer" that is stored in a database, so that all links are 2 way. While allowing 2 way links will mean that some documents will have thousands of links, filtering can hide most or all of them. Link filtering can be by trusted friend or authority, reputation by voting, tags, link types, dimensions, or any other conceivable method. When inserting text into a formatted document, the option should be given to inherit the format of the to or from document, no format, or a new format. Since links will be used for formatting, links need to be able to contain sets of spans. If http urls are used, links could look like: https://hyperworlds.org/1/2.html?start42end123. These are the main elements that are necessary to achieve the integration and collaboration of all human endeavors and communications. So far, this has been mostly about the back-end server architecture and behavior. What is needed for the front-end software is to accommodate the needs of those working in every area of the arts and sciences, business, industry, government, private and organizational activities to do their own work and link them to any related areas. Always editable, annotatable, linkable, filterable, reconfigurable, reorganizable to any extent needed. While 3D worlds like Second Life add new capabilities to the Internet, they are usually limiting in other ways, such as communicating abstract ideas, weak support for text other than chat, lack of mind mapping, outlining, project management, business planning and activities, math and scientific modeling, etc. There needs to be a 3D environment in which all forms of software can be used in a collaborative form, a new meta-operating system. Any document can have any level of privacy or sharing. The virtual permascroll is partly public, partly hidden, but all addresses are unique because of the unique server numbers. All documents will be locally cached up to the computer's specified limit. Since a version of a document never changes once it is published, the cached version will always be correct, and can be transcluded into a new document or version. There will be a visible clue that a version was created by the original author or someone else. The original author can specify that others cannot create new versions of a document, but only transclude parts or all of it into a new document. There will be a visible clue of transclusions from other authors, but less visible if from your own documents. If Linda is not used to find documents, a range of server addresses could be assigned to at least 3 delivery servers (zxservers). If response time becomes too slow, more than 3 would be used for that span of addresses. If the volume of documents becomes too large, the span will be subdivided. If there is a sudden spike in demand for a particular document, it would be temporarily cached on a large number of servers. Databases needed: links (including formatting), authors, server locations, views, dimensions, transclusions, the permascroll (subdivided by spans of server addresses), filters, payments. Some of these might be implemented as trees. Although I used the 1.1.1 format to simplify explanation, the Xanadu tumbler format could actually be used to facilitate subdividing the address segments, if needed. There would be 5 options when inserting text into a formatted document: inherit format from previous or next character, surrounding text, no format (user's default style), or from the transcluded document. The web (1.0, 2.0, ...) has features that are necessary, but not sufficient for many tasks. Wikis can be edited by anyone, but require constant vigilance to keep them from being vandalized, and aren't really well suited for presenting many different points of view. The wikipedia claims to have a "neutral point of view", but I think that's an oxymoron. Blogs often allow adding comments at the end, but not linking them to relevant spans of text. Email has become a nightmare of spam, and has no security. Although more books, music, and movies are being sold online, they lack any ability at all to be linked to and from; adding your own formatting (highlighting, notations, bold, ...), and links, copying portions into what you are writing. They have the advantage of saving space and weight over paper and plastic versions, but generally lack some of the advantages of paper. This is totally unnecessary. When you pay for information, it should have added value (more than free information), not subtracted. Imagine trying to write a book with all your source books being over-protected PDF's. You would be better off going to the library and copying the pages you need, then scanning, OCR-ing, or retyping what you need. Or better yet, buying the books so you can mark up the pages. This is a totally unnecessary waste of time, money, and scarce resources caused by bad program design and management decisions. Multiply that waste by billions. In contrast, Xanadu would offer all the advantages of marking up paper plus a lot more. And you would only pay for the portions of documents you actually use. The publisher could have the option of giving away the first x amount for free for reviews, publicity, or charitable reasons if they wished. They could charge any amount they choose, including nothing. It is a rational design. Publishers would not be allowed to charge for museum pieces locked up behind glass walls (look, but don't touch). The original unblemished document will always be linked to. When I hear that something is "value added", I automatically think it's "value subtracted", since that's usually the lie being shoveled out. We have learned to lower our expectations for software not because of reality, but because of wrong decisions made decades ago that are followed by millions of sheep-like consumers and peer-pressured unquestioning geeks. Don't think outside the box. Get rid of the box. With enough imagination and persistence, nearly anything can be done in software. It should be the embodiment of dreams, not the shackles of mass-produced mediocrity. Links should have 3 parts: 1. the numeric address of the destination span(s), 2. the optional domain name address temporarily used in advertising, 3. the visible part that's actually seen by the user. There are 2 primary choices. Start with simple, but easily programmable data structures that are not sufficient to support a wide variety of needs, thus requiring an ever increasing arms race of supporting plug-ins and incompatible and unlinked new over-simple data structures. Or design a more complex data structure that supports almost any conceivable use and reuse. Xanadu achieves this by transcluding all content from a permascroll that both protects all original documents while allowing almost unlimited reuse, markups, variations, formats, links, and annotations. From the programmers viewpoint, Xanadu presents a challenge, but perhaps no more so than some of the current massively multi-player online games, which are built on complex, but highly capable databases. Linking between spans of all kinds of media; allowing changing content without breaking the links; providing many ways to view and edit the same data; facilitating extensive reuse of anything anywhere by anyone (with reasonable exceptions); making it simple to sell any media in any context; annotate and markup anything at any time - these are not simple goals that can be accomplished with trivial software. But they are worthy goals that will provide enormous benefits to the world of the future. March 27, 2008 Programmers may find it helpful to think in terms of Xanadu's input, process, and output. Input: Text - insert, create, delete, move, format, select style, link, be an active reader/editor. Images, animation, video - pan, zoom, crop, layer, apply effects, tag sections, composite, link. Audio - effects, noise removal, composite (mix), volume, equalize. Process: Store all documents, versions, creators, sellers, buyers, dimensions, links, filters, compress, decompress, encrypt, transmit, auto-backup, redundant security, animate transitions to maintain context. Protect anonymity where appropriate. Output: Everything (within reason) configurable, can have personal views and versions of anything displayed on any computer. Parents, teachers, and employers can create filters. Independent adults choose their own sets of filters to focus on what they want and keep out undesirable content. Private servers can be completely or partially fire-walled for commercial and/or security reasons. Make it easy to find original contents (display past and future locations reduced size). Jack Seay Galileo Galilei “In questions of science, the authority of a thousand is not worth the humble reasoning of a single individual.” |