1

Cookies!

Alduous McBurlington

January 10, 2018 02:41

None

Follow

Hello again, Sansarians!

Another idea I was considering in the previous post I made about In-World transactions was cookies.

The basic idea from LL's perspective is that they don't want to host persistent scenes as an extremely efficient alternative to the always-on grid system, so enabling a cookie system to link with the client, relay experience-exclusive data to the scene, and so consequently allow for what ordinary websites deem enough for the front end (sans login, which is already client-handled) to show customized content to the user.

Not only could a single cookie per user be very low-maintenance but it would allow for many new creator opportunities such as customized user content and industry-standard persistent data (such as those within websites).

Let me know what you guys think and don't forget to vote if you like the idea!

4 comments

• 0
  
  Alduous McBurlington January 10, 2018 03:30

  In hindsight, I'm realizing this might be easily exposed using the AgentPrivate.Client API and so could be a viable option for Sansar in the short-term by simply adding a data table, per user (within their user database), of the user's experience data that automatically expires if the user doesn't visit the select experience in an x number of days.

  This framework, in addition to in-world transactions, would help open Sansar to gaming-formatted content like MMO-RPGs and other large-scale interactive environments; which I think for the overhead the size of a few MBs at best is a mighty fine alternative to exposing the server and allowing table-line injection via SQL or something similar!

  Edited by Alduous McBurlington January 10, 2018 03:36
• 0
  
  Galen January 10, 2018 05:55

  I know there isn't clear definition on this yet, but LL is considering some sort of data store. I speculate that it could be that a script could decide to have some data that could be per experience, per user + script owner (to protect data from other vendors' scripts), or per user and accessible by all scripts.

  But yeah; if I follow your meaning, a cookie is not necessary because your scripts can easily identify who someone visiting your scene is. Web browser cookies exist largely as an alternative to that and partly because web browsing can be anonymous. Sansar already requires you to log in and thus provides "guaranteed" identity.

• 1
  
  Alduous McBurlington January 10, 2018 06:33

  Ah yes, my reasoning as to why it would be useful is to safely store and access data regarding the user on a per-experience basis (like RPG talents, last know location, current quest). That being said, if they allow something using the Reflective namespace that acts as a sort of $GLOBALS array (as you see in PHP) that persists between instances and scenes over time then that would be cool too.

  Really I suggested it because there haven't been any known plans publicly (that I know of) about this, and its much easier to implement than an SQL wrapper in the short-term.

• 0
  
  Gindipple January 10, 2018 07:20

  Any persistence at all would be useful, and we've been asking for it for months.

  But it's so fundamental it's barely worth asking for as you have to expect eventually they have to add it.

  It just comes down to waiting is all.

  But I'd rather we don't define what it looks like. It could be in the form of an internal server or an external one. From there let us coders decide how we use it. All we care about is that it's efficient and easy to use really. It could be a large key-value pair<T1,T2> for all I care at the start.

  Later they could add a full fledged DB storage and you could morph your data over to that or some form of http requests/response.