This is a pretty vague assertion. Yes, 3 or 5 years from now, there may be
a protocol that handles all these things. But how do you think these
protocols come about in the first place? Someone has to do it! The whole
point of this is to be proactive instead of reactive. The technology exists
*now* to do these things if you are willing to take the extra step to mature
it. This won't be the first time I have ridden the bleeding edge of a new
technology. Thats where all the excitement is; doing amazing things that no
one has done before.
>>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.
>
>Describe the world as best you can in text or render it with the help of a
>few of the lists graphic artists and gradually move it to the evolving VRML
>medium as it continues to grow and improve. Many people are working with
>VRML so the ability to move it forward is a for sure and if a new more
>efficent format comes along its a sure bet there will be conversion programs.
I am not concerned with the capability of VRML. I believe that VRML is both
a capable environment and evolving in an intelligent, structured manner. My
assumption has been from the beginning that VRML would be the standard for
interface design and construction.
>>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.
>
>Not so. Java applets will enable dynamic content and could be used to
>communicate data between avatars. In fact the new USR 56kbps modems would
>be ideal for this sort of communication because they only work 56kbps
>recieve and 33.6 send where you would recieve the locations of the avatars
>in plain sight at 56kbps but only need to transmit your own location at
>33.6kbps.
Wishful thinking. Although client side Java applets would enable dynamic
content and interaction, there are some serious limitations:
1) Without any type of server-side software, there will be strict limits on
the range and complexity of dynamic content. About the most you could do
with the Java applets would amount to eye candy. For the really ambitious,
it would be possible to get around this via cleverly designed CGIs and Java,
but the performance would be poor and significantly limited in scope.
2) You cannot coordinate communication between many different clients
without a server to coordinate them. This not a technological problem but a
theoretical problem. It is difficult for randomly addressed clients to
locate other randomly addressed clients on a network. This is especially
true when you have a network as big as the Internet. This is why there
exists such a beast as the "chat server".
There aren't really that many technological limitations to this project.
Most of the limitations I have been discussing are limitations inherent to
the nature of the technology. These limitations must be appropriately
addressed if you really intend to accomplish anything. If properly
addressed, these limitations would become minor. Refusing to address these
issues will only cause trouble in the long term, especially when you hit the
limits they impose.
>>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.
>
>So we'll create a standard java applet for communcation! Just say if you
>want avatars add this applet and people will because people want
>interaction. Besides we can change any of this as we go along. If we all
>stick to standard off the shelf products we won't run into deadends because
>there will always be some sort of file conversion utility and if we use
>standard platform-independent file formats we can easily move them from one
>server to another and upgrade the hardware as necessary.
As mentioned above, inter-client communication *requires* server-side
software. This cannot be avoided. The vast majority of the components and
software used will be off-the-shelf. But I have rarely built an
interactive, data heavy site that didn't require at least *some* custom
client/server software. This may seem complicated to you, but this is the
way the technology is extended. It really isn't that difficult. From the
standpoint of people building worlds, you probably won't even notice that
there is a custom component behind it. You would use VRML et al the same as
you always did. At worst, you may be required to use our own set of Java
communications/interaction objects instead of the default ones, but even
this should be very trivial to the people who have to program using them.
In fact, this may simplify the Java code significantly.
>>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.
>
>Fortunetly USR has a monopoly on this scene so most of us will come through
>ok. Can't satisfy everyone unfortunetly but thats the way it is. Most of us
>won't be able to run it as well until we all upgrade to Pentium MMX
>200mhzs. :)
The compatibility issues isn't with the hardware, but with the types of
telco connections used. However, a large percentage of ISPs use the
appropriate types of telco connections, so you probably won't have a problem.
-James Rogers
jamesr@best.com