Re: [Opensim-dev] Opensim database management - garbage collection

[Charles Krinke]

The integers for create_time and access_time are "epoch times", where the 
beginning of the epoch is 1/1/70.

To convert one uses the mysql function from_unixtime(create_time) or 
from_unixtime(access_time) to see a YY-MM-DD-HH-MM-SS format.

On OSGrid, we now have about 1,000,000 entries in the assets table consuming 
about 50 GBytes. Of those 1,000,000 entries, about half have create_time == 0. 
It looks like the earliest is around the beginning of November, 2008 when the 
logic to write create_time and access_time became operational.

I look at that and think that have access_time and create_time is a really good 
thing. I am not sure I could support number of times accessed as these seem 
sufficient to me at this point, but perhaps I am being myopic.

Charles





From: J Ross Nicoll 
To: opensim-dev@lists.berlios.de
Sent: Thursday, January 15, 2009 7:37:16 AM
Subject: Re: [Opensim-dev] Opensim database management - garbage collection

Any chance of a number of times accessed field for assets, in addition  
to the access_time field?

While I'm looking at the assets table, is there any specific reason  
why creation/access times are stored as integers rather than using  
actual date & time types?

On 15 Jan 2009, at 00:24, Mike Mazur wrote:

> Hi,
>
> On Wed, 14 Jan 2009 22:22:09 +
> Ai Austin  wrote:
>
>> I wonder if someone can summarise for me the way in which Opensim
>> manages old inaccessible assets...
>
> From what I understand, nothing is done to old inaccessible assets.
> There is some difficulty in determining which assets are inaccessible.
> The reasons include:
>
> - assets can be referenced in scripts by UUID (so I heard)
> - assets may be referenced by regions not currently online
>
> In a grid where you control all the regions and databases, it should  
> be
> feasible to write a tool that can discover inaccessible assets.
>
>> I.e. if someone uploads a texture, perhaps uses
>> it on an object that is then deleted, and then delete a texture, is
>> it removed from the database... or can it persist and be there
>> forever?
>
> AFAIK the texture remains in the DB forever.
>
> Mike
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev

The University of St Andrews is a charity registered in Scotland : No  
SC013532



___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

[Opensim-dev] 27 LSL functions left

[Charles Krinke]

There are 27 LSL functions with no implementation left, and they are:

llRotTarget, llRotTargetRemove, llLoopSoundMaster, llLoopSoundSlave, 
llPlaySoundSlave, llLookAt, llStopLookAt, llCollisionFilter, llAttachToAvatar, 
llDetachFromAvatar, llRotLookAt, llPointAt, llStopPointAt, llGodLikeRezObject, 
llPassTouches, llSetDamage, llTextBox, llPassCollisions, llGetCenterOfMass, 
llEdgeOfWorld, llSetSoundQueueing, llTriggerSoundLimited, llGroundRepel, 
llRemoteDataSetRegion & llSetInventoryPermMask.

We started with Tedd's vision a bit over a year ago and 300 functions are 
implemented, that is a great job to all who contributed. 

The end is in sight, and patches to partially or completely implement one or 
more of these functions would be greatly appreciated by all.

Charles
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] 27 LSL functions left

[Charles Krinke]

The vehicle functions are stubs and could use a little attention. That is, 
llSetVehicleType, llSetVehicledoubleParam, llSetVehicleFloatParam, 
llSetVehicleVectorParam, llSetVehicleRotationParam, llSetVehicleFlags & 
llRemoveVehicleFlags.

I dont think it is that crucial to have complete secondlife compatibility at 
this point. I rather think it is more important to get enough functionality so 
that folks can use scripts at all.

We can have all those wonderful discussions about compatibility as soon as we 
have all the functions implemented. And I expect that discussion and the 
resulting patches to go on for some time.

Charles





From: "Frisby, Adam" 
To: "opensim-dev@lists.berlios.de" 
Sent: Friday, January 16, 2009 6:31:51 PM
Subject: Re: [Opensim-dev] 27 LSL functions left

 
Big congratulations to everyone who has contributed, I had no
idea it was this close. Do we have a list of functions which only have a
partial implementation and need more work?
 
Regards,
 
Adam
 
From:opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Charles
Krinke
Sent: Friday, 16 January 2009 4:14 PM
To: opensim-dev
Subject: [Opensim-dev] 27 LSL functions left
 
There are 27
LSL functions with no implementation left, and they are:

llRotTarget, llRotTargetRemove, llLoopSoundMaster, llLoopSoundSlave,
llPlaySoundSlave, llLookAt, llStopLookAt, llCollisionFilter, llAttachToAvatar,
llDetachFromAvatar, llRotLookAt, llPointAt, llStopPointAt, llGodLikeRezObject,
llPassTouches, llSetDamage, llTextBox, llPassCollisions, llGetCenterOfMass,
llEdgeOfWorld, llSetSoundQueueing, llTriggerSoundLimited, llGroundRepel,
llRemoteDataSetRegion & llSetInventoryPermMask.

We started with Tedd's vision a bit over a year ago and 300 functions are
implemented, that is a great job to all who contributed. 

The end is in sight, and patches to partially or completely implement one or
more of these functions would be greatly appreciated by all.

Charles___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] 27 LSL functions left

[Charles Krinke]

Dear Bri:

Can you offer some suggestions as to what you might propose as we move forward? 
If I get your drift, you are addressing what many call "regression", and that 
is important also. One of the thoughts I had on that subject was a series of 
sims with scripts running 24/7 demonstrating the various functions that folks 
could log in and see they were working after each update. At least that is what 
we have been doing on the plazas for some time. 

Perhaps you have some additional insight that could let us close the loop?

Charles

p.s. I know a sailboat is not a vehicle and making sure the force, mass, torque 
functions keep working is also important.





From: Brianna 
To: opensim-dev@lists.berlios.de
Sent: Saturday, January 17, 2009 1:00:36 PM
Subject: Re: [Opensim-dev] 27 LSL functions left

 
On completed functions, what appears to be constantly ignored are other area 
changes or errors that will break what was a working function. This consumes a 
great deal of time thinking of new methods for an equivalent and to me defeats 
the purpose of a function. The number of functions in that category is not 
trivial. A few of us have considered creating a script to test all as a 
harbinger.
Bri
(The sailboat is not a 
vehicle)
- Original Message - 
From: J Ross Nicoll 
To: opensim-dev@lists.berlios.de 
Sent: Saturday, January 17, 2009 10:51  AM
Subject: Re: [Opensim-dev] 27 LSL  functions left

Absolutely agreed on the compatibility. There will be implementation  quirks 
worth matching, but I think in most cases code can be made to work on  both OS 
and SL easily enough, and will be more reliable for the thought put  into it.

If anyone has BSD licensed (because I'm not getting into reading code  that 
might cause trouble later) code which uses entirely implemented  functions, but 
doesn't work in only one of OS/SL, feel free to e-mail it to me  with 
instructions and I'll fix it, give a good reason why it can't/shouldn't  be 
fixed, or take that back...

On 17 Jan 2009, at 02:41, Charles Krinke wrote:

The vehicle functions are stubs and could use a  little attention. That is, 
llSetVehicleType, llSetVehicledoubleParam,  llSetVehicleFloatParam, 
llSetVehicleVectorParam, llSetVehicleRotationParam,  llSetVehicleFlags & 
llRemoveVehicleFlags.

I dont think it is that  crucial to have complete secondlife compatibility at 
this point. I rather  think it is more important to get enough functionality so 
that folks can use  scripts at all.

We can have all those wonderful discussions about  compatibility as soon as we 
have all the functions implemented. And I expect  that discussion and the 
resulting patches to go on for some  time.

Charles





 From: "Frisby, Adam" 
To: "opensim-dev@lists.berlios.de"  
Sent: Friday, January 16, 2009 6:31:51  PM
Subject: Re: [Opensim-dev] 27 LSL functions  left


Big  congratulations to everyone who has contributed, I had no idea it was this 
 close. Do we have a list of functions which only have a partial  
implementation and need more work?
 
Regards,
 
Adam
 
From: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Charles  Krinke
Sent: Friday,  16 January 2009 4:14 PM
To: opensim-dev
Subject: [Opensim-dev] 27 LSL functions  left
 
There are 27 LSL functions with no  implementation left, and they are:

llRotTarget, llRotTargetRemove,  llLoopSoundMaster, llLoopSoundSlave, 
llPlaySoundSlave, llLookAt,  llStopLookAt, llCollisionFilter, llAttachToAvatar, 
llDetachFromAvatar,  llRotLookAt, llPointAt, llStopPointAt, llGodLikeRezObject, 
llPassTouches,  llSetDamage, llTextBox, llPassCollisions, llGetCenterOfMass, 
llEdgeOfWorld,  llSetSoundQueueing, llTriggerSoundLimited, llGroundRepel,  
llRemoteDataSetRegion & llSetInventoryPermMask.

We started with  Tedd's vision a bit over a year ago and 300 functions are 
implemented, that  is a great job to all who contributed. 

The end is in sight, and  patches to partially or completely implement one or 
more of these functions  would be greatly appreciated by  all.

Charles___
Opensim-dev  mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev


The University of St Andrews is a charity registered in Scotland : No  SC013532




 ___
Opensim-dev mailing  list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] 27 LSL functions left

[Charles Krinke]

Dear Bri:

I was certainly not criticizing you. I was just trying to figure out how to 
best move forward. We are all volunteers and the trick is always to figure out 
how to leverage all of our efforts to help each other move forward. One of the 
ideas I had was to have a set of scripts running on a set of known regions that 
folks could go and see were working and obtain the source from a web site. 
Another related part of that same idea was to update regions and have a set of 
scripts that one can easily check on with a login after region update.

That is one of the purposes of the fountain, html-on-a-prim and a couple of the 
other demonstrations at Wright Plaza.

So, perhaps some similar idea might help you and your group.

Charles






From: Brianna 
To: opensim-dev@lists.berlios.de
Sent: Saturday, January 17, 2009 1:53:43 PM
Subject: Re: [Opensim-dev] 27 LSL functions left

 
As to the SL compatibility, at this point in 
development running back to SL to test is a handy tool. That also is a reason 
to 
get flow control statements completed.
Our next meeting we will see what we 
can concoct as a suggestion besides whining.
Bri
(The sailboat is not a vehicle)
 
 
- Original Message - 
From: Charles Krinke 
To: opensim-dev@lists.berlios.de 
Sent: Saturday, January 17, 2009 1:34  PM
Subject: Re: [Opensim-dev] 27 LSL  functions left

Dear Bri:

Can you offer some suggestions as to what you might  propose as we move 
forward? If I get your drift, you are addressing what many  call "regression", 
and that is important also. One of the thoughts I had on  that subject was a 
series of sims with scripts running 24/7 demonstrating the  various functions 
that folks could log in and see they were working after each  update. At least 
that is what we have been doing on the plazas for some time. 

Perhaps you have some additional insight that could let us close the  loop?

Charles

p.s. I know a sailboat is not a vehicle and making  sure the force, mass, 
torque functions keep working is also  important.





 From: Brianna  
To: opensim-dev@lists.berlios.de
Sent: Saturday, January 17, 2009 1:00:36  PM
Subject: Re: [Opensim-dev]  27 LSL functions left

 
On completed functions, what appears to be constantly ignored are other  area 
changes or errors that will break what was a working function. This  consumes a 
great deal of time thinking of new methods for an equivalent and to  me defeats 
the purpose of a function. The number of functions in that category  is not 
trivial. A few of us have considered creating a script to test all as a  
harbinger.
Bri
(The sailboat is not a  vehicle)
-  Original Message - 
From: J Ross Nicoll 
To: opensim-dev@lists.berlios.de 
Sent: Saturday, January 17, 2009 10:51 AM
Subject: Re: [Opensim-dev] 27 LSL functions left

Absolutely agreed on the compatibility. There will be implementation  quirks 
worth matching, but I think in most cases code can be made to work on  both OS 
and SL easily enough, and will be more reliable for the thought put  into it.

If anyone has BSD licensed (because I'm not getting into reading code  that 
might cause trouble later) code which uses entirely implemented  functions, but 
doesn't work in only one of OS/SL, feel free to e-mail it to  me with 
instructions and I'll fix it, give a good reason why it  can't/shouldn't be 
fixed, or take that back...

On 17 Jan 2009, at 02:41, Charles Krinke wrote:

The vehicle functions are stubs and could use a  little attention. That is, 
llSetVehicleType, llSetVehicledoubleParam,  llSetVehicleFloatParam, 
llSetVehicleVectorParam,  llSetVehicleRotationParam, llSetVehicleFlags &  
llRemoveVehicleFlags.

I dont think it is that crucial to have  complete secondlife compatibility at 
this point. I rather think it is more  important to get enough functionality so 
that folks can use scripts at  all.

We can have all those wonderful discussions about  compatibility as soon as we 
have all the functions implemented. And I  expect that discussion and the 
resulting patches to go on for some  time.

Charles





 From: "Frisby, Adam" 
To: "opensim-dev@lists.berlios.de"  
Sent: Friday, January 16, 2009 6:31:51  PM
Subject: Re: [Opensim-dev] 27 LSL  functions left


Big  congratulations to everyone who has contributed, I had no idea it was this 
 close. Do we have a list of functions which only have a partial  
implementation and need more work?
 
Regards,
 
Adam
 
From: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Charles  Krinke
Sent: Friday, 16 January 2009 4:14  PM
To: opensim-dev
Subject: [Opensim-dev] 27 LSL functions  left
 
There are 27 LSL functions with no  implementation left, and they are:

llRotTarget, llRotTargetRemove,  llLoopSoundMaster, llLoopSoundSlave, 
llPlaySoundSlave, l

[Opensim-dev] 0.6.2 minor release

[Charles Krinke]

Reports are good on the current trunk stability, so we just tagged r8067 as 
r8068. This means that r8068 is the 0.6.2 release. 

A binary build is being prepared by Nebadon and will be available on the 
osgrid.org and opensimulator.org web site a little bit later today.

Good work everyone for the development and testing to get us back to a point of 
relative stability.

Charles
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] 27 LSL functions left

[Charles Krinke]

Dear Brianna:

I struggle with these issues all the time and have been for nearly two years 
now with OpenSim.

One of the things I find that helps is to concentrate on the things that are 
implemented rather then the features that are not implemented. There are more 
tests I can imagine that will fail, then there are tests that pass. Mostly 
based on the fact that OpenSim is only about 60% finished.

Perhaps suggesting to some of your folks that concentrating on keeping 
continuous scripts testing working features is a better risk/reward ratio then 
demonstrating all the things that do not work. Also, it helps to have other 
independent folks test scripts as sometimes we fool ourselves with a 
configuration issue.

That is one of the reasons why sharing script source with forums, e-mail and 
IRC has become so powerful for OpenSim. We can all have the same script and if 
tests can fail that used to work then we have good traction for a Mantis. This 
gets even better when an independent person can perform the same test and get 
the same failure on a different sim using a different operating system.

Charles





From: Brianna 
To: opensim-dev@lists.berlios.de
Sent: Saturday, January 17, 2009 3:12:18 PM
Subject: Re: [Opensim-dev] 27 LSL functions left

 
Charles,
 
No criticism received. What I want to pursue is a 
broader test set. Owen often constructs bizarre looking objects that only 
exist for test. From his kicked ball cross, strange linked swing set to our 
vendor that sells you a blank box. They exist only to test functions. We were 
thrilled to see the WP style teleporter healed (TP's were fixed). We need a 
better answer for content creators that can't understand why last weeks objects 
no longer work.
 
Bri
(The sailboat is 
not a vehicle)
- Original Message ----- 
From: Charles Krinke 
To: opensim-dev@lists.berlios.de 
Sent: Saturday, January 17, 2009 2:25  PM
Subject: Re: [Opensim-dev] 27 LSL  functions left



Dear  Bri:

I was certainly not criticizing you. I was just trying to figure  out how to 
best move forward. We are all volunteers and the trick is always to  figure out 
how to leverage all of our efforts to help each other move forward.  One of the 
ideas I had was to have a set of scripts running on a set of known  regions 
that folks could go and see were working and obtain the source from a  web 
site. Another related part of that same idea was to update regions and  have a 
set of scripts that one can easily check on with a login after region  update.

That is one of the purposes of the fountain, html-on-a-prim and  a couple of 
the other demonstrations at Wright Plaza.

So, perhaps some  similar idea might help you and your group.

Charles






 From: Brianna  
To: opensim-dev@lists.berlios.de
Sent: Saturday, January 17, 2009 1:53:43  PM
Subject: Re: [Opensim-dev]  27 LSL functions left

 
As to the SL compatibility, at this point in  development running back to SL to 
test is a handy tool. That also is a reason  to get flow control statements 
completed.
Our next meeting we will see what  we can concoct as a suggestion besides 
whining.
Bri
(The sailboat is not a  vehicle)
 
 
-  Original Message ----- 
From: Charles Krinke 
To: opensim-dev@lists.berlios.de 
Sent: Saturday, January 17, 2009 1:34 PM
Subject: Re: [Opensim-dev] 27 LSL functions left

Dear Bri:

Can you offer some suggestions as to what you might  propose as we move 
forward? If I get your drift, you are addressing what  many call "regression", 
and that is important also. One of the thoughts I  had on that subject was a 
series of sims with scripts running 24/7  demonstrating the various functions 
that folks could log in and see they  were working after each update. At least 
that is what we have been doing on  the plazas for some time. 

Perhaps you have some additional insight  that could let us close the loop?

Charles

p.s. I know a  sailboat is not a vehicle and making sure the force, mass, 
torque functions  keep working is also important.





 From: Brianna  
To: opensim-dev@lists.berlios.de
Sent: Saturday, January 17, 2009  1:00:36 PM
Subject: Re:  [Opensim-dev] 27 LSL functions left

 
On completed functions, what appears to be constantly ignored are other  area 
changes or errors that will break what was a working function. This  consumes a 
great deal of time thinking of new methods for an equivalent and  to me defeats 
the purpose of a function. The number of functions in that  category is not 
trivial. A few of us have considered creating a script to  test all as a 
harbinger.
Bri
(The sailboat is not a  vehicle)
-  Original Message - 
From: J Ross Nicoll 
To: opensim-dev@lists.berlios.de 
Sent: Saturday, January 17, 2009 10:51 AM
Subject: Re: [Opensim-dev] 27 LSL functions left

Absolutely agreed on the compatibility. There will be implementation  quirks 
worth matc

[Opensim-dev] Timezones, UTC, GMT & PST

[Charles Krinke]

There are some issues coming up about timezones and grids. It seems that 
events, scripts, web interfaces and other things are affected by timezones. It 
gets a bit more complicated when one considers that our mysql logic uses local 
time with calls that involve NOW().

Some folks feel that all the time on all the sims on all the grids should be 
set to UTC, and that is a reasonable approach.

Others feel that a UGAIM should set the timezone for a grid and tell the sims 
connected to that UGAIM what timezone they are in and what time it is at the 
time of grid registration with a UGAIM, and that is also a reasonable approach.

There is more. But, rather then just declaring what I might feel to be the 
answer, I would like to seek a consensus that is best for OpenSim and any 
comments or suggestions are greatly appreciated to this "timely" subject.

Charles
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Console Log Colours for Messages

[Charles Krinke]

Just weighing in a little bit. I personally dont have any bias one way or the 
other on colors.

Charles 





From: Ai Austin 
To: opensim-dev@lists.berlios.de
Sent: Monday, January 19, 2009 1:35:08 PM
Subject: Re: [Opensim-dev] Console Log Colours for Messages

At 20:51 19/01/2009, Sean Dague wrote:
>The coloring of those fields is based on a hashing algorithm of the tag
>(it's done in the log4net module I wrote).  I can take Red out of that
>rotation, though that will definitely cause at least a few days of
>confusion as the colors people are used to for certain tags will go away.
>
>How big an issue do people see for using red for a tag coloring?  I'd
>like to hear some more voices before changing that.


Good to hear it a centralized thing Sean... My proposal is that one 
colour (the "error red" is reserved for just that - real errors... 
not warnings or status messages.  Good to hear from others if that 
will be an issue for them.

I should check that errors indicated by module writers do actually 
come out red though - whatever hash colour their module 
is?  Otherwise the change is not of value Sean, 

___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Timezones, UTC, GMT & PST

[Charles Krinke]

Ok, now I am confused again. I got the impression from Stefan that we were 
doing the right things.

I also believe that time data is written on disk as "epoch" time, meaning the 
number of seconds since 1/1/1970.

So, where is the problem? Can you help us understand?

Charles





From: Melanie 
To: opensim-dev@lists.berlios.de
Sent: Sunday, January 18, 2009 2:39:40 PM
Subject: Re: [Opensim-dev] Timezones, UTC, GMT & PST

And, as I said, I care about being _able_ to put time data on disk 
in local time (NOT UTC + offset) with all local time quirks.
That doesn't have to be default, or trivial, but must remain possible.

Melanie


Teravus Ovares wrote:
> As I said in IRC,
> 
> I'm firmly of the mind that we should make it easy to ensure that all
> time data is consistant.   I think the easiest way to do this is to
> standardize on UTC.  Whatever time zone your server hardware/OS is in,
> you can always get UTC from it.
> 
> I am not averse to having a 'super advanced OMG what the heck are you
> doing' option to set a UTC offset above and beyond..   but I really
> think it should be UTC by default across the board.
> 
> Best Regards
> 
> Teravus
> 
> On 1/18/09, Gerhard Dünnebeil  wrote:
>> When dealing with time you have to distinguish between the time the
>> machines work on and the time the users sees.
>>
>> Introducing time zones at the wrong level also introduces a lot of
>> confusion as you (the developer) always have to know with which time
>> zone you currently deal.
>>
>> MySQL isn't really an issue as you can set the time zone you want to
>> work in with the session.
>>
>> So my thoughts:
>> Use UTC internally; that includes storage of data, machine to machine
>> communication, 
>> Use the users time zone when (and only when) communicating with the
>> user, which is mainly when times are displayed.
>>
>> This is easier as one might think, as using UTC as the time base is
>> available in all standard OS (windows, linux, ...) these days. There is
>> no need to set a system clock to UTC as long as the system knows the
>> offset to UTC.
>>
>> Gerhard
>>
>>
>> Dahlia Trimble wrote:
>> > With the err... um... inevitable future event when the LL grid opens
>> > the doors to full interoperability, and given that their large
>> > customer base is accustomed to using "SLT" (California time) and all
>> > the scripts that may assume SLT, shouldn't we weigh that option over
>> > UTC or GMT or CUT or whatever it's called these days?
>> >
>> > On a side note, regions running in virtual machines may have less
>> > control over the system clocks than regions running in a regular
>> > machine. I'd like to suggest that region times could be configured in
>> > OpenSim.ini and/or set by a central server using ntp or a similar
>> > protocol.
>> >
>> > On Sun, Jan 18, 2009 at 10:32 AM, Charles Krinke > > <mailto:c...@pacbell.net>> wrote:
>> >
>> > There are some issues coming up about timezones and grids. It
>> > seems that events, scripts, web interfaces and other things are
>> > affected by timezones. It gets a bit more complicated when one
>> > considers that our mysql logic uses local time with calls that
>> > involve NOW().
>> >
>> > Some folks feel that all the time on all the sims on all the grids
>> > should be set to UTC, and that is a reasonable approach.
>> >
>> > Others feel that a UGAIM should set the timezone for a grid and
>> > tell the sims connected to that UGAIM what timezone they are in
>> > and what time it is at the time of grid registration with a UGAIM,
>> > and that is also a reasonable approach.
>> >
>> > There is more. But, rather then just declaring what I might feel
>> > to be the answer, I would like to seek a consensus that is best
>> > for OpenSim and any comments or suggestions are greatly
>> > appreciated to this "timely" subject.
>> >
>> > Charles
>> >
>> > ___
>> > Opensim-dev mailing list
>> >Opensim-dev@lists.berlios.de <mailto:Opensim-dev@lists.berlios.de>
>> >https://lists.berlios.de/mailman/listinfo/opensim-dev
>> >
>> >
>> > 
>> >
&

Re: [Opensim-dev] new Mono

[Charles Krinke]

+1 Sean. And to add, most of the testers are using mono-2.0.1 currently. That 
is, those that are testing with svn trunk.

Everytime we update mono, there is a period of trauma, so we are trying to move 
as fast as practical, but consider the fact that there are thousands of 
deployments of OpenSim regions so we want to do this deliberately.

Charles





From: Sean Dague 
To: opensim-dev@lists.berlios.de
Sent: Thursday, January 22, 2009 12:06:45 PM
Subject: Re: [Opensim-dev] new Mono

Mo Hax wrote:
> So where does Mono 2.2 fit with OpenSim, is that version now supported by
> the recent OpenSim commits?
> 
> Just wondering if I can use C# 3.0 syntax elements in it.

I'm now running 2.2 in my environments, and life is pretty good with it.
As we've not yet cut off people with mono < 2.0 we need to stay with C#
2.0 syntax.  I expect that will change this summer, after all the Linux
distros are shipping mono >= 2.0.

-Sean

-- 
Sean Dague / Neas Bade
sda...@gmail.com
http://dague.net___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] new Mono

[Charles Krinke]

Actually, I just checked the mono-project.com web site and it looks like 
mono-2.2 has now been released in both source and some binaries.

So, ... If a couple of folks would like to become the guinea-testers with 
guinea-regions, this might be a good time.

Charles

p.s. The SecondLife.com official download is still 1.21.6, so the chant "1.21.6 
--- 1.21.6 ---" is still valid.




From: Paul Fishwick 
To: opensim-dev@lists.berlios.de
Sent: Thursday, January 22, 2009 12:52:20 PM
Subject: Re: [Opensim-dev] new Mono

Is this newer version of Mono available in binary without having to compile?
I see to recall Ubuntu 8.10 coming with an older version.
-p

Charles Krinke wrote:
> +1 Sean. And to add, most of the testers are using mono-2.0.1 
> currently. That is, those that are testing with svn trunk.
>
> Everytime we update mono, there is a period of trauma, so we are 
> trying to move as fast as practical, but consider the fact that there 
> are thousands of deployments of OpenSim regions so we want to do this 
> deliberately.
>
> Charles
>
> 
> *From:* Sean Dague 
> *To:* opensim-dev@lists.berlios.de
> *Sent:* Thursday, January 22, 2009 12:06:45 PM
> *Subject:* Re: [Opensim-dev] new Mono
>
> Mo Hax wrote:
> > So where does Mono 2.2 fit with OpenSim, is that version now 
> supported by
> > the recent OpenSim commits?
> >
> > Just wondering if I can use C# 3.0 syntax elements in it.
>
> I'm now running 2.2 in my environments, and life is pretty good with it.
> As we've not yet cut off people with mono < 2.0 we need to stay with C#
> 2.0 syntax.  I expect that will change this summer, after all the Linux
> distros are shipping mono >= 2.0.
>
> -Sean
>
> -- 
> Sean Dague / Neas Bade
> sda...@gmail.com <mailto:sda...@gmail.com>
> http://dague.net
>
>
> 
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>  


-- 
Dr. Paul A. Fishwick   E-Mail: fishw...@cise.ufl.edu
Dept. of Computer & Info   Phone & FAX: (352) 392-1414
Science and Engineering   WWW: http://www.cise.ufl.edu/~fishwick
University of Florida  (PGP Key available at above WWW address)
P. O. Box 116120
332 Bldg. CSE, Gainesville, FL 32611-6120

___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] new Mono

[Charles Krinke]

Thanks, Coyle:

This actually brings into the light one of our issues, and that is mono 
idiosyncracies versus OpenSim idiosyncracies.

Many folks have advanced their mono to mono-2.0.1. Most of those with 1.2.6 are 
having problems with reliability. Some of those with mono-1.9.1 are having 
problems. Some of the mono-2.0.1 binary compiled packages have problems and I 
think the Ubuntu may be one of them.

So, ... what some of us are recommending lately is to compile mono from source 
and if there are problems, compile with the large heap option. 

Charles





From: Dave Coyle 
To: opensim-dev@lists.berlios.de
Sent: Thursday, January 22, 2009 2:24:12 PM
Subject: Re: [Opensim-dev] new Mono

On 2009-01-22 15:52:20 -0500, fishw...@cise.ufl.edu wrote:
> Is this newer version of Mono available in binary without having to
> compile?  I see to recall Ubuntu 8.10 coming with an older version.

Ubuntu 8.04 == Mono 1.2.6
Ubuntu 8.10 == Mono 1.9.1
Ubuntu 9.04 == Mono 2.0.1

(what's in the official repos, anyway)

-Coyle
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

[Opensim-dev] Mantis#3027

[Charles Krinke]

Tommil is doing some good work on nHibernate and has a new patch on Mantis. It 
would help to have at least one "+1" on the patch to commit it.

Charles
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

[Opensim-dev] anon logins

[Charles Krinke]

One of the recurring themes is a suggestion that we encourage "anon" logins in 
the standalone and grid logic.

This would allow "guests" to logon and perhaps have a certain limited set of 
abilities. That is, to walk, chat, fly at a minimum, but not to be able to 
'take', 'edit', or perhaps limit teleports beyond the login region.

Anyway, I open this mini "Pandora's Box" to see if this is something that 
should be put on the list.

Charles
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] anon logins

[Charles Krinke]

That is a reasonable point, Nebadon. I was thinking more of this from the 
OpenSim viewpoint as opposed to the current viewer. 

It is possible, even probable that viewers will evolve in different directions. 
I wonder if this is a reasonable direction for OpenSim and then let viewers 
adjust as necessary. 

There are a few logical issues from the OpenSim viewpoint. One of those that 
comes to mind is what happens when 2 or a dozen different "guests" or "anon" 
enter a region simultaneously (and even at the same time).

Charles






From: Nebadon Izumi 
To: opensim-dev@lists.berlios.de
Sent: Friday, January 23, 2009 8:58:15 AM
Subject: Re: [Opensim-dev] anon logins

1st though that jumps out at me, is we dont have a viewer capable of doing 
this.. Without having our own viewer to be able to modify, i dont ever see this 
becoming a reality, the linden viewer would not cleanly allow for Anonymous 
account usage.

Neb
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] anon logins

[Charles Krinke]

Great. These are interesting ideas. Having a dynamic last name assigned like 
"Guest001" through "Guest999" (or Anon, or Anonymous) might be a way forward 
for chat and IM. Personally, I would prefer a 'shorter' as opposed to 'longish' 
last name, but thats only my personal typing bias.

I could certainly see OpenViewer, Hippo, IdealistViewer or RexClient moving in 
this direction if there was sufficient community interest.

The main reason I brought it up was to think forward a little bit towards 
educational, scientific and general usage in a 3D internet paradigm that might 
be one of those small steps that would gain OpenSim more acceptance.

I am not thinking of the SecondLife client or maingrid here so much as trying 
to imagine a few features that would benefit OpenSim six months from now. And a 
guest or anon login seems like one of those.

This being the eave of our OS2B, it just seemed to me that discussing a few of 
these sorts of ideas would be at least stimulating for our OpenSim community.

Charles





From: Sean Hennessee 
To: opensim-dev@lists.berlios.de
Sent: Friday, January 23, 2009 9:50:13 AM
Subject: Re: [Opensim-dev] anon logins

Last name "anonymous"; first name would have to be unique. Then you
would have a unique first/last name to make the viewer happy. Perhaps a
web page could assign you a unique first name before you logged in.

Opensim would then need to treat this user special, (anyone with last
name anonymous). I would imagine the Opensim.ini file would specify
what capabilities an anonymous user had.

[anonymous]
move=true
fly=false
chat=true
shout=false
build=true
script=false
etc.

Peace,
Sean

Nebadon Izumi wrote: 
Frank give this a try , try logging into osgrid or
secondlife 2 times with the same account and tell me what happens, and
how do you think the SL viewer would respond if 30 peopel logged into
Wright Plaza with the name "Anonymous User" think beyond just the
login, think about functionaly using Chat and access things in world
that require checking the user name and delivering information to
them..  Personally i dont see this happening with the Linden Viewer,
but lets keep the topic rolling here, im not trying to shut it down,
perhaps someone can prove me wrong.

Nebadon




___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de 
https://lists.berlios.de/mailman/listinfo/opensim-dev 

-- 

Sean Hennessee
mailto:s...@uci.edu http://www.nacs.uci.edu/~sean
Central Computing Support
Network & Academic Computing Services
UC Irvine
(949)824-8225 Office
(949)293-5224 Cell


... . .- -. /   . -. -. . ... ... . .___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] anon logins

