[Opensim-users] the concept of "visitor"

Tue Feb 2 23:23:26 UTC 2010

Karen Palen wrote:
> I too suspect that there is a need for a tool to clean out the "kruft"!
>
> I dumped my sim out to four OAR files and several IAR files then reloaded them into a new MySQL database. The DB went from 1.3Gb to 220Mb! About 90% of that was in the "asset" section.
>
> at the moment I am unsure just how much of the "kruft" was due to system glitches and bad loads of experimental OAR files, but clearly there is a need to clean up the leftovers from such experiments!
>
> To judge by the Second Life experience, we will never be entirely free of system glitches that leave "orphan" assets. The only real question is when they become significant enough to clean up!
>
> It would seem that an experimental sim like mine would naturally accumulate more "kruft", but at the same time it is much easier to rebuild the database on such a sim! I shudder to think at the effort that would be involved in rebuilding the huge Second Life database!
>
> Karen
>
> --- On Tue, 2/2/10, Paul Fishwick<fishwick at cise.ufl.edu>  wrote:
>
>    
>> From: Paul Fishwick<fishwick at cise.ufl.edu>
>> Subject: Re: [Opensim-users] the concept of "visitor"
>> To: opensim-users at lists.berlios.de
>> Date: Tuesday, February 2, 2010, 1:56 PM
>> Good suggestions. I have someone
>> working on an opensim SQL toolkit and
>> it probably could
>> be adapted in that way. The toolkit will also include the
>> option to do a
>> db cleaning, deleting
>> users, deleting regions, showing specific stats, etc.
>>
>> The separate db for the timelimit is an interesting
>> idea  -- that would
>> certainly clean the slate,
>> say, every 24 hours.
>>
>> @Master_Mirage: the kruft ... it isn't clear to me how much
>> there is yet
>> but I do know that our
>> database has grown at a significant rate that does not
>> appear to be
>> commensurate with the added
>> assets and prims that we have put into it. Still needs some
>> analysis to
>> know exactly what is going
>> on. Once the SQL tool has been developed, we should have
>> results of this
>> analysis.
>>
>> p
>>
>> John Mieske wrote:
>>      
>>> why not add a PHP file that does this all for you
>>>        
>> ?  Example : They
>>      
>>> click a button that says Visitor John. It gives them a
>>>        
>> temp user and
>>      
>>> PW with full instructions to their e-mail. They log
>>>        
>> in. Now the timer
>>      
>>> on the PHP can delete the temp user and PW after 24
>>>        
>> hours. You can
>>      
>>> even have a php that refreshes every hour that checks
>>>        
>> the database and
>>      
>>> removes the temp users that has no need to be there.
>>>        
>> Make sure you
>>      
>>> create a seperate database for the time limit so that
>>>        
>> it wont have to
>>      
>>> be added to the MAIN SQL database. If the "extra" SQL
>>>        
>> databse has the
>>      
>>> name and user's time stamp ready for deletion then it
>>>        
>> removes it from
>>      
>>> the MAIN database for the name and PW and then goes
>>>        
>> back to the temp
>>      
>>> and removes it there too. So two databases with name
>>>        
>> and PW to show
>>      
>>> which is fake.
>>>
>>> This can be done in many ways. Just a thought.
>>>
>>> John Mieske / Sonya Penucca
>>>
>>> On Tue, Feb 2, 2010 at 10:49 AM, Paul Fishwick<fishwick at cise.ufl.edu
>>>        
>>      
>>> <mailto:fishwick at cise.ufl.edu>>
>>>        
>> wrote:
>>      
>>>       I would like to open up one of
>>>        
>> our worlds to the general public by
>>      
>>>       allowing people
>>>       to log in as visitors. This is
>>>        
>> related to the "anonymous login"
>>      
>>>       and has
>>>       been discussed
>>>       in various forms, but here is
>>>        
>> the concept - not sure if anything
>>      
>>>       exists
>>>       yet in trunk to
>>>       support this:
>>>
>>>       1. A user logs in using
>>>        
>> whatever name they want. If authentication is
>>      
>>>       turned off, this is
>>>         no problem. However,
>>>        
>> what would be ideal is that when the user logs
>>      
>>>       off, any trace
>>>         of them is removed from
>>>        
>> the database-- they do not persist.
>>      
>>>       2. When the user logs in, they
>>>        
>> have access to the Library part of the
>>      
>>>       inventory, but are
>>>          unable to load any assets
>>>        
>> to the server, thus they would have
>>      
>>>       nothing under "My Inventory"
>>>          or be able to copy items
>>>        
>> from the Library or the world into My
>>      
>>>       Inventory. The Library
>>>          would contain all
>>>        
>> necessities (clothing, basic objects and scripts
>>      
>>>       that they require
>>>          in the space).
>>>
>>>       3. The user cannot build on
>>>        
>> the island but can run scripts and
>>      
>>>       navigate
>>>       performing full
>>>          interaction.
>>>
>>>       #1 is not a huge issue since I
>>>        
>> would imagine that the incremental
>>      
>>>       space
>>>       allocation for
>>>       users just means additional
>>>        
>> rows in the user/agent tables -- shouldn't
>>      
>>>       take up too much
>>>       room. #2 is a bigger problem -
>>>        
>> visitors should not be taxing the asset
>>      
>>>       server. #3
>>>       can be handled by unchecking
>>>        
>> both boxes next to Create Objects in
>>      
>>>       About
>>>       Land->Options.
>>>
>>>       Are either #1 or #2 possible?
>>>        
>> They would seem to be a prerequisite for
>>      
>>>       something approaching
>>>       basic web page services:
>>>        
>> people come in, visit, and exit while
>>      
>>>       leaving a
>>>       minimal trace.
>>>       Builders on the other hand,
>>>        
>> have special login names that give
>>      
>>>       them the
>>>       capability to build
>>>       and load assets (possible with
>>>        
>> groups?).
>>      
>>>       -p
>>>
>>>       --
>>>       Paul Fishwick, PhD
>>>       Professor
>>>       University of Florida
>>>       CISE Department, CSE 301
>>>       Gainesville, FL 32611
>>>       Email: fishwick at cise.ufl.edu
>>>        
>> <mailto:fishwick at cise.ufl.edu>
>>      
>>>       Web: http://www.cise.ufl.edu/~fishwick
>>>       <http://www.cise.ufl.edu/%7Efishwick>
>>>
>>>
>>>        
>>     _______________________________________________
>>      
>>>       Opensim-users mailing list
>>>       Opensim-users at lists.berlios.de
>>>        
>> <mailto:Opensim-users at lists.berlios.de>
>>      
>>>       https://lists.berlios.de/mailman/listinfo/opensim-users
>>>
>>>
>>>
>>>        
>> ------------------------------------------------------------------------
>>      
>>> _______________________________________________
>>> Opensim-users mailing list
>>> Opensim-users at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-users
>>>
>>>        
>>
>> -- 
>> Paul Fishwick, PhD
>> Professor
>> University of Florida
>> CISE Department, CSE 301
>> Gainesville, FL 32611
>> Email: fishwick at cise.ufl.edu
>> Web: http://www.cise.ufl.edu/~fishwick
>>
>> _______________________________________________
>> Opensim-users mailing list
>> Opensim-users at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-users
>>
>>      
>
>
> _______________________________________________
> Opensim-users mailing list
> Opensim-users at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-users
>
>
>    
A couple of weeks ago the list was abuzz with submissions about banning 
and managing the ban. The procedures outlined in the visitor concept 
could be used very effectively to qualify new users. The 24 hour test 
period could be used for emails and such to qualify a user and in this 
case a combination of MAC and IP logging could be compared for each log 
on during the visit period.

This could be one proactive approach to getting better users ahead of time.

Just a thought.

Bill