Slashdot Mirror

The project was originally called Project X, then later renamed HotSauce.

More further info & screen shots, go here:
http://mappa.mundi.net/maps/maps_018/

"Photographs, pictorial and diagrammatic illustrations, computer graphics, and animations are now an essential aspect of communicating research findings. These new avenues prompt discussion of different techniques, and encourage innovative approaches to visual communication. This competition was created to reward these new techniques and ways of communicating."

"In the ancient Greek arts of rhetoric, memory was a science. The science has an origin in what is surely myth. The poet Simonides of Ceos was hired by the noble Scopas to attend a formal banquet as a paid performer, singing a poem of praise of his host. As was the custom, Simonides began by first praising a pair of gods. After the performance, Scopas informed the poet that he would only get half of the agreed-upon fee, the other half he should get from the gods who had stolen the limelight.

"At that point, a messenger came in and told Simonides that a couple of athletic men on horseback were outside waiting for him. Simonides went outside, but nobody was there. But, while he was outside, the gods destroyed the banquet hall to teach Scopas a few lessons about respect. (The lessons being pay the poet; don't mess with the gods; and, memory palaces are a gift from above.)

"The banquet hall was so badly destroyed that none of the diners could be recognized. Simonides was able to remember the exact location of every guest at the banquet, using the principles of the Method of Loci, the science of memory. Later, Cicero (106-43 B.C.) wrote a few pages on the science in his classic work, De Oratore. [See De Oratore, II. lxxxvi. 350- 353]. The definitive treatment in Greek literature, however, is the work of an unknown author previously attributed to Cicero in the classic work Ad Herennium.

"The principles of the science are fairly simple, at least using our modern hindsight. A person who wished to memorize a large work, say an address after dinner or the closing argument of a legal proceeding, would begin by constructing a memory palace. While novices constructed a palace by going to a real one and memorizing the rooms, the memory palace could just as easily be any structure that can be imagined."

Source: Mappa Mundi

Here (for free)

Here too (for free)

This one too (for free)

This one also (free)

And don't forget this classic ($30 poster)

-T

Dude.. if you want asynchronous, bidirectional communications, just use sockets like you do now. Nothing very hard about that is there?

Soap is two things; a messaging system and a data representation method. It isn't a terribly efficient one of either, but it's effective at both. (You could, however, if for some wierd reason you wanted to, *use* a soap data representation to send a data object over an ordianary socket; the data encapsulisation and messaging mechanism are seperable.)

As far as the messaging system goes, though, it's a messaging system. not a full communications package; a simple messaging system. if your problem isn't well suited to simple mmessage passing, then you shouldn't use SOAP message passing. Use something else.

web services aren't "robbing" you of anything; they're a least common denominator appropriate for *some* things. If you need something more than what they can handle, just don't use them. Or use them in tandem with something more complex.

If you are forseeing a future in which you are forced to interface with other machines over SOAP to perform tasks which SOAP is totally unsuited for, and you have to bend over backwards to get "compatibility" with these machines-- well, that may well happen. Stupid people probably will use SOAP for totally inappropriate purposes. If you ever have to deal with that situation, I'm sorry.

However, that isn't SOAP's fault; it will be the fault of the people who decided to implement the inappropriate protocol over SOAP, and they are the ones you should take the problem up with (once it arises).

Stupid people can design bad protocols *now*. Stupid people do design bad protocols *now*. SOAP isn't going to design bad protocols for them; it just offers a often-inappropriate alternative.

SOAP could be better; what you suggest (a bidirectional whatever) would be really neat. But i doubt it would get as popular as SOAP, becuase it's more complicated. SOAP is popular *because* it's simple.

I suggest you try BXXP. I am not sure, but it sounds like it is EXACTLY what you want. It has failed to catch on where SOAP has caught on because it is more complicated. If i am incorrect in this i apologize.

By the way, you still have not attempted to explain in any way why you dislike unicode. you also have not attempted to offer any *alternatives* to unicode. Honestly, tell us, i am curious.

Don't forget Mappa.mundi, they've been selecting maps and running features on them for a long while. A good selection to choose from.

If you want the online version of this book, visit cybergeography.org or join the mailing list. Also check out mappa.mundi.net for well written and researched articles on related topics. Martin Dodge, author of this book, contributes monthly columns about cyberspace maps.

Another interestring web site about that topic is mappa mundi.

Mappa Mundi, a good webzine that often discussed these types of visualization issues before it ceased production, ran an article on Tim Bray's Hyperlink Totems, referring to an early mapping-the-web project of his.

That was 1995. He's been doing this a while!
----

Actually, content was the whole point behind the protocol. We were trying to solve a class of problems, all driven by content requirements. Examples are the SEC's EDGAR database, a variety of other "deep wells", and a class of problems ranging from mapping network topology to creating personalized "maps" (views) of the Internet. See here for more on the philosophy behind the content requirements.

The protocol emerged from long discussions about how to solve these content problems. We tried as hard as possible to reuse existing protocol infrastructure, but quickly found that there were no protocols that handled the metadata problems we were trying to attack.

The (IMHO) brilliant thing Marshall did was to build two levels into the solution. BXXP is the general-purpose framework that was used for the Simple Exchange Profile application we were going for in the first place. The nice thing was that BXXP works for a broad range of other applications, such as asynchronous messaging.

The bottom line is why reinvent the wheel more than once?

Carl

Actually, content was the whole point behind the protocol. We were trying to solve a class of problems, all driven by content requirements. Examples are the SEC's EDGAR database, a variety of other "deep wells", and a class of problems ranging from mapping network topology to creating personalized "maps" (views) of the Internet. See here for more on the philosophy behind the content requirements.

The protocol emerged from long discussions about how to solve these content problems. We tried as hard as possible to reuse existing protocol infrastructure, but quickly found that there were no protocols that handled the metadata problems we were trying to attack.

The (IMHO) brilliant thing Marshall did was to build two levels into the solution. BXXP is the general-purpose framework that was used for the Simple Exchange Profile application we were going for in the first place. The nice thing was that BXXP works for a broad range of other applications, such as asynchronous messaging.

The bottom line is why reinvent the wheel more than once?

Carl

Actually, content was the whole point behind the protocol. We were trying to solve a class of problems, all driven by content requirements. Examples are the SEC's EDGAR database, a variety of other "deep wells", and a class of problems ranging from mapping network topology to creating personalized "maps" (views) of the Internet. See here for more on the philosophy behind the content requirements.

The protocol emerged from long discussions about how to solve these content problems. We tried as hard as possible to reuse existing protocol infrastructure, but quickly found that there were no protocols that handled the metadata problems we were trying to attack.

The (IMHO) brilliant thing Marshall did was to build two levels into the solution. BXXP is the general-purpose framework that was used for the Simple Exchange Profile application we were going for in the first place. The nice thing was that BXXP works for a broad range of other applications, such as asynchronous messaging.

The bottom line is why reinvent the wheel more than once?

Carl

He calls it a framework, not a protocol:

when someone else needs an application protocol that requires connection-oriented, asynchronous request-response interactions, they can start with BXXP.