[sldev] Request for LL feedback on avatar scanner features

Dale Glass dale at daleglass.net
Thu Feb 1 16:16:35 PST 2007

В сообщении от 2 февраля 2007 00:25 Jason Giglio написал(a):
> I don't think permanent caching is a good idea.
> Billing status does change, in both direction.  
Even if it does, does it matter? The point of knowing somebody's payment data 
is basically as an indication of how much they invested into SL, and how 
effectively they can be kept out if they're found to be undesirable.

Once you provided that data, LL will still have it even if you change your 

> Names change too.  In 
AFAIK, there's still no way for a random person of doing that, and the only 
exception I know of is people becoming Lindens.

Even in that case, it'd be okay. If you remember somebody under their old 
name, you'd just keep getting it when looking at say, object creators until 
you cleared your cache. If the key is the same, it's still the same person, 
after all.

Expiring the cache every week just in case could be done, which should still 
be an improvement.

> fact, nearly everything on there can change under some circumstances.
> You are making dangerous assumptions about what will and won't change.
It depends on the situation.

For example, my scanner as originally designed requests payment data and birth 
date for everybody around. Birth date is set in stone, payment data even if 
it does somehow change to a "lesser" status, it's probably harmless to keep 
it like that anyway. Once you look at somebody's profile, the scanner could 
use that data without making an extra request to the server to get the same 

Extended further: Adding a timestamp to profiles it could be known for sure 
whether any data has been invalidated. One request to the server would tell 
you whether anything needs to be updated or not.

What I'm aiming for here is that since I'm working on something that will add 
extra load to the server (if used) I'm attempting to add something that will 
lower the load to compensate.

Even if my scanner goes into the official client, not everybody would always 
use it, while caching improvements if they go in would benefit everybody. So 
if this works the way I expect, I would hope for a net win.

> XML is a data interchange format for blind exchange, not for storing
> data within an application.
XML is a very good format for it, for these reasons:

* It's already used in the client (XML UI say), so it makes sense to use 
something with existing code to support it
* It can deal perfectly with issues like delimitation and charsets. It's a lot 
easier to just use XML than to figure out whether japanese in 
somebody's "about" field would break my parser
* It can represent nested structures easily, which is good for things like the 
group of lists they belong to
* It's easy to extend, so if more data needs to be stored, backwards 
compatibility is very easy to achieve.

> Just make the data "on-request" and leave it at that.  This isn't a huge
> volume of data, if you only load it when the user requests.
Now where's the fun in that? If I make it to be ONLY by request, then what's 
the point in it, you can just go and load profiles like before.

This is just the beginning though. For example I've been asked to make the 
scanner identify people who belong to a group (not necessarily having it as 
the active one). That's another thing that could use caching.

> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070202/ef108385/attachment.pgp

More information about the SLDev mailing list