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

[Zha Ewry]

Lawson and I chatted a fair bit about this in-world... I've two thoughts
here. First, I'm just going to be brutally difficult about putting terms for
things which don't show up as parts of the flows and services we define in
the AWG. But... and listening to why, and how Lawson got to these issues,
helped me a lot, in terms of explanatory need, we probably do need to think
about the slightly larger, say eco-system, in which the architecture
resides. In that world, which includes the clients, the tools, and things
like backups of assets on people's private hard disks, there can, and should
be terms for things like "asset under local construction" and "Freeze dried
asset gorp ready to be turned into an asset" and "Cached Inventory handles"


I'm totally ok with getting some good nomenclature into the eco-system, and
I'm also pretty sure that a nice set of libraries, which had classes like
"proto_asset" with constructors as such, and classes like
"asset_service_proxy" with methods like
"upload_proto_asset(proto_asset&,permissions_mask)
Such clases wouldn't be within the scope of the architecture, ut they would
be within the eco-system.

- Zha

On 10/7/07, Lawson English <lenglish5 at cox.net> wrote:
>
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071007/86d15904/attachment.htm