-- Jeff Sonstein, M.A. http://ariadne.iz.net/ http://ariadne.iz.net/~jeffs/jeffs.asc ============================================== there are no bugs there are just undocumented features -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 07, 1999 1:02 PM To: [EMAIL PROTECTED] Subject: BOUNCE [EMAIL PROTECTED]: Non-member submission from ["Mike Fletcher" <[EMAIL PROTECTED]>] >From [EMAIL PROTECTED] Thu Oct 7 13:01:50 1999 Received: from vrtmail.robocity (vrtmail.vrtelecom.com [209.195.170.44]) by ariadne.iz.net (8.8.7/8.8.7) with ESMTP id NAA26630 for <[EMAIL PROTECTED]>; Thu, 7 Oct 1999 13:01:50 -0700 (PDT) (envelope-from [EMAIL PROTECTED]) Received: from cr706570a (cr706570-a.yec1.on.wave.home.com [24.112.128.169]) by vrtmail.robocity with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 4DFA2B99; Thu, 7 Oct 1999 15:52:37 -0400 From: "Mike Fletcher" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Subject: RE: [fruitsoflivingworlds] Re: Persistence and server record models Date: Thu, 7 Oct 1999 16:03:31 -0400 Message-ID: <[EMAIL PROTECTED]> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <[EMAIL PROTECTED]> Importance: Normal Background: All of the Living Worlds-derived systems make no distinction between an avatar and a generic SharedObject, that is, any given SharedObject might just as easily be used as an avatar. (Minor note: Fruits of Living Worlds would actually allow you to create a SharedObject without the avatar interfaces, but it also allows you to add those interfaces to any object within the multi-user graph). Since a SharedObject has an unbounded number of states, and states can store arbitrary data, what you're describing is theoretically doable in most Living Worlds-derived systems today[1] (assuming adequate message size and that you can get the audio to play on the system, of course). You could quite easily create an MFFloat, MFInt32, SFString/whatever state which stored the data, which would then be decoded by the client object and turn it into the media data. Scanners and registrars create the multi-user graph. That multi-user graph is likely what you are considering at an "avatar builder", i.e. it describes the data-map pattern and available messages for a given SharedObject. Communicating that graph to the server allows it to properly allocate resources for the SharedObject. Discussion: I do not however, think it is an optimal approach. Multi-user technologies (MUTechs) tend to be optimised for small-message-size, and minimal per-message latency, dumping large quantities of data (such as media files) through the same generally will tend to break most of those optimisations (DirectPlay and other guaranteed-UDP or multi-channel systems being notable exceptions). The message immediately following the large message will, in most naive MUTechs have a huge latency. Even without these assumptions, using a multi-user technology to store arbitrary resources is, well, a headache. How does your server-side optimisation for small states work when you have 40MB audio files stored in a single state record (you'll likely wind up trashing 120MB of memory or so as you create the various buffers etc. assuming it is a sub-2K object)? Certainly, you should be able to handle SharedObjects which pull tricks like these, but generally you want to encourage a more responsible use of your server's resources. Using states to store pointers/URIs to media tends to be more flexible solution. I.e. I point to an audio source, of any type (it might be served by another service running against the same database, might be a dedicated streaming audio source, a dedicated web server etc.) within my states, giving all of the parameters required for my client to resolve this into a data stream, but I don't store the actual media data in the SharedObject state records. A service which provides for storing audio data is going to have a very different engineering solution than one for storing multi-user state information. Why not connect them instead of combining them? Consider connection to a RealPlayer server, why reinvent its data collection, storage and broadcast facilities when we can simply point the browser to them? Enjoy yourself, Mike [1] Note: Blaxxun has a hard message size limit (300Bytes?), I don't try anything over 65K on Holodesk Communicator (I haven't looked to see if there's a problem there, Eric coded that stuff, but I just don't try it anyway because Communicator is heavily optimised for small messages), don't have any information about the others, but the specification says nothing about limiting state size, so in theory they should all support it.