[Charles Krinke]

Mircea:

My apologies if your ideas were not credited properly. As I recall, you and 
others have suggested guest logins and I just thought this morning was a good 
time to open the discussion a little bit on our OS2B.

Charles





From: Mircea Kitsune 
To: opensim-dev mailing list 
Sent: Friday, January 23, 2009 10:03:57 AM
Subject: Re: [Opensim-dev] anon logins

 This is the same idea I discussed here a month ago which I brought up with the 
exact same vision. As I said then, we don't need
such a feature client-side in order to allow anonymous logins. Grids could 
enable
so called "guest logins" which would allow one to login with any first
name they want and a grid chosen last name that would be used for anonymous 
users (eg: Guest, Anonymous, Unregistered) and of course no
password. So to anon login, you would just use the names
AnyNameIWantHere Guest with no password, and if the grid allows be there as a 
guest. This feature is not yet
implemented for grid mode as far as I know but could be very useful. Guess this 
is +2 for the feature for now.


Date: Fri, 23 Jan 2009 08:54:01 -0800
From: c...@pacbell.net
To: opensim-dev@lists.berlios.de
Subject: [Opensim-dev] anon logins


One of the recurring themes is a suggestion that we encourage "anon" logins in 
the standalone and grid logic.

This would allow "guests" to logon and perhaps have a certain limited set of 
abilities. That is, to walk, chat, fly at a minimum, but not to be able to 
'take', 'edit', or perhaps limit teleports beyond the login region.

Anyway, I open this mini "Pandora's Box" to see if this is something that 
should be put on the list.

Charles


check out the rest of the Windows Live™.
More than mail–Windows Live™ goes way beyond your inbox. More than messages___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] anon logins

[Charles Krinke]

Overweight tourist with a camera like There.com ??

But, yes, that is another good question, how should we represent the avatar and 
what features should a sim allow to a guest avatar. All good things to consider 
as we evolve the Metaverse off into the future.

Personally, I would think a guest should have the ability to read notecards, 
experience scripts, probably be able to "touch". Things that would fit into the 
paradigm of a naive user entering the Metaverse for the first time.

I like the browser Xenkii idea. I rather suspect most of these folks will enter 
our Metaverse through some sort of browser interface as a result of a hyperlink 
on a 'Flat Web Site'.

Charles





From: Nebadon Izumi 
To: opensim-dev@lists.berlios.de
Sent: Friday, January 23, 2009 11:18:12 AM
Subject: Re: [Opensim-dev] anon logins

I think one thing also needs figuring out is how will appearance be handled for 
these users, personally i think Anonymous users should be something like a puff 
of smoke, and not Ruth or even Human appearance, it should be something obvious.

Neb
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

[Opensim-dev] OS2B Ideas

[Charles Krinke]

To get this discussion going on "OS2B Eve"... 

What are the things that are most important that OpenSim implement in the next 
year?

We all have our lists and I would think this is a good time to bring them out 
and discuss them a little bit.

Remember, the "audience" is really the core developers and those who would 
submit patches.

Our project is organized around "passion". He or she with a passionate idea 
works on it to implement it in C# in OpenSim.

Charles
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Proposal for a cleanup/correction of the region-module system

[Charles Krinke]

ROFL. Oh, it was the 'z' versus the 's' you were discussing.

I thought it was the "i" versus the "I".





From: Dahlia Trimble 
To: opensim-dev@lists.berlios.de
Sent: Saturday, January 24, 2009 4:39:03 PM
Subject: Re: [Opensim-dev] Proposal for a cleanup/correction of the 
region-module system

I'm not really a fan of UK zpelling,,, but I imagine people uzing grep could 
zearch for "initiali"

I'll probably continue to uze the UZ englizh zpelling in my code ;)



On Sat, Jan 24, 2009 at 4:32 PM, MW  wrote:

I have to say I'm not a big fan of what I've seen of mono.addins so far. Maybe 
ExtensionLoader is better, so I do think we should look at that. As I think it 
is better to only have one system of loading plugins/modules. 

As for initialise vs Initialize, hehe. Well personally I think it should stay 
as it is. I really see no reason to change it. I do know of other opensource 
projects that use initialise, Ogre being one. And it would be as hard for me to 
remember to look/search for Initialize as it would be for you to look for 
initialise.

So my vote is a strong keep to UK english or even the mix we have (because some 
bits are in US english). But I really don't think people should have to switch 
code that is there to US english. Sorry thats a point I do feel quite strongly 
on.

But saying that if everyone else voted in favour of that switch I wouldn't 
stand in the way. Just would think it was wrong. Any code I write is just 
likely to have uk spelling. The same way any code you write is likely to have 
US spelling. And opensim has had the UK spelling from the start.


Ryan McDougall  wrote:
On Sat, Jan 24, 2009 at 10:04 PM, Homer Horwitz

wrote:
> Hi all,
>
> the current system for handling region-modules is slightly broken if
> you add/remove regions dynamically (or even for region-restarts). I've
> put up some thoughts at
> http://opensimulator.org/wiki/New_Region_Modules for discussion.
> Please answer on the associated 'discussion' page or here on the list.
>
> Cheers,
>  Homer

I have two requests:

1. Can we unify RegionModules with IPlugin system I did a while ago?
This would mean learning and using Mono.Addins, or ExtensionLoader if
that is Mono.Addins's replacement.

Let's just use one system. I am not sure there is a semantic reason
why they should be different.

I didn't touch it myself because I didn't/don't understand the
delicate internals of RegionModules, and was worried about precisely
the sort of issues raised by Homer.

Also, Dispose() can be used in using{} statements. Lets use it, or
have a base class default to Dispose(){ Close(); }.

2. Can we standardize on US English?

I know our illustrious founder MW speaks the Queen's English, which is
the language of the educated; its not really fair to enforce the
linguistic hegemony of the country that spawned GWB and Britany Spears
in our dear pool of sanity and righteousness; but every open source
project I've ever worked on spells it Initialize. Including
Mono.Addins.

You have no idea how times I had to grep my source for "Initialize" in
order to make it compile. :(

Cheers,
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev


___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Conversion to IClientCore

[Charles Krinke]

This seems like a capital idea to me and will allow OpenSim to more easily have 
modules added for other, non-secondlife clients in the future in addition to 
making the current modrex project move more smoothly. So, lets get going.

I have looked at the http://opensimulator.org/wiki/OpenSim_0.6_IClientAPI page 
on the wiki and it seems reasonable.

I also looked at OpenSim/Framework/Client and see IClientCore.cs and two 
interface files, IClientIM.cs and ICLientChat.cs

So, as I understand the project, we are formally requesting patches to help 
migrate the 500 subroutines currently using IClientAPI to use IClientCore and 
when all the relevant subroutines have IClientCore implementations, we will 
deprecate the existing IClientAPI methods.

Charles

p.s. There are still 27 LSL functions in the "NotImplemented" state and even 
modest patches to have just some functionality would help. I would really like 
to get all the "NotImplemented" out of the source so we can declare the first 
phase of LSL implementation done in accordance with Tedd Hansen's vision.





From: "Frisby, Adam" 
To: "opensim-dev@lists.berlios.de" 
Sent: Sunday, January 25, 2009 3:49:35 PM
Subject: [Opensim-dev] Conversion to IClientCore

 
Hi guys,
 
I’ve been somewhat distracted lately getting ModRex up
and running that I haven’t had time to finish the conversion process I
started back in November from the IClientAPI interfaces to IClientCore ones. I
would like to see if we can get some additional people in writing patches to
add the new IClientCore interfaces.
 
The process is fairly simple, and I hope we can organise
some kind of effort ala the LSL-functions effort where a list is composed then
split up into discrete tasks that are more palletable to a community effort.
 
For those interested in the technical details of what needs
to be done – it’s a case of:
 
Phase 1
-  Find a group of functions and events in IClientAPI.cs that are 
related (eg, Chat, Parcels, TerrainData, etc)
-  Create a new IClient.cs file (eg IClientChat.cs) and cut and 
paste those functions and events into the new
interface.
-  Add “IClientType” to LLClientView.cs to
inherit from, and update the function at the bottom to Register the extra 
interface.
-  Rinse and Repeat until all functions have
IClient.cs’s.
 
Once we’ve added new interfaces for everything, it
becomes time to start porting over modules to use the newer interfaces
 
Phase 2
-  Find references to IClientAPI and replace them with
IClientCore equivilents. There’s a page on the wiki (“OpenSim
0.6 IClientAPI”) which contains examples and an example howto.
 
Anyone (Charles?) feel like drawing up the list of items to
be ported and begin the work?
 
Regards,
 
Adam___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] TSB Feasibility Study: Online Virtual Worlds for Urban Regeneration Consultation

[Charles Krinke]

Dear Mic:

I have heard from many folks that realistic terrain is an objective for a 
number of projects to represent real-life regions in a simulation, so I would 
vote +1 for any class, written details, tutorial, demo *or* whatever might get 
this knowledge spread around the Metaverse a bit.

Charles





From: Mic Bowman 
To: opensim-dev@lists.berlios.de
Sent: Thursday, January 29, 2009 8:36:16 AM
Subject: Re: [Opensim-dev] TSB Feasibility Study: Online Virtual Worlds for 
Urban Regeneration Consultation

FWIW...

There are two "plazas" on ScienceSim that use terrain built from GIS
data (Yellowstone National Park and Mt St Helens volcano... should be
one more 4x4 plaza coming soon). Feel free to come by and take a look
(hypergrid info for sciencesim is on the opensim wiki).

If there is interest, I would be happy to do a "class" on the process
I used to make those regions.

--mic


On Thu, Jan 29, 2009 at 7:14 AM, Dave Coyle  wrote:
> On 2009-01-25 16:13:35 -0500, m...@tola.me.uk wrote:
>> As for OpenSim, I'm still exploring (though I'm running out of time). The 
>> Orcas
>> island example  that Nebadon posted a link to is quite neat (or at least the
>> improved version linked to from the blog post) and the Berkeley simulation 
>> from
>> lidar images also provides a good example.
>
> Another link which might be useful.. generating OpenSim terrain maps
> from USGS DEM data:
>
>http://www.ics.uci.edu/~lopes/terraingen/
>
> -Coyle
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] RegionOnline status

[Charles Krinke]

Well, there are a few use cases from a grid standpoint that might be worth 
considering.

1. Being able to reserve a block of X,Y for a particular group or orgainization.
2. Being able to allow some to bring down a region and know that the same X,Y 
is available after update, maintenance, whatever.

>From the standpoint of operating OSGrid, which admiteddly is a bit unusual use 
>case, having a region reservation would allow grid admins to make a 
>reservation for an individual or an organization and also ensure that the same 
>X,Y is available when the region owner brought their region back up again.

Charles





From: Frank Nichols 
To: opensim-dev@lists.berlios.de
Sent: Monday, February 2, 2009 8:50:25 PM
Subject: Re: [Opensim-dev] RegionOnline status

To me the region does not need to know if or when the reserved status 
would expire. Some process/module must have set it to reserved, and to 
me would then assume the responsibility of knowing when/if to expire the 
reservation.

Dahlia Trimble wrote:
> I would think if a "RESERVED" state were added there would probably 
> need to be an expiration date associated with it.
>
> On Sat, Jan 31, 2009 at 8:23 PM, Frank Nichols  > wrote:
>
> There is a member in RegionProfileData (regionOnline) which is
> currently
> not used and does not exist in the region db table. I would like
> to add
> it to the region table as an enum and not a boolean. Currently the
> code
> assumes a region that has an entry in the region table is online
> (as far
> as I have figured out...) With this field in place we can
> impliment the
> requested feature of reserving regions as well as having regions
> online
> but not available for logins. I suggest the following enums:
>
> RESERVED
> OFFLINE
> ONLINE
>
> at least for starters.
>
> Before submitting a patch to support this, i wanted to get some
> direction and comments from the core developers and architects.
>
> Frank
> ___
> Opensim-dev mailing list
>Opensim-dev@lists.berlios.de 
>https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
> 
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>  

___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

[Opensim-dev] AssetServer Observations and Suggestions

[Charles Krinke]

We have been studying the assets table on OSGrid as it heads toward the "disk 
full" stage and I have a couple of observations and am heading towards a 
suggestion. Maybe this is already accounted for in the "Cable Beach" project, 
at which point, this will only indicate that I did not read all the exchanges 
carefully enough.

It appears to me that we are storing on the MySQL data store at the assetServer 
on a grid every edit of every script, terrainImage and clothingItem amongst 
other things. So, my first observation is that we appear to be storing all the 
older, obsolete items that can no longer be accessed.

Additionally, it appears to me that we are also storing things that could 
arguably be stored on the regions datastore, such as the terrainImage.

Now, to the beginnings of a suggestion. It seems to me that each avatar will 
have a "home" region. And that perhaps that is the place to store the items in 
an avatars inventory. Things like scripts, notecards, textures and the like. 

At that point, the assetServer on a grid could be used to store only pointers 
(or URL's) to each avatars inventory on his or her home region.

So, by doing that, we start shifting the ever increasing disk storage 
requirements of a grid back to the regions distributed around the internet.

Again, perhaps Cable Beach is already doing this, and if so, this is great. If 
not, I put out these ideas and duck as the tomatoes start flying.

Charles
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] AssetServer Observations and Suggestions

[Charles Krinke]

Well, lets see if we can disect the problem a bit more and maybe take these 
issues one at a time.

I believe it may be a reasonable argument that the terrain of a region is a 
property of the region so that a regions terrain should be stored in the 
regions database and not on the assetServer database. In particular, I would 
argue that all the old terrain edits should be deleted from the assetServer 
database as they are not accessible or useful anymore.

Without even getting into any issues of inventory across regions, lets see if 
we can find a consensus on handling the current "terrainImage" that is stored 
on the assetServer and then go to another issue. I pick this one first as it 
seems more clearcut, but lets see how the discussion goes.

Charles





From: Melanie 
To: opensim-dev@lists.berlios.de
Sent: Sunday, February 8, 2009 12:37:52 PM
Subject: Re: [Opensim-dev] AssetServer Observations and Suggestions

Hi,

I think while some alternate scenarios are possible, the real 
solution lies in pure "storage providers" that a user subscribes to, 
and which are grid-independent, or in local storage on the user's 
hard disk.

In the interim, we should maybe create a means to determine which 
assets can be discarded. SPecifically, scan eacha nd every prim 
asset to determine referenced textures and content items. Scan each 
region to determine inworld item asset references. Tag all items not 
found, wait a while, then judiciously delete.

Basically, the only resources that a script will reference by UUID 
are textures and sounds. Animations cannot be referenced by UUID, 
neither can other prim objects, unless god mode rez is used.
Wearables can't be referenced by asset ID either, so these will 
always have an inventory item, be it in user inventory or inworld. I 
believe that within about 6 months, equilibrium will be reached, 
e.g. a point where growth in the asset database is proportional to 
the actual number of new items created, rather than just old copies 
of edited items.

Assets on region is a bad idea, IMHO, because it means that region 
operators are responsible for the inventories of users who have no 
region at all, and user inventories would be available only if that 
region happens to be up. in OSGrid, that can't be depended on.

Melanie


Frank Nichols wrote:
> I like the idea of shifting responsibility for user storage costs closer 
> to the user. Region maybe a good place to do this.
> 
> Frank
> 
> Charles Krinke wrote:
>> We have been studying the assets table on OSGrid as it heads toward 
>> the "disk full" stage and I have a couple of observations and am 
>> heading towards a suggestion. Maybe this is already accounted for in 
>> the "Cable Beach" project, at which point, this will only indicate 
>> that I did not read all the exchanges carefully enough.
>>
>> It appears to me that we are storing on the MySQL data store at the 
>> assetServer on a grid every edit of every script, terrainImage and 
>> clothingItem amongst other things. So, my first observation is that we 
>> appear to be storing all the older, obsolete items that can no longer 
>> be accessed.
>>
>> Additionally, it appears to me that we are also storing things that 
>> could arguably be stored on the regions datastore, such as the 
>> terrainImage.
>>
>> Now, to the beginnings of a suggestion. It seems to me that each 
>> avatar will have a "home" region. And that perhaps that is the place 
>> to store the items in an avatars inventory. Things like scripts, 
>> notecards, textures and the like.
>>
>> At that point, the assetServer on a grid could be used to store only 
>> pointers (or URL's) to each avatars inventory on his or her home region.
>>
>> So, by doing that, we start shifting the ever increasing disk storage 
>> requirements of a grid back to the regions distributed around the 
>> internet.
>>
>> Again, perhaps Cable Beach is already doing this, and if so, this is 
>> great. If not, I put out these ideas and duck as the tomatoes start 
>> flying.
>>
>> Charles
>> 
>>
>> ___
>> Opensim-dev mailing list
>> Opensim-dev@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>  
> 
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> 
> 
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] AssetServer Observations and Suggestions

[Charles Krinke]

Well, with all due respect to all, and I do respect you all, currently I am 
trying to focus on a couple of issues in the current C# logic and see if we can 
get a consensus on changing a couple of details that will help us move closer 
to a reasonable long-term strategy.

The things I am looking at right now are:

1) Some items which are currently stored on the assetServer at the gridlevel 
that could arguably be stored at the region level instead, such as a regions 
terrainImage.

2) Some items which when edited, create a new entry that is stored on the 
assetServer with a new random UUID and as a consequence, the previous item 
stored are orphaned and unavailable to the creator at all.

3) The issue that "access_time" may not be updated in all cases.

It seems to me that solving these three issues with our existing C# logic, or 
having "Cable Beach" make some progress by solving these issues helps us move 
along.

As a couple of examples:

Each terrain edit appears to create a new "terrainImage" entry in the assets 
table and each time that happens, all previous terrain images become unlinked, 
unusable and unnecessary. A similar thing happens with scripts, notecards, and 
clothes. Prims themselves are stored in the regions datastore, so they dont 
apply to this discussion.

A MySQL query of the form: select count(*) from assets where 
access_time="0";should be decreasing on an ongoing basis. Perhaps some 
could start checking this and looking for occurences where a fetch or an edit 
of an item from the assets table do not update the access_time. It is my hope 
that searching by access_time will be at least one method of identifying 
unusable entries that should be deleted.

Charles





From: Tommi Laukkanen 
To: opensim-dev@lists.berlios.de
Sent: Sunday, February 8, 2009 1:55:02 PM
Subject: Re: [Opensim-dev] AssetServer Observations and Suggestions


I like the idea of grid independent storage providers (assets and inventories). 
It is in analogy with open id providers which are application independent 
identity providers. The challenge with both is that the UUID should always be 
accompanied by the provider url unless we have a way to resolve provider URL 
from asset UUID.  In other words if Frank will have texture asset on his avatar 
with given UUID it does not get me anywhere unless I have a way to find out 
from which URL I can actually download that asset. You can hide this from the 
viewer program and implement it in region services for example but ultimately 
you will still face the same problem. If we want simple engineering solution 
which works in all situations we should figure out how we will solve mapping 
from asset UUID to provider service URL. Possible solutions:
 
1) Use keys which consists of UUID and asset provider URL instead of just 
UUID's (not very practical when you store the key to database)
2) Have distributed registry with maps UUIDs and provider URLs. This might be 
even theoretically impossible as they amount of keys in the distributed 
registry would be same as all the assets in the internet. Could this be 
resolved by allocating UUIDs to different nodes based on somekind of UUID hash 
value?
3) Try to hard wire asset access to correct repository behind the scenes. In 
other words in HG region all avatars would notify the region which is their 
asset provider and region will broker the asset calls to correct asset 
provider. Client in turn assumes that each region may have separate asset 
server and queries assets separately from each region. This is not very clean 
solution and can result in quite complex overall system.
 
Number 2 would be good for enforcing uniqueness of UUID's so that it is not 
possible to manually copy an asset and steal the identity by using the same 
UUID. So this registry could be used to also store ownerhship rights for UUIDs.
 
Work name: Distributed Identity Ownerhship and Provider Registry
 
best regards,
Tommi Laukkanen

On Sun, Feb 8, 2009 at 11:21 PM, Paul Fishwick  wrote:

On the observation that most multi-player games have asset stored
client-side,
thus allowing huge and feature-rich worlds, it would be nice to have an
option ("private assets", "fixed assets" perhaps indicated by land
parcel ?) that required people who wanted to take advantage of
interacting there to first download all assets prior to launching
the viewer. Having both ends of the spectrum (at one end, all
startup assets are private and non-dynamically shared and at the other
end, all assets are dynamically loaded to each connecting client)
would provide more flexibility and some detailed spaces.

-p


Frank Nichols wrote:
> I like the idea of shifting responsibility for user storage costs closer
> to the user. Region maybe a good place to do this.
>
> Frank
>
> Charles Krinke wrote:
>
>> We have been studying the assets table

Re: [Opensim-dev] AssetServer Observations and Suggestions

[Charles Krinke]

Dear Mike:

What you say seems reasonable and I applaud you.

On the related subject of mutability, I have a tough time imagining that each 
edit of the terrain of a region is useful. I would suggest that only the last 
"terrainImage" is useful and cannot imagine any reference to any obsolete 
terrainImage by any object anywhere.

There are a significant number of items in OpenSim mysql databases such as the 
various edits of a script where we appear to be storing a new UUID for each 
edit. In a similar manner, I would think that such obsolete edits are not 
useful.

So, half of the problem is a strategy to slow down the bloat of our 
assetServers with perhaps additional references to additional assetServers and 
half is to perhaps re-consider all the orphaned items we are leaving in our 
mysql database and find a way to stop doing that.

Charles





From: Mike Mazur 
To: opensim-dev@lists.berlios.de
Sent: Sunday, February 8, 2009 6:11:46 PM
Subject: Re: [Opensim-dev] AssetServer Observations and Suggestions

Hi,

On Sun, 8 Feb 2009 10:13:45 -0800 (PST)
Charles Krinke  wrote:

> We have been studying the assets table on OSGrid as it heads toward
> the "disk full" stage and I have a couple of observations and am
> heading towards a suggestion. Maybe this is already accounted for in
> the "Cable Beach" project, at which point, this will only indicate
> that I did not read all the exchanges carefully enough.
> 
> It appears to me that we are storing on the MySQL data store at the
> assetServer on a grid every edit of every script, terrainImage and
> clothingItem amongst other things. So, my first observation is that
> we appear to be storing all the older, obsolete items that can no
> longer be accessed.

This ever-expanding asset database is a consequence of how assets are
handled by SL, the SL viewer and, since OpenSim was first developed
against the SL viewer, by OpenSim as well. The premise is that no asset
is mutable, because any asset may be referenced by its UUID. The
reference may exist in a script or on the back of a napkin. There are
more details (the way I understand them) in a previous email[1] I sent
to the list.

Cable Beach will not solve this problem.

> Now, to the beginnings of a suggestion. It seems to me that each
> avatar will have a "home" region. And that perhaps that is the place
> to store the items in an avatars inventory. Things like scripts,
> notecards, textures and the like. 

I'm not sure this is the right way forward. It requires that the user's
home region is up anytime they wish to use their avatar and access
their inventory. The user's home region becomes a single point of
failure.

> At that point, the assetServer on a grid could be used to store only
> pointers (or URL's) to each avatars inventory on his or her home
> region.

This is a good start, except instead of pointing to the user's home
region, it could point to the user's own asset server. The asset server
could be provided by a grid (OSGrid), their own asset server (a Cable
Beach instance, perhaps), or some other third party that may provide
asset storage/access in the future (SL, Yahoo!, Google, AOL, etc).

Thanks,
Mike


[1]
https://lists.berlios.de/pipermail/opensim-dev/2008-December/004053.html
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] what are the core region modules? which are not?

