That's why I mentioned to create a secondary database that stores the USER and their DATE. This way the original database doesn't need to be updated. It only needs to hold the normal info of the user. The temp database would check if that date is within the 24 hour period. if they like it they just click ONE button the website and poof the info in the second database would be gone and their USER and PW never gets deleted.. nothing more to do. Its very very simple. No extra clutter.<div>
<br><div><br></div><div>John<br><br><div class="gmail_quote">On Tue, Feb 2, 2010 at 3:46 PM, Master_Mirage <span dir="ltr"><<a href="mailto:mirage123@verizon.net">mirage123@verizon.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Well as a grid owner running a public grid i have a few thughts to that.<br>
The 1st would be that frontends/web interface's have a big part as thats<br>
how one would make an accunt anyway. Its not hard to have a exp. date and<br>
offers 'should thay wish' to be a full menber. That matters to the user that<br>
likes what thay see and donot have to re-enter it all over again.<br>
<br>
The next part is what about the kruft? The junk left in the db. While that<br>
could add up IF you had a boat load of looky loo's but actualy its verry<br>
small. Yes it will add more to the assets db but given the exp. date it<br>
would be akin to tossing a pebble into the grand canyon. I say that because<br>
to import anything to a scale that it matters, takes time. The acount<br>
expires unless the user wants to stay.<br>
<br>
A good bit of this is mostly done in the frontend interface not so mutch<br>
core. It has to be the way it is so that 3rd party minds can work on what<br>
you want.<br>
<br>
Mostly my thought is the kuft is so low and purging it risky.. ill take the<br>
kruft<br>
<br>
Now IF i wanted to do that as you said so well. Assuming alot of 'visitors'.<br>
I would send there data to a temp. media. a sub data base. Unless the<br>
user/visitor desides to stay , the front would just move the temp db in the<br>
main one.<br>
<br>
Part of the problem is that a 'Vistor' is intrested to know what a 3d world<br>
is, how it works what can it do. Crippling any part of it for them is<br>
counter to the point.<br>
<br>
End thought is the KRUFT is of no real problem. Drop in the pool<br>
<div><div></div><div class="h5"><br>
<br>
Paul Fishwick wrote:<br>
><br>
> I would like to open up one of our worlds to the general public by<br>
> allowing people<br>
> to log in as visitors. This is related to the "anonymous login" and has<br>
> been discussed<br>
> in various forms, but here is the concept - not sure if anything exists<br>
> yet in trunk to<br>
> support this:<br>
><br>
> 1. A user logs in using whatever name they want. If authentication is<br>
> turned off, this is<br>
> no problem. However, what would be ideal is that when the user logs<br>
> off, any trace<br>
> of them is removed from the database-- they do not persist.<br>
><br>
> 2. When the user logs in, they have access to the Library part of the<br>
> inventory, but are<br>
> unable to load any assets to the server, thus they would have<br>
> nothing under "My Inventory"<br>
> or be able to copy items from the Library or the world into My<br>
> Inventory. The Library<br>
> would contain all necessities (clothing, basic objects and scripts<br>
> that they require<br>
> in the space).<br>
><br>
> 3. The user cannot build on the island but can run scripts and navigate<br>
> performing full<br>
> interaction.<br>
><br>
> #1 is not a huge issue since I would imagine that the incremental space<br>
> allocation for<br>
> users just means additional rows in the user/agent tables -- shouldn't<br>
> take up too much<br>
> room. #2 is a bigger problem - visitors should not be taxing the asset<br>
> server. #3<br>
> can be handled by unchecking both boxes next to Create Objects in About<br>
> Land->Options.<br>
><br>
> Are either #1 or #2 possible? They would seem to be a prerequisite for<br>
> something approaching<br>
> basic web page services: people come in, visit, and exit while leaving a<br>
> minimal trace.<br>
> Builders on the other hand, have special login names that give them the<br>
> capability to build<br>
> and load assets (possible with groups?).<br>
><br>
> -p<br>
><br>
> --<br>
> Paul Fishwick, PhD<br>
> Professor<br>
> University of Florida<br>
> CISE Department, CSE 301<br>
> Gainesville, FL 32611<br>
> Email: <a href="mailto:fishwick@cise.ufl.edu">fishwick@cise.ufl.edu</a><br>
> Web: <a href="http://www.cise.ufl.edu/~fishwick" target="_blank">http://www.cise.ufl.edu/~fishwick</a><br>
><br>
> _______________________________________________<br>
> Opensim-users mailing list<br>
> <a href="mailto:Opensim-users@lists.berlios.de">Opensim-users@lists.berlios.de</a><br>
> <a href="https://lists.berlios.de/mailman/listinfo/opensim-users" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-users</a><br>
><br>
><br>
<br>
</div></div><font color="#888888">--<br>
View this message in context: <a href="http://n2.nabble.com/the-concept-of-visitor-tp4501558p4503535.html" target="_blank">http://n2.nabble.com/the-concept-of-visitor-tp4501558p4503535.html</a><br>
Sent from the opensim-users mailing list archive at Nabble.com.<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
Opensim-users mailing list<br>
<a href="mailto:Opensim-users@lists.berlios.de">Opensim-users@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-users" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-users</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>John Mieske / Sonya Pencuca<br><a href="http://johnmieske.org">http://johnmieske.org</a><br>Space Grid Station<br>"Religion - The art of killing people to prove who's imaginary friend is better."<br>
</div></div>