I am in complete agreement. But letting anyone write any code they feel
like and put it on the server is definitely *not* a way to ensure
compatibility. Using off-the-shelf technologies is not an issue. Interface
and API standardization *is*.
>>Your "3D IRC chatchannel" is a perfect example.
>
>This is whats wrong with software such as WorldsChat or WorldsAway is that
>the chat environments are completely incompatable with each other.
>
Letting everyone build their own software without any type of interface
standardization or control will cause the same problem.
>>It will probably require a powerful TCP/IP server engine coupled with a some
>>type of small, fast database engine. A number of communications and
>>interaction APIs will have to be built into the system to allow users to
>>build their own (Java?) software modules so that they can add their own
>>functionality and designs to the world without inadvertently hindering or
>>damaging the system.
>>The entire world can then be built on top of this World engine. What you do
>>and put in the world is completely up to the user in any fashion the user
>>chooses. The software must be a carefully detailed architecture, but the
>>world does not have to be.
>
>Stick to evolving VRML standards.
The VRML standards are irrelevant to the above point. VRML is *not* a
self-operating/self-serving environment. There is an entire layer of
software between the VRML and the operating system/network. Normally, this
is an HTTP server, but for our purposes, an HTTP server will probably not be
sufficient. However, the final product *should* use off the shelf
protocols. The server-side software will be more complex than an ordinary
HTTP server due to the additional requirements and miscellaneous internal
protocols. That you can accomplish everything you wish this world to do
with just VRML is wishful thinking.
>>All the technologies used will be off-the-shelf: Java, C/C++, TCP/IP, HTML,
>>VRML, etc. However, we may be forced to use these technologies in new and
>novel ways.
>>As I mentioned above, this project will almost surely require a custom
>>server engine.
>
>This will not be centralized. It will be ALL OVER the net! Even in personal
>FTP sites. People will place their .WLD VRML files on their personal FTP
>sites and people will teleport to them using teleporters from other
>transhuman/extropian realms. If the # of people accessing these WLD files
>grow, we can then move it to a server but by that time, bandwidth will be
>faster and data transfer rate per month restrictions for personal websites
>will be raised due to faster bandwidth. Remember, USR 56kbps modems over
>standard telco lines come out in JAN 97!!
I never claimed that the software was required to be centralized. In fact,
I am assuming that it isn't. And besides, you are thinking of distributed
data, not a distributed server. Distributed data was never an issue because
it doesn't have any impact on the software.
The way you are describing this, the world won't be much better than the
Internet already is. It will be a chaotic hodge-podge of whatever static
material people put in their FTP directories. There will be little useable
interactive or dynamic content.
What I want to see personally is a tightly integrated environment that is
everything the Internet wishes it was. I want to see creative landscapes
and artistic design mixed with person-to-person interaction. No one should
be restricted from doing what they want, but it should be under the auspices
of a larger plan. I don't see where these concepts are necessarily mutually
exclusive. Architecture and design is important if you want this world to
be able to handle more than a dozen simultaneous users. You can't throw all
the technical and design issues out the window for the sake of convenience.
A chaotic software system is neither scalable nor particularly extensible.
And just as a note on 56kbps modems: They won't work with every service
provider. The modems assume that the ISP is using a PRI telco connection
(which is the case many times) and not one of the myriad of other options.
If the ISP is using a PRI, then the 56kbps modem establishes a 1B quasi-ISDN
connection to the ISP over standard phone lines. If the ISP uses any other
type of telco connection, you are stuck using the same slow speeds you
always did.
>>If this project was so simple, someone would have done it
>>already.
>
>No because most people don't know how to use VRML tools or have machines
>fast enough to run VRML smoothly as well as time and effort.
>
If people wanted to learn VRML, they would learn. VRML can be a little slow
on older systems, but the requirements aren't terribly steep. Of course,
VRML 2.0 will make the requirements significantly steeper. Also, some
operating systems are more adept at this type of stuff than others. Sadly,
some OSs common on older machines (such as DOS/Win3.11) are very poor for
this type of thing. Win95 works ok though, and a Mac will get you by
(although this is a really poor platform for Java), so a great many should
people should have the minimum development capability. Putting forth the
effort is a personal problem and not particularly relevant, IMO.