[Charles Krinke]

SDague has a good point. And it gets a bit more interesting when one considers 
the OSSearch module, which did become non-functional a few days ago and folks 
have been scrambling and struggling to get their regions back in operation.

It could be argued that bringing that active module, which is one small C# file 
into SVN might be to our advantage for the same reasons we are discussing here.

Charles




From: Sean Dague 
To: opensim-dev@lists.berlios.de
Sent: Monday, February 9, 2009 11:30:59 AM
Subject: Re: [Opensim-dev] what are the core region modules? which are not?

Dahlia Trimble wrote:
> When a module moves out of core and to forge, what process would be in place
> to make sure these modules remain compatible when possibly breaking changes
> are made to core? I use the IRC module in some of my regions and I wouldn't
> want to see it broken, and I like to stay close to head in all of my regions
> so I can be more aware of how development progresses. As such I would
> potentially vote -1 on taking IRC out of core until there is some way to
> maintain functionality as core evolves.

I'm personally all for moving thinks to an Optional space, but we have
to be honest with ourselves, moving a module to the forge means that
there is a better than 50% chance it's unusable in 2 weeks time.  I
think for things we've considered "dead" that's fine, but I'd be
reluctant to push bits out that people do regularly use (like the irc
bridge).  At least until we have:

1. an easy way to build an out of core module build tree
2. network repository support for modules (ala what's in mono addins)
3. some type of versioning on module interfaces, so we can know if a
plugin thinks it can work with the current build

Otherwise we are more or less jetisoning a lot of features and reducing
the number of users that we can serve out of the box.  The same logic
that would leave these modules in the tree is the same logic that keeps
all the extra stuff in bin/, to make it easy for the new user to get
started.

This shouldn't stop this current level of reorganization, which I think
is very useful.  But is just a warning on next steps of removing things
from the tree.

-Sean

-- 
Sean Dague / Neas Bade
sda...@gmail.com
http://dague.net___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Groups in OpenSim

[Charles Krinke]

Dear Ruud:

Regardless of whether anyone is working on it or not, all contributions are 
welcome. I would think the thing to do is start with a vision, discuss with 
others, add patches to Mantis and repeat.

Along the way, others may contribute and we can all learn together.

So, I would encourage you, and others, to add to our groups source as time and 
passion allows.

Charles





From: Ruud Lathrop 
To: opensim-dev@lists.berlios.de
Sent: Thursday, February 12, 2009 7:46:41 AM
Subject: [Opensim-dev] Groups in OpenSim

Hi,

Does anybody know if somebody is working on features to implement Groups? I see 
a GroupsModule in Core.Avatar. But that doesn't hold much implementation. 

If nobody is building that, how can I start working on something like that?

Ruud ___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Groups in OpenSim

[Charles Krinke]

Personally, I would suggest that "groups" is an enabling technology and I would 
concur that seperating economy notions from groups is a good thing.

For "groups" functionality, the ability to form groups and have group 
communicaton similar to our IRC channels currently would go a long ways to 
fleshing out and testing additional functionality under load. We need to use 
our sims more to understand where the limits are.

Additionally, adding the logic for group ownership of land and objects will 
help us get closer to a reasonable permissions model and thence closer to 0.7 
for OpenSim.

Charles





From: Justin Clark-Casey 
To: opensim-dev@lists.berlios.de
Sent: Sunday, February 15, 2009 10:52:06 AM
Subject: Re: [Opensim-dev] Groups in OpenSim

Frisby, Adam wrote:
> My personal thoughts would be definitely host on the gforge until 
> completion, then decide on whether it goes into core or not (same as 
> hypergrid).

Personally, considering the modules that are in OpenSim core at the moment, I 
think that a groups module could 
definitely be considered a core module from the outset (and so be developed in 
core).  It's by far the biggest piece of 
missing functionality for both an SL-like environment and many of the other 
virtual environments that one can imagine.

However, having said that it's not as if people have been rushing to implement 
groups code in core - it has been a 
requested piece of unimplemented functionality for a long time.  So it might be 
more convenient to develop it outside 
core if non-core developers are going to be working on it.

I guess the situation might be somewhat different again if the groups module 
also implements integration to other 
systems (perhaps commercial ones) which would be more controversial to place in 
core.  Though then again I would hope 
that such functionality could be split into further modules, with just the main 
groups code going into core.

btw, Mike - very glad to see your sponsorship of this as public domain code.  
And I very much understand your reluctance 
to talk about sponsored development that hasn't yet been agreed.  All I would 
say is that the more open everything is, 
the more smoothly everything seems to go in terms of getting code adopted and 
in terms of interacting with the wider 
OpenSim community.

> 
>  
> 
> Regards,
> 
>  
> 
> Adam
> 
>  
> 
> *From:* opensim-dev-boun...@lists.berlios.de 
> [mailto:opensim-dev-boun...@lists.berlios.de] *On Behalf Of *Michael 
> Huntington
> *Sent:* Friday, 13 February 2009 12:55 PM
> *To:* opensim-dev@lists.berlios.de
> *Subject:* Re: [Opensim-dev] Groups in OpenSim
> 
>  
> 
> Well, I don't mind sharing a little info.. but remember we're still in 
> planning stages and getting the feature list together. Also I personally 
> don't have a problem having this project open during development. So 
> I'll let Adam and the DeepThink team decide on that... I'll host any 
> files if needed or we can use opensim's gforge. All, I'm doing is 
> sponsoring this project.. because I know how much the community would 
> like groups and other features up and running. 
> 
>  
> 
> Basically we're working on getting economy and groups running.. and 
> hopefully if Diva accepts our offer, we can get groups working across 
> the Hypergrid... (still working on that). DeepThink already has a list 
> of features listed for how we can safely and securely implement groups 
> and economy.
> 
>  
> 
> Again, I'm not the most tech savvy person.. I'm just sponsoring this.. 
> so Adam can share as much info as he likes.. once we come to a 
> conclusion on what the exact features will be ... but so far it seems he 
> understands what we're looking for in the project.
> 
>  
> 
> On Fri, Feb 13, 2009 at 3:49 PM, Frisby, Adam  > wrote:
> 
> I think the consensus with Mike is to develop it on the forge, but I'll 
> let him speak for me here since he's sponsoring it and I don't want to 
> say anything  that may be wrong.
> 
>  
> 
> Regards,
> 
>  
> 
> Adam
> 
>  
> 
> *From:* opensim-dev-boun...@lists.berlios.de 
>  
> [mailto:opensim-dev-boun...@lists.berlios.de 
> ] *On Behalf Of *Dahlia Trimble
> *Sent:* Friday, 13 February 2009 12:48 PM
> 
> 
> *To:* opensim-dev@lists.berlios.de 
> *Subject:* Re: [Opensim-dev] Groups in OpenSim
> 
>  
> 
> Agreed... something like groups is too complex to be submitted all at 
> once, unless it's a module in forge. I've been working on group chat 
> infrastructure and this could cause conflict unless it's developed in an 
> open manner.
> 
> On Fri, Feb 13, 2009 at 12:43 PM, Justin Clark-Casey 
> mailto:jjusti...@googlemail.com>> wrote:
> 
> Frisby, Adam wrote:
>  > Yep, Mike here has graciously offered to have us develop it for the 
> public domain. With a little luck we should be starting this one so

Re: [Opensim-dev] Please do not revert fixes without careful comtemplation

[Charles Krinke]

Sorry, the other assets are not just "small texture data". We have 
terrainImages, amongst other things.

Our assets table in OpenSim contains lots of things including the infamouse 
"blank", so lets look at it in total and not just from the script viewpoint. 

Course with scripts themselves, we have every edited version of every edited 
script in addition to every change of every other asset complicating the 
problem.

Charles





From: Melanie 
To: opensim-dev@lists.berlios.de
Sent: Monday, February 16, 2009 4:44:56 AM
Subject: Re: [Opensim-dev] Please do not revert fixes without careful 
comtemplation

Again, I'd like to stress that I believe this is too dangerous to do 
for anything other than textures.
It is also not really needed for things other than textures, since 
the other assets are comparatively small, textural data.

I would not want to risk even the smallest chance of a hash 
collision on script source.

Melanie

Stefan Andersson wrote:
> Coming in a bit from the side here,
> 
>  
> 
> we have, for some time, discussed to separate out the binary blog out of the 
> metadata for an entirely different reason, namely to be able to weed out 
> binary duplicates.
> 
> 
> If there was a way for us to separate out the binary parts, into something 
> like 'binaryassetId, hashData[256], binarydata' and then just have the asset 
> table referencing that row, I think it would help a lot.
>  
> 
> I realize it's a separate discussion, just chipping in my two cents.
> 
> 
> Best regards,
> Stefan Andersson
> Tribal Media AB
> 
> 
> 
>  
> 
> 
> Date: Sat, 14 Feb 2009 17:49:22 +0200
> From: tommi.s.e.laukka...@gmail.com
> To: mma...@gmail.com
> CC: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] Please do not revert fixes without careful 
> comtemplation
> 
> 
> Hello,
>  
> On second though we could keep the current structure and expose all fields 
> also through AssetBase properties. Then we could save / load the AssetBase 
> with nhibernate as a single object and leave out the Metadata  property from 
> NHibernate mapping. Does this sound good?
>  
> regards,
> Tommi
> 
> 
> On Sat, Feb 14, 2009 at 5:06 PM, Mike Mazur  wrote:
> 
> Hi,
> 
> On Sat, Feb 14, 2009 at 4:05 PM, Tommi Laukkanen
> 
>  wrote:
> 
>> I was talking with mikkopa and he suggested we should create two tables to
>> cover AssetBase to solve this issue properly. Namely AssetMetadata for
>> metadata information and AssetData for blobs to avoid situation where we end
>> up accessing also the blob data just to read metadata.
> 
> I was hoping not to have to do that.
> 
> It should be straightforward to support the current
> AssetBase/AssetMetadata composition in the existing OpenSim data
> layers, but as sdague warned me earlier, by mapping multiple classes
> to one table I was entering a world of pain. Seems that's exactly
> what's happening with NHibernate.
> 
> The reason I introduced the AssetMetadata class is to supply metadata
> information only for some requests that Cable Beach, the new asset
> server, supports. Now I realize that this was probably a premature
> optimization.
> 
> Instead of modifying the DB schema, we could have AssetBase inherit
> from AssetMetadata, as I outlined before[1]. Alternatively, we could
> get rid of AssetMetadata altogether and store everything in AssetBase
> as before, splitting out the metadata sometime in the future when a
> use case warrants it.
> 
> What do you think?
> 
> Thanks,
> Mike
> 
> 
> [1] https://lists.berlios.de/pipermail/opensim-dev/2009-February/004918.html
> 
> 
> 
> 
> 
> 
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Please do not revert fixes without careful comtemplation

[Charles Krinke]

I am so sorry that we are having communications difficulties.

Terrain Images, are, I believe, neither "textual" nor "text".

That was just an example.

The point is that we need to be careful and consider all the various assets 
which include a lot more then textures and scripts.

Charles





From: Melanie 
To: opensim-dev@lists.berlios.de
Sent: Monday, February 16, 2009 8:23:16 AM
Subject: Re: [Opensim-dev] Please do not revert fixes without careful 
comtemplation

Hello,

that was a typo. The correct word was "textual". All asset types 
besides textures are text.

Melanie

Charles Krinke wrote:
> Sorry, the other assets are not just "small texture data". We have 
> terrainImages, amongst other things.
> 
> Our assets table in OpenSim contains lots of things including the infamouse 
> "blank", so lets look at it in total and not just from the script viewpoint. 
> 
> Course with scripts themselves, we have every edited version of every edited 
> script in addition to every change of every other asset complicating the 
> problem.
> 
> Charles
> 
> 
> 
> 
> 
> From: Melanie 
> To: opensim-dev@lists.berlios.de
> Sent: Monday, February 16, 2009 4:44:56 AM
> Subject: Re: [Opensim-dev] Please do not revert fixes without careful 
> comtemplation
> 
> Again, I'd like to stress that I believe this is too dangerous to do 
> for anything other than textures.
> It is also not really needed for things other than textures, since 
> the other assets are comparatively small, textural data.
> 
> I would not want to risk even the smallest chance of a hash 
> collision on script source.
> 
> Melanie
> 
> Stefan Andersson wrote:
>> Coming in a bit from the side here,
>> 
>>  
>> 
>> we have, for some time, discussed to separate out the binary blog out of the 
>> metadata for an entirely different reason, namely to be able to weed out 
>> binary duplicates.
>> 
>> 
>> If there was a way for us to separate out the binary parts, into something 
>> like 'binaryassetId, hashData[256], binarydata' and then just have the asset 
>> table referencing that row, I think it would help a lot.
>>  
>> 
>> I realize it's a separate discussion, just chipping in my two cents.
>> 
>> 
>> Best regards,
>> Stefan Andersson
>> Tribal Media AB
>> 
>> 
>> 
>>  
>> 
>> 
>> Date: Sat, 14 Feb 2009 17:49:22 +0200
>> From: tommi.s.e.laukka...@gmail.com
>> To: mma...@gmail.com
>> CC: opensim-dev@lists.berlios.de
>> Subject: Re: [Opensim-dev] Please do not revert fixes without careful 
>> comtemplation
>> 
>> 
>> Hello,
>>  
>> On second though we could keep the current structure and expose all fields 
>> also through AssetBase properties. Then we could save / load the AssetBase 
>> with nhibernate as a single object and leave out the Metadata  property from 
>> NHibernate mapping. Does this sound good?
>>  
>> regards,
>> Tommi
>> 
>> 
>> On Sat, Feb 14, 2009 at 5:06 PM, Mike Mazur  wrote:
>> 
>> Hi,
>> 
>> On Sat, Feb 14, 2009 at 4:05 PM, Tommi Laukkanen
>> 
>>  wrote:
>> 
>>> I was talking with mikkopa and he suggested we should create two tables to
>>> cover AssetBase to solve this issue properly. Namely AssetMetadata for
>>> metadata information and AssetData for blobs to avoid situation where we end
>>> up accessing also the blob data just to read metadata.
>> 
>> I was hoping not to have to do that.
>> 
>> It should be straightforward to support the current
>> AssetBase/AssetMetadata composition in the existing OpenSim data
>> layers, but as sdague warned me earlier, by mapping multiple classes
>> to one table I was entering a world of pain. Seems that's exactly
>> what's happening with NHibernate.
>> 
>> The reason I introduced the AssetMetadata class is to supply metadata
>> information only for some requests that Cable Beach, the new asset
>> server, supports. Now I realize that this was probably a premature
>> optimization.
>> 
>> Instead of modifying the DB schema, we could have AssetBase inherit
>> from AssetMetadata, as I outlined before[1]. Alternatively, we could
>> get rid of AssetMetadata altogether and store everything in AssetBase
>> as before, splitting out the metadata sometime in the future when a
>> use case warrants it.
>> 
>> What do you think?
>> 
>> Thanks,
>> Mike
>> 
>> 
>> [1] 

Re: [Opensim-dev] Any OpenSim viewers being built from scratch?

[Charles Krinke]

Dear Mike: 

As Dahlia said, the IdealistViewer is a good candidate as it begins to add 
features. Many of us have high hopes for IdealistViewer during the course of 
this year.


As OpenSim, we have decided to stay in SecondLife viewer compatible so we are 
measuring the operation and performance of OpenSim against the current 
SecondLife official viewer, currently 1.21.6. This does change from time to 
time and when it changes, we strive to stay compatible.

This SecondLife viewer represents the largest set of users for OpenSim, so this 
seems like a reasonable decision.

It is entirely probable that other viewers such as Hippo, IdealistViewer, 
OpenViewer, Xenkii, Rex and others will become widely adopted and we hope that 
will happen. We also hope that they will stay compatible with the SecondLife 
viewer, but as 2009 unfolds, it will be very interesting to see what happens.

Charles




From: Michael Huntington 
To: opensim-dev@lists.berlios.de
Sent: Monday, February 16, 2009 1:44:04 PM
Subject: [Opensim-dev] Any OpenSim viewers being built from scratch?

I know this isn't a viewer related dev group... but...I was wondering if anyone 
was building a viewer that wasn't so tied down to SecondLife? Basically a 
viewer that has been built from the ground up with OpenSim in mind.

The viewers so far have been the biggest OpenSim eyesore for me... if anyone 
knows of a viewer project targeted for OpenSim or knows someone interested in 
starting that kind of project please let me know or forward my email to them.

Thanks!___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Please do not revert fixes without careful comtemplation

[Charles Krinke]

Well, it really doesnt matter what one calls them. Binary data, text, whatever.

The point is that we have a number of issues with our assets table in OpenSim 
that a bit of thought would help.

1. We have a significant number of assets whose name is "blank" that are 
created with a default constructor. And I suspect are never accessible.
2. We have a significant number of assets of each and every edit of terrain, 
where only the very last one is accessible.
3. We have a significant number of assets of each and every text edit for each 
and every textual assets. Where only the last one should be accessible.

Its a bit like collecting every scrap of paper ever written with either text or 
binary glyphs and putting them in a big filing cabinet.

After a while, finding the ones that are "interesting" in a "timely" manner 
starts to get a little "challenging".

Charles





From: Melanie 
To: opensim-dev@lists.berlios.de
Sent: Monday, February 16, 2009 4:43:53 PM
Subject: Re: [Opensim-dev] Please do not revert fixes without careful 
comtemplation

Yes, I did forget sounds. Probably because they never reached 
critical mass on any system I have anything to do with. Though, a 
lot seem to exist, judged by the number of gestures.
As for images, I call them all "textures", because any image could 
be used as a texture. They are all jp2 steams, so even though they 
may have a different purpose from covering prims, they are 
technically identical in storage format and type of content, and 
would be handled the same.

Melanie

Justin Clark-Casey wrote:
> Melanie wrote:
>> No. Terrain images are textures. They are assets referring to jp2 
>> streams. That makes them textures. And, AFAIK, all other assets are 
>> text.
> 
> Other non-text assets are images that aren't textures and sounds.
> 
>> 
>> Melanie
>> 
>> Charles Krinke wrote:
>>> I am so sorry that we are having communications difficulties.
>>>
>>> Terrain Images, are, I believe, neither "textual" nor "text".
>>>
>>> That was just an example.
>>>
>>> The point is that we need to be careful and consider all the various assets 
>>> which include a lot more then textures and scripts.
>>>
>>> Charles
>>>
>>>
>>>
>>>
>>> 
>>> From: Melanie 
>>> To: opensim-dev@lists.berlios.de
>>> Sent: Monday, February 16, 2009 8:23:16 AM
>>> Subject: Re: [Opensim-dev] Please do not revert fixes without careful 
>>> comtemplation
>>>
>>> Hello,
>>>
>>> that was a typo. The correct word was "textual". All asset types 
>>> besides textures are text.
>>>
>>> Melanie
>>>
>>> Charles Krinke wrote:
>>>> Sorry, the other assets are not just "small texture data". We have 
>>>> terrainImages, amongst other things.
>>>>
>>>> Our assets table in OpenSim contains lots of things including the 
>>>> infamouse "blank", so lets look at it in total and not just from the 
>>>> script viewpoint. 
>>>>
>>>> Course with scripts themselves, we have every edited version of every 
>>>> edited script in addition to every change of every other asset 
>>>> complicating the problem.
>>>>
>>>> Charles
>>>>
>>>>
>>>>
>>>>
>>>> 
>>>> From: Melanie 
>>>> To: opensim-dev@lists.berlios.de
>>>> Sent: Monday, February 16, 2009 4:44:56 AM
>>>> Subject: Re: [Opensim-dev] Please do not revert fixes without careful 
>>>> comtemplation
>>>>
>>>> Again, I'd like to stress that I believe this is too dangerous to do 
>>>> for anything other than textures.
>>>> It is also not really needed for things other than textures, since 
>>>> the other assets are comparatively small, textural data.
>>>>
>>>> I would not want to risk even the smallest chance of a hash 
>>>> collision on script source.
>>>>
>>>> Melanie
>>>>
>>>> Stefan Andersson wrote:
>>>>> Coming in a bit from the side here,
>>>>>
>>>>>  
>>>>>
>>>>> we have, for some time, discussed to separate out the binary blog out of 
>>>>> the metadata for an entirely different reason, namely to be able to weed 
>>>>> out binary duplicates.
>>>>>

Re: [Opensim-dev] Please do not revert fixes without careful comtemplation

[Charles Krinke]

Dear Teravus:

No problem. The key point I was trying to make is that as time goes on we seem 
to be increasing exponentially the storage requirements in the UGAIM assets 
table. The terrainImage entry was an example of of an 'asset' that is a little 
different in perception then say, a texture covering a face of a prim.

This example was intended for us to think about those 'assets' which can be 
pruned on a regular basis so that our ability from the UGAIM viewpoint to find 
and retrieve an asset in a timely manner does not get so long as to make our 
sims performance degraded.

Charles





From: Teravus Ovares 
To: opensim-dev@lists.berlios.de
Sent: Tuesday, February 17, 2009 6:39:52 AM
Subject: Re: [Opensim-dev] Please do not revert fixes without careful 
comtemplation

I thought it prudent to point out that the following statement is 100% fiction;

" 2. We have a significant number of assets of each and every edit of
terrain, where only the very last one is accessible"

What I think you meant to say was,

"2. Every two days each region generates a new map tile image and
names it terrainImage.  These do eventually add up"

Best Regards

Teravus

On Tue, Feb 17, 2009 at 9:31 AM, Stefan Andersson  wrote:
>
>> > 1. We have a significant number of assets whose name is "blank" that are
>> > created with a default constructor. And I suspect are never accessible.
>>
>> In fact, this field has always seemed redundant to me since the user only
>> ever manipulates assets by their inventory
>> name, which is entirely separate from the asset name. The asset name is
>> never visible to the user (and afaik is not
>> used anywhere else in the code).
>>
>> At one point I thought about proposing to remove it. Possibly this issue
>> should be revisited.
>
> I believe it's kept there just as a convenience - to be able to get some
> kind of semantics, not necessarily exact, when browsing the table.
>
>> > 2. We have a significant number of assets of each and every edit of
>> > terrain, where only the very last one is accessible.
>>
>> Yes, this does seem wasteful to me since old terrain assets are not used
>> by anything, afaik.
>
> I have proposed a number of times that we could have a virtual asset_key as
> well as an asset_id - so that things that would rewrite assets could use the
> asset_key as an aux method to actually try to overwrite the asset. In the
> terrain case, the asset would be overwritten by key, not by id. This would
> allow us to implement a number of parallell schemas where some assets would
> be overwritten (asset_key = asset_id) and some where we would keep a history
> (only asset_key) and some where doing either or would be configurable.
>
>> > 3. We have a significant number of assets of each and every text edit
>> > for each and every textual assets. Where only the last one should be
>> > accessible.
>>
>> Unfortunately, this is not the case. For instance, imagine that you create
>> a script in your inventory. You drag this
>> script into a region object. At this point, both the entry in your
>> inventory and the entry in the region point to the
>> same textual asset.
>>
>> But then you edit the script in your inventory. After the edit it points
>> to a new asset containing the edited text.
>> However, the region object is still pointing to the old script asset. So
>> we need to keep both the old and new textual
>> assets.
>
> Not to mention the fact that the viewer caches stuff.
>
>> However, you're right in that textual assets which are never used
>> elsewhere (i.e. are intermediate edits that never get
>> dragged into an object, given to someone else, or otherwise transmitted)
>> might possibly be eliminated with some
>> sufficiently careful scheme.
>
> Binary de-duplication and added semantics in the form of 'key' or 'class'
> would probably go a long way.
>
>> > Its a bit like collecting every scrap of paper ever written with either
>> > text or binary glyphs and putting them in a big filing cabinet.
>> >
>> > After a while, finding the ones that are "interesting" in a "timely"
>> > manner starts to get a little "challenging".
>
> Let's keep the shining torch of this discussion burning.
>
> /Stefan
>
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] oddities with asset storage

[Charles Krinke]

My goal in starting this whole discussion in the first place was two fold.

Fold 1: Get us considering how to evolve OpenSim so that assets database 
currently containing 1.5million entries and consuming 50GBytes to support 
10,000 users does not continue to grow without bound at the current 4GByte/week 
rate if possible. I see other grid deployments facing a similar issue in their 
future and some evolution at this point may help us all.

Fold 2: I believe there are a few changes such as the "last terrain image" 
store that we can change in the near term, and I am hoping we can define a 
'reaping' strategy for grids that lets them tame the exponential growth of the 
'assets' table in the MySQL database defined by OpenSim as 2009 continues.

Charles





From: Melanie 
To: opensim-dev@lists.berlios.de
Sent: Wednesday, February 18, 2009 12:20:42 PM
Subject: Re: [Opensim-dev] oddities with asset storage

There are several viewer being developed already and their authors 
are aware of requirements and responsive to different needs.

Mainly, any new viewer will be able to accommodate changes quickly, 
unlike the LL viewer. So I see no need for a drawn out 
standardization discussion. This project is in too early a phase for 
this.

Melanie

