[sldev] Request for LL feedback on avatar scanner features
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,
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:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070202/ef108385/attachment.pgp
More information about the SLDev