User talk:Tree Kyomoon/Use Cases

From Second Life Wiki
(Redirected from Talk:Tree's Use Cases)
Jump to navigation Jump to search

Re Login-less Viewing of Regions: I know what you mean (and it would be useful), but the description you give is not correct in its use of the term "login-less":

When you view some part of the 3D virtual world, the camera view is always relative to some presence. In the current SL (and in virtually all other 3D worlds and games), there is one very strong implementation of presence (the position of an avatar after login), and in SL there is also a weaker implementation of presence in the notion of camera pivot point, which can move away from the avatar's position. However, even the camera pivot point is currently constrained by the avatar presence.
Similar issues apply in the case of some possible Login-less Viewing of Regions: the camera always needs to have a location, because without that the server end has no idea which object details to send you for viewing. Therefore, there will always be some form of presence associated with your "login-free" viewing, even if you're supplying the viewing coordinates directly. In other words, what you're requesting is not "login-free" viewing but "lightweight login" viewing, or possibly "no-avatar login" viewing.
The server end will still need to identify you as a valid recipient of object viewing information, even if it is only by your IP address, and to assign your viewer a presence location. (Totally unauthenticated viewing requests are untenable because of trivial abuse.) What's more, it has to do this with respect to your known login credentials in order to implement viewing access controls, which will become common once the world expands beyond the Linden grid.
In summary, lightweight logins might well be useful for restricted access, and avatar-less logins would be useful in many situations because of the current non-scalability of SL for events like live music and sports. The term "login-free" describes this only poorly however, because you can't really create a useful presence without knowing its credentials. --Morgaine Dinova 05:58, 24 September 2007 (PDT)

I think I understand your point, but I respectfully disagree. The primary purpose of "presence" in SL is so that other avatars can "see" or at least be aware of you. That creates a tremendous amount of additional bandwidth/resource useage that wouldnt be required in a login-less state. I believe it is technologically possible to "view" any region without affecting it at least in ways that can be observed by other "agents". It is crucial that this kind of observation of the client be completely anonymous or the "you tube", "google earth" or other publicly accessible content idea wouldnt work.

that said, you could certainly passively gather ip information like web server logs do anyway, but the information should be just that, passive, and not bar entry to viewing.

This, in my opinion, will be a great way to introduce people to Second Life who couldnt be bothered to go through all the trouble of creating an account. "SecondLife Tube" akin to youtube would only be the beginning --Tree Kyomoon

Presence

  • Tree, I have to assume that my explanation was extremely poor, because what I'm saying is universally true yet you keep refuting it, which makes no sense at all. :-) So, I'll try again, and hopefully I can do better this time:
  • If a 3D viewer of any kind whatsoever, whether the current one or a browser-based one or any other kind, wishes to obtain a live view of a virtual world being run on a remote server, and if that server system delivers view information to clients by sending data on only those items in a given vicinity (as opposed to absolutely everything), then it has to maintain a notion of camera location at the very least, and very commonly also a heading vector, and posibly also a pivot point offset. Without one or more of those, it cannot determine a data subset to send, so it would have to send data on every object it knows about. That location info is part of the presence to which I was referring, and it has nothing at all to do with avatar visibility: a server requires a presence so that it can deliver the appropriate objects for a view, but it certainly doesn't need any avatar to be visible, detectable, or existing at all.
  • Now, if you wish to lump presence and avatars together into an indivisible unit then all you are doing is requiring that some different word be used for the actual presence separate from the avatar, so it gets us nowhere. Because, as I explained, the point of presence needs to be there even if the avatar is invisible and undetectable by any means whatsoever; in fact, it has to be there even if the avatar was never instantiated at all, or in other words, doesn't exist. As I said, without a point of presence, the server would have no idea what subset of data to send you. This is true even in the case of stateless servers and clients which send fully specified viewport requests, except that in this case the presence would actually be held in the client. You can't get away from the concept of presence in any situation where perspective view is being presented, because it's an integral part of the operation of cameras, directional viewing, and server download set optimization.
  • So, your "login-less" or "login-free" use case (which could be very useful) still requires a point of presence on the server (or on the client or on a proxy if the server is stateless), whether or not there is an authenticated login or totally open access. Without a notion of presence you wouldn't be able to navigate around in the scene at all. And even in a non-interactive design where there are no user camera/navigation controls, there is still a presence, except that it's fixed to some default position and orientation.
  • I hope that that's explained it better. Sorry that I did such a shoddy job before. ;-)

And yes, it's a very interesting idea. I've written up some Use Cases describing massively scalable viewing systems without any avatar existing at all at each observing presence. These deliver similar functionality to yours, except that mine are part of normal client operation and therefore require full logins:

I think that your idea will be very popular with malls, because free unauthenticated access will no doubt be subsidized by huge advertising hoardings dead center in the field of view on connecting to the mall host. :-) --Morgaine Dinova 18:42, 26 September 2007 (PDT)

PS. But don't forget about abuse control. Even unauthenticated access will require *some* temporary credential, even if it's as lightweight as an IP address. Sadly, given the ease with which a botnet could demolish a virtual world's bandwidth by asking for millions of 3D views, my guess is that an IP address will not be a sufficient credential in the real world. --Morgaine Dinova 06:45, 27 September 2007 (PDT)

Technically you are correct, and I didnt mean to imply that I was disagreeing with the finer point of "presence" in the technical sense.

I respectfully submit that by clouding the issue with so much technical detail you may be in danger of making it invisible. The POINT, and I see you agree with it, is that there should be a way to view and interact locally with SL grid content without having to login! I am making a USE CASE here, not a technological implementation suggestion.

I would suggest that if you have related use cases, you should describe them in detail on new linked pages, rather than going into such depth in this discussion so that they can be properly examined and keep this particular thread from becoming overly crowded out with unnecessary detail. --Tree Kyomoon