Dirk Krause wrote:
> Ok, granted.  But isn't this a bit chicken/egg here? Possible solution 
> scenarios should define the requirements of the viewer, which probably won't 
> write itself.  Esp. when new viewers will be based on openmv somebody should 
> tell John et al. :-).
> 
> -Ursprüngliche Nachricht-
> Von: opensim-dev-boun...@lists.berlios.de 
> [mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Melanie
> Gesendet: Mittwoch, 18. Februar 2009 20:42
> An: opensim-dev@lists.berlios.de
> Betreff: Re: [Opensim-dev] oddities with asset storage
> 
> In the viewer, the following are true:
> 
> - The asset ID attached to an inventory item may not change
> - The item ID of an inventory item may not change
> - an asset's content may not change.
> 
> So, with this client, it's moot.
> 
> We are exploring other concepts and will be implementing them as and 
> when other clients become usable.
> 
> Melanie
> 
> 
> Dirk Krause wrote:
>> There could be business modell attached to it.
>> Lets say you sell only the 'right to use it for a given time' to the user, 
>> then you would have only one set of assets with multiple inventory pointers 
>> from your 2000 customers. Once you delete/disable it, no one can use it 
>> anymore. Once you update it, all 2000 have a newer version of it.  The other 
>> model would be the 'I buy it so I get a real copy of it'. The asset will be 
>> copied (in my scenario to my local inventory domain, so I 'really' own it). 
>> If you delete yours, mine is still there. If you update it, I need to obtain 
>> a newer copy. There could even be a concept that something is there only 
>> once (maybe art); you create it, give it a away (for a good price) and you 
>> don't have it anymore. The asset vanishes from your inventory domain.
>> 
>> Regarding the SL compatibility - maybe it doesn't need to be broken. IIRC 
>> isn't there this CAPS mechanism that already proxies assets? Couldn't there 
>> be some kind of intelligence behind it that collects and distributes assets 
>> from the different domains?
> 
>> 
>> -Ursprüngliche Nachricht-
>> Von: opensim-dev-boun...@lists.berlios.de 
>> [mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Melanie
>> Gesendet: Mittwoch, 18. Februar 2009 19:57
>> An: opensim-dev@lists.berlios.de
>> Betreff: Re: [Opensim-dev] oddities with asset storage
>> 
>> Making a copy is the greater evil. With implicitly shared assets, 
>> only content creators create assets. With asset copying, each 
>> sale/give creates assets.
>> Take SL:
>> 
>> I make a clothing item. I have to make 18 uploads (creating 18 
>> assets) to finally use 2 of the uploaded textures. I have also 
>> created 36 wearable assets through this.
>> 
>> Then i put that item for sale. 2000 users buy it.
>> 
>> With implicitly shared assets, assets consumed: 18 texture, 36 wearable.
>> 
>> With asset copying, assets consumed: 4001 texture, 4003 wearable
>> 
>> See, the point of diminishing returns for copying is very close.
>> 
>> Melanie
>> 
>> 
>> John Ward wrote:
>>> Justin Clark-Casey wrote:
 The problem is that you may have given that item to somebody else.
 Giving an item does not make an asset copy, it just makes an
 inventory item copy (both inventory items still point towards the
 same asset).
 
 So you may delete your item, but we don't know if the asset
 referenced by that item lives on in someone else's inventory (or in
 an object inventory).  So we can't delete the underlying asset.
>>> 
>>> Why not make an asset copy when one makes an inventory copy?  Then 
>>> delete the asset when deleted from inventory.  Is each user having their 
>>> own copy of many things a

Re: [Opensim-dev] [mmox] My evaluation of LLSD+LLIDL

[Charles Krinke]

Thats cool, John. Thank you for that. This is a very helpful step forward.

Charles





From: "Hurliman, John" 
To: "m...@ietf.org" ; "opensim-dev@lists.berlios.de" 

Sent: Friday, February 20, 2009 6:20:34 PM
Subject: [mmox] My evaluation of LLSD+LLIDL

I have a partial, very early implementation of a C# LLIDL lexer/parser and code 
generator in SVN at http://openmv.org/svn/misc/LLIDL/ (under the BSD license) 
in addition to the C# implementation of LLSD that has been under active 
development for about a year. This is my evaluation of the combined LLSD+LLIDL 
system in comparison to other similar offerings. Please add comments, 
corrections, and general feedback.

Linden Lab Structured Data by itself provides an abstract type system. This 
defines a fixed number of data types: null, boolean, signed 32-bit integer, 
64-bit floating point, string, 128-bit UUID, timestamp, URI, binary data, 
array, and map. Arrays and maps are weakly typed allowing them to store any 
LLSD data type. Type-casting mechanics are defined, creating a complete, weakly 
typed system. Implementation involves a layer to handle the weak typing 
(straightforward in Python, usually a class for each type inheriting from a 
base class in OO languages) and a layer to handle the conversions to and from 
native language types.

LLSD by itself is not very interesting; each individual programming language 
already had its own way of handling data and has no need for a new abstract 
type system. The idea is that if all languages shared a common type system, one 
or more serializations can be defined that allows the types to travel language 
and network boundaries. The approach used in other systems (ASN.1, Google 
Protocol Buffers, Apache Thrift, etc.) is to clearly define the data types at 
the serialization level instead of at the LLSD<->native level. My opinion is 
that this is an implementation detail that does not affect the developer using 
library in any meaningful way.

Where LLSD gets interesting is the addition of LLIDL. The interface description 
language for LLSD defines a text format for defining messages, similar to what 
you find in ASN.1, Protobufs, Thrift, and every other IDL. The text is very 
easy to parse (here's my ANTLR grammar file to convert LLIDL files to an AST: 
http://openmv.org/svn/misc/LLIDL/LLIDL.g, compare this to the ANTLR grammar for 
ASN.1: http://www.antlr.org/grammar/1231433381400/ASN.g). What you do with the 
LLIDL is an open question. You can make a simple parser that validates LLSD 
against an LLIDL definition, but that doesn't add value beyond being a good 
debugging tool. You can make a converter for incoming LLSD to conform to an 
LLIDL definition, but this has questionable value. Section 2.1 of the LLSD 
draft already states that reading the values will either "just work", or 
default values will be filled in for missing parameters. The only thing LLIDL 
can offer in addition to this is a warning
 of whether or not the
re were missing or extra fields. Additionally, this forces you to work with 
weakly typed data where you want to have strict type enforcement. The code 
generated by ASN.1, Protobufs, Thrift, etc. doubles as a compiler-enforced 
contract. Consider the following example:

Thrift:

struct UserProfile {
  1: i32 uid,
  2: string name
}

This might generate psuedocode code like this:

public struct UserProfile {
  int uid;
  string name;
  public void Serialize(Stream outputStream) { ... }
}

LLSD/LLIDL:

&UserProfile = {
  uid : int,
  name : string
}

This generates:

LLSDMap UserProfile;

With keys "uid" and "name" that hold the types int and string, respectively. 
When writing code with the first example, you know exactly what data types the 
enclosing type is composed of, what the types of each format are, and any 
default/fixed values. Working with the LLSD/LLIDL system, your only reference 
is to open up the LLIDL text file and look at it. This is roughly equivalent to 
a well formatted README file.

The solution? Implement a strongly typed generator on top of LLSD/LLIDL. This 
is what my llidlgen program attempts to do. For very basic examples of LLIDL 
(such as the example above) this seems like a straightforward thing to do. 
However, because of the baked in assumption that no one would attempt to do 
this, there are several problems. The outputted code is full of generator-named 
types and variables, lots of special handling has to be added to prevent the 
output from turning into layer after layer of nested classes, there are 
situations such as nested maps ({ $ : { $ : int } }) that drastically increase 
the complexity of converting LLSD types to native types, and the fact that this 
happens to be using an abstract type system starts to feel like a trivial 
design decision that is eventually hidden away from the developer.

Summary:

* There is no clear benefit to standardizing on conversions at the abstract 
type level instead of the serializa

[Opensim-dev] Mantis#3148

[Charles Krinke]

Mantis#3148 from Chillken is languishing a bit. Since it touches 18 important 
files, I am reticient to apply it without a second +1. I wonder if Justin, Mw, 
Lbsa, Adam or SDague might look at it, please.

Charles
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] MXPClient?

[Charles Krinke]

We also have the issue of a modal dialog box that recently started coming up in 
VS2008 Express saying "Solution folders are not supported in this version of 
the application. Solution folder 'Solution Files' will be displayed as 
unavailable".

I think this is an extension beyond what the Express editions support and we 
might want to consider making our build a tiny bit more 'vanilla'.

Charles





From: MW 
To: opensim-dev@lists.berlios.de
Sent: Sunday, February 22, 2009 10:30:00 AM
Subject: Re: [Opensim-dev] MXPClient?


Strange, I always get a pop up telling me the solution/project has changed 
externally and asking if I want to reload it. Maybe that can be turned off in 
the preferences or something.

--- On Sun, 22/2/09, Diva Canto  wrote:

From: Diva Canto 
Subject: Re: [Opensim-dev] MXPClient?
To: opensim-dev@lists.berlios.de
Date: Sunday, 22 February, 2009, 6:28 PM


OK. I guess new projects don't load when VS is already running. Had to
exit and restart.


MW wrote: 
After running prebuild it should be in the VS (2008)
solution, under OpenSim.Client.MXP

--- On Sun, 22/2/09, Diva Canto  wrote:

From:
Diva Canto 
Subject: [Opensim-dev] MXPClient?
To: opensim-dev@lists.berlios.de
Date: Sunday, 22 February, 2009, 6:14 PM


Hi,

I just noticed that trunk got an additional client, OpenSim/Client/MXP. 
It doesn't show in the solution of VS, but it's there on disk. Where 
does this come from? Or was this a commit mistake?

Crista

___
Opensim-dev mailing
 list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
 




___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev


___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] MXPClient?

[Charles Krinke]

Dear Adam:

How is the ModRex module? Is that what we need for the Rex client to connect to 
OpenSim? I dont recall if it is functional or not.

Are any of the ActiveWorlds, There.com others interesting? Croquet? Wonderland?

Charles





From: "Frisby, Adam" 
To: "opensim-dev@lists.berlios.de" 
Sent: Sunday, February 22, 2009 8:16:45 PM
Subject: Re: [Opensim-dev] MXPClient?

I'm open to ideas on other clients we could implement too btw.

Anything that has a well described protocol is up for grabs.

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Diva Canto
> Sent: Sunday, 22 February 2009 7:55 PM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] MXPClient?
>
> Frisby, Adam wrote:
> > Melanie can probably elucidate a little as to why it's good for us to
> have a couple of IClientAPI's in core - namely that it helps prevent
> monoculture in naming schemas and flow.
> >
> +100 just for this.
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] User Authentication

[Charles Krinke]

Dear Diva:

As "charles.kri...@osgrid.org", all I can say to all that is : "Harumph".

And the fact that you bring up a number of good points. It is especially 
thrilling to actually think we may have enough reliability to actually begin 
thinking about implementing some of the needed security.

It is always a balance between software development forward motion and security 
for the users, even this "charles.kri...@osgrid.org" guy, who sounds a bit like 
a loose cannon visiting "Sports Illuminated".

So, I commend you for thinking through some of this and offer my whole hearted 
support to encourage folks to test it *before* I get up one morning and find 
"Wright Plaza" is a smoking hole in the ground.

Charles Krinke





From: Diva Canto 
To: opensim-dev@lists.berlios.de
Sent: Monday, February 23, 2009 11:47:19 AM
Subject: [Opensim-dev] User Authentication

Hi,

I'm about to start tightening the ropes for the Hypergrid in order to 
make it safer, and also make safer some loose ends of OpenSim without 
HG, and I would appreciate feedback on this.

The first issue that needs to be addressed is the issue of user 
authentication. The regions need to be able to verify that the agent 
that claims to be representing charles.kri...@osgrid.org is, indeed, 
representing charles.kri...@osgrid.org. (As you know, right now this 
is... err... a bit overlooked... *coughs*... and not just in the HG... 
*more coughs*).

Having looked at OpenID, I came to the conclusion that it's not enough 
to know that osgrid.org has a user named "Charles Krinke", and we 
certainly don't want Charles to be constantly typing his password 
everytime he moves; the region needs to know that this user is already 
logged in to the system AND the region also needs to know that the agent 
that is representing this user is a legitimate agent.

OK, so the part about being logged in is easy; the user server already 
knows that, to some approximation.

However, the part about the agent being legitimate is a bit more tricky. 
Here's the bad thing that can happen: Charles logs in to OSgrid, and TPs 
to this intriguing region called "Sports Illuminated Swimming Suite 
Edition". That region happens to be up to no good. It grabs Charles 
current notion of identity (all the current identifiers we use), it 
crashes Charles' viewer so that the user server never knows about it, 
and proceeds to impersonate Charles using all those stolen identifiers; 
for example, it can go back to Charles's regions and erase them 
completely pretending to be Charles.

So, what can we do to detect the legitimacy of agents?

Having scratched my head over this, I came to the conclusion that the 
most promising element that can be used to identify agents is the 
Viewer's EndPoint. This is what happens down in the LLUDPServer (I'm 
sure something similar happens in other viewers' packet handlers):

if (packet != null)
{
if (packet.Type == PacketType.UseCircuitCode)
AddNewClient((UseCircuitCodePacket)packet, epSender, 
epProxy);
else
ProcessInPacket(packet, epSender);
}

The EndPoint epSender comes directly from the socket and I'm assuming it 
can't be faked, at least the IP part. Is this correct? This is a 
critical assumption.

So, back to the "Sports Illuminated" scenario: that sim would then try 
to launch an agent at Charles' region. It can fake everything except 
being Charles' viewer machine. When Charles' region does that code 
above, it asks the User server for authentication of an agent with all 
those identifiers and the given EndPoint, and the User server tells back 
that Charles wasn't using that EndPoint to start with, so the 
authentication fails, and an alarm is rang.

Thoughts?

Crista

Disclaimer: I'm not an expert in security, I'm just using my brain in 
context.


___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] User Authentication

[Charles Krinke]

Dear Diva:

Thank you for thinking along these lines for the viewer. As this point, folks 
from SecondLife constitute our largest set of expected new adopters, and I 
believe keeping compatibility with the SL viewer is to our advantage.

This situation will probably change some time, but I would expect that time to 
be later this year at a minimum.

Charles




From: Diva Canto 
To: opensim-dev@lists.berlios.de
Sent: Monday, February 23, 2009 2:31:25 PM
Subject: Re: [Opensim-dev] User Authentication

Right. The constraint here, let's not forget, is that we want to
continue to reuse the LL viewer for a while.
I'm going to read that doc about OpenID tokens, but if it requires
participation from the viewer, forget it... We are and will continue to
be in LL Viewer hacking mode in the foreseeable future, abnd I want to
make things safe before a better viewer comes along.

The bottom line question in my email, phrased in OpenID terminology, is
whether we can use the Viewer's IP address as the token.


Tommi Laukkanen wrote: 
As we cannot change the viewer at the moment one could use the
opensim login code to create the token...
 
regards,
Tommi



___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de 
https://lists.berlios.de/mailman/listinfo/opensim-dev 
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] [REX] [Fwd: User Authentication]

[Charles Krinke]

ealm. Another common usage is
prefix notation, which involves prepending the realm to the username and
using '\' as a delimiter.  Modern RADIUS servers allow any character to
be used as a realm delimiter, although in practice '@' and '\' are
usually used.

  Realms can also be compounded using both prefix and postfix
notation, to allow for complicated roaming scenarios; for example,
somedomain.com <http://somedomain.com/> \usern...@anotherdomain.com
could be a valid username with two realms.

  Although realms often resemble email domains, it is
important to note that realms are in fact arbitrary text and need not
contain real domain names.

  So users from different Grids could roam freely between
"partnering" Grid servers using realms.




  Proxy operations


  When a RADIUS server receives an AAA request for a user name
containing a realm, the server will reference a table of configured
realms. If the realm is known, the server will then proxy the request to
the configured home server for that domain. The behaviour of the
proxying server regarding the removal of the realm from the request
("stripping") is configuration-dependent on most servers. In addition,
the proxying server can be configured to add, remove or rewrite AAA
requests when they are proxied.

  I believe the first step would be to get a RADIUS server
setup and working, and then work on setting up two grids together (using
REALM between the two RADIUS servers) and then once this could be done,
then later additional grids could be "trusted" and allowed onto the
network.  So users could roam freely between the "trusted grids".

  If a user was reported to the Grid Owner (as being an
"abusive user") then the Grid owner would suspend that user's account,
and send an "abuse notification" to the Grid Owner (that the user has
violated the Terms of Service for the Grid).  Basically just "pull the
plug" on that user's account, and kick them off the grid, and ban their
computer & IP address.

  It would make it extremely easy for "policing" the Grid, and
any users that want "Secure Inter-Grid" handshakes would just join the
REALM network.

Mark

  P.S. If you need some help with this, I'm sure we can sit
down and discuss it a bit, and set something up as a "demo" grid as to
how this could be done.  Then later other Grids (like OS Grid, and
various others) could join the REALM grid network.




  On Mon, Feb 23, 2009 at 2:19 PM, Toni Alatalo
 wrote:


  this kinda sounds like trying to achieve what rexauth
does, no?

  perhaps someone could write how it is w.r.t to that
case? i might be
  able, but too tired now and probably busy tomorrow.

  also John Hurliman is planning new auth stuff with
openid and some
  openid related token thing (i forgot the name) which
is basically 'same
  as rexauth but standards instead of Finnish magic',
like he said the
  other day :) .. so perhaps he replies his plan there,
seems to be online
  at least.

  ~Toni

  --~--~-~--~~~---~--~~
  this list: http://groups.google.com/group/realxtend
  realXtend home page: http://www.realxtend.org/
  -~--~~~~--~~--~--~---



  Hi,

  I'm about to start tightening the ropes for the
Hypergrid in order to
  make it safer, and also make safer some loose ends of
OpenSim without
  HG, and I would appreciate feedback on this.

  The first issue that needs to be addressed is the
issue of user
  authentication. The regions need to be able to verify
that the agent
  that claims to be representing
charles.kri...@osgrid.org is, indeed,
  representing charles.kri...@osgrid.org. (As you know,
right now this
  is... err... a bit overlooked... *coughs*... and not
just in the HG...
  *more coughs*).

  Having looked at OpenID, I came to the conclusion that
it's not enough
  to know that osgrid.org <http://osgrid.org/>  has a
user named "Charles Krinke", and we
  certainly don't want Charles to be constantly typing
his password
  everytime he moves; the region needs to know that this
user is already
  logged in to the system AND the

Re: [Opensim-dev] User Authentication

[Charles Krinke]

Thank you for letting me be the example. I find this exchange very stimulating. 
Much more so then some of the posturing going on in certain IETF mailing list 
right now.

I have not given a whole lot of thought to security before, but I can see that 
we are going to go around on this for a while. As I think about it, the 
opensource method of describing the details, finding the flaws and then solving 
them one at a time is a much more refreshing method then the typical security 
conversations I have which usually end up as "you are not allowed to know how 
this works"

With Respect
Charles 

p.s. "Sports Illuminated". I like that one.





From: Diva Canto 
To: opensim-dev@lists.berlios.de
Sent: Monday, February 23, 2009 5:05:42 PM
Subject: Re: [Opensim-dev] User Authentication

Mark Malewski wrote: 
Just to clarify...
 
> Grids could provide openIDs in the form of 
> "openid.osgrid.org/users/screenname"
 
With all grids being independent of one another, or in the
example given by John, maybe use an "openid.osgrid.org/users/screenname"
 
http://openid.osgrid.org/users/Charles_Krinke
 
For those of you who don't know, this already exists. Click this:
http://osgrid.org:8002/users/charles_krinke
or this:
http://ucigrid00.nacs.uci.edu:8002/users/crista_lopes


Again, in this example Charles happens to have his identity at
OSGrid, but that's not a requirement of the exchange. It could just as
easily been an identity from another grid.
 
This way various grids could all run "openID" servers, and trust
agreements would need to be established between the various grids.
I'm not going to act on anything that suggests "trust agreements
between various grids." That's an AWG concept that I very much disagree
with, and want no part in. I have no problem with companies cutting
corners on security in order to be able to exchange agents on a
lawyer-backed up trust basis. But that's not what I'm doing here, and
that's not what a lot of people want OpenSim to be.

The goal is to be able to go from my home standalone to *any* sim out
there that I know nothing about, and still be sure that nothing bad
will happen to my belongings. Anything less than this is not acceptable
as a goal, for me.

Crista___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] On solving Authentication and such

[Charles Krinke]

I would concur. I can certainly see this idea expediting PDA and cell phone 
group and IM communication into the Metaverse. This seems like an entirely 
reasonable additional use case as we evolve.

Charles



From: Mike Mazur 
To: opensim-dev@lists.berlios.de
Sent: Tuesday, February 24, 2009 4:06:04 PM
Subject: Re: [Opensim-dev] On solving Authentication and such

Hi,

On Tue, 24 Feb 2009 09:45:27 -0800
Diva Canto  wrote:

> I think the proposal is exactly the opposite, at least for the time 
> being. That is, let's use whatever the LL viewer already has for 3D 
> rendering, and let's move the non-3D features out onto Web
> applications.

The way I understood the proposal is to separate out the 3D and 2D
functionality at all(?) levels.

This means that the server will provide one client stack implementing
one protocol that deals only with 3D information. Avatar movement,
scene description, agent updates, prim updates, etc. The viewer speaks
this protocol in order to display to the user what is happening in the
3D world. This makes it possible to write a client that is only capable
of viewing the world and doesn't care about inventory. The protocol
could be, for example, the LLUDP protocol.

The inherently 2D features, such as chat or inventory, can use another
protocol. The server will provide a different client stack that deals
only with the 2D feature(s). The viewer also implements this protocol to
provide these additional services to the user. This 2D information can
then be overlaid over the 3D rendering of the world. This allows to
write clients that manipulate this data only, like inventory managers,
asset browsers, chat-only clients, etc. The protocol used here could be
HTTP.

This separation of protocols for all the different ways a user
interacts with the virtual world sounds like a Good Thing (tm) to me.

Mike
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Authentication, take 2: Capabilities

[Charles Krinke]

Dear Diva:

As always, I have the highest of respect for your logic and would encourage 
your vision. It seems altogether reasonable to me.


As we move forward, considering those use cases in the future that are not 
currently very active such as standalone regions or arrays that also 
participate in the HyperGrid notion is good also.

On the OSGrid case, even though OSGrid is near and dear to my heart, I have to 
take a logical step back and say that OpenSim should evolve in a manner that 
makes it most useful for educational, scientic and commercial applicatons and 
development should not be pertubated for OSGrid's benefit.

Having said that, I can also say that OSGrid desires to continue to be right at 
the leading edge of OpenSim development and support that development as much as 
possible while a community continues to develop. These two OSGrid goals have a 
certain amount of tension between them, but so far this has been very positive 
tension.

Charles






From: Diva Canto 
To: opensim-dev@lists.berlios.de
Sent: Saturday, February 28, 2009 8:53:48 AM
Subject: Re: [Opensim-dev] Authentication, take 2: Capabilities

I've come full circle on this issue of security and the Linden Viewer, 
and I have something to propose.

First, my conclusions:

(1) Capabilities are a fantastic idea for secure open systems. <3's it!
(2) The Linden viewer, as it's going in practice, is unsafe for an open 
Virtual Worlds system.

My proposal:

(a) Let's design OpenSim around the organizing concept of capabilities. 
We're already half-way there, thanks to the Linden Viewer, even if it 
took us there kicking and screaming. Designing OpenSim around the 
organizing concept of capabilities means that no sensitive service 
should ever be exposed face-value on the web; it should always be 
exposed behind a capability URL. For example, the inventory access 
services that we have now are fundamentally unsafe. Someone tried to add 
an authorization step (session id), but that failed badly and was 
abandoned. Melanie and others doing walled-gardens rely on placing these 
services behind firewalls or in obscure places that only 2 or 3 people 
know the address. Security through obscurity works well in certain 
cases, but it's fragile and it simply doesn't work in open systems. It 
will not work for the Hypergrid.

By placing the services behind capability URLs, instead of face-value 
URLs, we can expose the servers on the public web and still be sure that 
only authorized components will access them -- this, without having to 
verify the credentials of the caller over and over again with expensive 
remote calls: the simple fact that the caller knows the secret URL is 
enough for authorization.

What this means is that regions must gain Capabilities to access both 
the users' agents and the users' services as the users move into them. 
Or not. Right now, we're giving the regions all the capabilities, some 
explicitly (for the users' agents), some implicitly (services). The 
explicit ones are those that the regions get by calling the SEED Cap URL 
-- which mainly serves to get the very important cap for the viewer's 
Event Queue. The implicit ones are those currently hard-coded: the 
inventory services, the asset services, IM, etc. We should make those 
also explicit; then it will be up to the *policies* (a separate thing) 
to define which components get which caps.

We should create a Capabilities service, which can be run off a separate 
server (or the user server -- again, I wish this was configurable too!). 
This Caps service will be responsible for managing the capabilities 
pertaining to users and regions within one domain of trust (UGAIMs). So, 
users and regions who log in to this domain of trust will be given 
initial capabilities, and these may be expanded and retracted  as 
certain actions occur.

Different domains of trust may have different capability policies. For 
example LCO's Cap service may very well give all of its regions all the 
capabilities to access the backbone services directly, as well as the 
capability to access all agents' Event Queues, no questions asked. 
OSGrid may not give its regions the capability to access the inventory 
service while still giving its regions the capability to access the 
agents' Event Queues; and for regions that are not registered in OSGrid, 
OSGrid may very well not give them the capability to access the users 
agents' Event Queues.

(The EQ's are the key element in Teleports; if a region doesn't have 
access to the viewer's EQ, it cannot teleport the agent. The user, 
however, may have an agent in the home system with an open EQ to the 
viewer, so that Teleports can happen controlled by the home system -- 
this is the cool new Teleport procedure that I'm going to experiment with)

Capabilities have an additional positive side-effect: they force us to 
slice monoliths into small, independent services ("capabilities") 
explicitly mapped to names,

Re: [Opensim-dev] Virtual World Educators Conference

[Charles Krinke]

Dear Rich:

On OSGrid is a region called "Metaversity Campus", which was recently created 
by BlueWall Slade for the purpose of virtual education. Another region 
currently being used for education on OSGrid is Dradis. Additionally, there are 
a number of UC Irvine regions. 

You might find it interesting to set aside some time to both examine these 
regions and consider using them in a seminar at the conference being planned. I 
would suggest the mere use of these regions would constitute a significant 
"preso".

There is currently a C# class meeting twice a week with 12 students on OSGrid 
and it is going very well. The students are even asking for additional 
homework, which I would submit is a good measure of the success of a course.

Charles Krinke





From: Rich White 
To: opensim-dev@lists.berlios.de
Sent: Sunday, March 1, 2009 9:14:26 AM
Subject: [Opensim-dev] Virtual World Educators Conference

For those interested - We will be hosting a "virtual world educators"
conference at Pittsburg State University (Dept. of Education building)
in the big metro (LOL) of Pittsburg Kansas this summer - I planned on
doing some Cobalt preso's and have had Opensim and Wonderland folks
confirm they will do some preso's as well ... should be a fun event !
... Details will be posted here - http://vweducation.ning.com as we
organize the event !  Might be a nice event to set up a Open
Cobalt booth !

Cheers,
Rich
=
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] OGP/Capabilities

[Charles Krinke]

If I recall correctly, and I might be wrong, but the conversation I had with 
the lindens about OGP had them focused on their AgentDomain. Sort of a "super 
grid server" if you will. When quizzed about a full handoff, they said "we 
arent working on that".

So, my impression about OGP is it extends the linden grid, but is only half of 
an interop solution.

Charles





From: Diva Canto 
To: opensim-dev@lists.berlios.de
Sent: Tuesday, March 3, 2009 7:31:32 PM
Subject: [Opensim-dev] OGP/Capabilities

Finally Linden Lab produced an interesting document:
http://www.ietf.org/internet-drafts/draft-lentczner-ogp-base-00.txt

I think capabilities are the right concept here, and I'm pleased to see 
them taking center stage in that document. In particular the hint at 
inventory-related capabilities, which will allow secure inventory access.

I'm not sure I buy into some of the details, but the basic combination 
HTTP+REST+Capabilities --> +1.

The Event Queue...well...  It sucks. I think we need to look at 
alternatives for posting things to the client. I can't believe there 
aren't any; I think there are, but maybe they all come down to this, 
event queues on the server-side, whatever their form.

If there are no better alternatives, then we need at least to rethink 
what the EQ is all about. If the EQ CAP is not given to the regions, but 
stays within the user's home system, that might work. Also, if there 
would be several different *types* of Event Queues that might work well 
too; so for example, we might give the social-net-related EQ CAP 
(groups, IM, etc) to the social net component without compromising agent 
transfers. The more I think about this, the more I'm convinced that 
regions have no business in agent transfer activities, other than 
negotiating the capabilities when agents come.

I really like that document, I must say, but it's strength is also its 
weakness. It's just about the basic levels. It says nothing about how 
those things are driven higher up.

Crista

___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] OGP/Capabilities

[Charles Krinke]

Ah. Got it. The OGP notion is the Linden interop which is how the "gridnauts" 
got from the betagrid to an OpenSim region and to several OSGrid regions last 
year.

But, ... I believe those avatars that teleported from the betagrid to either 
the OpenSim standalone regions or the OSGrid regions were under the AgentDomain 
and so were "not completely, exactly", er, "handed off" to the new region. The 
AgentDomain was still connected to the "special client" that was being used.

Charles





From: Diva Canto 
To: opensim-dev@lists.berlios.de
Sent: Tuesday, March 3, 2009 7:50:42 PM
Subject: Re: [Opensim-dev] OGP/Capabilities

I don't know what OGP is. I'm looking at this specific document, and
it's as generic as a document can be. Specifically, it doesn't say
anything about how to use the basic protocols HTTP+REST+CAPs. The
different uses will produce quite different systems, I think.


Charles Krinke wrote: 
If I recall correctly, and I might be wrong, but the
conversation I had with the lindens about OGP had them focused on their
AgentDomain. Sort of a "super grid server" if you will. When quizzed
about a full handoff, they said "we arent working on that".

So, my impression about OGP is it extends the linden grid, but is only
half of an interop solution.

Charles





From: Diva Canto 
To: opensim-dev@lists.berlios.de
Sent: Tuesday, March
3, 2009 7:31:32 PM
Subject: [Opensim-dev]
OGP/Capabilities

