[sldev] [META][AWG]log chat of AWG meeting Friday, Oct 5, 2007

Lawson English lenglish5 at cox.net
Sun Oct 7 16:44:13 PDT 2007


Callum Lerwick wrote:
[..]
> I'm really not understanding what you're saying here. You seem to be
> seeing grave complexity where there is none. Standard file formats are a
> given. The asset's local identity is a local implementation detail. It
> can be stored in a local file named "penisbike.slobj" or managed by a
> local asset manager in the same manner as other global assets. Or both.
>
> Remember, we're heading for a future where nontechnical users aren't
> going to know or care where their data actually is. All they know is
> they log in to Gmail and their email is there. They log in to Second
> Life and their inventory is there. (Or not there, as the case may be.)
>
> Local storage becomes nothing more than cache, and possibly a backup
> mirror. And unused disk space is wasted disk space...
>   
Well, that's the flipside of what Zha and I have been arguing about.

I want to make sure we have "not an asset" defined. She thinks the 
definition isn't necessary, but I've been worrying that "not an asset" 
will mean to some people "doesn't exist." You seem to have proven me 
correct.




I believe  there can and likely SHOULD BE plenty of data  associated 
with the client that doesn't live in an external asset server. If "not 
an asset" is defined as being "'unpublished' to the external world," 
where "external" includes 1-person sims, then plenty of data that the 
client might display will never be an asset or even a "proto-asset."

But users will still want (or at least likely will still want) to be 
able to manipulate that data using the same general interface that is 
reserved only for assets in the current SL client.

What that data is, or could be, is not defined, and I agree that 
discussing it in any detail it falls outside the purvue of designing the 
client-server architecture. BUT, we should keep in mind that some stuff 
that the user may see or want to see in the client, won't fit the 
protocols and not put up blinders when discussing what the client may or 
may not do.



L.



More information about the SLDev mailing list