Dynamic Markup with MOO
4 Jul 96 - 16 Nov 98 - Larry "Wingnut" Wendlandt
Copyright (c) 1996 WingyWorld Productions
NO COMMERCIAL USE WITHOUT AUTHORIZATION!
This is a information file contoured toward explaining the use of dynamic markup in the SenseMedia moos, such as Chiba or Voodo. Statements made within may not be totally truthful, but are used for ease of comprehension. Here we go!!!
Ted Nelson, who plays with things like Project Xanadu, has excellent ideas that are related to dynamic markup. I advise you to read as much as you can about this man and his ideas.
DYNAMIC MARKUP... can be summed-up as the act of a computer making an encoded document "on-the-fly"... often done with a program and often compiled from many sources. It is the opposite of STATIC MARKUP. When you STATIC MARKUP an average web page, you go into your trusty text editor or web page maker, eventually SAVING a document to disk, and THAT is your web page. It is a bunch of HyperText Markup Language (HTML) commands that look like jibberish when viewed in a text editor/displayer, but they look MUCH better when 'rendered' with a HTML browser. Even though this HTML stuff looks ugly in an un-rendered web page, HTML commands are NOT too complicated. They usually start with a < , then they have an ALMOST-easy-to-understand command, then a bit of text or technical stuff, and then a closing >. If you HAD to actually type one... it wouldn't be TOO terribly difficult. You could do it. But WHAT IF... a computer could ask you a bunch of questions like...
What's your name?
Do you want a background picture for your web page?
Is it a LITTLE picture that I should 'tile' all over the background?
What's the name of that picture file?
Do you want a background COLOR instead?
What color?
Do you want a picture at the top?
Do you want it centered?
How many pixels wide should it be?
How many pixels high should it be?
What's the path and name of the picture?
Right below that, do you want some text?
What text?
What font type and size?
What color lettering?
Should I center that?
Want some little bullet pictures on each side of that?
Should I make this text into a link?
Where should the link POINT to?
Want a blank line at this point?
How about a horizontal divider line?
What kind of horizontal line?
What color should IT be?
Would you like to use a TABLE command here?
How about a FRAME command?
Do you want to embed a VRML (3d rotate-able picture) here?
Do you want to embed a sound effect or audio link here?
What's the name of the audio file?
What do you have in your pockets?
In what ways are you similar to your parents?
(and LOTS more)
You can see that there would be LOTS of questions, because web browsers have LOTS of things they can do to make your web page look cool. But eventually, once this computer had gathered all the info it needed from you, it could MAKE (automatically)... a web page for you. It could use a SPECIAL PROGRAM to put all of your information in the right places amongst the HTML ugliness, and BUILD the web page. It could add (append) line after line of HTML, mixed with the answers to those questions... to a text file, ending when it ran out of question data. And if the computer remembers your question answers correctly, and the DATA you entered was correct, and if it has a SPECIAL PROGRAM that properly 'mixes' question answer data with html... the computer should be able to hand you a beautiful web page. In fact, if this computer SAVED all the DATA that YOU entered... into a DATABASE, then, if you accidently deleted your web page, the computer could make a replacement... WITHOUT having to ask you all of those questions again. That'd be good, right? Of course!
From this point on... I'm going to use Ted Nelson's term "transclusion" often, and I'm essentially using it somewhat incorrectly. See the Ted Nelson and Project Xanadu links at the top of this document... to get the full story.
The action(s) that a computer program takes to MAKE its pre-stored data into YOUR web page... is called TRANSCLUSION. The program section that RUNS in order to do the transclusion-to-html... is called a TRANCLUSION DESCRIPTOR... or simply... a TD. In our example here, this computer would be 'transcluding' from question DATA... into standard HTML. For ease of terminology, the answers to ALL of those questions you replied to... will be called a DATASET. ALL the answers to those questions, are held in YOUR dataset. A 'dataset' can contain ONE or MANY big or little chunks of data (each chunk is sometimes called a PROPERTY or FIELD), often with MARKERS between each chunk to keep them separated from each other. A DATASET is sometimes called a RECORD or an OBJECT. The term 'dataset' is a rubbery term. Often, datasets contain other datasets which each contain datasets full of datasets. But always, somewhere in the chain, there is actual data... or let's hope so! Even the word DATASET, is a dataset containing a set of data (letters) used to make the word DATASET. Crazy, eh? Back to our story...
Naturally, there are many 'settings' inside the computer's transclusion descriptor program (TD) that DESCRIBE how to take DATA from its database (from your dataset) and mix it within HTML commands correctly. Computers can't think on their own, and there are lots of HTML commands, so the transclusion program MUST BE TAUGHT how to correctly use them, so it can insert pieces of YOUR dataset (from its database) exactly where it is suppose to. Teaching a computer to make HTML from DATA... is done by the programmer when she/he writes the transclusion program. TD's can be programmed to convert/mark-up/make/transclude OTHER types of documents as well. If someone wanted to build a transclusion descriptor for a postscript document, word processor document, virtual reality file, ascii art, or whatever... the SAME basic methods COULD be used to make one of those type documents just as easily. The TD would take pieces of data, wrap them in special junk, and write that stuff to a text file. Give the computer the right answers (the right DATASET)... and out pops a special document. Interesting?
If you think about it, the QUESTION ASKING program, and the transclusion descriptor... are two different programs. The question-asking thing is a user INPUT program, because it gathers data from YOU. It DOES do outputting also, because it creates a DATASET to store in its database. Conversely, the TD is a user OUTPUT program, because it outputs web pages. Is DOES do inputting also, because it gathers data from your stored dataset... which is maybe in RAM memory or maybe on its disk drive.
In our example, we are using a STANDARD HTML TD. The programmer essentially teaches the TD how to smoosh YOUR data... and HTML commands... together. Once programmed, AND if HTML commands don't change too drastically, the TD could make web pages FOREVER, one after another. As long as it has a stored dataset to transclude, its an automatic web page machine! Cool, eh?
So now, we have a computer, remembering the DATA that we answered the questions with... and our web page can be re-made anytime we want it... or constantly. If some buddy of yours answered all those questions as well, the SAME transclusion descriptor program (td) could take HER/HIS stored data, and make THEM a web page too. ONE machine, with any number of DATASETS, can become ANYONE'S web page machine!
Let's take a moment to talk MORE about DATASETS. In our example, the programmer told the computer to ask you questions in a SPECIAL ORDER. The TD remembers which order it asked you the questions in... and that way, it knew later which data chunks to mix with which html commands. Question asking requires MUCH data error checking, so that IF, for example, the computer asked you for your NAME... and you entered the HTTP path to some picture... then the question would be re-asked, because the computer saw that your name didn't look AT ALL like a name. This error checking is done so that the computer can be VERY sure that it has the CORRECT data in the CORRECT ORDER. When all of the questions were answered to its liking, it might store the dataset in a method like this...
<answer1><divider><answer2><divider><answer3><divider><answer4> etc.
If you go back up and look at the ORDER of the example questions I listed, and used some demo answers, and lets say that the DIVIDER is a semicolon... then the actual dataset order (sometimes called the dataset's STRUCTURE)... might look like this...
Jimmy;yes;no;jimmy's background.gif;no;no;none;yes;yes;400;200
The TD remembers what order the dataset structure is in, so... when it later READS these chunks of data, it knows EXACTLY WHICH ONE it is getting, and knows which HTML command to mix with it. You can now see why the translusion descriptor program... must know EXACTLY... how the question-asking program stores your dataset. Now we move on.
I really must quickly explain that asking questions TO a person, and gathering data FROM those questions, and storing those answers (a dataset) to a disk drive... is really easy for almost ANY computer. Yes, you WOULD need a programming language installed on it, so that you could write the TD program (data/html mixer)... but a simple language would work fine. You WOULD need some RAM or disk space to SAVE the questions and their answers... pretty easily done. And preferably, this easily-programmable database computer would need to be somehow connected to the internet. (Rumor has it... EVERYTHING is better when hooked to the internet!)
HEY! Isn't a MOO essentially a database? Most moos are ALREADY hooked to the internet! Oh gosh! And moos have programming languages already built in... for writing a transcluder program with! Moos have pockets to store our answer datasets in. The transcluder program can go look into those pockets (properties) quite easily! Hey... this might just WORK!
We'll let the moo computer store the DATASETS used to make the web pages, (and it will store the TD program, of course)... and you, store the web page. Hey wait a minute here... THAT is a bit WASTEFUL!!! ANYTIME we store datasets, we should TRY to do it in as few places as possible. YOU... are storing your data in the form of a web page, AND... the moo computer is storing your data in its database. Back-up copies are fine and all, but the moo database ALREADY has a backup copy of itself (they usually do). So... what COULD we get rid of?
Your web page!
WHAT? GET RID OF MY WEB PAGE? How will people ever get to see my cool web page if we don't save it somewhere?
Well... the information that is used to MAKE your web page (the DATASET made from your answers) IS SAVED... and the transcluder program itself (the TD) IS SAVED. Hhhmmm...
Check this out. WHAT IF... once we had programmed our HTML TD on the moo... and once we had made our web page dataset (by answering all the questions)... we CONNECTED the MOO computer to the World Wide Web?
NASA... we HAVE a problem.
HTML (web page jibberish) is new in popularity, and its Hyper-Text Transfer Protocol (http) doesn't do too well at chatting with other internet folk (mooing). Why, you ask?
HTTP 'servers' are designed to listen, then connect to somewhere, SERVE an HTML document (web page), and then disconnect. HTTP servers (often called WEB SERVERS) listen for something ASKING for a document (taking a link), then sends it a COPY of the document, then goes back to listening. They don't stay connected very long at all. The requester can read, print, store, discard, or do nearly anything else with the document after that, because the document is THERE... in the requester's computer. Meantime... the HTTP server (web server) has gone back to listening. In most cases, once the web server delivers the web page, its job is DONE... and YOU are staring at a web page! That web page is in YOUR computer, because the web server sent you an exact copy of a HTML file that is usually stored on its hard drive. It all happens due to 3 things. First, you requested a document from a WEB server. Second, the document had HTML inside it. Third, your web browser software understands what to do with that HTML. Now moo chatting... really doesn't fit for ANY of those 3 things. First, we chat on a moo server, not a web server. Second, we do not have HTML commands mixed in with our chat lines. Third, we don't use a web browser to chat on a moo with. We, more often, use a telnet client.
The software that most moos run... is NOT web server software. Moo servers couldn't deliver a HTML document via HTTP protocol if their chips depended on it! They are ALREADY busy running the moo program and passing love notes amongst the chatty users. They are going to be busier once they have to transclude HTML documents... so they have no time, or built-in abilities to LISTEN to the web, or deliver stuff. So...
WE NEED ANOTHER COMPUTER! A HELPER COMPUTER! We need a computer that is designed to listen to the World Wide Web, and deliver HTML for us. We need... a web server... located in the general vicinity (electrically speaking) as the moo computer. We'll call our new web server... WEBSTER! And since we're giving things names... let's call the MOO computer... MOOMAMA! Remember these names. I will refer to them often in the following sections.
NOTE: A 'web server' is actually a PROGRAM that monitors a special port on a computer, watching webland for web page requests. A 'moo server' is basically the same exact thing, only it monitors different ports, watching for a different type of connect request... telnet. SO... yes, you guessed it! Web server software AND moo server software CAN be run simultaneously on the same multi-tasking computer. We may see future moo server software releases be more prepared to talk to web server software, and vice versa. Someday, we may see both released with each other built-in.
For ease, I will continue to treat the moo server (Moomama) and the web server (Webster) as two separate entities. (I don't mix my corn and my mashed potatoes together either.)
A Bit About Webster...
Webster's normal job is to listen to the World Wide Web, and if he hears his name mentioned, he takes notice. Websters are designed to deliver STATIC (pre-made and stored on hard drive) web pages to other computers (yours) that request them correctly. He usually has LOTS of children (static web pages) on his hard drive, and each one is alive and well, on each's own special PATH. For example, at SenseMedia... he listens for someone to yell HTTP://SENSEMEDIA.NET/. If he hears that, he wakes up. He NOW knows that SOMEONE wants to view one of his children's static web pages... but he doesn't know which one. So next, someone yells a PATH name... like SNOW_WEB_PAGES/. Webster NOW knows that the requested child is SUPPOSEDLY in the SNOW_WEB_PAGES directory path. He continues listening... and hears... PEOPLE/. Now he knows the child is supposedly in the SNOW_WEB_PAGES/PEOPLE directory of his hard drive. Then, he hears Jimmy.html!!! Ah... now he knows that the REQUESTER wants a copy of JIMMY's web page, which is SUPPOSED to be located here (sensemedia.net), in the SNOW_WEB_PAGES directory, in the PEOPLE directory, named Jimmy.html... and he sends a copy of THAT static document IF he finds it. The PATH to get to Jimmy.html works almost exactly the same as PATHS in hard disk directories. That's because (here in the old days) web servers store their web pages on hard drives, in directories that have PATHS, and file TYPES that are added at the end of the name... like Jimmy.html. Webster ACTUALLY listens for a STRING of yells all in one big earful (called a URL - Uniform Resource Locator). If someone out there in webland wanted to see a copy of Jimmy's web page, they would REQUEST...
HTTP://SENSEMEDIA.NET/SNOW_WEB_PAGES/PEOPLE/JIMMY.html
The Webster knows EXACTLY where to look for this pre-made and pre-stored web page, and goes there immediately to see if the document can be found. If its NOT there, then the requester has taken an incorrect link, or typed the incorrect path or document name, or... Jimmy.html has left that location. The Webster (web server) issues an 'ERROR 404 - I CAN'T FIND THAT DARNED THING THAT YOU ASKED FOR' to whomever/whatever asked to look at Jimmy.html. So Webster listens for HTTP paths and document names (URL's), and if they are stored ON him, he will send a copy to the requester. If he can't find it on his hard drive, he reports an error to the requester. Remember though... that he HAS to hear HIS name FIRST! If he hears something OTHER than SENSEMEDIA.NET in the beginning... then he will ignore the yell completely. He listens for HIS name first, then a PATH to a document, and then the last thing HAS TO BE a document NAME.
As we mentioned earlier, Websters and Moomamas are designed for two DIFFERENT purposes. Websters are designed to keep track of their children via paths and names, and deliver copies of them to folks who ask for them on the world wide web. Moomamas ALSO take care of their children via paths and names, but are built to deliver copies of her children in STANDARD TEXT FORM via TELNET ports. They both do the same thing, but send the results via different transmission methods. What if... we could teach Moomama to help Webster send copies of Moomama's children via HTTP? Maybe we aren't quite ready for web-based chatting, but we sure could take text output from Moomama, add a bit of HTML to it, and send it somewhere on the web, couldn't we?
Teaching Moomama to Help Webster.
There are many types of moos, muds, mushes, etc out there in telnet land. Most of them use telnet server software, and have various methods of storing data. When you create a room, or an object, or a web page, and describe it, and paint it, and put other objects in it... the moo program REMEMBERS everything you've done. Some moo server programs store this 'remembered data' on disk, others... in RAM memory. Moomamas listen to telnet land, and OPEN A PORT to anyone who yells her name. Once the port is open, the requester (moo user) can, of course, chat with another person who is connected to Moomama... because Moomamas don't deliver-and-run! Moomama's stay connected to whatever computer is hooked to one of her ports. Similar to Webster, users can send requests for copies (actually, PORTIONS of copies) of Moomama's children. A good example is when you LOOK at a room in a moo. Moomama knows that you want to see what the room LOOKS like, so she retrieves data about how that room looks, and delivers it, in TEXT, to the requester's telnet screen. Often, she then sends the CONTENTS of the room, and also its EXITS and ENTRANCES... as you would indeed see these things if you LOOKed at a room. But moo rooms can contain lots of DETAILS other than just its LOOK. Exits and entrances can be locked, things can be hidden, there may be sounds in the room, or smells, or certain objects that can or can't be TAKEN or DROPPED... etc. By typing LOOK, we have asked Moomama to send us SOME of the data about THIS child, but only what can be SEEN. One could say that Moomama is using a TELNET LOOK TRANSCLUSION DESCRIPTOR!!! Likewise, if we typed SMELL, Moomama would deliver back whatever can be smelled. A TELNET SMELL TD! She delivers PORTIONS of the total data she holds on a child (certain properties)... in an easy-to-read text format. She actually TRANSCLUDES a pretty page of text for you to read after you typed LOOK. She puts the name of the child at the top of your screen, then carefully wordwraps the description of the child onto your screen (what the room LOOKed like). Then she retrieved the contents of the room by checking another of the childs' pockets, and outputted THAT report to you all nice and pretty. Then she looked in another pocket (property) on the child (object), and found out what exits and entrances there were, and you got THAT sent to your screen. Then she cracked a beer and waited for you to type something wierd like SMELL. Yup... Moomama has been transcludin' for YEARS... and she didn't even realize it! She takes various chunks of data from selected properties of a moo object, and moo wizards and moo programmers wrote TD's YEARS AGO that told Moomama how to correctly and neatly output a telnet LOOK request to a moo user.
Moos usually let you create objects of all sorts. Each... is a child or grandchild of Moomama. She REMEMBERS where it is, who made it, who its parent(s) are, if it can be taken, dropped, looked at, smelled, tasted, hit, thrown, broken... etc etc etc! She stores EACH little bit of information in separate PROPERTIES (pockets) on the child of hers (object) that YOU created. Each PROPERTY has a name or a number so that she can find the pocket when she needs to. There could be a pocket on one of her children or grandchildren named .LOOK or maybe .SMELL. If Moomama can't find the correctly-named pocket on the child, she MOST OFTEN searches the child's PARENT for a pocket with THAT name, and uses the data from there instead. On the SenseMedia moos, which run LambdaCore moo programs, you may choose to refer to Moomama's children/grandchildren as OBJECTS, and if you're preparing for the object-oriented decades ahead, you COULD call them INSTANCES. The pockets are called PROPERTIES and sometimes ATTRIBUTES. Properties on Moomama's objects aren't ALWAYS just used as pockets to store junk in. They also sometimes carry 'traits' or 'attributes' handed down from parents and grandparents, and very often... some from Moomama herself. Yes, attribute data DOES often look exactly like any other junk that's been put into a pocket... but what is important is whether the CHILD has set the attribute itself, or whether the attribute was set on an ancestor, and just handed-down to the child. Knowing WHO (which object) has 'set' (filled) an object's properties... is very important to a transclusion descriptor program. The child she is examining the pockets on... may be many levels of ancestry below herself, and each parent of an object cold have the ability to set a property. EVERY child has a parent. Most have MANY. Very few have Moomama as a parent. ALL have Moomama as a GRANDPARENT of some type. In fact, Moomama is ALWAYS EVERY OBJECTS GREATEST GRANDMAMA! Do you understand why? Good! This inheritence-based information will most likely change with SenseMedia's multi-inheritence "hyperarchical" database structure emergence. Hyperarchy is beyond the scope of this info-file.
Now... we know Moomama can check properties on her children (get into their pockets)... and we know Moomama has the ability to transclude stuff from her database into telnet text (take raw pocket lint from properties of any of her children and deliver it pretty to a telnet port). Moomama's transcluder uses a plain TEXT DESCRIPTOR to make pretty screens from children's properties (like the LOOK example above). Earlier, we talked about how a HTML TD program is used to make a web page, which is NOT telnet text. It is HTML, which is text with wierd stuff mixed in.
How it came to be...
This person who calls himself Rocker, who is SenseMedia's Archwizard, got busy trying to solder (electrically connect) a pipe from Webster to Moomama, so he could copy web pages from Moomama onto Webster's hard drive. He didn't have much time to write a TD on Moomama. Rumor has it that he and others TESTED theories by whipping up a basic HTML TD program that would gather the data that was brought back by Moomama doing a LOOK at an object... and turned it into HTML. Nothing too fancy, nothing too wonderful, but it worked. Once Rocker's soldering was complete... the web page could be moved (copied) from Moomama... to Webster's hard drive... so someone on the World Wide Web could browse it. Remember? Moomama is terribly-equipped for listening to the web. Meantime, a hard-working enchantress named Irradiate took over the HTML TD project, putting many hours into refining the HTML transclusion system. There were other smart people involved too, some from the now-extinct WorldMoo, but I'm not sure who they are.
There was still a problem...
Although these wizards had indeed taught Moomama how to make HTML documents for Webster to store on his hard drive, Webster DID NOT have enough room on his hard drive to store web pages for all 7954 of Moomama's children and grandchildren. Not even CLOSE! How were they going to solve THIS little dilema? And not only THAT... but if Rocker and Irradiate stored ALL those web pages, plus stored the DATASETS to make those web pages, plus stored the PROGRAM (TD) to make them, then THAT would AGAIN be wasteful. So what do we get rid of? Yup, the web pages. But wait now. If we aren't going to copy 7954 web pages to Webster's hard drive, what do we use Rocker's pipe for?
Someone said... "What if... when someone wanted to web-browse a moo object... we could tell Webster to wait a few seconds while Moomama transcluded an HTML document (web page) for the child, and when it was done being marked-up, hand it to Webster so he can deliver it via HTTP? Instead of using Rocker's Moomama-to-Webster pipe for transfering web pages to Webster's HARD DRIVE... we can just hand the web page to Webster for IMMEDIATE SENDING! We won't SAVE the document STATIC-wise (on a hard drive) whatsoever. Its made, then delivered, then discarded, then we party.
And the Gods were pleased, and the sun came out, and the flowers bloomed, and peace was once again restored in the minds of the wizards.
Webster now could listen to the web for HTTP requests for LOOKS, SMELLS, or any action from Moomama's children. Webster tells Moomama which child, and which ACTION. Someone on the web could ask Webster for a SMELL of Moomama's child #3591... possibly by using a path and name like HTTP://sensemedia.net/snow/3591/smell.html. Webster asks Moomama to transclude a web page with the data she gets from performing a SMELL command on child #3591. Moomama, who's been taught to transclude properties into HTML by Irradiate... MAKES a web page DYNAMICALLY (right now!) and hands it to Webster... who then delivers it to the requester via HTTP... and... it works... and the web page is NOT stored on a hard drive EVER!!! Each web page IS stored in Moomama's RAM memory, in a variable called R... just for a moment, and then she hands R to Webster, and erases R's contents from her memory.
So now... we have exactly ONE HALF of our 'HOOKING MOOMAMA to Webster' project done. Web browsers can now browse ANY of Moomama's children. Her object's web pages get made dynamically and are NOT STORED in web-page form. And YOU thought you needed to store your web page! Well guess what? Do you see how NOT storing static web pages for all moo objects... has kept Webster's hard disk fairly empty? That means you probably CAN use Webster's hard drive to store a static web page if you really wanted to. Or how about some pictures, or some sound files? Those are things that CAN'T be transcluded by Moomama... but their ADDRESSES (url's) CAN BE! All in all, the most efficient and easiest-to-update method of producing/maintaining HTML documents/mark-up is to let Moomama do it. You simply change a small section (the contents of a property/pocket) and your done. Moomama finds the change next time the web page is requested, and automatically transcludes a perfect web page. Do you see how... if the moo can build web pages, why not utilize its power to build YOUR web page. It ALREADY builds a web page (dynamically) for your room, your note, your avatar, and everything else you might moo-build.
Teaching Webster to Help Moomama
Now... to complete the project... SOMEONE needed to make EVERYTHING on the world wide web (including Webster's hard drive)... viewable from TELNET land. Either Moomama OR Webster would need to be taught how to transclude HTML from the web... into something that looked good to a telnet terminal. This meant that the transcluder would need to REMOVE all the HTML commands from the stuff inside of people's web pages, and output it to telnetters in a way that was pretty, and that looked AT LEAST SIMILAR to the way the author of the web page intended it to look. This was not going to be an easy task, and it has NOT yet been completely satisfactorily solved. Various moo clients are starting to make attempts to build-in web browsers, or monitor for incoming html and launch auxilliary browsers. There will be many changes to telnet clients involving html in the future. Keep in mind... that it does NOT take a web server (Webster) to request a HTML document from the web. So IF the html-to-text transcluder resided on MOOMAMA... then she would not use the pipe to Webster at all. And since Websters don't have programming languages on them to write TD's with, Moomama is the perfect choice. SenseMedia has started building limited transcluders and descriptors for this purpose, but everyone is limited because most telnet terminals cannot display graphics and fancy fonts like web browsers can. This will change. Some companies are producing web browsers that are also telnet terminals. Pueblo, from Chaco Communications Inc. is one such "browsing telnet" software package for your computer. It listens for incoming small pieces of SPECIAL html, and yet talks to Moomama as a standard telnet terminal. It also tries to understand STANDARD HTML, so you can view web pages from within the moo. Because it uses special html for laying-out its screens, it requires Moomama to have a special Pueblo-only transcluder and descriptor. Wizards at SenseMedia's Snow and Voodo have completed preliminary versions of these special Lambda-based Pueblo transcluders... the first EVER!
Someone stumbled along about this point and asked... "If Chaco makes a browser that looks like a telnet client, shouldn't Netscape do the same?" With Netscape's implementation of Java, Javascript, and frames... it became a possibility, and both Snow AND Voodo have Java-based transcluders that mark-up html and Javascript in a way that makes Netscape look like a fancy telnet terminal. Both moo's "Netscape-telnet-simulator" transcluders are in their preliminary stages, but do indeed work. That, in itself, is amazing, considering Netscape has wandered far away from the standard html specifications, making moo wizards do frequent descriptor updating and intense research. Pueblo is no Netscape, and Netscape is no Pueblo, yet they can work hand in hand with each other, each having merits and drawbacks.
To get to the grit of all this, it IS possible in SenseMedia moos... to store the DATA for ANY web page (not the html web page itself) in properties on moo objects. When someone asks to see your web page, the moo will MAKE it... WHEN ASKED FOR! Certain properties, such as .htext, can store actual pre-made HTML which is ADDED to whatever HTML the TD marked-up automatically. Actions can be used in other places to SUPERCEDE the transcluder's version of an object's web page COMPLETELY. This allows for 3 options for an object's webbing. First, you could choose to NOT do ANYTHING to the object's hproperties, and let the TD do all the work. Or, you could ADD some things onto/into the TD version of the web page... by setting CERTAIN hproperties, and not setting others. OR... you can almost COMPLETELY override the TD and make a complete web page for the object YOURSELF. Of course, in this case, you'd have to store YOUR html for that object SOMEWHERE, like in an .htext property... and that would cost quota. Also, you're NOT going to want to put a 385,000 byte jpeg picture in an objects property, but you CAN put a URL that POINTS to the location of where that picture is, and then the moo will EMBED the picture's address into your web page. After all, that's the way its done NORMALLY. You don't see a picture when you list the text (un-rendered) of a web page... you see an ADDRESS (URL)... usually in the form of <img src=(path_to_your_picture.jpg)>.
Building an HTML Transcluder!
How do I tell the moo to make a web page for me automatically? Well, currently, it is not the smoothest operation on the planet. Keep in mind that by working with dynamic html transclusion, you are 'riding the crest of the wave' sotospeak. Transclusion is BRAND NEW, and it is leading edge web technology. See, way back in the dark ages, when Irradiate, Rocker, and others.... built the early transcluders, they knew they were going to need some SPECIAL properties (pockets) on all of Moomama's children (moo objects). So, they busted-up the main parts of a standard web page into SECTIONS. Actually, those sections were already defined by the HTML standard. One of the first sections the wizards came across was <head>... which is an html tag marking the start of a documents' HEADER information. Within the <head> and </head> they found various html stuff, but mostly... they found the tag <title> and </title>... which has the title of the document between them. Irradiate knew that each object on Moomama indeed had a title. Moomama was ALREADY storing the title of each object in THAT objects pocket named .title... which was filled by the @create process of birth. So, Irradiate made a pocket on all of Moomama's objects called .htitle (which stands for html-title if you hadn't guessed). She wasn't exactly sure of what to put IN that property yet, or whether to make it a LIST-type property, or a STRING-type property... but she knew she'd need that pocket on everything. (It's not really as hard as it sounds. Keep in mind that ALL properties on Moomama's object #1, often called $root, get handed down to ALL CHILDREN of #1 automatically. They burn NO memory until something is put INTO them. And check THIS out... if Moomama goes to check a property on a child, and finds it empty, it goes and checks it's PARENTS' property with THAT SAME NAME. If IT is empty, it goes to IT'S parent, and then to IT'S parent, and eventually, it gets back to checking #1 for a property with THAT SAME NAME. And guess what. If no objects through that upward heirarchy had that property set, then Moomama uses the contents of THAT property on #1. So Irradiate really just makes an .htitle property on #1 ($root), and puts some temporary pocket lint in that property... but later, she will put MAGIC in there.)
There were 3, or 7, or 6, or 9, or... 5 other 'sections' of an average web page, Irradiate would soon postulate. But for the purposes of ease, lets stick with this .htitle property which she put on $root. Irradiate knew she was going to need a verb... YES, some moo code... placed on #1 or SOMEWHERE (maybe on a html transcluder object), that could grab the title of a moo object (stored by Moomama in object.name at @create time) and shove it inbetween a <title> and a </title> and then temporarily store that for a bit... while we catch our breath. So, she wrote one, called this:hhead... and since THIS was #1, it was #1:hhead. The name 'hhead' was used because <title> was a HTML command located WITHIN the <HEAD> section of web pages. Essentially, the :hhead verb got the requested child number from Webster (remember him?)... then went and looked in the childnumber.name property, plucked the title of the object from there, slapped <title> and </title> on the ends of it, and then stuck THAT in a variable (named R) for safe keeping. Just that easy, the #1:hhead verb was DONE! And if you looked at R, it might look like this...
<HTML> <== This is put on by a different verb. :hprefix?
<HEAD> <== This is probably added by :hhead
<title> A goofy moo object </title> <== :hhead added this!
</HEAD> <== Also probably added by :hhead
To remind you again, I may be wrong with the verb names used above. But all in all, SOME verb adds those HTML commands to R. Yes, there ARE other 'specialty' things within the HEADER of some web pages, but those things could be taken care of later. Almost EVERY static web page had a TITLE, so Irradiate KNEW she had met the 'minimum requirements' for junk found between <head> and </head>. After all, this was the FIRST EVER Lambda-driven HTML transcluder. Step one... get it to work! Tweek and featurate LATER!
The next SECTION of a standard web page... Irradiate found to be the BODY section. It was a section that contained most of the BIG, MEATY part of the web page. This section of a web page happens between the <body> and </body> markers. She found that an object's DESCRIPTION, which is stored in the object.description property on almost all moo objects, was the big, meaty part of an object. And please remember that Moomama keeps checking parents, and parents of parents, and parents of parents of parents, until she finds a .description property that ISN'T empty. Because of this PARENT SEARCHING tendency of Lambdacore object-oriented systems, Lambdacore manuals suggest that wizards set their #1.description to something like 'This object has no description'. Moo objects OFTEN get their .description set by players, but there is always a chance that an object is @created, but its owner forgets to @set the .description property. Irradiate put a property (pocket) on #1 called .hdescription, and @set it to 'This object has no webby description' or something like that. Soon... she would come up with an idea that would cause her to REMOVE the .hdescription property and never need it again.
Because of Lambda's 'parent-search' tendency... if a requested object had no .description for TELNET folks to see, Moomama would 'parent-search' until eventually getting back to #1 (unless stopped earlier by a set .description) and would output #1.description to the telnetters which was 'This object has no description' and that was PERFECT! Now it was Irradiate's turn at bat for her HTML transcluder. Again, she was going to need to write some moo program. This program would need to get the requested child number from Webster, then go look in child.hdescription, and if not set... go parent searching. BUT WAIT!!! Since users OFTEN set an object's .description, but knew not of the brand new .hdescription property, then maybe, instead of 'letting' Moomama do parent searches for .hdescription properties, which would probably eventually lead to using #1.hdescription, Irradiate decided to 'redirect' Moomama over to the child's .description property if a .hdescription could not be found. Now... parent searching could no longer EVER end up hitting #1.hdescription, because Irradiate TOLD Moomama, via her new verb... #1:hdescription, to CHANGE Moomama's search to .description IF .hdescription could not be found on a given object. After all, a DESCRIPTION of the object, in text, was what Irradiate really needed for her hdescription section of the transcluder, and many objects' .description held JUST THAT... the object's description in TEXT form (for the telnetters). AND... in fact... web browsers do a pretty good job with text themselves, so once Irradiate's new #1:hdescription verb got its hands on a good .description, it just slapped it right onto the end of R. Remember R? Now R contained an html title, and a text description. Sounds like the start of a good web page!!! And Irradiate totally eliminated the .hdescription property on ALL objects including $root, because she decided to have the $root:hdescription verb go look DIRECTLY at an object's .description... NOT its .hdescription... saving a property (good), and still enabling parent-search travelling 'up' the .description ancestry trail... all the way back to Moomama ($root/#1) if necessary. So, if an object had no .description, and its parent(s) had no .description, then Moomama would use #1.description, which is probably set to 'This object is in need of a description.'
To make the story a bit shorter... Irradiate went on to add CONTENTS transclusion for objects that could contain things, EXITS transclusion for rooms, 'awake and alert' testing for player objects, special processing for notes, and letters, and a few thousand other tweeks and repairs... until almost EVERY object in the moo... would transclude into a tolerable - looking web page. Moomama's html transcluder object grabs the object number from Webster, builds a web page for that object, and hands it back to Webster (thru Rocker's pipe) for delivery to the requester. It worked great! Until... Netscape wandered astray! Yup, Netscape wandered away from the 'highly-suggested method' of doing HTML commands, and they went and invented some of their own. Irradiate was FURIOUS! (Not really). But what she DID know, was that the new Netscape commands WERE indeed cool. And she also knows that Netscape is the LEADING browser builders on the planet. So NOW what?
The temptation to try some of these new Netscape commands eventually caught Irradiate in a state of weakness, and soon, Irradiate was 'mashing the mac'... working on a 'Netscape-enhanced' HTML transcluder object. She played with tables, and frames, and <BODY> arguments that would make Einstein ask for tutoring. She dug through the dumpsters behind Netscape company until she eventually figured out these new 'non-standard html' commands. Netscape made claims that weren't true... and things were true that Netscape hadn't claimed. New Netscape versions were downloaded very often... beta .25, .26, .26a! Finally, Irradiate was happy with the looks of her Netscape-enhanced transcluder. It made an objects web page look EXTRAORDINARY. But... since not all browsers could use the new commands, this transcluder only gets used when Netscape requests an object's web page. All other browser requests are routed through the standard HTML transcluder. I would expect to eventually see a Microsoft Explorer transcluder on the horizon, because of their ActiveX thing. Also, JAVA applet source code could be transcluded, then compiled locally into an applet, and sent with an object's web page as well. That... may be a ways off yet. Maybe not. To clear up some potential lies here... I BELIEVE the STANDARD HTML transcluder verbs still/will reside on #1 ($root)... and Netscape, Pueblo, and future transcluders will reside as separate objects.
Have we yet talked about how browsers (requesters) have the ability to identify themselves when they request something? I don't know if ALL of them do, but the way its figured... if the requesting browser doesn't ID itself, then it will be sent STANDARD HTML, or as close to that as is deemed necessary. (Now THERE'S a frozen standard!) But this is a good practice. Even if a verse to some Rumanian folk song is sent as the ID for the requesting browser, the moo will make standard HTML, because it WAS requested on a WEB SERVER, and that's what web servers do... send HTML outputs. I COULD have called them 'documents'... but that sounds like a file, or a piece of paper. Transcluded 'documents' are not necessarily EITHER of those. It might be just... R. Remember R... a variable... a storage place in ram memory... a strip of html codes stacked on top of each other??? Sure you do. That darned R has been used by Irradiate THE ENTIRE TIME. Everytime she completed another SECTION of web page, she'd add (append) her results to R!!! So now if she could just tell Webster to TAKE R... then SEND R TO REQUESTER, well then there weren't much of a 'document' or 'file' made, now was there? But often, it is STILL called a document. By definition, a web server serves web 'documents', whether they were ever a file, or a piece of paper, or a STRING made from scraps of pocket lint from one of Moomama's children. Web pages are TEXT files... just acsii characters and linefeeds and carriage returns and an occassional rebel tab. String variables (such as R) are just exactly the same thing. Yes, Irradiate had to shove some carriage returns and linefeeds (<br>) into R along the way. Some browsers liked <P>, some hated it. Lynx (a text-style browser) never heard of a <br>, but loved <pre>. It was trully impossible to satisfy all the different emerging HTML commands-per-browser. To force this paragraph full circle, browsers can, do, will, should ID themselves, so Webster CAN tell Moomama what TYPE of transcluder to use (currently standard HTML, Pueblo, or Netscape-enchanced HTML). And... R is a string variable, which... after the transclusion is done... holds a web document. This may change... but always, somewhere, when asked to... an HTML transcluder object or verb-set... makes (marks-up) a string of HTML commands... to be handed to Webster for delivery. Understand? Excellent!
Now Rocker (remember him?) and his gang of upstarts... decided to take things a bit further. Somewhere, he learned that VRML (Virtual Reality Modeling Language) was ALSO a TEXT file. Yup, a STRING of VRML commands, much like Irradiate's string variable R! SO... you guessed it! A VRML transcluder. Rocker started this project in much the same way as Irradiate started her web page transcluder. He began analyzing a vrml file, looking for SECTIONS. He found them! But THIS time, Rocker had to deal with a 'graphical simulation' of what each of Moomama's children LOOKED like. See, Irradiate had DESCRIPTIONS of each object, and you would READ about what color the object was, how big it was, what it was shaped like, and how it integrated itself with objects around it. (Integrated could mean things like opened, closed, on floor, hanging in mid air, connected to something, held, etc). With Rocker's project... these things would be SEEN!!! Yikes! Well, Rocker took the 'generic' approach to things, and started by making EVERY moo object... mark-up into a VRML cube. Each object used its TITLE (name), just like Irradiate's HTML transcluder, but from there forward, he started filling R with VRML commands that... when 'browsed' from a VRML-ready browser... showed the requester a CUBE! Rocker put a few properties on #1, like .height, .width, .depth, .color, .ambient_light, .diffused_light, and a bunch of other semi-complicatedly-named VRML-type properties. He made enough props to obtain the 'minimum requirements' for making a pretty-looking VRML cube. Then, he decided to add-on the TEXT .description for that object. (but not in the picture itself... right underneath or above the picture). And then, if it was a room, he added EXITS text, and then he added CONTENTS if it was a container, and MORE text-displaying abilities if the object was a note or a letter. Eventually, he had completed version 1 of the VRML transcluder. EVERY child of Moomama was now able to be 'represented' as a VRML 3-dimensional cube (with SOME text). But Rocker and the gang weren't NEAR done yet. It didn't take anyone long to realize that not everyone was going to want a Goofy Moo Object that looked like a cube. So, Rocker arranged it so that IF the user had a VRML file laying around somewhere that was preferred over the basic cube, the user could put the URL (path) for THAT vrml... into one of the object's pockets... and the vrml transcluder would use THAT vrml instead of the cube. The NAME of the property (pocket) that is used to store the alternate vrml file 's URL is not known to me... and it could change soon anyway, as this is a VERY new system.
Rocker kept working. One of the early things he did, was to take notice of all the ROOM objects that got requested, and he designed a special transcluder sub-section that actually built a better looking 'generic' or 'default' room than a basic cube. He built a box! The box room had one open side (so folks could sort of look THROUGH one wall and into the box). There was a floor, a ceiling, and three walls. ALL of the floor, wall, and ceiling 'panels' he marked-up with his room transcluder sub-section... ALSO allowed for GIF and JPG pictures to be plastered on the sides of them... each panel having TWO sides. So, a fully-detailed BOX room could have 2 JPGs/GIFs per panel, and 5 panels total... or up to 15 'elements' to a box room. Less elements are indeed possible, by NOT covering over each panel's default PAINT JOB with a gif or jpg. Minimum elements... 5. That's FIVE dual-side-painted panels. Rocker positioned the five panels with VRML 'translation' and 'rotation' commands, shoved into R... and then 'grouped' the five panels into ONE VRML OBJECT... the room! It worked quite well. Rocker had built the first Lambda-based 'Generic VRML Room'. Well, I guess the cube was the first, but it wasn't really a room. Along the way, Rocker added properties to the generic room object similar to... .panel_one_color_front, .panel_one_color_back, .ceiling_color_inside, .panel_two_height, .panel_two_width, .light_one_brightness, .camera_one_position, .camera_one_angles, etc, etc, etc. If someone was going to be able to @go to this room, then SOMEONE or SOMETHING (properties) were going to need to tell the VRML-ready browser EXACTLY how the room was suppose to look, and where, within the room, avatars were going to 'land' and what they'd 'see' from THAT position. And what about if they dropped a THING in the room? Things were currently CUBE shaped. Something would have to tell the VRML displayer WHERE in the room to place the cube, how big was it going to be compared to the room, would its name be displayed within the picture, etc. This became a VERY complicated task... with MANY 'assumed defaults' decisions to be made. Plus, if a user was to have maximum FUN creating rooms, MANY properties on rooms would have to allow the user to set their values. An example might be WHAT GIF or JPG to put on which panel, or do we paint the ceiling or not, or maybe raise the height of one wall, or even use a complete VRML room of the user's choosing. Much thought! Much work! Result? Much FUN... and a very versatile VRML room-transcluding system. It worked! Basic box, modified box, extremely modified box, or separate VRML room from anywhere on the planet. Now THAT'S versatility! Onward ho... to the avatars.
Next, the gang decided that moo-people shapes (called avatars), really shouldn't look like a cube... and really shouldn't look like a generic vrml room either. So, it was time to build the Generic Avatar. Now, most of what I've talked about to this point is a total crock. I don't even know Irradiate or Rocker. I don't know what they name the verbs they write, or the properties they add to $root or generic things. But I THINK I DO understand the theories of dynamic mark-up of moo things, and I've seen plenty of evidence that I am generally on the correct track in describing these changes at SenseMedia to you. But I am no expert, and I have limited information on the internals of SenseMedia transclusion, so I am destined to tell you things that are NOT TOTALLY TRUTHFUL. I make-up some of the property names, or verb names... because it probably doesn't matter anyway... the properties and verbs are still under development... their names destined to change... maybe often. Avatars is one of the many things I DON'T understand. I don't know if Rocker's Raiders used pre-made generic avatars (static files) or if they marked-up properties from the generic user to 'build' the avatar THAT way. But either way, the avatars showed up... at Voodo... and probably soon, the VRML transcluders will show up at other SenseMedia moos as well. Ideally, avatars should be marked-up from properties on YOUR avatar, or from properties on the generic avatar. Because, although not yet implemented due to wandering standards and evolving technologies, someday... you will want to raise the right arm of your avatar, and wave to someone. This will be VERY HARD WORK for Moomama, and YOUR VRML displayer or moo client software. It takes 16 polygons (cube-type vrml building blocks) to make a semi-decent simulation of a human hand. Another two for the arm and forearm, not to mention the 30-30000 OTHER polygons that make up our gawdy, well-armed, gorgeous avatar. And it NEED NOT resemble a human whatsoever. It COULD have 100 arms, and they all wave at once. But keep THIS in mind. A minimum of 18 polygons need to be MOVED to simulate a human arm waving. Yes, you COULD make the hand into ONE polygon shape IF you didn't need to wiggle the fingers during the wave. But if you wanted FULL wave control, its 18 polygon moves PER FRAME. If someone is in the room with you... like the person you're waving to... then THEY must be SENT, by Moomama or Webster, 18 polygon translation/rotation commands PER FRAME. A FRAME is a measure of 'screen updates'. When dealing with 3D high-resolution moving graphics, FRAME RATE is VERY important in determining smoothness or 'fluidity' of movement... like the arm waving back and forth. Television uses 30 frames per second. In other words, TV redraws the entire screen every 1/30th of a second. So, if you wanted your avatar to wave with the 'fluidity' of common television, Moomama or Webster would have to send EACH occupant of the room... (IF indeed the other avatar's camera is looking at your wave) ...18 VRML translation/rotation commands... 30 times per second. And if 10 people were in the room, that would be 5400 commands per second!!! That's what it takes to wave to 10 people with one human arm with wiggling fingers. Now you can imagine how bad this might be if all ten of those avatars were waving at each other all at the same time? I come up with something in the neighborhood of 56,000 VRML commands sent per second. As you can see, high-detail (finger wiggle) waving of multiple avatars in one room at one time... is still a ways off. So, keep the avatars simple for the time being. Use generics for awhile if you can tolerate it, and don't look for any high-frame-rate, tap-dancing avatars in the real near future.
Two other high-priority sections of displaying a LOOK at an object... are CONTENTS and EXITS. The thought of building VRML transclusion for CONTENTS is frightening, at least to THIS author. Not only would a CONTAINED object be listed in a room's .contents property, but its SITUATION must be listed as well. An object's SITUATION is a widely variable and non-standardized set of properties. Let's see if I can describe an example SITUATION dilema....
Our example object will be a cup, which, according to its .description, is placed upside-down atop a thick tablecloth, that partially covers a small dining table located along the northeast wall of the room. With an
in-moo LOOK, you'd READ this from the cup's description, and if you LOOKED at the room... Moomama would report... Contents: A cup.
Same with HTML. The best you could do with HTML is have a picture of the room, showing the cup and its support group. But with VRML, its a whole new ballgame. There are three VERY important 'attributes' to a VRML cup. Although its SHAPE is important, it is NOT one of the big 3 attributes needed by Rocker's VRML transcluder. The 3 attributes most important to the VRML TD are ROTATION, TRANSLATION, and SCALE.
In the beginning, there was ROTATION!
Rocker, who wants to transclude this room into VRML, has a nervous breakdown at this point. Know why? Let's see. First, Rocker has to check the cup to see if there is a user-made .wrl (VRML) file for this object. If so, he has to retrieve that for the transcluder to use. Let's say there IS one, and its a nice, well-written .wrl file of a cup. Now, the cup is claimed to be UPSIDE DOWN, so he has to remember to flip the object over SOMEHOW before he places it in the room. Hey wait... Moomama can't READ the description of the object... it can only copy it to you from an object's .description property. SOMETHING is going to be needed to TELL the transcluder that this object is upside-down. And it SHOULD be cup-owner-settable, so the owner can flip the cup upright when necessary. In VRML displayers, as well as any other 3D-type displayer, the 'attitude' of an object is determined by HOW FAR around the X, Y, and Z axis... the object has been turned. Most likely, many of these axis ROTATION values will be percentage-type settings. To determine ROTATIONAL ATTITUDE, three numbers are needed. The 3 values are... HOW FAR ROTATED AROUND THE X AXIS, HOW FAR AROUND Y AXIS, AND ...Z AXIS. To flip a cup upside down, much as a human hand might do it, you would rotate 0% around the X axis, 0% around the Y axis, and 50% around the Z axis. Most likely, a SET property on the cup, maybe .rotation, would need to hold the values {0,0,50}. These 3 values would HOPEFULLY be set to 0,0,0 in the owner's .wrl file. Because IF the object's rotation settings were at 0,0,50 inside the .wrl, then the transcluder would read 0,0,50 from the object's .rotation property, and the cup would end up-right again. So the cup MUST start with 0,0,0 rotation if the transcluder is to work correctly with the .rotation property settings. I am no expert on object rotation and geometry. I believe that X, Y, and Z rotational settings for heavy geometry are often called rho, phi, and theta. Don't quote me, because you'll accidently spit on someone. :)
Translation... the art of placement!
Now, WHERE is that cup within this room? Here, we'll probably be working with percentages again, since we don't know how many inches or feet or miles long or wide the room is. In our example, the cup is atop a thick tablecloth, that partially covers a small dining table, over along the northeast wall of the room. Rocker gave us a box for our room. It is the OWNER'S job to determine WHICH wall is the northeast wall. But once the user decides which wall panel is facing northeast, Rocker's transcluder is going to need to know which panel it is... so he can place a cup over there. The transcluder simply knows the panels as panel1, panel2, and panel3. VRML defines a method to decide WHERE in a 'scene' an object is located. This setting is called TRANSLATION. Translation is HOW FAR AN OBJECT IS SLID-DOWN the X, Y, and/or Z axis. BUT... unlike rotation settings, translation settings NEVER end. With rotation settings, where we used percentages... if we rotated 100% around the Z axis, it comes out the same as rotating 0% around the Z axis. But when we SLIDE a certain percentage-of-total-distance down the Z axis, SOMETHING is going to need to tell the VRML displayer HOW LONG the Z axis IS, so it can calculate a percentage-of-slide down that axis. For example, you want the object to translate (slide) along the Z axis -10%. Now, if the Z axis TOTAL LENGTH is, let's say... 100 FEET... then the object would appear to move away from you a distance of 10 feet. But what if the Z axis is determined to be 100 miles long? Here, a -10% translate (slide) along the Z axis would put the object 10 miles away... well out of sight. So, a box owner NEEDS to be able to set the Z axis length. After all, what if a moo-builder wants a small country instead of a box. I hope you see now that translation (percentages of skid along an X, Y, or Z axis) is VERY related to the LENGTH of an axis. Rocker most likely created a property on his generic_vrml_box called .axis_scale or something like that. Let's say by default, Rocker set his box room 'gradiant units' to be INCHES. He COULD have used feet, or millimeters, or any other unit of measure. He chose inches. Now lets say that he wanted his generic vrml box to be 240 inches wide (X), 120 inches high (Y), and 240 inches deep (Z). He might set his .axis_scale property on the generic VRML room to {"inches", 240, 120, 240}. In contrast, a COUNTRY builder might set the .axis_scale property on their box to {"miles", 3400, .002, 240) which would make a COUNTRY that was 3400 miles wide, .002 miles high, and 23 miles deep. You can see that... although the Z axis number for the room AND the country are both 240, one is miles, and the other is inches. A VRML TD's TRANSLATION section would be able to do this correctly, because it KNOWS from the FIRST setting (inches or feet or miles or whatever) what unit of measure to use. In this way, the OWNER of the object is allowed to determine how far a -10% slide down an axis really is. Therefore, if someone wanted to use a child of the generic VRML room, they would automatically be working in inches, and IF the cup (remember it?) had a property on it called .translation, then it might hold 3 percentage numbers. Lets say the cup's .translation property is set to {85, 25, 50}. Now, the VRML TD program - translation section... comes along and reads those numbers from cup.translation. The first number... 85, is for X. So, the cup is 85% slid along the X axis. WHAT IS THE LENGTH OF THE X AXIS? Well, if you're using the box, its 240 inches. Moo code can easily determine how many inches 85% of 240 is, and it now knows how many inches into the 240 inch wide room to place the cup (the left & right settings). Then, the TD uses the second number (25) to determine how far (in inches) to slide the cup along the Y axis or... how far it is off the floor of the box. Next, the Z axis percentage-to-inches conversion is completed, and the TD knows how far into the room the cup should be. Do you understand now how translation works, and how percentage numbers CAN be used IF the overall length of each axis is known? I hope so. I have NO IDEA what moving an object left/right, up/down, or closer/farther away... is called. In filmmaking... to move a camera forward/backward is called dollying. Moving left/right is called trucking, and moving up/down is called pedding. Keep in mind that dollying and ZOOMING are NOT the same, because they each have a different affect on background scenery.
SIZE it all up! Last of the BIG 3 attributes!
The SIZE of the cup is another setting that the VRML TD is going to have to have before drawing our cup. Some people refer to size as SCALE, because... like translation... in order for us to use percentage-type numbers, we will need to know the size of the room. SIZE settings probably DO NOT NEED TO BE PERCENTAGES. Let's try it BOTH ways. First, lets do it the LITERAL way, using the same method as with translation. Let's make our cup 3 inches wide, 5 inches tall, and since our cup will be round, it is also 3 inches deep. (Understand why that is?) In this case, we might put a property on the cup named .size, and set it to equal {"inches", 3, 5, 3}. Since the Rockbox (Rocker's generic VRML box) has it's scales already set to inches, it would be quite easy for the TD to determine the cup's size... relative to the room size. If the cup's .size was set to {"millimeters", 70, 110, 70}... THAT would still not be too much of a problem to convert to inches for scaling it properly with the room. Now lets look at another possibility. Let's say someone sets the cup's .size to {"miles", 30, 60, 30}! The VRML TD would convert that to inches, and the cup would be HUGE... easily swallowing the Rockbox and anything else nearby. Now if the Rockbox was 7000 miles wide, high, and deep... not a problem. But it AIN'T! And after all, you wouldn't want to be chatting with your friend in your nice moo room, and suddenly someone teleports a planet into the room, quickly blocking your view of your friend, your room, and your objects. So, something different needed to be done. You COULD program the entrance-based verbs to disallow TOO LARGE objects from entering the room. The disallowing verb would most likely convert the object's SIZE settings to a unit-of-measure (gradiation) that was the same as the room. In other words, if the room was measured in INCHES, and the object was measured in MILES, than the verb would convert the object size to INCHES and then compare the size of the room to the size of the object. IF the object took up more than 40% of the room, it would be refused. HEY... LOOK AT THAT! We're back using PERCENTAGES again! Hhmmm. We might have to ponder that overly BIG objects, and overly TINY objects are sometimes entertaining. So... the percentage - of - scene used up by ALLOWED objects should be room-owner-settable.
I'm not sure how SenseMedia plans to deal with scaling and sizing of objects within container-type objects. I'll try to keep us informed as to what I find out in the future.
At this point, you can see what Rocker had to ponder in his quest to deal with the BIG 3 'situation' attributes for transcluding an object into a scene. We're not even close to completing the TD yet. What if the table is too high, or the tablecloth too thick. Can the cup be embedded into the table? (Collision detection problem.) In WHAT WAY is the tablecloth PARTIALLY on the table? Where along the northeast wall is the table? Where, atop the table, is the cup sitting? Will the lights in the room shine off of it? Should the cup carry its own invisible spotlight for itself? The future will bring PHYSICS into the game. How heavy is the cup? How strong is the table? Is there wind in this room? Is the cup TAKEABLE? Can an avatar carry 100 of them? 1000?
MORE COMING REAL SOON! GET it FRESH by browsing this.
*** Addendum ***
At some point (this one), it might be worthwhile to mention some OTHER possible transcluders at work here. Up to this point, we have talked about OUTPUT transcluders and their plugins (descriptors). We've only talked about making an OUTPUT be a certain way, either telnet plain-text, or html... but always an OUTPUT. There IS such a thing as INPUT transcluders, though they are often well-hidden. Moomama allows its users to create objects, using commands such as CREATE or DIG. If you typed something like CREATE #1 named "Child_of_Moomama"... Moomama 'transcludes' YOUR command into a LIST of special commands that MAKES a new child named "Child_of_Moomama". Some of those commands store the new child's name, and time/date made, and its description, and who owns it, and who its parent is, etc etc. This LIST OF COMMANDS it does to CREATE the new child... is a special language that its database manager understands. Since Moomama is taking YOUR create command, and changing it into a list of actions for her database manager... she is INPUT TRANSCLUDING, and the descriptor of how she does that is built-in to Moomama's LambdaCore system.
TWO other applications of INPUT TRANSCLUDERS may be happening in Webster. The first happens when she HEARS an HTTP request come in for something that is stored on her hard drive. She has to convert the HTTP address (path and document name... called a URL) into a special language that HER hard drive manager can understand. This is a form of input transclusion as well. The second way she MAY be input transcluding, is when someone on the web asks for HTTP://sensemedia.net/snow/3591/smell.html! Moomama is NOT prepared to handle a command that looks like THAT. She's prepared for commands like SMELL HERE. So Webster probably converts the URL to something that APPEARS as if a user actually typed SMELL HERE from telnet land. This way, Moomama can understand it. The 'Webster-to-Moomama input transcluder could be even more advanced... and may be able to transclude the URL into the correct language for Moomama's database manager DIRECTLY... which saves Moomama from having to do a step of input transclusion herself. (The step from 'SMELL HERE' to DATABASE MANAGER CODE.) Still with me?
SO now you have a bit of insight as to WHAT'S NEW at SenseMedia, and you may have a grasp on transclusion and dynamic mark-up, as well as input tranclusion (dynamic mark-down?). There may also be more talk of 'hyperarchical' inheritence structures here someday. Stay tuned to this document (http://www.winternet.com/~wingnut/html/trans.html) for more info as it is transcluded.
(This document changes REAL often! Last updated on 16 Nov 98.)
Wingy's Homepage
Send mail to Wingy