Finally Linden Lab produced an interesting document:
http://www.ietf.org/internet-drafts/draft-lentczner-ogp-base-00.txt

I think capabilities are the right concept here, and I'm pleased to see 
them taking center stage in that document. In particular the hint at 
inventory-related capabilities, which will allow secure inventory
access.

I'm not sure I buy into some of the details, but the basic combination 
HTTP+REST+Capabilities --> +1.

The Event Queue...well...  It sucks. I think we need to look at 
alternatives for posting things to the client. I can't believe there 
aren't any; I think there are, but maybe they all come down to this, 
event queues on the server-side, whatever their form.

If there are no better alternatives, then we need at least to rethink 
what the EQ is all about. If the EQ CAP is not given to the regions,
but 
stays within the user's home system, that might work. Also, if there 
would be several different *types* of Event Queues that might work well 
too; so for example, we might give the social-net-related EQ CAP 
(groups, IM, etc) to the social net component without compromising
agent 
transfers. The more I think about this, the more I'm convinced that 
regions have no business in agent transfer activities, other than 
negotiating the capabilities when agents come.

I really like that document, I must say, but it's strength is also its 
weakness. It's just about the basic levels. It says nothing about how 
those things are driven higher up.

Crista

___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev




___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de 
https://lists.berlios.de/mailman/listinfo/opensim-dev 
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Ini file(s) loading

[Charles Krinke]

Paul. I would think an installation wizard would be a capital idea. Only issue 
is it needs a "zealot" to champion it and move it forward. But, it certainly is 
a good idea.

Charles





From: Paul Fishwick 
To: opensim-dev@lists.berlios.de
Sent: Sunday, March 8, 2009 1:48:16 PM
Subject: Re: [Opensim-dev] Ini file(s) loading

This makes a lot of sense, and seems how other usable packages are
deployed. Is there a way to achieve it cross-platform?
p

