I remember a small magazine (called Science Digest, IIRC) I read in the mid 80's. It was short little science articles, probably a couple hundred words each (at most)...not unlike RSS feeds today, perhaps.
One article was about scientists making the most perfect sphere to date out of some crystal. It was measured to be so perfectly round that if you scaled it up to the size of the earth, it's highest peak would be 12 feet higher than it's lowest point.
I'm sure the technology for this thing has improved a lot in 20 years.
You claimed that XML gave you so much more than a data representation.
XML is there to free me from the need to write a parser and dealing with all the annoying issues like encoding and delimiting data, because those issues take work to satisfactorily solve, and I have better things to do with my time than writing parsers for programs whose primary purpose has nothing to do with parsing.
Sounds to me like your original assertion:
XML works by freeing you from the need to come up with your own format and a parser.
I assert that a parsed XML tree really doesn't buy you that much. You must still walk your structure manually. Who does the semantic validation? How many XML instances in the wild use a doctype declaration? How many adhere to a DTD? Almost none that I've seen. They are ad-hoc constructions used to store data. The data representation format has value, but claiming the parser in such situations adds significant value is a silly argument. You must still do a lot of semantic validation as your code walks the data structures associated with the parsed instance. Even in instances that adhere to a DTD, if the underlying data is at all complex you'll have code that follows very closely what the DTD states....why can follow what in what contexts. Wonderful. But shouldn't all data in the system be defined in one place? Isn't that the whole rationale for the DRY principle? Why is it okay to duplicate it in this context?
According to your original argument, you like XML because it frees you from certain drudgeries. I say that it's great you're so impressed. Here is another tool that can free you from so much more. Give it a shot. You may discover ways to break chains you don't even know are there.
I claimed XML is just a data representation. You claimed that XML gave you so much more than a data representation. If you do genuinely believe that, and like XML because it is a tool that offers you certain benefits, then it would seem logical to find the best tool to accomplish the task.
I simply point out that other tools that are even simpler than manipulating XML parse trees and have additional benefits that you might like.
Expand your toolkit. You may not like it. But at least you'll know the tool is there and what it can do.
Why would you want that? You advocated for it. You said:
XML works by freeing you from the need to come up with your own format and a parser.
I simply point out that with sexp, here is your parsed data
data
Even better, here is you performing the desired operations on your parse tree:
(eval data)
Yes, it's just that easy. If that doesn't fulfill your requirement, why did you advocate for it?
Now, to make you feel a little more safe, as little or as much done during processing as you require....including nothing, if you're worried about your database issue. The data/code is inert until you try to execute it. That shouldn't be hard to understand...you do exactly the same thing (but with a lot more code) when you do it with XML.
I know it's a little scarey and seems a little spacey. All I can do is tell you that everything will be okay, and it will be an eye opener.
I notice you still haven't provided examples, btw.
You're right. Simple examples don't do it justice and your arguments don't indicate that you're really not interested in learning. But if you would like to learn, ponder defining methods for +, -,/, *, log....(they're inbuilt in most languages...I won't provide you with an implementation).
% (+ 5 (* 3 4)) 17
Now, imagine a dialect where you define methods like html, body, head, etc that output html tags. Or a dialect that describes docbook. You define two sets of methods: one that downtranslates to html and one that translates it into LaTeX. Execute your code / data and you get the output you want.
If you don't see the utility, I'm not surprised. I understand. I've heard it said that most people don't really don't understand the power until they've done it for a couple of years. But once you do....they'll never go back.
If you are really interested in learning and not just saying "I don't get it", I recommend you pick up a copy of SICP - Structured Interpretation of Computer Languages. It's the first year MIT computer textbook. I have a B.Sc and an M.Sc. in Computer Science and 10 years in the industry since then...and I learned a lot going through the textbook about a year ago. Peter Norvig (Google's Director of Research) points out that SICP has an unusual Amazon rating distribution. It's double-humped: a large number of 0's and a large number of 5's with nto a lot in between. The speculation it comes down to people who get it, and people who don't. It's worth it if you get it...the names that seem to get it and advocate it are titans of computers and computer science.
I find it interesting that the people that are closest to XML are usually the people that are most vocal about the limitations and misconceptions of it, and talk most fervently about the benefits of things like sexps. The company I worked for had a precursor to XML that preceded it by about 7 or 8 years (before my time). We had Tim Bray as a founder. We purchased Microstar (yes, that one). I've worked with ex-Omnimark people. I can't explain why, but the people that are closer to working with XML...not at a high level, but at a low level seem to drift toward sexps as they go...
Of course it doesn't specify what the data means. Nor it should, because that's not the point of it. How the hell can any markup format do that, anyway? It's simply an unsolvable problem in this respect.
What if you came up with an XML DTD that could represent a Java program structurally? What if you then wrote a Java program to manipulate those XML data files? Then what if you wrote that program in your new XML-Java language?
The program is the code. The code is the program.
Now generalize the concept. For any XML data file, what if you could enhance your language so that the XML elements actually corresponded to calls (subroutine, methods, jumps, whatever)?
I've seen your link, but it's completely useless. It's completely devoid of any technical information.
The technical information is elsewhere. The movie trailer shouldn't tell you how a movie ends....it should encourage you to go see the movie.
Your basic tenet seems to be, "Why reinvent the wheel."
Okay, why reinvent the wheel? S-Expressions have been around since the 60's. They are far simpler to understand and use than XML. They show the equivalence of data and code (von Neumann, anyone?) when considered in the context of Lisp. They are more economical than XML. In fact, it's hard to find a way in which they are not superior.
But this doesn't get us any closer to the issue you don't seem to grasp: XML is a data representation. The underlying problems still exist. What does the data mean? You've added a turtle between you and the problem. That's the XML parser. The XML parser really does very little for you. Now you walk a parse tree. It's a lot of effort for ver little payoff. To rephrase: It's not a silver bullet. Consider the S-Expression alternative in Lisp. Make methods out of portions of the code. But S-Expressions aren't a silver bullet either.
XML is a data representation. It works? How does it work? By representing data?
What else could work? S-Expressions? SGML? ASN.1? Flat text file?
The data representation isn't solving the problem.
XML, Extreme Programming, technique / technology of the week all are trying to do the same thing: help us manage complexity. Fred Brooks had a lot to say there. My favorite quote from the 'No Silver Bullet' essay:
Software entities are more complex for their size than perhaps any other human construct because no two parts are alike (at least above the statement level). If they are, we make the two similar parts into a subroutine--open or closed. In this respect, software systems differ profoundly from computers, buildings, or automobiles, where repeated elements abound.
I can think of a few legitimate reasons and many less honest goals. The world is awash with non-free propaganda, which is designed to make the user feel helpless.
My wife would like to understand.:) Is it legitimate? Certainly. Is it less than honest. I don't think so. She's definitely non-technical, but exceptionally smart. Her reaction is generally "just plan better". I argue that the industry has been struggling with this issue for decades. I don't think we're all morons to have built so much infrastructure and come so far, but we still can't solve the simple parts like accurately identifying how long it will take us to accomplish our goal.
My wife is just one of several I'd like to talk to about it. They're mostly other non-technical people, although a couple may have engineering or physics backgrounds.
Raise my spirits with a story of educational and respectful conversation. I'd love to hear about it.
Hopefully, your spirits have been raised. Now soar...
Thanks. This is the first response I've seen that is at least along the lines of the response I was hoping to get. My problem with these sorts of explanations, is it still doesn't capture the complexity.
When you're writing code that you've never seen anyone do before. Doing things across multiple languages, building infrastructure. But because you've never seen anything like this, and certainly never looked at the code for anything similar, how do you explain why your time estimates can be so off?
Alternatively, why does the industry have so much difficulty with deadlines? What makes development complexity defy good planning? Are we really an entire industry of bad planners? Not all software projects take longer than expected to develop, but those are either relatively simple or relatively straightforward. When software becomes complex and / or more researchy, it appears the complexity overtakes our ability to propertly estimate.
Why?
The best example I had (especially for the more R&D-y projects) was this: you're given a vague drawing of a scene. It's a relatively tight photograph. You think the scene is in L.A. (or some other sufficiently large city). Go find the photograph. All you have is a vague out-of-focus sense of what it is you're looking for.
Now some people might complain that what I'm describing is a poorly designed system or poorly described requirements. That may be partially true, and that may be the case for the more straight-forward projects. But when you're doing something relatively unique, all you have is a known destination (an in-focus picture), not the actual location (where the photo was taken).
I'm sorry, but just because you rant, doesn't mean you should be modded up.
Ajax is a floor cleaning product. AJAX is an acronym standing for something different. The fact that the two have a similar name is irrelevent. Thinking differently means you should probably go for a CAT scan (no, not "cat scan") or perhaps a PET scan (no, not "pet scan"). Perhaps you should go stand on a soap box in front of your local city hall with a bull horn and expound the virtues of a non-acronymic world.
Give me a break.
You say nobody cares that it is AJAX, but they care that it works well and does what they want.
If no one cares about the technology behind a good user experience, there will be no good user experience.
Technology, by and large, is an iterative improvement upon previous technology. Failure to recognize this means your genes should probably have been relegated to the non-tool using part of the animal kingdom.
I didn't dispute that the Canadian population is compacted along the US border. I simply said that broadband access is available, even in areas of Canada that are physically remote (when compared to the US) and, in the eyes of their business community at least, unworthy of provision of service. There were stories on Slashdot in the last 6 months talking about how small towns (50,000+ people) were having trouble getting broadband access in the town. Check it out.
The Pacific Ocean issue is a red herring, because the population of people living in the Pacific Ocean is currently low, lower than even that of Canada's Northern Territories (which I admitted don't have good service for the most part).
Then why can my brother, who lives almost 8 hours north of the US border, 1.5 hours away from the nearest "city" (city of 5,000 people) in a farming/logging town of less than 1,000 people can get broadband access, and how all these centres in the US cannot? Hell, the largest city in our province is about 200,000 people, and that's about 3.5 hours away!
My mother, who lives on a farm several miles outside that town cannot currently get broadband, but it's supposed to be available soon.
You're right, the vast majority of the Canadian populace is concentrated along the US border, but that by no means implies that broadband isn't available in a very high percentage of the country. There are very remote areas that don't have good access (ie, the territories), but the country is pretty well covered considering the population density.
Is that rural enough? It's the town I grew up in. It's in Saskatchewan.
Yup, broadband available.
Compare that with places in the US that are complaining they can't get broadband because they only have a few hundred thousand people. C'mon. Really.
Now, I'll admit that my parents who live on a farm several miles from town (and a half mile from a forest that you could walk through and get to the freakin' north pole only crossing a couple roads) can't get broadband. Yet. But they could if they were a half mile closer to town.
Yes, Canada is highly concentrated along the US border. But broadband is still available.
Perhaps you live in Alberta. It's more like the US. That might explain your lack of service availability.
You qualified your supply/demand discussion with the word 'motivated'. Very good. If the person submitting the original story had qualified their remarks as you have done, I would not have had a problem with their assertion.
Unfortunately, they did not do so.
Further, the vast majority of support for F/OSS is free. Both sought from free sources and offered freely. Therefore, their unqualified remarks regarding demand were misguided, to say the least.
Exactly....I made the same point when responding to someone earlier. Making a project FOSS software removes a barrier to entry in the support arena. Then, whether that support is offered freely or on a fee-for-service basis is an orthogonal issue.
No. You are speaking to removal of barriers to entry for those that wish to support a product. This is a valid point only in so far as we're talking about economically viable business.
Read the original slashbox. They stated that F/OSS projects are assured of continued support. By their very nature. Because they are F/OSS.
I have no problems with the idea that VB would have longer support if it were F/OSS. I simply want to point out that F/OSS zealotry is counter-productive when used as propaganda...
This is also very similar to a demo I saw on a video for SIGGraph 1993. It was called Pad.
The demo showed something like an article or a financial statement. There was a dot near the end of a sentence, and when you zoomed in, it was a spreadsheet with the financials. It was totally black and white (monochrome black and green, actually), but it looked really nifty. Everything pixelated like hell, but with some of the scalable interface components that Apple and Microsoft and probably others are working on, you could perhaps even do away with the pixelation.
We believe that navigation in information spaces is best supported by
tapping into our natural spatial and geographic ways of thinking. To
this end, we are developing a new computer interface model called
Pad.
The ongoing Pad project uses a spatial metaphor for computer
interface design. It provides an intuitive base for the support of
such applications as electronic marketplaces, information services,
and on-line collaboration. Pad is an infinite two-dimensional
information plane that is shared among users, much as a network file
system is shared. Objects are organized geographically; every object
occupies a well defined region on the Pad surface.
For navigation,
Pad uses "portals" - magnifying glasses that can peer into
and roam over different parts of this single infinite shared desktop;
links to specific items are established and broken continually as the
portal's view changes. Portals can recursively look onto other
portals. This paradigm enables the sort of peripheral activity
generally found in real phy...
And so the article continues.
Citeseer reference to the article can be found
here.
Slashdot Mirror
I remember a small magazine (called Science Digest, IIRC) I read in the mid 80's. It was short little science articles, probably a couple hundred words each (at most)...not unlike RSS feeds today, perhaps.
One article was about scientists making the most perfect sphere to date out of some crystal. It was measured to be so perfectly round that if you scaled it up to the size of the earth, it's highest peak would be 12 feet higher than it's lowest point.
I'm sure the technology for this thing has improved a lot in 20 years.
Sounds to me like your original assertion:
I assert that a parsed XML tree really doesn't buy you that much. You must still walk your structure manually. Who does the semantic validation? How many XML instances in the wild use a doctype declaration? How many adhere to a DTD? Almost none that I've seen. They are ad-hoc constructions used to store data. The data representation format has value, but claiming the parser in such situations adds significant value is a silly argument. You must still do a lot of semantic validation as your code walks the data structures associated with the parsed instance. Even in instances that adhere to a DTD, if the underlying data is at all complex you'll have code that follows very closely what the DTD states....why can follow what in what contexts. Wonderful. But shouldn't all data in the system be defined in one place? Isn't that the whole rationale for the DRY principle? Why is it okay to duplicate it in this context?
According to your original argument, you like XML because it frees you from certain drudgeries. I say that it's great you're so impressed. Here is another tool that can free you from so much more. Give it a shot. You may discover ways to break chains you don't even know are there.
I claimed XML is just a data representation. You claimed that XML gave you so much more than a data representation. If you do genuinely believe that, and like XML because it is a tool that offers you certain benefits, then it would seem logical to find the best tool to accomplish the task.
I simply point out that other tools that are even simpler than manipulating XML parse trees and have additional benefits that you might like.
Expand your toolkit. You may not like it. But at least you'll know the tool is there and what it can do.
At least you'll know.
Why would you want that? You advocated for it. You said:
I simply point out that with sexp, here is your parsed data
Even better, here is you performing the desired operations on your parse tree:
Yes, it's just that easy. If that doesn't fulfill your requirement, why did you advocate for it?
Now, to make you feel a little more safe, as little or as much done during processing as you require....including nothing, if you're worried about your database issue. The data/code is inert until you try to execute it. That shouldn't be hard to understand...you do exactly the same thing (but with a lot more code) when you do it with XML.
I know it's a little scarey and seems a little spacey. All I can do is tell you that everything will be okay, and it will be an eye opener.
You're right. Simple examples don't do it justice and your arguments don't indicate that you're really not interested in learning. But if you would like to learn, ponder defining methods for +, -, /, *, log....(they're inbuilt in most languages...I won't provide you with an implementation).
Now, imagine a dialect where you define methods like html, body, head, etc that output html tags. Or a dialect that describes docbook. You define two sets of methods: one that downtranslates to html and one that translates it into LaTeX. Execute your code / data and you get the output you want.
If you don't see the utility, I'm not surprised. I understand. I've heard it said that most people don't really don't understand the power until they've done it for a couple of years. But once you do....they'll never go back.
If you are really interested in learning and not just saying "I don't get it", I recommend you pick up a copy of SICP - Structured Interpretation of Computer Languages. It's the first year MIT computer textbook. I have a B.Sc and an M.Sc. in Computer Science and 10 years in the industry since then...and I learned a lot going through the textbook about a year ago. Peter Norvig (Google's Director of Research) points out that SICP has an unusual Amazon rating distribution. It's double-humped: a large number of 0's and a large number of 5's with nto a lot in between. The speculation it comes down to people who get it, and people who don't. It's worth it if you get it...the names that seem to get it and advocate it are titans of computers and computer science.
I find it interesting that the people that are closest to XML are usually the people that are most vocal about the limitations and misconceptions of it, and talk most fervently about the benefits of things like sexps. The company I worked for had a precursor to XML that preceded it by about 7 or 8 years (before my time). We had Tim Bray as a founder. We purchased Microstar (yes, that one). I've worked with ex-Omnimark people. I can't explain why, but the people that are closer to working with XML...not at a high level, but at a low level seem to drift toward sexps as they go...
Just some observations...
What if you came up with an XML DTD that could represent a Java program structurally? What if you then wrote a Java program to manipulate those XML data files? Then what if you wrote that program in your new XML-Java language?
The program is the code. The code is the program.
Now generalize the concept. For any XML data file, what if you could enhance your language so that the XML elements actually corresponded to calls (subroutine, methods, jumps, whatever)?
The technical information is elsewhere. The movie trailer shouldn't tell you how a movie ends....it should encourage you to go see the movie.
For more trailers, I'd recommend many of the essays at http://www.paulgraham.com/
Your basic tenet seems to be, "Why reinvent the wheel."
/ 9a30c508201627ee
Okay, why reinvent the wheel? S-Expressions have been around since the 60's. They are far simpler to understand and use than XML. They show the equivalence of data and code (von Neumann, anyone?) when considered in the context of Lisp. They are more economical than XML. In fact, it's hard to find a way in which they are not superior.
But this doesn't get us any closer to the issue you don't seem to grasp: XML is a data representation. The underlying problems still exist. What does the data mean? You've added a turtle between you and the problem. That's the XML parser. The XML parser really does very little for you. Now you walk a parse tree. It's a lot of effort for ver little payoff. To rephrase: It's not a silver bullet. Consider the S-Expression alternative in Lisp. Make methods out of portions of the code. But S-Expressions aren't a silver bullet either.
For more on this, there is a wonderful description by Erik Naggum that is worthy of serious consideration:
http://groups.google.com/group/comp.lang.lisp/msg
Brad
XML works? Huh?
XML is a data representation. It works? How does it work? By representing data?
What else could work? S-Expressions? SGML? ASN.1? Flat text file?
The data representation isn't solving the problem.
XML, Extreme Programming, technique / technology of the week all are trying to do the same thing: help us manage complexity. Fred Brooks had a lot to say there. My favorite quote from the 'No Silver Bullet' essay:
My wife would like to understand.
My wife is just one of several I'd like to talk to about it. They're mostly other non-technical people, although a couple may have engineering or physics backgrounds.
Hopefully, your spirits have been raised. Now soar...
Thanks. This is the first response I've seen that is at least along the lines of the response I was hoping to get. My problem with these sorts of explanations, is it still doesn't capture the complexity.
When you're writing code that you've never seen anyone do before. Doing things across multiple languages, building infrastructure. But because you've never seen anything like this, and certainly never looked at the code for anything similar, how do you explain why your time estimates can be so off?
Alternatively, why does the industry have so much difficulty with deadlines? What makes development complexity defy good planning? Are we really an entire industry of bad planners? Not all software projects take longer than expected to develop, but those are either relatively simple or relatively straightforward. When software becomes complex and / or more researchy, it appears the complexity overtakes our ability to propertly estimate.
Why?
The best example I had (especially for the more R&D-y projects) was this: you're given a vague drawing of a scene. It's a relatively tight photograph. You think the scene is in L.A. (or some other sufficiently large city). Go find the photograph. All you have is a vague out-of-focus sense of what it is you're looking for.
Now some people might complain that what I'm describing is a poorly designed system or poorly described requirements. That may be partially true, and that may be the case for the more straight-forward projects. But when you're doing something relatively unique, all you have is a known destination (an in-focus picture), not the actual location (where the photo was taken).
I studied at MGU (Moscow State University) for a little while\
As a geek that moved to Moscow recently...were you ever able to find a bookstore that sold computer books in English?
Please!?
Allow me to rephrase:
Well...duh....
Takes one to know one.
Swish!
-- Homer Simpson and his brain
As can Microsoft coder bytes...
Ajax is a floor cleaning product. AJAX is an acronym standing for something different. The fact that the two have a similar name is irrelevent. Thinking differently means you should probably go for a CAT scan (no, not "cat scan") or perhaps a PET scan (no, not "pet scan"). Perhaps you should go stand on a soap box in front of your local city hall with a bull horn and expound the virtues of a non-acronymic world.
Give me a break.
You say nobody cares that it is AJAX, but they care that it works well and does what they want. If no one cares about the technology behind a good user experience, there will be no good user experience.
Technology, by and large, is an iterative improvement upon previous technology. Failure to recognize this means your genes should probably have been relegated to the non-tool using part of the animal kingdom.
Grow up.
I didn't dispute that the Canadian population is compacted along the US border. I simply said that broadband access is available, even in areas of Canada that are physically remote (when compared to the US) and, in the eyes of their business community at least, unworthy of provision of service. There were stories on Slashdot in the last 6 months talking about how small towns (50,000+ people) were having trouble getting broadband access in the town. Check it out.
The Pacific Ocean issue is a red herring, because the population of people living in the Pacific Ocean is currently low, lower than even that of Canada's Northern Territories (which I admitted don't have good service for the most part).
Then why can my brother, who lives almost 8 hours north of the US border, 1.5 hours away from the nearest "city" (city of 5,000 people) in a farming/logging town of less than 1,000 people can get broadband access, and how all these centres in the US cannot? Hell, the largest city in our province is about 200,000 people, and that's about 3.5 hours away!
My mother, who lives on a farm several miles outside that town cannot currently get broadband, but it's supposed to be available soon.
You're right, the vast majority of the Canadian populace is concentrated along the US border, but that by no means implies that broadband isn't available in a very high percentage of the country. There are very remote areas that don't have good access (ie, the territories), but the country is pretty well covered considering the population density.
How about this:
- Nearest city pop > 1,000,000: ~ 1,900 kms
- Nearest city pop > 500,000: ~ 800 kms
- Nearest city pop > 250,000: ~300 kms
- Nearest city pop > 25,000: ~200 kms
- Nearest city pop > 5,000: ~120 kms
- Your population: ~900 people
Is that rural enough? It's the town I grew up in. It's in Saskatchewan.Yup, broadband available.
Compare that with places in the US that are complaining they can't get broadband because they only have a few hundred thousand people. C'mon. Really.
Now, I'll admit that my parents who live on a farm several miles from town (and a half mile from a forest that you could walk through and get to the freakin' north pole only crossing a couple roads) can't get broadband. Yet. But they could if they were a half mile closer to town.
Yes, Canada is highly concentrated along the US border. But broadband is still available.
Perhaps you live in Alberta. It's more like the US. That might explain your lack of service availability.
Sounds like talking (short range) or yelling (mid-range) to me...
*sigh* When will this all end?
Or perhaps he meant "commoner,"....
Unfortunately, they did not do so.
Further, the vast majority of support for F/OSS is free. Both sought from free sources and offered freely. Therefore, their unqualified remarks regarding demand were misguided, to say the least.
Exactly....I made the same point when responding to someone earlier. Making a project FOSS software removes a barrier to entry in the support arena. Then, whether that support is offered freely or on a fee-for-service basis is an orthogonal issue.
Read the original slashbox. They stated that F/OSS projects are assured of continued support. By their very nature. Because they are F/OSS.
I have no problems with the idea that VB would have longer support if it were F/OSS. I simply want to point out that F/OSS zealotry is counter-productive when used as propaganda...
Can anyone explain to me how a F/OSS project implies assurances of continued support while there is demand for said support?
- Also, what is the best way to rate productivity in an OS?"
Personally, I like to use Kilo-porns per hour...The demo showed something like an article or a financial statement. There was a dot near the end of a sentence, and when you zoomed in, it was a spreadsheet with the financials. It was totally black and white (monochrome black and green, actually), but it looked really nifty. Everything pixelated like hell, but with some of the scalable interface components that Apple and Microsoft and probably others are working on, you could perhaps even do away with the pixelation.
I also found a website for Pad++.
From the SIGGraph article:
-
We believe that navigation in information spaces is best supported by
tapping into our natural spatial and geographic ways of thinking. To
this end, we are developing a new computer interface model called
Pad.
And so the article continues. Citeseer reference to the article can be found here.The ongoing Pad project uses a spatial metaphor for computer interface design. It provides an intuitive base for the support of such applications as electronic marketplaces, information services, and on-line collaboration. Pad is an infinite two-dimensional information plane that is shared among users, much as a network file system is shared. Objects are organized geographically; every object occupies a well defined region on the Pad surface.
For navigation, Pad uses "portals" - magnifying glasses that can peer into and roam over different parts of this single infinite shared desktop; links to specific items are established and broken continually as the portal's view changes. Portals can recursively look onto other portals. This paradigm enables the sort of peripheral activity generally found in real phy...