Brianna wrote:
> I prefer to see a 'wizard' quick interview startup like MySql for Win has 
> incorporated. I believe that approach is user friendly and less prone to 
> error than editing OpenSim.ini or the suggested multi ini's. One box check 
> for OSGrid would save many edits in Network, as an example. Those of us that 
> do this everyday are often not considerate to how formidable to a new user 
> OpenSim appears. After a day or so of comfort then editing ini.example to 
> fine tune will make for a happy camper and a hell of a lot less questions in 
> game or IRC.
>
> - Original Message - 
> From: "Dave Coyle" 
> To: 
> Sent: Saturday, March 07, 2009 3:07 PM
> Subject: Re: [Opensim-dev] Ini file(s) loading
>
>
>  
>> On 2009-03-07 10:02:55 -0500, jeffa...@gmail.com wrote:
>>
>>> For a binary release, I think having only user-editable config/*.ini
>>> files would make the most sense.  But maybe how we handle .ini files
>>> in SVN is necessarily more complicated.
>>>  
>> For packaged binaries, at least in the Linux world, config files are
>> going to have to be moved elsewhere during the packaging process
>> anyway, so where they're located in the SVN repo and whether they're
>> called *.ini or *.ini.example is largely irrelevant... for producing
>> official/official-like distro packages, anyway.
>>
>> -Coyle
>> ___
>> Opensim-dev mailing list
>> Opensim-dev@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev 
>>
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>  


-- 
Paul Fishwick, PhD
Professor and Director, Digital Arts and Sciences Programs
University of Florida
Computer & Information Science and Eng. Dept.
Bldg. CSE, Room 301
P.O. Box 116120
Gainesville, FL 32611
Email: fishw...@cise.ufl.edu
Phone: (352) 392-1414
Fax: (352) 392-1220
Web: http://www.cise.ufl.edu/~fishwick

___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] machine performance stats for grids

[Charles Krinke]

Dear Paul:

There is a page on opensimulator.org for grids and all are encouraged to 
describe statistics for their grids. In addition, all of the 60 or so grids on 
that page have their own sub-page to describe statistics and some do.

Also, some use the loginscreen to read contents of various tables in the MySQL 
database that use the opensimwiredux web frontend for their grid.

Charles





From: Paul Fishwick 
To: opensim-dev@lists.berlios.de
Sent: Sunday, March 8, 2009 7:44:14 PM
Subject: [Opensim-dev] machine performance stats for  grids

Do any of the large opensim grid owners publish performance statistics that
on attributes such as

# of giga or tera bytes required for assets
# of prims per region
# of regions in grid
# or frequency of accesses per second or over a duration   ?

-p

-- 
Paul Fishwick, PhD
Professor and Director, Digital Arts and Sciences Programs
University of Florida
Computer & Information Science and Eng. Dept.
Bldg. CSE, Room 301
P.O. Box 116120
Gainesville, FL 32611
Email: fishw...@cise.ufl.edu
Phone: (352) 392-1414
Fax: (352) 392-1220
Web: http://www.cise.ufl.edu/~fishwick

___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] adding unneeded complexity to OpenSim.ini

[Charles Krinke]

I have to admit puzzlement on this complexity also.

But, as I read all this, I would also urge that if a significant change is made 
that a wiki entry can be made so that the question : "My OpenSim doesnt work 
anymore and I think it is config?" can be answered : 
http://opensimulator.org/wiki/





From: Ovi Chris Rouly 
To: opensim-dev@lists.berlios.de
Sent: Saturday, March 14, 2009 6:30:21 AM
Subject: [Opensim-dev] adding unneeded complexity to OpenSim.ini

Dear All,

I'm deeply with Melanie and Paul Fishwick on this.
Section delimiters in a single ASCII text configs have
served computer science very well for many years.

Why fix it if it "ain't" broke?  OpenSim works pretty
well (plus a small learning curve) right out of the box.

Respectfully,

Chris


>
> Message: 1
> Date: Sat, 14 Mar 2009 09:35:48 +
> From: Melanie 
> Subject: Re: [Opensim-dev] Round 2: Config changes preview
> To: opensim-dev@lists.berlios.de
> Message-ID: <49bb7a74.6070...@t-data.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Has anyone notices how impossibly complicated, complex and
> unmaintainable this is going to become?
> Instead of demanding the user read a simple set of instructions,
> then do the RightThing, you try to do all their thinking for them,
> resulting in something that will make neither novice nor grid
> operator happy.
>
> You are increasing, not decreasing, complexity and the effort to get
> up and running.
> Rename, copy, multiple subdirectories, even I am hard put to see any
> sense in that, and I'm a dev, for crying out loud!
>
> Melanie
>
> Mike Mazur wrote:
>> Hi,
>>
>> On Sat, Mar 14, 2009 at 2:34 AM, Justin Clark-Casey
>>  wrote:
>>> In this version I've done away with all the subdirectories.  There is 
>>> now a simpler structure
>>>
>>> config/OpenSim.ini.example
>>> config/defaults
>>> config/override
>>
>> On first glance, it's not obvious how the config files in these
>> directories are treated. Is the defaults/ directory scanned for valid
>> .ini files which are then processed?
>>
>> The defaults/ directory contains scripting.ini.defaults. To enable
>> these settings, what should the user do? Rename to
>> defaults/scripting.ini, then edit? Is it necessary to copy to
>> override/scripting.ini and edit instead?
>>
>> In my opinion, having both a directory a *.ini.defaults extensions is
>> one too many. Perhaps we can get away with the two directories
>> containing only .ini files?
>>
>> config/OpenSim.ini.example
>> config/available/*.ini
>> config/override/*.ini
>>
>> Or we could have just one directory which contains *.ini.defaults (or
>> *.ini.example) files alongside *.ini files:
>>
>> config/OpenSim.ini.example
>> config/*.ini{,.defaults}
>>
>> To enable settings, just rename .ini.defaults to 
>> .ini.
>>
>> Mike
>> ___
>> Opensim-dev mailing list
>> Opensim-dev@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
>
>
> --
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
> End of Opensim-dev Digest, Vol 19, Issue 37
> ***
> 


___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

[Opensim-dev] Memory Leak and stats

[Charles Krinke]

One of the nagging problems we have appears to be memory leaks. There are 
consistent and frustrating reports of more heavily used regions using up all 
the RAM, then starting swap, then lagging, then freezing every week.

In order to help bring a little clarity to this, Nebadon has put together:

http://nebadon2025.com/SStats

Which is a web page to show the stats on a number of plazas and other regions 
on OSGrid.

I would like to suggest a couple of things:

1. Can some of us look at this page and see what we might be able to intuit?
2. Can we consider adding more stats that can display and help us get memory 
usage more under control?

Charles
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

[Opensim-dev] 24 LSL functions left

[Charles Krinke]

There are 24 LSL functions left in the "NotImplemented" state of the more then 
330 we started with a little over a year ago.

The 24 are:

llRotTarget(), llRotTargetRemove()
llLoopSoundMaster(), llLoopSoundSlave(), llPlaySoundSlave()
llStopLookAt(), llCollisionFilter(), llAttachToAvatar(), llDetachFromAvatar()
llRotLookAt(), llPointAt(), llStopPointAt(), llGodLikeRezObject(),
llPassTouches(), llSetDamage(), llTextBox(), llCollisionSprite(),
llPassCollisions(), llGetCenterOfMass(), llEdgeOfWorld(),
llSetSoundQueueing(), llTriggerSoundLimited(), llGroundRepel(),
llSetVehicleFlags(), llRemoveVehicleFlags(),
llRemoteDataSetRegion(), llSetInventoryPermMask()

It would be a great thing to see patches for some of these so we can get to the 
finished point on at least the first level of implementation of all the LSL 
functions.

Charles
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

[Opensim-dev] density

[Charles Krinke]

We have m_density defined in two different places with two different values.

One is in: ...\OpenSim\Region\Physics\OdePlugin\ODECharacter.cs - (72, 22) : 

public float m_density = 60f;

Another is in:   ...\OpenSim\Region\Physics\OdePlugin\ODEPrim.cs(152):   

 private float m_density = 10.06836f; // Aluminum g/cm3;

And
in looking at the usage to calculate mass, it looks like the math is
right, but yet, the avatar seems to have a higher density then the
prim. 

I know that these are empirically determined, but in
trying to look forward to a world where we actually might use the
density of metal, rubber, glass, rock, plywood to do some additional
physics *stuff*, it seems that we might want to see if we can harmonize
our notion of density a little bit.

Perhaps I am just missing the boat here. But, I would like to understand how we 
might be able to move forward a little bit on density some time.

Charles___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] density

[Charles Krinke]

I'm not criticizing the mass of the avatar at all, but I am trying to look 
forward to a time when we could have different masses of prims and objects and 
go beyond what traditional secondlife is used to.

In thinking about that, I am hoping we could discuss how we might make a table 
or enum's of several materials such as shown in the client for rubber, glass, 
metal, stone and see some advantage in our use of physics for materials of 
differing densities and frictions.

Perhaps it may not matter what the avatar density is so much, as it might 
matter how we move forward in defining additional material properties for 
OpenSim that make use of the packet types already defined.

Charles





From: Teravus Ovares 
To: opensim-dev@lists.berlios.de
Sent: Sunday, March 22, 2009 2:32:58 PM
Subject: Re: [Opensim-dev] density

A couple of points here

As far as LSL is concerned, mass is the same whether metal, rubber, glass,
rock or plywood from what I've been told.There are other changes
though..  like bounciness.

The mass of the avatar has been the same since implementation and
works well with the Avatar PID controller in the ODEPlugin.   Changing
the avatar mass may make the Avatar PID controller malfunction as it
is.   Chances are it will need to be re-tuned for a lower mass (which
is what I /think/ you're syaing here)

Other comments?

Teravus

On 3/22/09, Charles Krinke  wrote:
>
> We have m_density defined in two different places with two different values.
>
> One is in:
> ...\OpenSim\Region\Physics\OdePlugin\ODECharacter.cs - (72,
> 22) :
>
> public float m_density = 60f;
>
> Another is in:
> ...\OpenSim\Region\Physics\OdePlugin\ODEPrim.cs(152):
>
>
>  private float m_density = 10.06836f; // Aluminum g/cm3;
>
> And in looking at the usage to calculate mass, it looks like the math is
> right, but yet, the avatar seems to have a higher density then the prim.
>
> I know that these are empirically determined, but in trying to look forward
> to a world where we actually might use the density of metal, rubber, glass,
> rock, plywood to do some additional physics *stuff*, it seems that we might
> want to see if we can harmonize our notion of density a little bit.
>
> Perhaps I am just missing the boat here. But, I would like to understand how
> we might be able to move forward a little bit on density some time.
>
> Charles
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Graceful failure or down grading for scripting.

[Charles Krinke]

Well, it seems to me that we are "OpenSim" and not "SecondLife" and that it is 
entirely appropriate for our osFunctions() to be enabled by default in  our 
OpenSim.ini file. So, I am "pro" this idea.

Charles




From: Melanie 
To: opensim-dev@lists.berlios.de
Sent: Friday, March 27, 2009 6:19:29 PM
Subject: Re: [Opensim-dev] Graceful failure or down grading for scripting.

I'm very strongly -1 on watering down AllowOSFunctions. If that is 
false, it should do what it says on the can, namely make _all_ 
osFunctions fail.
I outlined a possible solution on Mantis.

Melanie

Frisby, Adam wrote:
> A simple bool probably isn't enough.
> 
> Let's enable an ENUM with the current ThreatLevel, plus maybe a second 
> function which returns a bool , "bool isFunctionAvailible("osWhatever");", 
> the latter ties in with extensible OSSL via Commanders (not enabled now, but 
> in the future it could be).
> 
> Adam
> 
>> -Original Message-
>> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
>> boun...@lists.berlios.de] On Behalf Of Michael Cortez
>> Sent: Friday, 27 March 2009 12:36 PM
>> To: opensim-dev@lists.berlios.de
>> Subject: Re: [Opensim-dev] Graceful failure or down grading for
>> scripting.
>> 
>> > I have a mantis ticket currently open that has a possible
>> > implementation that utilizes C# attributes,
>> 
>> Forgot to include the mantis ticket:
>> 
>> http://opensimulator.org/mantis/view.php?id=3346
>> 
>> 
>> Cheers,
>> --
>> Michael Cortez
>> ___
>> Opensim-dev mailing list
>> Opensim-dev@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> 
> 
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] cosimus: a little simulator tinkerbox in Lua+C

[Charles Krinke]

Dear Andrew:

I want to encourage you in your project. Our forge is intended to have projects 
that are of relevance to the OpenSim context and I would think that this 
certainly qualifies.

The trick is going to be to get *something* working *sortof* and then having 
others use that work and test it, help extend it, use it. In other words, to 
then gain some momentum with the community.

This will most likely involve writing some wiki pages on opensimulator.org and 
others for a new module. After all, we are about adding modules to extend 
OpenSim.

So, good luck and keep us  posted.

Charles





From: Andrew Yourtchenko 
To: opensim-dev@lists.berlios.de
Sent: Saturday, March 28, 2009 4:09:18 AM
Subject: [Opensim-dev] cosimus: a little simulator tinkerbox in Lua+C

Hi all,

sorry for somewhat abusing this list (I am not sure if this should be
used for anything else other than OpenSim) - but given that this
*might* be of some use to some opensim dev folks, I hope I will be
forgiven :)

It's my hack to get the non-C# simulator code.

Hence it's a cocktail of C and Lua. At the moment should be viewed
more as a prototype/tinkerbox quality, could be useful to quickly test
some odd scenarios
(as there's no recompile required, and in some cases not even a viewer restart).
At the moment the functions are pretty limited, but as my two week
vacation during which I pretty much completely rewrote everything and
hacked the most of the lua code, is coming to an end, I'm gonna push
it to github and see how it goes.

Not any releases yet and indeed NOT to be used on anything besides
your laptop :)

Repository with GIT:

http://github.com/ayourtch/cosimus/tree/master

MIT license.

Question - as I aim this to be a "little stepbrother of opensim" -
would it be ok to create a page on forge.opensimulator.org ?

An any feedback obviously welcome!

cheers,
andrew (aka Dalien in the other life :)
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

[Opensim-dev] funky region names?

[Charles Krinke]

 I am getting some comments about region names beginning with spaces *and*
 region names longer then 32 characters having some side effects in map and
 search from OSGrid users.

 It makes me wonder if the grid server should have some additional
 constraints to trim leading spaces and names longer then 32 characters so
 associated .PHP programs and the client do not get unhappy.

 So, I pose the question and wonder what folks think is the proper solution.

 Charles___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] funky region names?

[Charles Krinke]

Well, I dont *know* if the MySQL has this issue or not, yet. I went ahead and 
reported what I had heard.

*If* we have this issue, then it is one of Regions/region.xml files registering 
a region with a long name and/or a name with spaces in the front. 

It seemed appropriate to discuss it as it is one theory why some searches are 
causing clients to crash.

Charles





From: Chris Hart 
To: opensim-dev@lists.berlios.de
Sent: Sunday, March 29, 2009 1:33:25 PM
Subject: Re: [Opensim-dev] funky region names?

 
The MSSQL database schema limits region names to 20 characters,
so having discovered the hard way that names longer than that cause trouble
when registering with a grid we’ve now avoided that problem with
validation on the web app we use that serves the region xml. I have no idea
when 20 characters was set for the limit, and had assumed this was just one of
those numbers dictated by the client and didn’t think we were different
from the MySQL configuration until this email. 
 
That aside, if there are client issues over 32 characters then regions
shouldn’t be allowed to register with the grid if the client used to
connect to those regions is the LL client. Perhaps there could be a regex
setting in the ini for validating region names? Would leave room for different
validation requirements for different clients.
 
Chris
 
From:opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Charles
Krinke
Sent: 29 March 2009 21:22
To: opensim-dev
Subject: [Opensim-dev] funky region names?
 

 I am getting some comments about region names beginning with spaces *and*
 region names longer then 32 characters having some side effects in map
and
 search from OSGrid users.

 It makes me wonder if the grid server should have some additional
 constraints to trim leading spaces and names longer then 32 characters so
 associated .PHP programs and the client do not get unhappy.

 So, I pose the question and wonder what folks think is the proper
solution.

 Charles
No virus
found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.0.238 / Virus Database: 270.11.31/2028 - Release Date: 03/28/09
07:16:00___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] This will NEVER go away

[Charles Krinke]

Since OpenSim is not going away, perhaps this is a good time to discuss 
'groups' implementations.

It seems to me that getting to where we have some semblance of 'groups' in 
OpenSim is to our advantage and will help the various grids progress. I wonder 
what other thoughts there are?

Charles
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] The essence of "grid"

[Charles Krinke]

OSGrid exists with two goals.

1. Test OpenSim SVN on a regular basis and report results to aid in software 
development.
2. Nurture a community.

We need to start by considering that OpenSim splits the asset storage between 
regions and the OpenSim assetServer. So, the OpenSim asset model is a little 
different then SecondLife since we already distribute some assets between 
regions and the UGAIM.

Are we saying that OSGrid is doing something problematic and pertubating the 
OpenSim development? I am confused about the OSGrid comments in this 
philosophical discussion. As I see the whole situation, OSGrid is testing the 
mainline trunk SVN from OpenSim in a manner consistent with the desires of the 
community.

Charles





From: Justin Clark-Casey 
To: opensim-dev@lists.berlios.de
Sent: Wednesday, April 15, 2009 8:24:45 AM
Subject: Re: [Opensim-dev] The essence of "grid"

Diva Canto wrote:
> As I zoom in on issues of trust and security, I'm getting to the point 
> where I need a sharp definition of "grid". What is a grid, besides being 
> a map/lookup service and a user accounts service?
> 
> a) nothing more than that
> b) a trust domain
> 
> If we choose b) then we need to think about OSGrid-like grids. How can 
> we trust that a collection of regions administered by different people 
> will behave? Can OSGrid-like grids survive without ToS being signed 
> between the grid operator and the region operators? What if the ToS is 
> such that it delegates to the region admins any liability on bad things 
> happening in their regions? -- that leaves the user with no central 
> authority to complain, which is as good as not having a trust domain.
> 
> If OSGrid-like grids (i.e. no contracts, or very loose ones; just a map 
> service) are to exist, then it's clear that b) doesn't hold in general. 
> It means that there can be grids that are simply a collection of regions 
> that come together in virtual space, but whose trustworthiness as a 
> whole doesn't exist.
> 
> The Hypergrid is specifically designed to cross trust boundaries. Should 
> the OSGrid-like grids become HG-ed sims that share the same map, and let 
> "grids" be, fully, trust domains?
> 
> You may think I'm getting into philosophy, but this is critical for the 
> technical work I'm doing right now related to authentication, 
> server-side vs client-side authority, etc. If we can assume that a 
> "grid" is a uniform trust domain with a central authority, things will 
> be simpler in many ways. If not, things will be a bit more complicated.
> 
> Thoughts?

I think that you could adopt b) without having a philosophical problem with 
OSGrid.  I would say that even the 'loose 
contracts' on OSGrid are a form of trust.  If someone were to abuse that trust 
then I be very surprised if they were not 
removed from the grid.

If OSGrid wanted better security by not sharing the current central services 
then perhaps they could stipulate that new 
regions had to connect by Hypergrid rather than the current model (once the 
various gaps in Hypergrid are ironed out)? 
Then, in a sense, all the directly connected regions becomes a large Hypergrid 
node in the federation that makes up OSGrid.

> 
> 
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> 


-- 
justincc
Justin Clark-Casey
http://justincc.wordpress.com
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Springs, Torques, joints , friction, questions and Vehicles oh my

[Charles Krinke]

Jeff Heaton at "Heaton Research" wrote a book on LSL scripting. All his scripts 
are available at his "Heaton Research" parcel on SecondLife and in the books, 
which are on Amazon.com.

There are a couple of chapters devoted to vehicles and angular motors in making 
a script for a car, boat & airplane.

It might be that using Jeff's examples might get us further along the vehicle 
physics curve?

Charles





From: Dahlia Trimble 
To: opensim-dev@lists.berlios.de
Sent: Wednesday, April 15, 2009 10:21:45 AM
Subject: Re: [Opensim-dev] Springs, Torques, joints , friction, questions and  
Vehicles oh my

Unfortunately I lack experience using the LSL vehicle API, and I've also had 
little success finding good example scripts which were written for the Havok 4 
implementation which is currently in use in SL. Most of the scripts I found 
were quite simple and written for Havok 1, and unfortunately do not work well 
with H4. I've also had little success finding anyone with extensive experience 
using these apis who would be willing to share code and insight. :(

I'm not aware that jointed vehicles are currently implemented in SL so I 
wouldn't think that a comparable API written for ODE or Bullet would need to 
include recursive methods for joints if compatibility with the current LSL 
implementation were desired. Then again, providing access may inspire some 
interesting vehicles but could they be displayed with the LL viewer? Perhaps as 
separate physical prims, or as linksets where the translations of the 
individual prims which make up wheels and axles could be manipulated to 
simulate joints?

Other potential issues might be understanding the effects of each of the 
parameters and their interactions. i.e., does changing buoyancy affect hover 
efficiency? which takes precedence? Are there any scripts which use these 
parameters properly which might be ported over and would be affected?

Perhaps an alternative during development might be to have temporary names for 
the methods and parameters which are different than the LSL names, then once 
the necessary characterizations have been completed and the mappings and 
interactions are implemented and deemed sufficient, the names could be changed 
to the equivalent LSL names.



On Wed, Apr 15, 2009 at 9:42 AM, Teravus Ovares  wrote:

Greetings all

I was hoping to get some robot physics simulation people's ideas here.

Looking at the LSL Vehicle API, it seems clear that there is at least
an angular motor and a linear motor involved.   There may be two
angular motors, one for the angular movement and one for the vertical
attractor(which may just be a jacobian constraint).  In ODE, angular
motors are implemented as springs.Sometimes this can cause
instability and vibration. The truth is, using ODE's angular motor
may or may not be the best solution.   There are others.   For
example, on the ODE-users list currently they're talking about
applying torques directly using the Recursive Newton-Euler
formulation.

"
desired joint velocities and accelerations (qp and qpp respectively),
then the joint torques can be calculated with:

tau = M(q) * qpp + V(q,qp) + G(q) + F(qp)

where M(q) is your inertia matrix and V(q,qp) is a vector of the
coriolis forces, G(q) is a vector of the gravity forces and F(qp) is a
vector of fiction forces.
"

Recursive Newton-Euler formulation
http://www.cours.polymtl.ca/roboop/docs/node146.html

A list of some constants in the LSL Vehicle API:

ANGULAR_DEFLECTION_EFFICIENCY
ANGULAR_DEFLECTION_TIMESCALE
ANGULAR_FRICTION_TIMESCALE
ANGULAR_MOTOR_DECAY_TIMESCALE
ANGULAR_MOTOR_DIRECTION
ANGULAR_MOTOR_TIMESCALE
BANKING_EFFICIENCY
BANKING_MIX
BANKING_TIMESCALE
BUOYANCY
HOVER_EFFICIENCY
HOVER_HEIGHT
HOVER_TIMESCALE
LINEAR_DEFLECTION_EFFICIENCY
LINEAR_DEFLECTION_TIMESCALE
LINEAR_FRICTION_TIMESCALE
LINEAR_MOTOR_DECAY_TIMESCALE
LINEAR_MOTOR_DIRECTION
LINEAR_MOTOR_OFFSET
LINEAR_MOTOR_TIMESCALE
VERTICAL_ATTRACTION_EFFICIENCY
VERTICAL_ATTRACTION_TIMESCALE

Thoughts and patches appreciated.

You'll find a mostly logically complete ODEVehicleSettings.cs in
OpenSim.Region.Physics.OdePlugin.ODEVehicleSettings.cs that contains
all of the constants as well as methods that are plugged in to the
physics plugin, but don't take any action in the physics engine yet.
This was created to organize vehicle API development.

Best Regards

Teravus
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] The essence of "grid"

[Charles Krinke]

Backing up a step.

OpenSim does not allow a way to *stop* a region from attaching to a UGAIM, be 
it OSGrid, or any other OpenSim grid. There is nothing unique about OSGrid 
except its history. OSGrid runs the OpenSim software as it exists. No more, no 
less.

I would think the first step would be to have a way to control whether or not a 
region can attach to a grid first before we get too wrapped up in other things.

At this point, the only way to stop a region from attaching to an OpenSim grid 
is to put a fake entry into the regions table.

Charles





From: Christian Scholz 
To: lo...@ics.uci.edu; opensim-dev@lists.berlios.de
Sent: Wednesday, April 15, 2009 2:27:31 PM
Subject: Re: [Opensim-dev] The essence of "grid"

Hi!

Cristina Videira Lopes schrieb:
> I'm trying to understand what it is that we are supposed to secure, 
> because security depends entirely on that :-)

That usually is my problem with most of these discussions be it on MMOX, 
AWG or social networking. So it would be good to have some sort of list 
of what needs to be secured against what sort of action.

> I've seen way too many talks/chats/posts/blogs talking about a Web of 
> VWs in some form, while making the unwritten assumption that the concept 
> of "grid" (aka Virtual World unit, or whatever you want to call it) 
> aligns with the concept of a domain of trust (i.e. a bunch of simulators 
> that trust each other, under the control of one authority). Then, a Web 
> of VWs is the interconnection of those domains of trust.
> 
> Well, OSGrid doesn't align with that. So either OSGrid is not a 
> valid/sustainable use case for OpenSim or there's something wrong with 
> that unwritten assumption. In my infinite tolerance towards variety, and 
> given the empirical evidence here, I'm leaning towards the latter (i.e. 
> there's something wrong with that assumption).

Unfortunately I am not too familiar on how OSGrid works but I can 
explain how it could work with the scenario I described where we have 
quite many separate services.

In this case a user would login to a region with separate locations of 
the user's inventory, a list of links to group memberships, a link to 
the user's profile and so on.

The region would then ask an authorization manager to get access to 
these resources on behalf of the user. The user will then be asked with 
a list of services the region wants access to and on "ok" this access 
will be granted in form of OAuth access token which can be used to 
perform signed requests to these services. (the concept of the auth 
manager needs to be developed as mentioned).

So in this case the region can only access a user's data after getting 
those tokens. If this "ok" is given automatically though security will 
obviously be lacking.

Now many regions could be grouped into one region domain which might 
mean that they e.g. provide some mapping services and they could maybe 
use shared access to that data.

In the case of a region domain consisting of regions operated by 
different providers this of course means that a rogue sim indeed could 
get access to that data. But in general I don't see a solution here 
unless you really give each sim access upon visiting. Which of course 
would be annoying.

> Yes, OSGrid, as is, will always be extremely vulnerable towards insider 
> rogues; technically, it's impossible to secure OSGrid's UGAIM servers 
> from malicious sims connected to it. But so what? Maybe people want it 
> like that, maybe the OSGrid community wants to perform human 
> surveillance instead of applying technical solutions such as the 
> Hypergrid (once it's matured). Should we stop supporting that use case?

I think in the case of a grid which is operated by many people and you 
don't want just a shared map but also shared access for convenience 
there is not much left for kicking out rogue domains. In fact a user 
might not know that it's a bad sim when entering it anyway so even in 
the case of a confirmation on each crossing that sim would probably gain 
access.

(Moreover I think bad clients is the more likely case of e.g. content 
theft).

> If we continue to support the existence of grids like OSGrid, then we 
> need to think what it means for the users to visit such grids, and how 
> they can visit them securely -- that's all I'm trying to figure out.

They should at least be made aware that there is not one entity running 
it you can sue (well, I don't know the TOS so I don't know if you 
actually could sue somebody).

-- Christian

PS: I know that the OAuth stuff is far away from what would be possible 
right now as it would also mean quite some changes to the client, I am 
mostly mentioning it for discussion purposes and because those are 
standard

Re: [Opensim-dev] The essence of "grid"

[Charles Krinke]

ly, it's impossible to secure OSGrid's UGAIM servers 
>> from malicious sims connected to it. But so what? Maybe people want it 
>> like that, maybe the OSGrid community wants to perform human 
>> surveillance instead of applying technical solutions such as the 
>> Hypergrid (once it's matured). Should we stop supporting that use case?
> 
> I think in the case of a grid which is operated by many people and you 
> don't want just a shared map but also shared access for convenience 
> there is not much left for kicking out rogue domains. In fact a user 
> might not know that it's a bad sim when entering it anyway so even in 
> the case of a confirmation on each crossing that sim would probably gain 
> access.
> 
> (Moreover I think bad clients is the more likely case of e.g. content 
> theft).
> 
>> If we continue to support the existence of grids like OSGrid, then we 
>> need to think what it means for the users to visit such grids, and how 
>> they can visit them securely -- that's all I'm trying to figure out.
> 
> They should at least be made aware that there is not one entity running 
> it you can sue (well, I don't know the TOS so I don't know if you 
> actually could sue somebody).
> 
> -- Christian
> 
> PS: I know that the OAuth stuff is far away from what would be possible 
> right now as it would also mean quite some changes to the client, I am 
> mostly mentioning it for discussion purposes and because those are 
> standards which are on the rise right now.
> 
>>
>> Justin Clark-Casey wrote:
>>> Charles Krinke wrote:
>>>> OSGrid exists with two goals.
>>>>
>>>> 1. Test OpenSim SVN on a regular basis and report results to aid in 
>>>> software development.
>>>> 2. Nurture a community.
>>>>
>>>> We need to start by considering that OpenSim splits the asset storage 
>>>> between regions and the OpenSim assetServer. So, the OpenSim asset model 
>>>> is a little different then SecondLife since we already distribute some 
>>>> assets between regions and the UGAIM.
>>> I didn't know you were doing this already.  Is there anywhere you could 
>>> point to with more details?
>>>
>>>> Are we saying that OSGrid is doing something problematic and pertubating 
>>>> the OpenSim development? I am confused about the OSGrid comments in this 
>>>> philosophical discussion. As I see the whole situation, OSGrid is 
>>>> testing the mainline trunk SVN from OpenSim in a manner consistent with 
>>>> the desires of the community.
>>> Not at all.  I think the debate is more about how the architecture will 
>>> move forward in the future.  As you know, 
>>> regions on OSGrid have to be pretty trustworthy so as not to abuse the 
>>> central grid services.  This classic architecture 
>>> won't go away, but it might be that active development and research 
>>> switches to other architectures (e.g. client side 
>>> asset/inventory access, hypergrid), which can be better secured for a 
>>> robust distributed virtual environment.
>>>
>>> OSGrid may want to consider at some point whether it wants to migrate or 
>>> switch to other architectures once these have 
>>> matured further.  I doubt that this maturity is all that imminent.
>>>
>>> Anyway, I'm probably putting words into Diva's mouth now.
>>>
>>>> Charles
>>>>
>>>> 
>>>> *From:* Justin Clark-Casey 
>>>> *To:* opensim-dev@lists.berlios.de
>>>> *Sent:* Wednesday, April 15, 2009 8:24:45 AM
>>>> *Subject:* Re: [Opensim-dev] The essence of "grid"
>>>>
>>>> Diva Canto wrote:
>>>>  > As I zoom in on issues of trust and security, I'm getting to the point
>>>>  > where I need a sharp definition of "grid". What is a grid, besides being
>>>>  > a map/lookup service and a user accounts service?
>>>>  >
>>>>  > a) nothing more than that
>>>>  > b) a trust domain
>>>>  >
>>>>  > If we choose b) then we need to think about OSGrid-like grids. How can
>>>>  > we trust that a collection of regions administered by different people
>>>>  > will behave? Can OSGrid-like grids survive without ToS being signed
>>>>  > between the grid operator and the region operators? What if the ToS is
>

Re: [Opensim-dev] The essence of "grid"

[Charles Krinke]

Thank you, Michael, for a good and objective description. I would concur with 
your points.

As we move forward, we also have to consider that economic considerations come 
into play in the notion of "personal trust" and "software trust logic".

There are folks already using both V$ (VirtualWallet) on some OpenSim regions 
and grids. Other folks are using vendor scripts with external web site 
connections in browsers. So, delivering goods and services in a reliable manner 
with currency transactions will have a significant effect on both notions of 
trust.

Charles





From: Michael Cortez 
To: opensim-dev@lists.berlios.de
Sent: Thursday, April 16, 2009 7:31:09 AM
Subject: Re: [Opensim-dev] The essence of "grid"

Michael Cortez wrote:
> My thoughts:
>
> To me, a Grid is a virtual space that can be of any given size, and to 
> date, currently consists of one or more discrete Regions that are laid 
> out in a two dimensional grid pattern.  A Grid allows for these 
> discrete individual spaces to be joined together to provide a seamless 
> virtual space that viewers can traverse as if they were a single large 
> simulation.
>
> A Grid can consist of just a single Region, or many Regions.
>
> Within a Grid, it may be desirable to assign ownership of virtual 
> space to specific agents for administration.  Those agents, through 
> their viewers (or other means) should be able to determine who may 
> enter their space, what those visitors can do once there, including 
> what communications are available and what objects they may simulate.  
> Currently we determine areas of administration in 256m^2 regions of 
> space, that are then sub-divided by parcels.
Oh, and I forgot to mention, I fully expect to see Grids of Grids  -- in 
fact, OSGrid could be seen as a grid of grids.  It consists of many 
individual Regions of space, that can on their own be considered a grid.

I'll state it again here, for those that don't care to read my other 
longer rambling message -- each instance of OpenSim is to a certain 
extent a self contained grid.  In standalone mode it has nearly all the 
same services as what is currently called a "Grid" -- and those services 
that are missing could be added.  In fact, "Grid Mode" is simply the 
delegation of specific subsets of responsibility to another entity.

--
Michael Cortez
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] The essence of "grid"

[Charles Krinke]

Backing up a bit, I think we need to start with the fact that a grid provides a 
common start point for an avatar logon. By that, I mean, a grid will have some 
quantity of users in the users MySQL or MSSQL table with a particular avatar 
appearance and some semblance of an inventory.

For the purpose of HyperGrid, many folks wish to travel from grid->grid, 
standalone->grid, standalone->standalone or grid->standalone. And most of those 
folks will expect to have their avatar appearance constant based on their 
original logon place as they HG around.

So, from the most basic point, we can say that our current and most reasonable 
use case is an avatar with custom edits and some inventory that logs onto a 
particular standalone or grid and then expects to be able to HyperGrid to a 
different grid and have that avatar and inventory stay reasonably constant. 
That is, the avatar should not be ruthed.

In order to accomplish this in the general case is a bit tricky and I believe 
is one of the issues being worked on currently. A number of other things begin 
falling out of this notion after this one is working reliability and 
consistently such as the other things brought up in this thread. 

But, I think it all begins with a desire for a consistent avatar and inventory 
experience while HyperGridding.

Charles
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] The essence of "grid"

[Charles Krinke]

I have had this discussion with Adam and Lbsa in the past.

The OpenSim equivalent to SecondLife's AgentDomain is our UserServer. 

So, the "trust domain" is the UserServer executable on a given grid.

Now, it may be incomplete, but that is the direction we have been going for the 
last two years.

Charles





From: Ideia Boa 
To: opensim-dev@lists.berlios.de
Sent: Thursday, April 16, 2009 1:16:52 PM
Subject: Re: [Opensim-dev] The essence of "grid"

 Finally someone to explain in brief what is "trust domain" and is
precisely what we need. We need to create something that the grids and
regions connected by
hypergrid can behave as "trust domain" 
Cristina got 10% of reason in your security considerations for
links between grids and regions. 
Melanie, thanks for the help given by your post.

Ideia Boa

Melanie wrote: 
In the future, the avatar and his inventory will be independent of 
the grid. This is already almost a reality.

To address another post, a "trust domain" doesn't imply that the 
visitor trusts it. It merely means that all regions within it trust 
each other. Like the servers that make up a web application.

Melanie

Charles Krinke wrote:

Backing up a bit, I think we need to start with the fact that a grid provides a 
common start point for an avatar logon. By that, I mean, a grid will have some 
quantity of users in the users MySQL or MSSQL table with a particular avatar 
appearance and some semblance of an inventory.

For the purpose of HyperGrid, many folks wish to travel from grid->grid, 
standalone->grid, standalone->standalone or grid->standalone. And most of those 
folks will expect to have their avatar appearance constant based on their 
original logon place as they HG around.

So, from the most basic point, we can say that our current and most reasonable 
use case is an avatar with custom edits and some inventory that logs onto a 
particular standalone or grid and then expects to be able to HyperGrid to a 
different grid and have that avatar and inventory stay reasonably constant. 
That is, the avatar should not be ruthed.

In order to accomplish this in the general case is a bit tricky and I believe 
is one of the issues being worked on currently. A number of other things begin 
falling out of this notion after this one is working reliability and 
consistently such as the other things brought up in this thread. 

But, I think it all begins with a desire for a consistent avatar and inventory 
experience while HyperGridding.

Charles





___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de 
https://lists.berlios.de/mailman/listinfo/opensim-dev 
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de 
https://lists.berlios.de/mailman/listinfo/opensim-dev 
  


-Inline Attachment Follows-

begin:vcard
fn:Ideia Boa
n:Boa;Ideia
note;quoted-printable:Best regards,=0D=0A=
Ideia Boa=0D=0A=
WorldSimTerra=0D=0A=
=0D=0A=
Join the new 3D world revolution : http://www.worldsimterra.com/ 
x-mozilla-html:TRUE
url:http://www.worldsimterra.com 
version:2.1
end:vcard___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] The essence of "grid"

[Charles Krinke]

Well, Mike. I respect your opinion and the others expressed about our existing 
community.

The community is what has gotten us to this point and it is important to listen 
to our community.

It seems reasonable that additional features can be added to OpenSim in a 
somewhat cavalier fashion, and thats fine.

Problems may occur if we start making existing features inoperable of shrug our 
shoulders when our community is hurting because some feature important to one 
use case may be subsumed by another use case.

So, with that said, lets evolve OpenSim and consider all the use cases, of 
which 'gridmode' is an important one.

Charles





From: Mike Dickson 
To: Melanie 
Cc: "opensim-dev@lists.berlios.de" 
Sent: Friday, April 17, 2009 8:24:36 AM
Subject: Re: [Opensim-dev] The essence of "grid"

Yes, just voicing my opinion.  And my concern is that you will prevent
me from running a walled garden in trying to get your "inventory on the
client" hypergrid model working.

As has been pointed out, the sources are BSD licensed, I could always
fork what's there and do my own thing.  It seemed more productive
however to voice my opinion and at least try and represent an alternate
point of view. Personally I think the rush to hypergrid is glossing over
lots of issues and the trust models being discussed and over simplified
at best. Again, thats my opinion and at this point I don't expect it
will get listened to.

Mike

On Fri, 2009-04-17 at 15:12 +, Melanie wrote:
> No one is preventing you from running a walled garden/SL clone. The 
> hypergrid won't touch you in that case. Hypergrid most certainly 
> belongs into core and will stay there.
> 
> Melanie
> 
> Mike Dickson wrote:
> > That's been my thought all along. What if the content in the users
> > "inventory" is my IP.  I've granted a license for a customer/user to use
> > it (perhaps even limited to where the content is used). 
> > 
> > I appreciate the energy around the hypergrid concept. But there are lots
> > of scenarios where the hypergrid is entirely irrelevant. I still believe
> > implementation of it belongs in the forge and not in the core. But I
> > completely agree with Michael that the energy around Hypergrid
> > shoduldn't de-empahsive the platform aspects of OpenSim in such a way
> > that a non-Hypergrid case becomes unimplementable (or even harder).
> > 
> > Mike
> > 
> >>  
> >> I know this is where you and others have hashed things to, but please 
> >> keep in mind -- the scenario where an organization may not want the user 
> >> to be in control of their inventory, and where they have no say as to 
> >> where it is stored.  I understand that it's not the general scenario of 
> >> people talking about hypergrid, but OpenSim is a platform that will be 
> >> used for things other then "hypergridding" and I don't want to see 
> >> alternative scenarios ruled out, or marginalized because of the current 
> >> focus on hypergrid.
> >> 
> >> Cheers,
> >> --
> >> Michael Cortez
> > 
> > 
> > ___
> > Opensim-dev mailing list
> > Opensim-dev@lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> > 
> > 
-- 
Mike Dickson 
BladeSystem infrastructure R&D

___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Development models

[Charles Krinke]

Diva went out of her way to put the original HyperGrid module on the forge. 

After it had gained acceptance, *others* suggested to her that adding it to the 
core part of OpenSim would be to our advantage.

We all voted on that and agreed this was the right thing to do.

There are other modules that in forge that come along from time to time, and 
some of them may very well end up in the core logic as we find and appropriate 
consensus.

Charles





From: Diva Canto 
To: mike.dick...@hp.com
Cc: "opensim-dev@lists.berlios.de" 
Sent: Friday, April 17, 2009 10:22:25 AM
Subject: Re: [Opensim-dev] Development models

The OpenSim project has a process for assessing and approving code to 
core, and the Hypergrid patch went through that process. In case you 
weren't here then, you can look those discussions up in the archives of 
this mailing list back in October/November.

I'm not sure the process is explained on the Wiki. Some of it is here:
http://opensimulator.org/wiki/Support#Feature_Requests
But it's not complete. Maybe Justin or others can explain it, if people 
are interested in knowing.


Mike Dickson wrote:
> Sort of, yes.  Except in opensim pretty much everything happens on head.
> IMO, ideally the hypergrid stuff would be done on a branch (and if I
> want that I can check out from that branch) and the changes wouldn't
> make it back into core until any changes to interfaces (or new
> implementations of interfaces) was defined and completed.
> 
> I'm not picking on your work. It's good stuff.  I'm arguing for more
> rigour in how things get into core and the modularity of the platform
> gets improved.  As a new developer understanding whats in OpenSim is a
> PITA today.  I'd like to see that improve so we can increase the number
> of hands making the improvements happen.
> 
> Mike
> 
> On Fri, 2009-04-17 at 17:05 +, Diva Canto wrote:
>> That's exactly what I'm doing here.
>>
> 
> 
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Development models (was Re: The essence of "grid")

[Charles Krinke]

Well... I rather suspect we are all headed for the same place, but, ... we seem 
to be having some semantic 'challenges' lately.

I *know* that all the hearts are in the right place on this list and that all 
we have to do is be understanding and supportive of each other.

The thing that has gotten us this far has been a trust in each other. For two 
years now, we have used the software development strategy of 'just work on what 
your passion tells you'. And it has gotten us a long ways down the path.

Now,... we are having a modicum of success *and* the investment of all in terms 
of time and servers has gotten significant. So,... we are *all* (myself 
included) getting anxious whenever we perceive our 'use case' *or* our part of 
the creation of OpenSim feels threatened.

Anyway,  


Laissez Les Bon Temps Roulez!

&&

Create what your passion dictates!







From: Ideia Boa 
To: opensim-dev@lists.berlios.de
Sent: Friday, April 17, 2009 1:16:23 PM
Subject: Re: [Opensim-dev] Development models (was Re: The essence of "grid")

 If we want to watch the birth of a so-called Web 3D, welcome Diva and
welcome Hypergrid. 
If we want to have a clone of SL, but with the option of different
grids, welcome all development aid, including Hypergrid, as this is
also a dream of LL. 
But if we only want to have a bad clone of
the SL in standalone, we can stop the development now, nothing more is
needed to have a game for some hours. 

For me I support and
I want to watch the birth of the Web 3D, I already attended the birth
of
the web, even before that, I work with some BBSs, then I went to the
web 2, and I do not want to lose the opportunity and maybe I am not the
onlyone, from the inside wanting to attend the birth of the future Web

Ideia Boa___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

[Opensim-dev] Closing a few Mantisi

[Charles Krinke]

In our Mantis screen is a tab for 'summary'.

On that 'summary' screen are two really interesting windows. One is the 'By 
Date' and the other is 'Longest Open'.

I would like to suggest that any patches to clear one or more of the 'Longest 
Open' would be greatly appreciated and would help to move the project along.

Charles
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] OAuth as authentication and authorisation (capability) specification

[Charles Krinke]

That is an interesting point. I think the perception by some is that we would 
like to have 'seamless' use of openid/oauth between various grids as folks 
might move from grid to grid using OGP, MXP, HG or other interop notions. So, 
popping up a password dialog in the midst of a teleport might be 'off putting'. 

I had heard there was a use case where that was not the case, but admit that I 
am not all that familiar with the inner workings of openid/oauth. If we need to 
have a password dialog in interop teleports, well, that may be a small price to 
pay.

Charles





From: Melvin Carvalho 
To: opensim-dev@lists.berlios.de
Sent: Saturday, April 25, 2009 11:10:08 AM
Subject: Re: [Opensim-dev] OAuth as authentication and authorisation 
(capability) specification

On Sat, Apr 25, 2009 at 5:09 PM, Tommi Laukkanen
 wrote:
> Hello
>
>>
>> Oauth is not an authentication system, it is delegated credentials
>> system via a third party.
>>
>
> Authentication and authorisation with delegated credentials is what we
> need as identities will be provided by identity providers and assets
> from asset providers in distributed model. We need the client to be
> able to authenticate against indentity provider acquire tokens and
> provide them to region for authentication on region level, access to
> profile information and assets etc. It is not good idea to pass
> credentials to the region server directly.

It's a good tech, and the community has done a lot of work getting the
open model recognised.

You'd be looking at at least two specs, openid and oauth to start
with, then there's a few others such as sreg and attributute exchange,
maybe pape, so there is some complexity there.

Also bear in mind that this was designed with standard pattern is
username/login from the 3rd party interface, so you'd have to server
up, for example a google login form (or every other kind of login
form) when singing in, or perhaps when teleporting, which might not be
the ideal user experience.

>
>> FOAF+SSL (aka Secure Web ID), is a much newer 3.0 techonology which
>> has less complex interactions (no third party authentication or
>> passwords required, it is a client server).  In a nutshell it uses the
>> well established SSL protocol for authentication, and FOAF to makup a
>> public key in your profile.
>
> You can use OAuth for 2 legged authentication but your suggestion
> sounds interesting as well. One would like to be able to use existing
> networks hosting user identities but time will rectify that for any
> new technologies as they gain popularity.

Do take a look if you get a chance, it's a good system, and SSL PKI is
mature and tried and tested, it is used to log in to secure email,
VPN, ssh and many other systems.  You just need to store a public key
with the users assets and you're well on your way.  Im happy to help
if it's needed, I'll try and follow the discussions here :)

>
> -tommi
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] moving away from grid vs. standalone

[Charles Krinke]

I would urge us to make changes to the master avatar stuff with notice and 
encouragement of folks to write FAQ, wiki entries, mini-apnotes and anything 
else that will help cut down on confusion of those who have significant effort 
invested into builds on existing regions.

Charles





From: Melanie 
To: d...@metaverseink.com; opensim-dev@lists.berlios.de
Sent: Wednesday, April 29, 2009 1:52:47 PM
Subject: Re: [Opensim-dev] moving away from grid vs. standalone

I have done a lot of stuff related to that. Master avatar should not 
even exist in the way it still does today, that is legacy. The very 
same thing can be done in another way (code-wise).
So the existing master avatar stuff can be removed,if that is the 
only blocker, i'll think up some new semantics for that and 
implement it.

Melanie

d...@metaverseink.com wrote:
> I think that there is a technical obstacle to doing that: the master 
> avatar stuff, that happens early on in the application (OpenSimBase, 
> line 688), needs to have the communication code in place. I think -- 
> although I may be wrong -- that that happens before region modules are 
> in place.
> 
> Melanie wrote:
>> I still think all that stuff can be put in region modules
>> 
>> Melanie
>> 
>> d...@metaverseink.com wrote:
>>> Maybe the right name for it is
>>> OpenSim.Region.ResourceServicesConnectors.dll
>>>
>>> d...@metaverseink.com wrote:
 Stefan Andersson wrote:
> How about
>  
> ---
> [RegionResourceServices]
> ;GridService = OpenSim.Region.Communications.Hypergrid.dll, 
> HGGridServices
> ;GridService = OpenSim.Region.Communications.Local.dll, 
> LocalBackEndServices
>  
> GridService = OpenSim.Region.Communications.OGS1.dll, OGS1GridServices
>  
> [GridService]
> grid_server_url = "http://192.168.1.101:9000";
> grid_send_key = "null"
> grid_recv_key = "null"

 The problem with specifying dlls *in this particular case* is that 
 these things aren't entirely orthogonal/different. The Hypergrid dlls 
 are a mashup of the other two. Therefore from a source code 
 perspective it makes things a heck of a lot more complicated than 
 they need to be if we simply merge things and use conditionals on 
 configuration variables. For example, hyperlinks (part of grid 
 services) is a really simple extension to LocalGrid services.

 The issue of local vs remote services isn't entirely orthogonal 
 either. Some parts of OGS1 use Local services -- the well know 
 pattern of trying things locally first and if that doesn't work, 
 proceed for a remote service call (e.g. OGS1 grid services does that).

 I see why you want this, in abstract. If another service comes along, 
 it can simply be added as a component. Or if someone writes, say, a 
 completely different inventory service, its interface can be added as 
 dll.

 But in this particular case, for the code we already have, I think 
 that having Local.dll, OGS1.dll and Hypergrid.dll is not working 
 well, even if the configuration process is the one you suggest. The 
 code is mess; things are _way_ more complicated than they need to be.

 So, maybe, what we can do is merging these two ideas. We'll have only 
 one dll (OpenSim.Region.ResourceServices.dll), but we'll specify 
 things in OpenSim.ini the way that you suggest, so that if anyone 
 comes along and wants to plug in a different inventory service, he 
 can just specify the  other dll and an entry class name for it.

 What do you think?


> [Security]
>  
> SessionAuthentication = {True|False}
> KeyAuthentication = {True|False}
>
> ---
>  
> The constructor is being fed a config source, so the service can 
> pick out whatever it needs.
>  
> All the shipped grid services could move into one assembly, as we're 
> explicitly specifying the implementing calss.
>  
> I believe this approach would get us improved flexibility.
>
> /Stefan
 ___
 Opensim-dev mailing list
 Opensim-dev@lists.berlios.de
 https://lists.berlios.de/mailman/listinfo/opensim-dev

>>> ___
>>> Opensim-dev mailing list
>>> Opensim-dev@lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>
>>>
>> 
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> 
> 
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] moving away from grid vs. standalone

[Charles Krinke]

It is always a balance between keeping functionality in an evolving project and 
refactoring and experimenting.

I will support and encourage refactoring and experimentation with one proviso. 
That proviso is a few paragraphs on the wiki giving clues to allow those 
deploying OpenSim what is going on and how to work around trunk during a period 
of refactoring and experimentation.

Charles





From: Mike Dickson 
To: "opensim-dev@lists.berlios.de" 
Sent: Thursday, April 30, 2009 8:57:24 AM
Subject: Re: [Opensim-dev] moving away from grid vs. standalone

I'll echo a sentiment I've tried to express before. This sort of
aggressive refactoring and experimentation is really important to the
growth of OpenSim.  The "release" process has been focused on trying to
figure out a stable point and snapshot-ing that. That places a burden on
the "release coordinator" to poll folks for what that stable "snapshot"
is.  IMO, ideally the heavy refactoring would happen on a branch or
separate tree and then pushed to HEAD when it stabilizes.  

Again, I'm completely for the heavy research  and refactoring focus.
But IMO if for a shared project you want to do that you need to adopt a
development approach that gracefully allows that to happen.

Mike


On Thu, 2009-04-30 at 15:37 +, Dahlia Trimble wrote:
> We need to be careful about how things are broken and make repairs
> expeditiously as we also hinder other developers if they are unable to
> use their regions for development and testing.
> 
> On Wed, Apr 29, 2009 at 3:01 PM, Melanie  wrote:
> Maybe these things need to be broken. We are almost locked
> into a
> rigid schema, now we still have a chance to go to true
> modularity
> and we should take it. After all, trunk is meant to be
> broken :)
>
>
> Melanie



___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

[Opensim-dev] 23 LSL functions remaining

[Charles Krinke]

I am asking for a few patches to complete the 23 LSL functions in our original 
project of more then 330. We are *almost* there, but need a little help with 
patches. Here is the remaining list that are still in the "Not Implemented" 
state.

llRotTarget()
llRotTargetRemove()
llLoopSoundMaster()
llLoopSoundSlave()
llStopLookAt()
llCollisionFilter()
llAttachToAvatar()
llDetachFromAvatar()
llRotLookAt()
llPointAt()
llStopPointAt()
llGodLikeRezObject()
llPassTouches()
llSetDamage()
llTextBox()
llCollisionSprite()
llPassCollisions()
llGetCenterOfMass()
llSetSoundQueing()
llTriggerSoundLimited()
llGroundRepel()
llSetVehicleFlags()
llRemoveVehicleFlags()
llRemoteDataSetRegion()
llSetInventoryPermMask()

Partial implementations are solicited. The goal here is to get all the LSL 
functions we have defined in LSL_Api.cs out of the not implemented state with 
at least *some* implementation.

Charles
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] 23 LSL functions remaining

[Charles Krinke]

This list is the original list we started with over a year ago. At this point, 
I would say any patches to get more implementation would be appreciated so we 
can get a bit further ahead.

Charles





From: Thomas Grimshaw 
To: opensim-dev@lists.berlios.de
Sent: Monday, May 11, 2009 7:33:27 PM
Subject: Re: [Opensim-dev] 23 LSL functions remaining

What about the llDetectedTouch* functions?

llRequestURL, llReleaseURL, llGetFreeURLs, llGetHTTPHeader, 
llHTTPResponse, llRequestSecureURL, etc etc

There are a lot more than 23 functions to go :)

~T

Charles Krinke wrote:
> I am asking for a few patches to complete the 23 LSL functions in our 
> original project of more then 330. We are *almost* there, but need a 
> little help with patches. Here is the remaining list that are still in 
> the "Not Implemented" state.
>
> llRotTarget()
> llRotTargetRemove()
> llLoopSoundMaster()
> llLoopSoundSlave()
> llStopLookAt()
> llCollisionFilter()
> llAttachToAvatar()
> llDetachFromAvatar()
> llRotLookAt()
> llPointAt()
> llStopPointAt()
> llGodLikeRezObject()
> llPassTouches()
> llSetDamage()
> llTextBox()
> llCollisionSprite()
> llPassCollisions()
> llGetCenterOfMass()
> llSetSoundQueing()
> llTriggerSoundLimited()
> llGroundRepel()
> llSetVehicleFlags()
> llRemoveVehicleFlags()
> llRemoteDataSetRegion()
> llSetInventoryPermMask()
>
> Partial implementations are solicited. The goal here is to get all the 
> LSL functions we have defined in LSL_Api.cs out of the not implemented 
> state with at least *some* implementation.
>
> Charles
> 
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>  

___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] 23 LSL functions remaining

[Charles Krinke]

Dear Thomas:

I see these six, and I see one more, that is, LSL_http_server().

Can you help me out with any others that are not on the original list, that is, 
those defined in the C# interface files. 

Or said differently, can you expand your 'etc etc' a little bit, please.

Charles





From: Thomas Grimshaw 
To: opensim-dev@lists.berlios.de
Sent: Monday, May 11, 2009 7:33:27 PM
Subject: Re: [Opensim-dev] 23 LSL functions remaining

What about the llDetectedTouch* functions?

llRequestURL, llReleaseURL, llGetFreeURLs, llGetHTTPHeader, 
llHTTPResponse, llRequestSecureURL, etc etc

There are a lot more than 23 functions to go :)

~T

Charles Krinke wrote:
> I am asking for a few patches to complete the 23 LSL functions in our 
> original project of more then 330. We are *almost* there, but need a 
> little help with patches. Here is the remaining list that are still in 
> the "Not Implemented" state.
>
> llRotTarget()
> llRotTargetRemove()
> llLoopSoundMaster()
> llLoopSoundSlave()
> llStopLookAt()
> llCollisionFilter()
> llAttachToAvatar()
> llDetachFromAvatar()
> llRotLookAt()
> llPointAt()
> llStopPointAt()
> llGodLikeRezObject()
> llPassTouches()
> llSetDamage()
> llTextBox()
> llCollisionSprite()
> llPassCollisions()
> llGetCenterOfMass()
> llSetSoundQueing()
> llTriggerSoundLimited()
> llGroundRepel()
> llSetVehicleFlags()
> llRemoveVehicleFlags()
> llRemoteDataSetRegion()
> llSetInventoryPermMask()
>
> Partial implementations are solicited. The goal here is to get all the 
> LSL functions we have defined in LSL_Api.cs out of the not implemented 
> state with at least *some* implementation.
>
> Charles
> 
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>  

___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] 23 LSL functions remaining

[Charles Krinke]

My goal here is to get at least "some" implementation for all the LSL functions.

Given at least "some", then the debate of compatibility starts to get 
interesting to more folks.

So, getting back to my original point, a few patches to get "some" 
implementation on the 27 or so (including the new ones and discluding a couple 
that SecondLife says are unused), lets see if we can get to where we can have 
some interesting 'compatibility' discussions.

I think it is fair to say that the list, excluding (u), (d), & (g) from 
http://wiki.secondlife.com/wiki/Category:LSL_Functions represents the list of 
those functions that should be implemented. Perhaps others could comment on 
this and help us get closure on this year and a half long project of 
implementing these functions.

Charles







From: Colin B. Withers 
To: "opensim-dev@lists.berlios.de" 
Sent: Tuesday, May 12, 2009 3:13:40 AM
Subject: Re: [Opensim-dev] 23 LSL functions remaining

There is also the question of compatibility with LSL. Questions have been 
raised about whether Opensim can be used as a development tool for SL. Here is 
one thread that calls compatibility into question:

http://www.sluniverse.com/php/vb/opensim-discussion/26340-opensim-compatibility-place-develop-secondlife.html

Is the aim to have 100% compatibilty, so that scripts developed in Opensim will 
be guaranteed to work in SL, and vice versa? As the old saying goes, you cannot 
be a little bit pregnant, it is either 100% or nothing.

Rock



From: opensim-dev-boun...@lists.berlios.de 
[opensim-dev-boun...@lists.berlios.de] On Behalf Of Charles Krinke 
[...@pacbell.net]
Sent: 12 May 2009 04:25
To: opensim-dev
Subject: [Opensim-dev] 23 LSL functions remaining

I am asking for a few patches to complete the 23 LSL functions in our original 
project of more then 330. We are *almost* there, but need a little help with 
patches. Here is the remaining list that are still in the "Not Implemented" 
state.

llRotTarget()
llRotTargetRemove()
llLoopSoundMaster()
llLoopSoundSlave()
llStopLookAt()
llCollisionFilter()
llAttachToAvatar()
llDetachFromAvatar()
llRotLookAt()
llPointAt()
llStopPointAt()
llGodLikeRezObject()
llPassTouches()
llSetDamage()
llTextBox()
llCollisionSprite()
llPassCollisions()
llGetCenterOfMass()
llSetSoundQueing()
llTriggerSoundLimited()
llGroundRepel()
llSetVehicleFlags()
llRemoveVehicleFlags()
llRemoteDataSetRegion()
llSetInventoryPermMask()

Partial implementations are solicited. The goal here is to get all the LSL 
functions we have defined in LSL_Api.cs out of the not implemented state with 
at least *some* implementation.

Charles
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] 23 LSL functions remaining

[Charles Krinke]

The folks on this mailing list have the power to make OpenSim more compatible 
with patches to the source.

So, as we go forward, lets exercise that power and add the missing 
implementation sections of a few dozen functions *and* find the ones that are 
not compatible and work out the details.

Charles





From: Frank Nichols 
To: opensim-dev@lists.berlios.de
Sent: Tuesday, May 12, 2009 7:38:00 AM
Subject: Re: [Opensim-dev] 23 LSL functions remaining

I think it is a matter of perspective, a "better" way to look at this 
issue - does this raise the question whether Secondlife can be used as a 
development tool for Opensim? If Opensim achieves it's desired goals 
then Secondlife will be relegated to a tiny corner of the new internet.

Colin B. Withers wrote:
> There is also the question of compatibility with LSL. Questions have been 
> raised about whether Opensim can be used as a development tool for SL. Here 
> is one thread that calls compatibility into question:
>
> http://www.sluniverse.com/php/vb/opensim-discussion/26340-opensim-compatibility-place-develop-secondlife.html
>
> Is the aim to have 100% compatibilty, so that scripts developed in Opensim 
> will be guaranteed to work in SL, and vice versa? As the old saying goes, you 
> cannot be a little bit pregnant, it is either 100% or nothing.
>
> Rock
>  
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] 23 LSL functions remaining

[Charles Krinke]

Thats easy. Since there is no specification, and all we can do is test scripts 
of various flavors from "completely non-functional" to "wondrously crafted", we 
*all* get to decide what a function "should" do.

This is a community effort. As a community, various folks contribute source 
from time to time. Various other folks are dedicated to testing and reporting 
the results.

So, "patches" are the key to moving any implementation *or* compatibility 
forward.

Charles





From: Colin B. Withers 
To: "opensim-dev@lists.berlios.de" 
Sent: Tuesday, May 12, 2009 9:04:18 AM
Subject: Re: [Opensim-dev] 23 LSL functions remaining

But then surely the question comes down to an understanding of what any 
particular function 'should' do. Is it entirely up to the writer to decide what 
any function is, and should do, or is there a clear definition of each function 
that they should be compatible with?

You cannot have partial compatibility, or no-one would have any confidence. I 
believe that LSL functions should be 100% compatible (written differently, of 
course, but the inputs and outputs should always be the same), or another 
scripting language should have been used (eg Lua) or developed.

I for one see Opensim use my opensim as a development platform, and I have been 
using it for development before bringing my creations into SL. I have not done 
much scripting yet, until all the functions are implemented, but I would expect 
that all the scripts I develop in my Opensim sandbox to work when I import them 
into SL.

Rock 

From: opensim-dev-boun...@lists.berlios.de 
[opensim-dev-boun...@lists.berlios.de] On Behalf Of Charles Krinke 
[...@pacbell.net]
Sent: 12 May 2009 16:06
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] 23 LSL functions remaining

My goal here is to get at least "some" implementation for all the LSL functions.

Given at least "some", then the debate of compatibility starts to get 
interesting to more folks.

So, getting back to my original point, a few patches to get "some" 
implementation on the 27 or so (including the new ones and discluding a couple 
that SecondLife says are unused), lets see if we can get to where we can have 
some interesting 'compatibility' discussions.

I think it is fair to say that the list, excluding (u), (d), & (g) from 
http://wiki.secondlife.com/wiki/Category:LSL_Functions represents the list of 
those functions that should be implemented. Perhaps others could comment on 
this and help us get closure on this year and a half long project of 
implementing these functions.

Charles




From: Colin B. Withers 
To: "opensim-dev@lists.berlios.de" 
Sent: Tuesday, May 12, 2009 3:13:40 AM
Subject: Re: [Opensim-dev] 23 LSL functions remaining

There is also the question of compatibility with LSL. Questions have been 
raised about whether Opensim can be used as a development tool for SL. Here is 
one thread that calls compatibility into question:

http://www.sluniverse.com/php/vb/opensim-discussion/26340-opensim-compatibility-place-develop-secondlife.html

Is the aim to have 100% compatibilty, so that scripts developed in Opensim will 
be guaranteed to work in SL, and vice versa? As the old saying goes, you cannot 
be a little bit pregnant, it is either 100% or nothing.

Rock



From: 
opensim-dev-boun...@lists.berlios.de<mailto:opensim-dev-boun...@lists.berlios.de>
 
[opensim-dev-boun...@lists.berlios.de<mailto:opensim-dev-boun...@lists.berlios.de>]
 On Behalf Of Charles Krinke [...@pacbell.net<mailto:c...@pacbell.net>]
Sent: 12 May 2009 04:25
To: opensim-dev
Subject: [Opensim-dev] 23 LSL functions remaining

I am asking for a few patches to complete the 23 LSL functions in our original 
project of more then 330. We are *almost* there, but need a little help with 
patches. Here is the remaining list that are still in the "Not Implemented" 
state.

llRotTarget()
llRotTargetRemove()
llLoopSoundMaster()
llLoopSoundSlave()
llStopLookAt()
llCollisionFilter()
llAttachToAvatar()
llDetachFromAvatar()
llRotLookAt()
llPointAt()
llStopPointAt()
llGodLikeRezObject()
llPassTouches()
llSetDamage()
llTextBox()
llCollisionSprite()
llPassCollisions()
llGetCenterOfMass()
llSetSoundQueing()
llTriggerSoundLimited()
llGroundRepel()
llSetVehicleFlags()
llRemoveVehicleFlags()
llRemoteDataSetRegion()
llSetInventoryPermMask()

Partial implementations are solicited. The goal here is to get all the LSL 
functions we have defined in LSL_Api.cs<http://LSL_Api.cs> out of the not 
implemented state with at least *some* implementation.

Charles
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de<mailto:Opensim-dev@lists.berlios.de>
https:/

[Opensim-dev] vehicle script

[Charles Krinke]

Jeff Heaton, in his book, "Introduction to Linden Scripting Language for Second 
Life" has a vehicle script for a basic car on page 171. At the risk of 
irritating Jeff, I am pasting it here and hoping we can use it for a test 
script to wring out vehicle script functionality.

It uses the LSL functions llSetVehicleType(), llSetVehicleFloatParam() & 
llSetVehicleVectorParam() which are three of the key vehicle functions we need 
to support.

I am hoping a few folks might take this script, test it, Mantis the results and 
help us get momentum to patch the missing pieces.

Charles

// Encog's Magic Wagon
// Very simple vehicle script

float forward_power = 15; //Power used to go forward (1 to 30)
float reverse_power = -15; //Power ued to go reverse (-1 to -30)
float turning_ratio = 2.0; //How sharply the vehicle turns. Less is more 
sharply. (.1 to 10)
string sit_message = "Ride"; //Sit message
string not_owner_message = "You are not the owner of this vehicle ..."; //Not 
owner message

setVehicle()
{
//car

llSetVehicleType(VEHICLE_TYPE_CAR);
llSetVehicleFloatParam(VEHICLE_ANGULAR_DEFLECTION_EFFICIENCY, 0.2);
llSetVehicleFloatParam(VEHICLE_LINEAR_DEFLECTION_EFFICIENCY, 0.80);
llSetVehicleFloatParam(VEHICLE_ANGULAR_DEFLECTION_TIMESCALE, 0.10);
llSetVehicleFloatParam(VEHICLE_LINEAR_DEFLECTION_TIMESCALE, 0.10);
llSetVehicleFloatParam(VEHICLE_LINEAR_MOTOR_TIMESCALE, 1.0);
llSetVehicleFloatParam(VEHICLE_LINEAR_MOTOR_DECAY_TIMESCALE, 0.1);
llSetVehicleFloatParam(VEHICLE_ANGULAR_MOTOR_TIMESCALE, 0.1);
llSetVehicleFloatParam(VEHICLE_ANGULAR_MOTOR_DECAY_TIMESCALE, 0.1);
llSetVehicleVectorParam(VEHICLE_LINEAR_FRICTION_TIMESCALE, <10.0, 2.0, 
1000.0>);
llSetVehicleVectorParam(VEHICLE_ANGULAR_FRICTION_TIMESCALE, <0.1, 0.1, 
0.1>);
llSetVehicleFloatParam(VEHICLE_VERTICAL_ATTRACTION_EFFICIENCY, 0.50);
llSetVehicleFloatParam(VEHICLE_VERTICAL_ATTRACTION_TIMESCALE, 0.50);

}

default
{
state_entry()
{
llSetSitText(sit_message);
// forward-back,left-right,updown
llSitTarget(<0.2,0,0.45>, ZERO_ROTATION );

llSetCameraEyeOffset(<-8, 0.0, 5.0>);
llSetCameraAtOffset(<1.0, 0.0, 2.0>);

//llPreloadSound("car_start");
//llPreloadSound("car_run");
setVehicle();
}

changed(integer change)
{


if (change & CHANGED_LINK)
{

key agent = llAvatarOnSitTarget();
if (agent)
{
if (agent != llGetOwner())
{
llSay(0, not_owner_message);
llUnSit(agent);
llPushObject(agent, <0,0,50>, ZERO_VECTOR, FALSE);
}
else
{
//llTriggerSound("car_start",1);


llMessageLinked(LINK_ALL_CHILDREN , 0, "WHEEL_DRIVING", 
NULL_KEY);
llSleep(.4);
llSetStatus(STATUS_PHYSICS, TRUE);
setVehicle();
llSleep(.1);
llRequestPermissions(agent, PERMISSION_TRIGGER_ANIMATION | 
PERMISSION_TAKE_CONTROLS);

//llLoopSound("car_run",1);
}
}
else
{
//llStopSound();

llSetStatus(STATUS_PHYSICS, FALSE);
llSleep(.4);
llReleaseControls();
llTargetOmega(<0,0,0>,PI,0);

llResetScript();
}
}

}

run_time_permissions(integer perm)
{
if (perm)
{
llTakeControls(CONTROL_FWD | CONTROL_BACK | CONTROL_DOWN | 
CONTROL_UP | CONTROL_RIGHT | 
CONTROL_LEFT | CONTROL_ROT_RIGHT | 
CONTROL_ROT_LEFT, TRUE, FALSE);
}
}

control(key id, integer level, integer edge)
{
integer reverse=1;
vector angular_motor;

//get current speed
vector vel = llGetVel();
float speed = llVecMag(vel);

//car controls
if(level & CONTROL_FWD)
{
llSetVehicleVectorParam(VEHICLE_LINEAR_MOTOR_DIRECTION, 
);
reverse=1;
}
if(level & CONTROL_BACK)
{
llSetVehicleVectorParam(VEHICLE_LINEAR_MOTOR_DIRECTION, 
);
reverse = -1;
}

if(level & (CONTROL_RIGHT|CONTROL_ROT_RIGHT))
{
angular_motor.z -= speed / turning_ratio * reverse;
}

if(level & (CONTROL_LEFT|CONTROL_ROT_LEFT))
{
angular_motor.z += speed / turning_ratio * reverse;
}

llSetVehicleVectorParam(VEHICLE_ANGULAR_MOTOR_DIRECTION, angular_motor);

} //end control   


} //end default
__

Re: [Opensim-dev] voice meetings

[Charles Krinke]

Indeed, discussing these subjects with those on the opensim-dev mailing list in 
voice or text is to all of our mutual advantage.

Many folks have complained to me of the way the money issue was handled and 
communication with the rest of the community is important to moving forward and 
helping credibility.

Charles





From: Cristina Videira Lopes 
To: "opensim-dev@lists.berlios.de" 
Sent: Friday, May 15, 2009 8:31:43 PM
Subject: [Opensim-dev] voice meetings

Another thing we could do to improve the state of comms would be to have 
voice meetings once in a while. I hate meetings as much as everyone 
else, but voice meetings tend to be much faster than email discussions 
back & forth. Hey -- we could even use Freeswitch with a cool virtual 
world system I know called OpenSim! :-)
I haven't tried installing it, but I can try to do it in one of the sims 
of the UCI Grid.
These would be meetings for core only.

As agenda for a possible first meeting to be held soon, I would propose
- postmortem of the money issue process/action
- pluginizing OpenSim servers
- anything else anyone wants to bring up

I know we're all in different time zones, so I'm not sure a synchronous 
meeting is feasible.
Would 8am PST work for everyone?

___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

[Opensim-dev] breaking OpenSim.ini changes

[Charles Krinke]

We seem to have breaking changes in OpenSim.ini today and I would like to 
recommend that we slow that down. 

In the past, we have been very careful about breaking changes in OpenSim.ini to 
preserve compatibility and go out of our way to send notice. It seems that 
changing syntax in our .ini file is something that should be done with 
deliberation and more concern and notice to our users.

Charles
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] breaking OpenSim.ini changes

[Charles Krinke]

No, this is not talking about anything to death, Melanie. This is about writing 
down for others to read and understand at least *some* of what you are trying 
to accomplish.

This can be done via blogs, wiki paragraphs, FAQ, or other.

This feeling has been a long time coming, Melanie, and this is a plea for you 
to write down at least *some* of what you are doing so that there are clues for 
the early adopters to read and understand.

Charles





From: Melanie 
To: opensim-dev@lists.berlios.de
Sent: Tuesday, May 19, 2009 8:47:55 AM
Subject: Re: [Opensim-dev] breaking OpenSim.ini changes

Well said. Trunk is supposed to be the developers' work area. If we 
can't use trunk as a work area anymore, maybe things should be in 
branches!
This is work in progress, and there will be breaking changes, and 
lots more. Documenting as we go it not an option, since we 
frequently have to go back and change things after the fact. Much 
easier to document when it's done than to keep remembering what is 
already on the wiki and where, and to update it whenever some small 
thing needs to be changed.
This is about code development, not about the general usability of 
trunk. Trunk is supposed to be broken, we have releases for people 
who expect things to JustWork(tm).

Now, let's get this work done and not talk it to death in committee.

Melanie

Nebadon Izumi wrote:
> I have to somewhat disagree here, not fully though, while i do agree perhaps
> there can be better ways of informing everyone, I do not agree with lumping
> all changes into 1 update, this is an Alpha level development project,
> whatever happened to Trunk is supposed to be broken.  My only suggestion to
> those who find difficulties at the time being midway through this refactor
> process, do not upgrade your regions beyond 9561 for the time being, and
> when the refactoring is complete we will sound the all clear whistle.  But
> for now expecting this to be perfect 1/2 through a giant refactoring is
> probably not something any of us should do.
> 
> 
> 
> 
> 
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] breaking OpenSim.ini changes

[Charles Krinke]

No, this is certainly not a big business development. It is an opensource 
development. 

And as such, our early adopters are our partners in this development.

This is a plea to you, Melanie, to write a few blog, wiki, or FAQ entries, or 
mentor someone to write them for you.

For an example, see Adam's blog where he has described his work on MRM along 
the way. And that is very good. It allows early adoptors to have a bit of an 
understanding of what has been created.

If you would merely consider writing down a few things once in a while, then I 
think this whole situation will get better for you.

Charles





From: Melanie 
To: opensim-dev@lists.berlios.de
Sent: Tuesday, May 19, 2009 9:05:11 AM
Subject: Re: [Opensim-dev] breaking OpenSim.ini changes

Charles,

I develop out in the open, commit early and often. Most of these 
past 100 commits were not meant to be used by anyone but myself and 
Diva. It's a work in progress in a work area and documentation would 
have been premature.

The asset system, since it now functions, can and will be 
documented. But to demand big$$$business development and 
documentation practices is not what opensim is about. Trunk is 
supposed to be broken and usually is. Even if the brokenness only 
consists in no one being able to use it. We can't document when it 
is expected that everything will change again anyway.

This is a huge refactor. We had them before, where trunk was 
unusable for months on end. This is another one of them. Please bear 
with us.

Melanie

Charles Krinke wrote:
> No, this is not talking about anything to death, Melanie. This is about 
> writing down for others to read and understand at least *some* of what you 
> are trying to accomplish.
> 
> This can be done via blogs, wiki paragraphs, FAQ, or other.
> 
> This feeling has been a long time coming, Melanie, and this is a plea for you 
> to write down at least *some* of what you are doing so that there are clues 
> for the early adopters to read and understand.
> 
> Charles
> 
> 
> 
> 
> 
> From: Melanie 
> To: opensim-dev@lists.berlios.de
> Sent: Tuesday, May 19, 2009 8:47:55 AM
> Subject: Re: [Opensim-dev] breaking OpenSim.ini changes
> 
> Well said. Trunk is supposed to be the developers' work area. If we 
> can't use trunk as a work area anymore, maybe things should be in 
> branches!
> This is work in progress, and there will be breaking changes, and 
> lots more. Documenting as we go it not an option, since we 
> frequently have to go back and change things after the fact. Much 
> easier to document when it's done than to keep remembering what is 
> already on the wiki and where, and to update it whenever some small 
> thing needs to be changed.
> This is about code development, not about the general usability of 
> trunk. Trunk is supposed to be broken, we have releases for people 
> who expect things to JustWork(tm).
> 
> Now, let's get this work done and not talk it to death in committee.
> 
> Melanie
> 
> Nebadon Izumi wrote:
>> I have to somewhat disagree here, not fully though, while i do agree perhaps
>> there can be better ways of informing everyone, I do not agree with lumping
>> all changes into 1 update, this is an Alpha level development project,
>> whatever happened to Trunk is supposed to be broken.  My only suggestion to
>> those who find difficulties at the time being midway through this refactor
>> process, do not upgrade your regions beyond 9561 for the time being, and
>> when the refactoring is complete we will sound the all clear whistle.  But
>> for now expecting this to be perfect 1/2 through a giant refactoring is
>> probably not something any of us should do.
>> 
>> 
>> 
>> 
>> 
>> ___
>> Opensim-dev mailing list
>> Opensim-dev@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> 
> 
> 
> 
> 
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] breaking OpenSim.ini changes

[Charles Krinke]

I feel that we should view trunk as our best effort at a functional code base 
with no guarantee. The most important thing is that it should compile. Beyond 
that, new checkins that add new features should be explained to the early 
adopters and testers that are wringing out the details and finding the bugs. 
Hence my plea for *something* written *sometime*.

Our early adopters and testers are our partners in this endeavour. They provide 
the feedback to the developers and the rest of the community about confidence 
on Windows/Linux variations, existing inventories, standalone versus grid 
deployments and regression. This means that in order to have the best 
efficiency at OpenSim development, a few clues in the form of blogs, wiki 
paragraphs or even single FAQ entries helps immensely and cuts down on the time 
the developer has to spend supporting his or her creation.

It is entirely reasonable for a developer to enlist help from a member of the 
community to write those blog, wiki or FAQ entries, and I would urge us all to 
do so. 

Charles





From: Melanie 
To: mike.dick...@hp.com; opensim-dev@lists.berlios.de
Sent: Tuesday, May 19, 2009 9:47:19 AM
Subject: Re: [Opensim-dev] breaking OpenSim.ini changes

MW pretty much reached the conclusion never to use a branch again. 
It was stated that trunk is a developers' WORK area.

It is not meant to be usable all the time. The only requirement is 
that it compiles.

People who want stable should use stable. I think demands that trunk 
remain usable sets a bad precedent.

Melanie

Mike Dickson wrote:
> On Tue, 2009-05-19 at 16:32 +, Melanie wrote:
>> So you say I should spend hours on documentation which I already 
>> KNOW it will be obsolete within days?
>> 
>> That _is_ just what big corps do. 20% dev time, 80% doc time.
>> 
>> Melanie
> 
> If you're so sure you're going to see that much churn in what you're
> doing maybe it should be done in a branch as MW was trying to do so you
> spare the rest of the community while you figure it out. Then you can
> properly document it when its stabilized and roll it into HEAD when its
> ready.
> 
> BTW, the refactoring is *really good work*.  OpenSim is a great project
> with lots of potential.  Just wish it had more discipline (which doesn't
> have to translate to only 20% coding time).
> 
> Mike
> 
> 
> 
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> 
> 
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] breaking OpenSim.ini changes

[Charles Krinke]

Nebadon, this page, which is a good one, is Diva's and my hat is off to her for 
writing a few things down.

What I am trying to do is convince Melanie that she needs to do something 
similar for the work she has committed.

Charles





From: Nebadon Izumi 
To: opensim-dev@lists.berlios.de
Sent: Tuesday, May 19, 2009 10:21:21 AM
Subject: Re: [Opensim-dev] breaking OpenSim.ini changes

Again documenting is being done, please lets just stop this thread already.

http://opensimulator.org/wiki/Services_and_Service_Connectors_Configuration

everytime someone mentions this im simply going to reply with the above link.

END OF STORY!!! why are we complaining about things that are being done..!!!
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Navigating the Wiki

[Charles Krinke]

Each week we meet at "Office Hour" on Wright Plaza at 11:00AM Pacific Time.

The first agenda item is deciding on a recommended version for the week, which 
is generally a version that has been used successfully on a few sims with 
reasonable traffic.

This gets posted, after "Office Hour" on the opensim wiki and on OSgrid.

Some weeks it stays the same, some weeks it advances. It depends on the 
reliability of the testing each week. But, by deciding at a consistent time and 
place, is has been working out.

Backing up a bit, I would say that we have three versions in play at any given 
point in time, much like Linux stable, unstable, head distributions.

Stable - The last tagged revision.

Recommended - An svn version, which usually advances each Tuesday that is as 
close to head as a committee feels comfortable. View this as the 'unstable' 
part of a Linux distribution.

Head - The lastest SVN revision, that is, the bleeding edge where the quote : 
"Those who work at the bleeding edge are sometimes sacrificied upon it" would 
sometimes apply.

Charles





From: Mark Malewski 
To: opensim-dev@lists.berlios.de
Sent: Wednesday, May 20, 2009 9:59:12 AM
Subject: Re: [Opensim-dev] Navigating the Wiki



> 1. What is the current recommended version?

That is a VERY good question.  What is the current consensus on that?  That is 
one question that I certainly don't have an exact answer for.  What do you 
suggest as the current recommended version?  Please chime in with your 
opinions...

   Thanks,

Mark




On Wed, May 20, 2009 at 11:52 AM, Mark Malewski  wrote:

Charles,

Excellent questions.  I'll work on the FAQ as well.  I'm almost certain that 
the FAQ needs updating.  I'll put it on my "To Do" list, and slowly get to it.  
Once I get closer to finishing, I'll post a list of pages "open for discussion" 
and "open for comment" so that we can talk about what things should be added 
(and where).  Yes, the FAQ pages do need some work.

If anyone else can think of some quick "newbie" questions (commonly asked 
questions) please let me know.  I'll jot them down, and work on adding those 
pages as well, with a nice navigation page/menu back to the main FAQ & support 
area page.


>  I also suspect the ongoing asset/inventory/server significant re-write going 
> on right now needs 
> some extra special attention as I see that one as a support nightmare.

Don't get me started...Why do you think I've been hanging 
out in the WIKI so much?  ;-)

Yes, I'm working on it.  Just give me some time.  ;-)

 Thanks,
   Mark

P.S.  Keep the questions coming, because those are all good topics that should 
be covered.  If anyone else has any additional good questions, please chime in. 
 I'll put them on the "To Do List".  



On Wed, May 20, 2009 at 11:11 AM, Charles Krinke  wrote:

Some of the common questions that come up but are not easily answered on the 
wiki are:

1. What is the current recommended version?

2. My OpenSim.ini does not work after an upgrade with SVN, how can I fix this?

3. How do I setup a region?

4. How do I setup a grid?

5. What does HyperGrid mean?

As we move forward, perhaps making sure these and other similar questions have 
at least two pages referencing them might help us.

One of those pages could almost always be the FAQ (Frequently Asked Questions), 
which is in itself need of a little attention.

Charles

p.s. I also suspect the ongoing asset/inventory/server significant re-write 
going on right now needs some extra special attention as I see that one as a 
support nightmare.





From: Robert Martin 
To: opensim-dev@lists.berlios.de
Sent: Wednesday, May 20, 2009 9:06:05 AM
Subject: Re: [Opensim-dev] Navigating the Wiki


While you are doing the truly Herculean task of fixing the Wiki could
you please make sure that
A there is a site map somewhere on the site (oh maybe on a page named
Site Map??)
B that every page present links to something (like related topics and
then to the navbar level topics??)
C Sanity and brevity need to be watch words for the page names (hint
if the name of the page is more than 10% of the content of the page
something is wrong)

-- 
Robert L Martin
Just trying to be a Voice Of Reason
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Navigating the Wiki

[Charles Krinke]

Some of the common questions that come up but are not easily answered on the 
wiki are:

1. What is the current recommended version?

2. My OpenSim.ini does not work after an upgrade with SVN, how can I fix this?

3. How do I setup a region?

4. How do I setup a grid?

5. What does HyperGrid mean?

As we move forward, perhaps making sure these and other similar questions have 
at least two pages referencing them might help us.

One of those pages could almost always be the FAQ (Frequently Asked Questions), 
which is in itself need of a little attention.

Charles

p.s. I also suspect the ongoing asset/inventory/server significant re-write 
going on right now needs some extra special attention as I see that one as a 
support nightmare.





From: Robert Martin 
To: opensim-dev@lists.berlios.de
Sent: Wednesday, May 20, 2009 9:06:05 AM
Subject: Re: [Opensim-dev] Navigating the Wiki

While you are doing the truly Herculean task of fixing the Wiki could
you please make sure that
A there is a site map somewhere on the site (oh maybe on a page named
Site Map??)
B that every page present links to something (like related topics and
then to the navbar level topics??)
C Sanity and brevity need to be watch words for the page names (hint
if the name of the page is more than 10% of the content of the page
something is wrong)

-- 
Robert L Martin
Just trying to be a Voice Of Reason
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Navigating the Wiki

[Charles Krinke]

I would also like to suggest, only so that Mark doesnt have all this dropped on 
his shoulders, that others help in various sections.

It seems reasonable to me that Mark co-ordinate this as the 'zealot'. So, lets 
help Mark get our wiki to the next stage of documentation.

Charles





From: Mark Malewski 
To: opensim-dev@lists.berlios.de
Sent: Wednesday, May 20, 2009 9:52:52 AM
Subject: Re: [Opensim-dev] Navigating the Wiki

Charles,

Excellent questions.  I'll work on the FAQ as well.  I'm almost certain that 
the FAQ needs updating.  I'll put it on my "To Do" list, and slowly get to it.  
Once I get closer to finishing, I'll post a list of pages "open for discussion" 
and "open for comment" so that we can talk about what things should be added 
(and where).  Yes, the FAQ pages do need some work.

If anyone else can think of some quick "newbie" questions (commonly asked 
questions) please let me know.  I'll jot them down, and work on adding those 
pages as well, with a nice navigation page/menu back to the main FAQ & support 
area page.

>  I also suspect the ongoing asset/inventory/server significant re-write going 
> on right now needs 
> some extra special attention as I see that one as a support nightmare.

Don't get me started...Why do you think I've been hanging 
out in the WIKI so much?  ;-)

Yes, I'm working on it.  Just give me some time.  ;-)

 Thanks,

   Mark

P.S.  Keep the questions coming, because those are all good topics that should 
be covered.  If anyone else has any additional good questions, please chime in. 
 I'll put them on the "To Do List".  



On Wed, May 20, 2009 at 11:11 AM, Charles Krinke  wrote:

Some of the common questions that come up but are not easily answered on the 
wiki are:

1. What is the current recommended version?

2. My OpenSim.ini does not work after an upgrade with SVN, how can I fix this?

3. How do I setup a region?

4. How do I setup a grid?

5. What does HyperGrid mean?

As we move forward, perhaps making sure these and other similar questions have 
at least two pages referencing them might help us.

One of those pages could almost always be the FAQ (Frequently Asked Questions), 
which is in itself need of a little attention.

Charles

p.s. I also suspect the ongoing asset/inventory/server significant re-write 
going on right now needs some extra special attention as I see that one as a 
support nightmare.





From: Robert Martin 
To: opensim-dev@lists.berlios.de
Sent: Wednesday, May 20, 2009 9:06:05 AM
Subject: Re: [Opensim-dev] Navigating the Wiki


While you are doing the truly Herculean task of fixing the Wiki could
you please make sure that
A there is a site map somewhere on the site (oh maybe on a page named
Site Map??)
B that every page present links to something (like related topics and
then to the navbar level topics??)
C Sanity and brevity need to be watch words for the page names (hint
if the name of the page is more than 10% of the content of the page
something is wrong)

-- 
Robert L Martin
Just trying to be a Voice Of Reason
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] 0.7 Release Discussion

[Charles Krinke]

It pains me to disagree with you, Nebadon, but when I look at the summary page 
on our Mantis this morning, I see 247 open Mantis issues. This actually is an 
admirable goal and I would think clearing as many of these as possible over the 
next month is an admirable goal. Like all goals, we always can declare success 
when it "feels" right and thats my wriggle room.

Charles





From: Nebadon Izumi 
To: opensim-dev@lists.berlios.de
Sent: Sunday, May 31, 2009 6:34:36 AM
Subject: Re: [Opensim-dev] 0.7 Release Discussion

I can agree with that, if everyone else agrees i have no problem with it, I 
would just hate for anyone to think that we are locking things up and they wont 
have our support.  And mostly i was more concerned with trying to clear mantis, 
that seams a bit unrealistic, as a good portion of fixing the mantis probably 
rely on us instituting many feature requests.  It kind of goes against the 
whole premise of freezing up feature requests.


On Sun, May 31, 2009 at 6:29 AM, Stefan Andersson  wrote:

Wise from experience, I would never propose anything as preposterous as to tell 
any core dev to do anything.
 
But if a substantial part of core devs and the patching community think it's a 
good idea and can be swayed to rally for it, I think we can see some really 
extraordinary measures that would make us all look pretty god damn good.

And hell, I stated it would be ambitious. Aim for the stars, hit the treetops, 
you know.
 
Best regards,
Stefan Andersson



 

 Date: Sun, 31 May 2009 06:24:51 -0700
From: nebadon2...@gmail.com
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] 0.7 Release Discussion


Have you even looked at mantis??? there are 728 open tickets, chances are if we 
clear mantis, we will have OpenSimulator 1.0.. I personally don't see this as 
feasible, this is to me looks like us trying to control what all the developers 
are doing, and I have to -1 this idea as it would probably make most devs just 
stop working.

Neb


On Sun, May 31, 2009 at 6:20 AM, Stefan Andersson  wrote:


I do believe we're all feeling the advent of 0.7 - a milestone in any open 
source project.
 
Here's a crazy idea for you; how about we agree to freeze feature set and major 
architecture as of now, and concentrate on only:
 
* Finalizing the backend restructuring
* Clear mantis (hell, let's CLEAR mantis! how's that for ambitious?)
* Write unit tests
 
until the cows come home, and tag the cow homecoming rev as 0.7? Or, say, 1st 
of aug happens, and we'll tag 0.6.7 then instead. ;)

I believe this kind of solidified 0.7 would give us all a breather, help us 
recoup, and then we can all go back to fiddling with our various dev projects 
again.
 
What you say?

Best regards,
Stefan Andersson




___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev




-- 
Michael Emory Cerquoni - Nebadon Izumi @ http://osgrid.org/

___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev




-- 
Michael Emory Cerquoni - Nebadon Izumi @ http://osgrid.org
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] 0.7 Release Discussion

[Charles Krinke]

No problem, man.

As I look at two other parts of the Mantis Summary page, both the "Longest 
Open" and the "Most Active" jump out at me.

So, ... I would suggest that if we were to concentrate on resolving/closing 
some of the "Longest Open" and "Most Active" that we have a way to move forward 
in a more or less logical fashion.

Charles





From: Nebadon Izumi 
To: opensim-dev@lists.berlios.de
Sent: Sunday, May 31, 2009 1:26:10 PM
Subject: Re: [Opensim-dev] 0.7 Release Discussion

I stand corrected, I went back and you are correct, i only had closed filtered 
out and not the "resolved" issues, hence the inflated count. sorry about that.  
I think all of these ideas are great, sorry to be the stickler in the mud, but 
I'd rather everyone beat up on me now while were discussing it than after the 
fact, so thanks everyone for comments, very good ideas.


On Sun, May 31, 2009 at 1:12 PM, Charles Krinke  wrote:

It pains me to disagree with you, Nebadon, but when I look at the summary page 
on our Mantis this morning, I see 247 open Mantis issues. This actually is an 
admirable goal and I would think clearing as many of these as possible over the 
next month is an admirable goal. Like all goals, we always can declare success 
when it "feels" right and thats my wriggle room.

Charles





From: Nebadon Izumi 

To: opensim-dev@lists.berlios.de
Sent: Sunday, May 31, 2009 6:34:36 AM

Subject: Re: [Opensim-dev] 0.7 Release Discussion


I can agree with that, if everyone else agrees i have no problem with it, I 
would just hate for anyone to think that we are locking things up and they wont 
have our support.  And mostly i was more concerned with trying to clear mantis, 
that seams a bit unrealistic, as a good portion of fixing the mantis probably 
rely on us instituting many feature requests.  It kind of goes against the 
whole premise of freezing up feature requests.


On Sun, May 31, 2009 at 6:29 AM, Stefan Andersson  wrote:

Wise from experience, I would never propose anything as preposterous as to tell 
any core dev to do anything.
 
But if a substantial part of core devs and the patching community think it's a 
good idea and can be swayed to rally for it, I think we can see some really 
extraordinary measures that would make us all look pretty god damn good.

And hell, I stated it would be ambitious. Aim for the stars, hit the treetops, 
you know.
 
Best regards,
Stefan Andersson



 

 Date: Sun, 31 May 2009 06:24:51 -0700
From: nebadon2...@gmail.com
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] 0.7 Release Discussion


Have you even looked at mantis??? there are 728 open tickets, chances are if we 
clear mantis, we will have OpenSimulator 1.0.. I personally don't see this as 
feasible, this is to me looks like us trying to control what all the developers 
are doing, and I have to -1 this idea as it would probably make most devs just 
stop working.

Neb


On Sun, May 31, 2009 at 6:20 AM, Stefan Andersson  wrote:


I do believe we're all feeling the advent of 0.7 - a milestone in any open 
source project.
 
Here's a crazy idea for you; how about we agree to freeze feature set and major 
architecture as of now, and concentrate on only:
 
* Finalizing the backend restructuring
* Clear mantis (hell, let's CLEAR mantis! how's that for ambitious?)
* Write unit tests
 
until the cows come home, and tag the cow homecoming rev as 0.7? Or, say, 1st 
of aug happens, and we'll tag 0.6.7 then instead. ;)

I believe this kind of solidified 0.7 would give us all a breather, help us 
recoup, and then we can all go back to fiddling with our various dev projects 
again.
 
What you say?

Best regards,
Stefan Andersson




___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev




-- 
Michael Emory Cerquoni - Nebadon Izumi @ http://osgrid.org/

___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev




-- 
Michael Emory Cerquoni - Nebadon Izumi @ http://osgrid.org

___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev




-- 
Michael Emory Cerquoni - Nebadon Izumi @ http://osgrid.org
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] 0.7 Release Discussion

[Charles Krinke]

Just to pick on the "Longest Open" for a little bit, here they are. The last 
column is the number of days the Mantis has been open.

It seems to me that a Mantis open over a year is a good candidate for a feature 
request, perhaps a 'wont fix' or even a 'we did fix and forgot to close'.

So, to avoid me unilaterally starting to close some of these, I would like to 
call on others to look into them and I will support *any* reasonable decision 
in getting our "Longest Open" to be less then 451 days old.

Charles





721 - opensim does not support https in *STANDALONE* 451 
765 - Continual request of 'non existent asset' 
c228d1cf-4b5d-4ba8-84f4-899a0796aa97 444 
960 - Neighbors that start up don't display 411 
0001054 - On teleport, child agents are not hidden, but remain visible in 
region of origin 400 
0001131 - Physical prims pushed off edge of region roll to infinity 392 
0001147 - Doing shift-drag-copy linked non-phantom prims produces phantom 
copies 390 
0001149 - Doing shift-drag-copy linked prims produces a new center point 390 
0001176 - "Already logged in" message on first connect attempt 388 
0001184 - Day Cycle Editor settings not remembered for sim 388 
0001209 - There are currently no constraints on link set size or prim count. 
387 
0001211 - Individually set Phantom flag for prims in a linkset 387 
0001217 - Edited child prims in linksets revert and don't save as changed 387 
0001229 - Avatar sometimes remains with selection after right-clicking an 
object 385 
0001244 - Prim permissions lost while in-world 384 
0001317 - r4746 - client does not get or display "inventory timeout" message 
from region 377 
0001332 - Taking groups of objects not implemented 376 
0001342 - sitting pose is not correct when sitting on a box 375 
0001343 - sitting pose is not correct when sitting on the rotated cylinder 375 
0001344 - simulator can't  provide service and system cpu 100% 375 
0001347 - Client gets flooded upon logon and lag increased in sims 375 
0001366 - sitting facing to the hill when sitting on tali ground 373 
0001373 - Logouts/Dropoffs not properly registered at both User Server and 
Region server 373 
0001379 - terrain load wildcard effect without using change regions first 371 
0001397 - Prims out of FOV should not be rendered client-side 369 
0001415 - llTargetOmega stops working from time to time 
 





From: Charles Krinke 
To: opensim-dev@lists.berlios.de
Sent: Sunday, May 31, 2009 1:29:10 PM
Subject: Re: [Opensim-dev] 0.7 Release Discussion


No problem, man.

As I look at two other parts of the Mantis Summary page, both the "Longest 
Open" and the "Most Active" jump out at me.

So, ... I would suggest that if we were to concentrate on resolving/closing 
some of the "Longest Open" and "Most Active" that we have a way to move forward 
in a more or less logical fashion.

Charles





From: Nebadon Izumi 
To: opensim-dev@lists.berlios.de
Sent: Sunday, May 31, 2009 1:26:10 PM
Subject: Re: [Opensim-dev] 0.7 Release Discussion

I stand corrected, I went back and you are correct, i only had closed filtered 
out and not the "resolved" issues, hence the inflated count. sorry about that.  
I think all of these ideas are great, sorry to be the stickler in the mud, but 
I'd rather everyone beat up on me now while were discussing it than after the 
fact, so thanks everyone for comments, very good ideas.


On Sun, May 31, 2009 at 1:12 PM, Charles Krinke  wrote:

It pains me to disagree with you, Nebadon, but when I look at the summary page 
on our Mantis this morning, I see 247 open Mantis issues. This actually is an 
admirable goal and I would think clearing as many of these as possible over the 
next month is an admirable goal. Like all goals, we always can declare success 
when it "feels" right and thats my wriggle room.

Charles





From: Nebadon Izumi 

To: opensim-dev@lists.berlios.de
Sent: Sunday, May 31, 2009 6:34:36 AM

Subject: Re: [Opensim-dev] 0.7 Release Discussion


I can agree with that, if everyone else agrees i have no problem with it, I 
would just hate for anyone to think that we are locking things up and they wont 
have our support.  And mostly i was more concerned with trying to clear mantis, 
that seams a bit unrealistic, as a good portion of fixing the mantis probably 
rely on us instituting many feature requests.  It kind of goes against the 
whole premise of freezing up feature requests.


On Sun, May 31, 2009 at 6:29 AM, Stefan Andersson  wrote:

Wise from experience, I would never propose anything as preposterous as to tell 
any core dev to do anything.
 
But if a substantial part of core devs and the patching community think it's a 
good idea and can be swayed to rally for it, I think we can see some real

Re: [Opensim-dev] Removal of project on GForge

[Charles Krinke]

I'm going to try to be as diplomatic as possible here.

All of us may contribute to various forge projects as we and our peers may 
determine from time to time.

I am truly sorry you are upset, Fly-Man, but that does not change anything. We 
move forward with or without any one individual and that includes all of us.

So, those who wish to contribute to forge projects are welcome. And when they 
no longer wish to contribute, we thank them.

Various source will evolve in forge from time to time at the discretion of 
those with commit privilege for each project. Some code survives, some gets 
deleted. But each project determines what survives and is deleted. Usually for 
reasons of obsolescence.

Charles





From: Kyle Hamilton 
To: opensim-dev@lists.berlios.de
Sent: Sunday, May 31, 2009 2:27:23 PM
Subject: Re: [Opensim-dev] Removal of project on GForge

Once you release something under the BSD license, anyone can do
anything with it, as long as the license is followed (i.e., the
copyright clause is followed).  It cannot be retroactively removed.
Further, anything on the Forge, in the subversion, is openly
available.  You can continue your development as closed-source, but
you cannot retroactively close anything that you'd previously opened.
(I'm not a lawyer, but my understanding is that the license counts as
an "estoppel", as long as its provisions are followed -- meaning that
you cannot stop distribution simply by stating that it can't be used,
because the courts are going to laugh in your face.)

-Kyle H

On Sun, May 31, 2009 at 2:23 PM, Fly Man  wrote:
> There's still a restriction on the things I made personally, those are
> licensed to me.
>
> Those aren't available on the trunks of those projects and those pieces are
> closed source.
>
> As long as the 2 things I mentioned in the #opensim-dev are being handled, I
> won't have to call upon these drastic measurements.
>
> 2009/5/31 Mike Dickson 
>>
>> I'm only using the WiRedux stuff of the modules you listed personally.
>> But I don't think the BSD license works the way you think it does.
>> Attribution is certainly required by the license and no reason you
>> couldn't do a closed source version based on it.  But what you put out
>> under a BSD license is sort of in the wild. There's no real provision to
>> restrict after the fact...
>>
>> Mike
>>
>> On Sun, 2009-05-31 at 17:29 +, Fly Man wrote:
>> > Addition to the previous message:
>> >
>> > This means that all the source needs to be deleted as stated under
>> > BSD.license and will not be re-uploaded to the Gforge or any other
>> > Gforge or SVN like system.
>> >
>> >
>>
>> ___
>> Opensim-dev mailing list
>> Opensim-dev@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Removal of project on GForge

[Charles Krinke]

Dear Fly-Man:

I would like to suggest we step back from a "point of honor" and try to figure 
out how to work together.

There are times in this project when passions rise high and this is one of 
those times. I would really like to find a way to move forward without pushing 
anyone into a corner.

Your enthusiasm, work ethic and code has been good for the grid deployments and 
all I can say is that I am sorry that you and others have gotten to the place 
where the need exists to make the statements said today.

So, please, please, lets figure out how to just work together.

Charles







From: Fly Man 
To: opensim-dev@lists.berlios.de
Sent: Sunday, May 31, 2009 5:53:35 PM
Subject: Re: [Opensim-dev] Removal of project on GForge

Kyle, please read back what I posted earlier before you start to throw
with words that I won't respond to:

* There's 2 people that just need to apoligize and then we can all get
back to what we're good in.

Unless those people step up and take responsibilty about their
actions, then it means that on the 2nd of June
I need to consult with a lawyer about the further steps that need to be taken

2009/6/1 Kyle Hamilton :
> How about you check out the subversion tree at the last revision
> without the "whole mess that it is now"?  That's what revision control
> systems are for, so you can check out old revisions.  You can control
> your own experience -- while everyone else can cooperate as they want
> to.
>
> You should do this instead of bitching on the mailing list and
> essentially saying "IT'S MY BALL AND I'M GOING HOME".
>
> You're thus making a huge deal out of, literally, nothing.  Which
> means you're a drama whore at best, and a troll at worst.
>
> Get a grip.  I will also point out that the main OpenSim project trunk
> isn't clean, and that branches are made to maintain specific
> milestones, and so your objection to "as long as the main trunk is
> clean" isn't even in line with what the community has (loosely)
> standardized on.  Yes, this might fly in the face of other projects'
> conventions, but this is what we have to deal with and have to live
> with as a part of working with OpenSim.
>
> -Kyle H
>
> On Sun, May 31, 2009 at 3:26 PM, Fly Man  wrote:
>> Ideia, this problem can easily be resolved by 2 people that just say
>> sorry and revert back the things that they added to the OpenSimWiredux
>> so I can take a clean copy of the code without the whole mess that it
>> is now.
>>
>> So, in other words as some won't know what I said on #opensim-dev:
>>
>> Jamenai: Please send me an email, explaining why you added things to
>> the Wiredux, stating that you didn't contact me before adding this and
>> that you will revert the source back to the rev that I added. It's
>> okay with me to make a new branch where you fiddle with all your stuff
>> as long as the main trunk is clean
>>
>> Nebadon: Please send me an email, telling me that you were wrong to
>> think that I left the scene just because of the Money Debacle. And
>> that you did know about me being in a small holiday until the 1st of
>> June as mentioned in several announcements that I did on all the IRC
>> channels.
>>
>> When those 2 people have made their excuses, I will no longer have a
>> need to ask for deletion of the projects and will be a happy camper
>> once again.
>>
>> It's not in my natural nature to be like this, but for some people
>> this might sound like nagging.
>>
>> No, it's not nagging, it's getting right what is wrong at this moment.
>>
>> 2009/6/1 Ideia Boa :
>>> Fly-Man
>>>
>>> I do not know who is right in your disagreement, but I think if you had
>>> something you were thinking that was not being done in the most correct, I
>>> think the only way would have launched the discussion on mail-list
>>> #opensim-dev and not just you away from everything and remove the work you
>>> did, the work of all is very important and only a small opinion can make a
>>> difference.
>>>
>>> See that I am not defending anyone, I'm only making an observation of what I
>>> read in a mail-list
>>>
>>>
>>> Ideia Boa
>>> www.worldsimterra.com
>>>
>>>
>>>
>>> Fly Man wrote:
>>>
>>> Addition to the previous message:
>>>
>>> This means that all the source needs to be deleted as stated under
>>> BSD.license and will not be re-uploaded to the Gforge or any other Gforge or
>>> SVN like system.
>>>
>>>
>>> 
>>> ___
>>> Opensim-dev mailing list
>>> Opensim-dev@lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>
>>>
>>> ___
>>> Opensim-dev mailing list
>>> Opensim-dev@lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>
>>>
>> ___
>> Opensim-dev mailing list
>> Opensim-dev@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
> __

Re: [Opensim-dev] MANTIS PRIORITY LIST PROPOSAL

[Charles Krinke]

I concur with Melanie.

In general, the issue with Mantis is that those things which are in the 
interest sphere of various core developers and patch submitters will be the 
ones that are fixed. 

So, our strategy is more finding, diagnosing and confirming repeatable 
failures, as a minimum. Beyond that, patches to fix Mantis issues are greatly 
appreciated. But, being an all volunteer organization, we have to accept the 
fact that issues will be fixed as each contributor finds and fixes those issues.

So, everything we can do to make developers lives easier by confirming notes, 
complete descriptions and diagnosis to minimize developers time is to our 
advantage.

Charles





From: Melanie 
To: opensim-dev@lists.berlios.de
Sent: Wednesday, June 3, 2009 10:13:13 AM
Subject: Re: [Opensim-dev] MANTIS PRIORITY LIST PROPOSAL

"Severity" is a malleable term. To me, a bug that will cause me to 
lose appearance on teleports would be _much_ more severe than one 
that eats SQLite tables.

Because I _do_ care about my avatar's appearance, but _don't_ use 
SQLite.

So, I would think it's really hard to find an objective way of 
ordering bugs.

Melanie

Robert Martin wrote:
> On Tue, Jun 2, 2009 at 5:58 PM, Dan  wrote:
>> Due to the large number of Mantis reports, how about prioritizing them
>> according to their importance, and focus on all Mantis reports related to
>> the most critical issues first.
>>
> how about this when we rank the bugs do two different sets of points
> 
> 1 number of months the bug has "lived" = 0.5 points per month
> 2 how "important" the bug is:
> A Filesystem damage: 20 points
> B File damage  :10 points internal files only 15 points if it
> trashes files outside
> C Client or server crash: 7 points with a bonus of 2 points if it
> is a repeatable multi-client crash
> D Login or core feature problem: 6 points
> E glitch or non locking problem: 2 points
>  and so forth
> 
> 
> also could we maybe close some of the bugs if we made sure they are
> actually still "live"
> 
> 
> 
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] IClientAPI vs ???

[Charles Krinke]

Yes, I would concur that getting patches to complete Adam's vision of 
IClientCore is a reasonable thing to do and would encourage patches that move 
us along this path.

Charles





From: MW 
To: opensim-dev@lists.berlios.de
Sent: Monday, June 8, 2009 9:41:02 AM
Subject: Re: [Opensim-dev] IClientAPI vs ???


Adam started doing just that a while ago with the IClientCore and split a few 
methods out to other intefaces. Its just it has never had much work done on it 
since. I guess we should maybe make it a aim to finish that for the 0.7.x 
series. 

--- On Mon, 8/6/09, d...@metaverseink.com  wrote:


From: d...@metaverseink.com 
Subject: Re: [Opensim-dev] IClientAPI vs ???
To: opensim-dev@lists.berlios.de
Date: Monday, 8 June, 2009, 4:42 PM


I hate the IClientAPI. It's ginormous! The reason why I hate it is that 
I tend to look at OpenSim dlls as components that can be reused by other 
programs. When those dlls have dependencies on IClientAPI, it's a pain 
in the neck to have to implement the 400 functions in it, especially 
when only 6 need 'meat.'

The IClientAPI is the abstract representation of the Linden client. 
Maybe we could split it into, say, 50 different APIs that represent 
functional units of clients. And then have LLClientView be an aggregator 
of all those interfaces?

Michael Cortez wrote:
> On more then one occasion it's been brought to my attention that 
> creating references to/with IClientAPI is bad and should be avoided.  At 
> other times, I've seen people instructed that they should use it instead 
> of doing X, Y or Z.
> 
> I would like to try and get a consensus of those with commit access, to 
> determine if/when IClientAPI should be :
> 1) avoided at all costs
> 2) avoided when there isn't much extra work
> 3) used because there's no significant reason to avoid it
> 
> And if your recommending 1 or 2, what alternatives do you suggest for 
> obtaining information about the Agent that the IClientAPI currently 
> provides.  Using 1 or 2 will sometimes create additional dependencies on 
> other systems.
> 
> Thanks,
> --
> Michael Cortez
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> 
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

[Opensim-dev] warnings in compile

[Charles Krinke]

I see our warnings in VS2008 have crept back up to 230 when building OpenSim 
and would suggest a few patches and attention to trying to bring the number of 
warnings down.

Charles
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev