From melanie at t-data.com Sat Apr 19 01:28:24 2014 From: melanie at t-data.com (Melanie) Date: Sat, 19 Apr 2014 03:28:24 +0200 Subject: [Opensim-dev] Opensim-Dev closing at Berlios Message-ID: <5351D138.6080905@t-data.com> Hi everyone, since Berlios is closing their mailing lists, we have migrated the lists to our own server. The lists at Berlios are now disabled or will shortly be disabled. Please use this new list for all future postings. - Melanie From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: representing an image, sound bytes, scriptcode, prim shape definition. But What happens when a scripted object is rez'ed, the code modifies the state of the script or prim or the inventory of the object? If a script modifies the link chain of a set of prims, changes the texture or any other mutable property on a prim, do we have a new asset? if it is a new asset, do we copy the textures into this new asset? Is the complete "file" changed, or only parts of the file? I know there is a huge debate on this going on on the sldev mailing list, but I'd prefer to go for something resonably simple and practical, as a first implementation. My suggestion is based on the concept of triplets, much like the triplets in RDF. Basically an asset can be seen as a collection of values, each value consists of three properties: , , to give some examples texture: 329AE20F-38C1-43fb-BDA0-6B13E569FCDF, Type, Texture 329AE20F-38C1-43fb-BDA0-6B13E569FCDF, Name, "Green grass" 329AE20F-38C1-43fb-BDA0-6B13E569FCDF, Width, 256 329AE20F-38C1-43fb-BDA0-6B13E569FCDF, Height, 256 329AE20F-38C1-43fb-BDA0-6B13E569FCDF, Image, 44BD483173EC206D130B5F775B2B31D......... 329AE20F-38C1-43fb-BDA0-6B13E569FCDF, Owner, 61AEA4D9-19CE-4fac-8E44-DFA24903BFB8 prim 61AEA4D9-19CE-4fac-8E44-DFA24903BFB8, Type, Primitive 61AEA4D9-19CE-4fac-8E44-DFA24903BFB8, Shape, Box 61AEA4D9-19CE-4fac-8E44-DFA24903BFB8, Position, 8D45A164-52B1-4dab-A7BE-53A7078CA50B 8D45A164-52B1-4dab-A7BE-53A7078CA50B, X, 125.7 8D45A164-52B1-4dab-A7BE-53A7078CA50B, Y, 10 8D45A164-52B1-4dab-A7BE-53A7078CA50B, Z, 19 61AEA4D9-19CE-4fac-8E44-DFA24903BFB8, Size, EA7254C0-D692-436a-949C-ADFE500E85EF EA7254C0-D692-436a-949C-ADFE500E85EF, Width, 10 EA7254C0-D692-436a-949C-ADFE500E85EF, Height, 2 EA7254C0-D692-436a-949C-ADFE500E85EF, Depth, 0.1 61AEA4D9-19CE-4fac-8E44-DFA24903BFB8, Name, "My plywood box" On first inspection this seems to be too complex, but this scheme can easily be extended to handle versioning, so in case somebody renames our texture in the above example, this can be handled quite easily, by storing this information: texture 0CDE3656-D5A1-4ac2-819C-F8285680BC28, Parent, 329AE20F-38C1-43fb-BDA0-6B13E569FCDF 0CDE3656-D5A1-4ac2-819C-F8285680BC28, Name, "Dark green grass" in essence, this has created a new asset, called "0CDE3656-D5A1-4ac2-819C-F8285680BC28", which inherits most of it's values from "329AE20F-38C1-43fb-BDA0-6B13E569FCDF". This is the strategy, which I'd suggest as a first go for assets, I would welcome any and all comments /Tleiades From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: not the case. =20 For example, consider something like =20 =20 that doesn't look like a bad idea at all to me. /Stefan= --_1d749aed-2031-4a4b-85b7-d636bdf6f011_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > It would be good to see a proposal on how to= change those objects into
> something better. None of us are in love= with them, but better
> approaches haven't popped up yet.

Probably because nobody has made any attempt at discussing and proposing ch= anges; this mail was an attempt to get that ball rolling.
 
There was some energy poured into analyzing how attachments were communicat= ed; that would be a good start, if we could get a wiki page up just detaili= ng what we know about scene entities.
 
> > * Related, we need to revise the xml serialization sche= me and the db
> > * schemes. The xml scheme should be user-friendl= y to the point where
> > * you should be confident to create and e= dit objects in notepad,
> > * basically. This is not the case at t= he moment. Massive duplication,
> > * weird bit values and non-int= uitive value ranges are king at the
> > * moment.
>
>= Given the amount of data in a prim, editing in notepad always is going
= > to be a bad idea. :) I think we've got something like 40 fields that> have to be sensible for the prim to work.

From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: not the case.
 
For example, consider something like
 
<Object position=3D"128.0 128.0 23.0">
<Rectangle extrusion=3D"straight" scale=3D"1.0 2.0 5.0" offset=3D"root"/= >
<Circle extrusion=3D"sphere" scale=3D"1 1 1" offset=3D"0 0 1"/><= BR> </Object>
 
that doesn't look like a bad idea at all to me.

/Stefan
= --_1d749aed-2031-4a4b-85b7-d636bdf6f011_-- From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: problem. It's actually counter-productive, as people, being irrational agents in general, will simply hear the message "you're nuts", and will come back again with more arguments for why they are not being irrational. It's a dead-end conversation.

Option b) is one that most technologists don't believe, because they know quite well that such policing cannot be done with the technology, but with an aggressive costumer protection department. Some technologists may very well follow it, because they know that there is some short-term cash to be made -- until it eventually dissolves when they realize that the costs of keeping the police and prosecution departments far outweigh the revenue, at least in a situation where there is no monopoly and people have choices (history shows that people tend to be attracted by tolerance).

My favorite is option c), and I think that OpenSim is general enough to account for several service models to emerge. People who want extra protection should only produce content on grids that offer that kind of protection, and not on the other, more tolerant, ones. I personally believe that such policing-heavy grids will not have a chance of surviving, unless, besides the protection, they offer some really cool things that attract people to them in the first place; but hey! - the point is that people will have choices.

Diva / Crista

The Burnman wrote:


On Mon, Mar 3, 2008 at 12:10 PM, Brian Wolfe <brianw at terrabox.com> wrote:
(warning, written 15 minutes after waking up and before first coffee was
downed.)

Noted.  ;)
 
Your arguments are spot on. :) I would add that having DRM or attempting
to curtail end users fredom of use is pushing society to being
untrustable. There is an old saying. Say something often enough and it
becomes true. Say people WILL steal content at times, be paranoid about
it and far more people WILL steal your content due to lack of respect ,
which is earned by the creator's lack of trust in others.

There is no paranoia in the valid concern that people will attempt to rip you off.  It happens all the time.  It will never cease to amaze me how entitled people feel to other people's Intellectual Property.  THAT is where the lack of respect and trust comes into play.  An artist or author who wishes to protect their work from those who are low enough to steal from them should not be looked on as paranoid, they are simply trying to enforce their rights under law.  Theft is where the lack of respect and trust come from.
 
However if you as a creator can bring yourself to see the good in
others, most will respect you enough to not steal your work. You will
still have some minor theft happening, but not nearly enough to stop you
from creating and profiting from your creations. This is just life and
society in general and unavoidable.

By your argument, we should do away with police and trust people to behave themselves.  Simply because it is impossible to prevent all theft, does not mean we should just give up in our attempts to make it difficult.
 
Here's another parallel to the whole DRM debate. We trust each other to
not run around killing people. We don't walk around wearing 100%
protective body armour because, well, it's impossibly expensive, and no
one will trust you due to your obvious paranoia. ;) Instead, we walk
around with no armour at all, yet the threat of serious bodily harm is
still there, and we manage to survive just fine.

Tell that to the two teenagers who were shot to death across town here last week.  They were in their driveway playing basketball.  Or the elderly man who was gunned down in his driveway a few towns away the week before that.  The danger is there, and it would certainly be far worse if there were no police to keep it relatively in check.  While there is no such thing as 100% safe, we are more safe due to the protections in place.  This analogy works just as well for asset protection in a metaverse environment.
 
There are bad apples, just don't let one bad apple ruin your
relationship with the rest of the apples.

There are bad apples, that we agree on.  The question is what to do about it.  Do we attempt to curb the bulk of content theft, or do we simply force content creators to deal with a lack of protection for their work?  If you were to poll the vast majority of content creators in Second Life what they would prefer...  no protection for their work, or some protection... what do you think their response would be?  And let's face it...  as it stands... the majority of people who will be designing content for a metaverse based on OpenSim will come from Second Life.

I can understand that from a developers perspective, Intellectual Property Rights protection is a nasty bear to wrestle in the development of the metaverse, but I do not see how the metaverse project benefits from alienating the people who will make the metaverse interesting.  Think about it...  what would you have without content?  Lots of empty space.

I believe that the first metaverse platform to successfully solve the IP Rights issue will end up on the top of the pile.  And with the concept that Charles and I were discussing here last night, I think OpenSim could well be that platform.


_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

--------------040800080008030402040201-- From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: automatically by OpenSim. So, since one table is created correctly, I'm assuming connecting to the database is occurring correctly since otherwise nothing would be created (i.e. in the case of incorrect permissions). I have also tested this on several other CentOS 5 boxes as well as with several disparate MySQL servers on those boxes with both local and remote connections (i.e. with OpenSim both on the same box and on different boxes than the MySQL database). I'm not sure if it is my configuration or a bug, so I figured I would post here first. Any help would be appreciated. Here are some of the system stats from the main machine on which I am testing OpenSim as well as the OpenSim.ini and mysql_connection.ini files: CentOS 5 (i686) MySQL 5.0.22 Kernel 2.6.18 (53.1.13.el5) 512MB RAM GCC 4.1.2 My OpenSim.ini file: [Startup] gridmode = False physics = OpenDynamicsEngine verbose = True physical_prim = True child_get_tasks = False serverside_object_permissions = True storage_plugin = OpenSim.Framework.Data.MySQL.dll storage_connection_string="Data Source=localhost;Database=opensim;User ID=opensim;Password=*******;"; storage_prim_inventories = True startup_console_commands_file = startup_commands.txt shutdown_console_commands_file = shutdown_commands.txt script_engine = OpenSim.Region.ScriptEngine.DotNetEngine.dll asset_database = mysql [StandAlone] accounts_authenticate = true welcome_message = Welcome to OpenSim inventory_plugin = OpenSim.Framework.Data.MySQL.dll userDatabase_plugin = OpenSim.Framework.Data.MySQL.dll asset_plugin = OpenSim.Framework.Data.MySQL.dll dump_assets_to_file = False [Network] default_location_x = 1000 default_location_y = 1000 http_listener_port = 9000 remoting_listener_port = 8895 grid_server_url = http://127.0.0.1:8001 grid_send_key = null grid_recv_key = null user_server_url = http://127.0.0.1:8002 user_send_key = null user_recv_key = null asset_server_url = http://127.0.0.1:8003 inventory_server_url = http://127.0.0.1:8004 [RemoteAdmin] enabled = false My mysql_connection.ini file: [mysqlconnection] hostname=localhost database=opensim username=opensim password=******** pooling=false port=3306 ------=_Part_13453_26798329.1204580145997 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello,

I have been trying for the last several days to get OpenSim working on a CentOS 5 box using MySQL.  It seems to work nicely with SQLite, but I really would like to get MySQL working.  I have tried both with the 0.5.0 release as well as a current SVN copy.  With both, I get MySQL configured and it connects to the database fine.  The problem comes (I believe) when it tries to create the tables the first time.  When I start with 'mono OpenSim.exe', I get the following:

<snippet>
OpenSim 0.4, SVN build

Performing compatibility checks...  Environment is compatible.

Starting...

Creating new local console
Logs will be saved to current directory in ./region-console.log
[DATASTORE
] [03-03 16:03:48] Attempting to load OpenSim.Framework.Data.MySQL.dll
[DATASTORE
] [03-03 16:03:48] MySql - connecting: Data Source=localhost;Database=opensim;User ID=opensim;Password=************;
[DATASTORE
] [03-03 16:03:48] MySql Database doesn't exist... creating
</snippet>

At this point OpenSim just sits there indefinitely.  If I log into MySQL and look at the opensim database, only the 'prims' table is created. 

From what I've read in the documentation, all the tables should be created automatically by OpenSim.  So, since one table is created correctly, I'm assuming connecting to the database is occurring correctly since otherwise nothing would be created (i.e. in the case of incorrect permissions).  I have also tested this on several other CentOS 5 boxes as well as with several disparate MySQL servers on those boxes with both local and remote connections (i.e. with OpenSim both on the same box and on different boxes than the MySQL database).  I'm not sure if it is my configuration or a bug, so I figured I would post here first.  Any help would be appreciated.

Here are some of the system stats from the main machine on which I am testing OpenSim as well as the OpenSim.ini and mysql_connection.ini files:

CentOS 5 (i686)
MySQL 5.0.22
Kernel 2.6.18 (53.1.13.el5)
512MB RAM
GCC 4.1.2

My OpenSim.ini file:

<snippet>
[Startup]
gridmode = False
physics = OpenDynamicsEngine
verbose = True
physical_prim = True
child_get_tasks = False
serverside_object_permissions = True
storage_plugin = OpenSim.Framework.Data.MySQL.dll
storage_connection_string="Data Source=localhost;Database=opensim;User ID=opensim;Password=*******;";
storage_prim_inventories = True
startup_console_commands_file = startup_commands.txt
shutdown_console_commands_file = shutdown_commands.txt
script_engine = OpenSim.Region.ScriptEngine.DotNetEngine.dll
asset_database = mysql
[StandAlone]
accounts_authenticate = true
welcome_message = Welcome to OpenSim
inventory_plugin = OpenSim.Framework.Data.MySQL.dll
userDatabase_plugin = OpenSim.Framework.Data.MySQL.dll
asset_plugin = OpenSim.Framework.Data.MySQL.dll
dump_assets_to_file = False
[Network]
default_location_x = 1000
default_location_y = 1000
http_listener_port = 9000
remoting_listener_port = 8895
grid_server_url = http://127.0.0.1:8001
grid_send_key = null
grid_recv_key = null
user_server_url = http://127.0.0.1:8002
user_send_key = null
user_recv_key = null
asset_server_url = http://127.0.0.1:8003
inventory_server_url = http://127.0.0.1:8004
[RemoteAdmin]
enabled = false
</snippet>

My mysql_connection.ini file:

<snippet>
[mysqlconnection]
hostname=localhost
database=opensim
username=opensim
password=********
pooling=false
port=3306
</snippet>
------=_Part_13453_26798329.1204580145997-- From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: between machines that are across the internet. However, this brings up another interesting topic.. generally Is a cheap DSL connection going to be enough to host a 'ton' of users anyway? You'd think you'd have to want to host a ton of users to get any benefit from using the load balancing. Best Regards Teravus On 3/6/08, Grumly wrote: > > Would this explain why DSL home hosted adjacent sims crossing is so shaky > sometimes ? > In this case, I am afraid such simulators could also not take advantage of > the new load balancing feature. > > *From:* Michael Wright > *Sent:* Thursday, March 06, 2008 12:47 PM > *To:* opensim-dev at lists.berlios.de > *Subject:* Re: [Opensim-dev] Concerning recent grid instability > andinconsistency > > > I haven't had much time to follow this discussion, but just a quick note. > We used to have a REST like communications protocol between the regions, but > this lead to a lot of problems. Granted it was like the rest of the backend > protocols we use, very err primitive. But I just not sure http/xml is the > best protocol to be used there, as a lot of the calls are time critical. And > there are some things we are yet to add which would increase the network > traffic between the regions by quite a bit. Thats why we switched to > remoting so we could at least have a binary protocol. Maybe we do need to > switch to udp, like I believe Linden Labs do (or at least they used to). > > *Brian McBee * wrote: > > Coming late to this discussion, but i have a couple of comments about our > use of remoting in the interregion communications: > > 1. It seems like remoting is really designed for a scenario where you own > both the client and server ends of the connection, and have a reasonable > expectation that the server is up. In a distributed grid environment like > OSGRID is running, that assumption isn't true. > > 2. When playing with the teleport code, I tried to find a way to lower the > timeout on the remoting calls, since a failed teleport took forever to > resolve. It appears that, at least the way we are doing it, the timeout is > hardcoded and cannot be changed. It looks like Microsoft tries to provide a > way to change that timeout, but it doesn't actually work. > > Perhaps longer term, we should be looking at replacing remoting with a > REST interface like we are using for the sim to grid communications. > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > ------------------------------ > Rise to the challenge for Sport Relief with Yahoo! for Good > > ------------------------------ > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > ------=_Part_5443_28098821.1204831788868 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
From what I've read, it can assuming you don't have regions load balancing between machines that are across the internet.
However, this brings up another interesting topic..    generally Is a cheap DSL connection going to be enough to host a 'ton' of users anyway?    You'd think you'd have to want to host a ton of users to get any benefit from using the load balancing.
 
Best Regards
 
Teravus

 
On 3/6/08, Grumly <grumly57 at hotmail.com> wrote:
Would this explain why DSL home hosted adjacent sims crossing is so shaky sometimes ?
In this case, I am afraid such simulators could also not take advantage of the new load balancing feature.
 
Sent: Thursday, March 06, 2008 12:47 PM
Subject: Re: [Opensim-dev] Concerning recent grid instability andinconsistency

 
I haven't had much time to follow this discussion, but just a quick note. We used to have a REST like communications protocol between the regions, but this lead to a lot of problems. Granted it was like the rest of the backend protocols we use, very err primitive. But I just not sure http/xml is the best protocol to be used there, as a lot of the calls are time critical. And there are some things we are yet to add which would increase the network traffic between the regions by quite a bit. Thats why we switched to remoting so we could at least have a binary protocol. Maybe we do need to switch to udp, like I believe Linden Labs do (or at least they used to).

Brian McBee <heartwide at gmail.com> wrote:
Coming late to this discussion, but i have a couple of comments about our use of remoting in the interregion communications:

1. It seems like remoting is really designed for a scenario where you own both the client and server ends of the connection, and have a reasonable expectation that the server is up. In a distributed grid environment like OSGRID is running, that assumption isn't true.

2. When playing with the teleport code, I tried to find a way to lower the timeout on the remoting calls, since a failed teleport took forever to resolve. It appears that, at least the way we are doing it, the timeout is hardcoded and cannot be changed. It looks like Microsoft tries to provide a way to change that timeout, but it doesn't actually work.

Perhaps longer term, we should be looking at replacing remoting with a REST interface like we are using for the sim to grid communications.


_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Rise to the challenge for Sport Relief with Yahoo! for Good

_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev


_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev


------=_Part_5443_28098821.1204831788868-- From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: balancing between machines that are across the internet. However, this brings up another interesting topic.. generally Is a = cheap DSL connection going to be enough to host a 'ton' of users anyway? = You'd think you'd have to want to host a ton of users to get any = benefit from using the load balancing. Best Regards Teravus =20 On 3/6/08, Grumly wrote:=20 Would this explain why DSL home hosted adjacent sims crossing is so = shaky sometimes ? In this case, I am afraid such simulators could also not take = advantage of the new load balancing feature. From: Michael Wright=20 Sent: Thursday, March 06, 2008 12:47 PM To: opensim-dev at lists.berlios.de=20 Subject: Re: [Opensim-dev] Concerning recent grid instability = andinconsistency =20 I haven't had much time to follow this discussion, but just a quick = note. We used to have a REST like communications protocol between the = regions, but this lead to a lot of problems. Granted it was like the = rest of the backend protocols we use, very err primitive. But I just not = sure http/xml is the best protocol to be used there, as a lot of the = calls are time critical. And there are some things we are yet to add = which would increase the network traffic between the regions by quite a = bit. Thats why we switched to remoting so we could at least have a = binary protocol. Maybe we do need to switch to udp, like I believe = Linden Labs do (or at least they used to). Brian McBee wrote:=20 Coming late to this discussion, but i have a couple of comments = about our use of remoting in the interregion communications: 1. It seems like remoting is really designed for a scenario where = you own both the client and server ends of the connection, and have a = reasonable expectation that the server is up. In a distributed grid = environment like OSGRID is running, that assumption isn't true. 2. When playing with the teleport code, I tried to find a way to = lower the timeout on the remoting calls, since a failed teleport took = forever to resolve. It appears that, at least the way we are doing it, = the timeout is hardcoded and cannot be changed. It looks like Microsoft = tries to provide a way to change that timeout, but it doesn't actually = work. Perhaps longer term, we should be looking at replacing remoting with = a REST interface like we are using for the sim to grid communications. _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -------------------------------------------------------------------------= ----- Rise to the challenge for Sport Relief with Yahoo! for Good=20 -------------------------------------------------------------------------= ----- _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -------------------------------------------------------------------------= ------- _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ------=_NextPart_001_01C8_01C87FCF.949045E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
True 3D"Visage
The example you gave is the good one. = In this very=20 case, I would rather use load balancing to move temporary my cheap DSL = hosted=20 region to some powerful servers on the grid, which would be = equipped=20 with a high bandwidth connection. This could be a "rent balanced = servers" rental=20 operation for specials events.
I suppose the move operation may = probably not be as=20 smooth as described in some posts I read.

From: Teravus Ovares
Sent: Thursday, March 06, 2008 8:29 PM
To: opensim-dev at lists.berlios.de= =20
Subject: Re: [Opensim-dev] Concerning recent grid=20 instabilityandinconsistency

From what I've read, it can assuming you don't have regions load = balancing=20 between machines that are across the internet.
However, this brings up another interesting = topic..   =20 generally Is a cheap DSL connection going to be enough to host a 'ton' = of users=20 anyway?    You'd think you'd have to want to host a ton = of users=20 to get any benefit from using the load balancing.
 
Best Regards
 
Teravus

 
On 3/6/08, Grumly=20 <grumly57 at hotmail.com> = wrote:=20
Would this explain why DSL home = hosted adjacent=20 sims crossing is so shaky sometimes ?
In this case, I am afraid such = simulators=20 could also not take advantage of the new load balancing=20 feature.
 
Sent: Thursday, March 06, 2008 12:47 PM
Subject: Re: [Opensim-dev] Concerning recent grid = instability=20 andinconsistency

 
I haven't had much time = to follow=20 this discussion, but just a quick note. We used to have a REST like=20 communications protocol between the regions, but this lead to a lot of = problems. Granted it was like the rest of the backend protocols we = use, very=20 err primitive. But I just not sure http/xml is the best protocol to be = used=20 there, as a lot of the calls are time critical. And there are some = things we=20 are yet to add which would increase the network traffic between the = regions by=20 quite a bit. Thats why we switched to remoting so we could at least = have a=20 binary protocol. Maybe we do need to switch to udp, like I believe = Linden Labs=20 do (or at least they used to).

Brian McBee <heartwide at gmail.com> wrote:=20 Coming=20 late to this discussion, but i have a couple of comments about our = use of=20 remoting in the interregion communications:

1. It seems like = remoting=20 is really designed for a scenario where you own both the client and = server=20 ends of the connection, and have a reasonable expectation that the = server is=20 up. In a distributed grid environment like OSGRID is running, that=20 assumption isn't true.

2. When playing with the teleport = code, I=20 tried to find a way to lower the timeout on the remoting calls, = since a=20 failed teleport took forever to resolve. It appears that, at least = the way=20 we are doing it, the timeout is hardcoded and cannot be changed. It = looks=20 like Microsoft tries to provide a way to change that timeout, but it = doesn't=20 actually work.

Perhaps longer term, we should be looking at = replacing=20 remoting with a REST interface like we are using for the sim to grid = = communications.


______________________________________________= _
Opensim-dev=20 mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev=

Rise to the challenge for Sport Relief with Yahoo! for Good

_______________________________________________
Opensim-dev = mailing=20 list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev=

=


_______________________________________________
Opens= im-dev=20 mailing list
Opensim-dev at lists.berlios.de=
https://lists.berlios.de/mailman/listinfo/opensim-dev=


_______________________________________________
Opensim-dev = mailing=20 list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/= listinfo/opensim-dev
------=_NextPart_001_01C8_01C87FCF.949045E0-- ------=_NextPart_000_01C7_01C87FCF.949045E0 Content-Type: image/gif; name="Emoticon1.gif" Content-Transfer-Encoding: base64 Content-ID: <95A3912E886848EC918F573786AE0336 at LBLAPTOP> R0lGODlhEwATALMPAPXv3v3pTvDHOei2K9u4a9qoLunPkLGLMdOZKfvbQMeyl5p4J+7JbrebXoAy GAAAACH5BAEAAA8ALAAAAAATABMAAASu8EkJDBNjMAOmf5UgJEGQJBj3AVfpuslAdBRDvu8p04YQ CIuFrzQIDgQFA2i4AAAWruYTgwiVFopnNCsUICy3hUMBvY67hcYwIHaU2Q43ZnAYuIDCUixYmC8G NzgmJyIZBQcXgYMnKIUDCA09jA4FgCcFCA4ZdFlHl5SbmQiGBx0GR0iZcXEIo5wUBH1ImK2tGQcN NCCxm70Dh7krBq2VvwgHB1kfExUNBwu4yh4RADs= ------=_NextPart_000_01C7_01C87FCF.949045E0-- From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: =20 * Overly complex (the configuration seem to, in themselves, be on par with = actually coding generic mappers) * Mandating major changes in our object structure (opening up for encapsula= tion violations or forcing dependencies on hibernate) * Totally invasive (as in, in practice demanding its storage philosophy to = be acommodated for and coded into core objects) =20 It has been proven a very bad thing to let objects take care of their own d= b serialization. More often than not, the object cannot be serialized from = within its own context (it might not have data like 'parent' needed for rel= ational storage) - and the object itself should not know about any given se= rialization method. =20 It IS a very bad thing to rely on 'storage' as a prime db serialization con= cept - you want 'changes': the first thing we need to do when we get to opt= imize the db layer, is to introduce more fine-grained update calls, like 'C= hangeOwner' and 'StoreTextures' instead of 'store object, with prims, textu= res and shapes'. I have asked several times how this would be accomodated i= n nhibernate, but have got no answers. =20 Now, I've been asking for some kind of overview of the wins with this and w= hat the drawbacks are, but have so far got none that gives me any idea of w= hat impact this has on our modular approach or on performance. =20 If we're not going to let it 'hibernate' objects, as in 'let the objects th= emselves store themselves' and if we have to set up config files detailing = out the mappings, why simply not just CODE the thing and get the granularit= y, performance and customizability (as in, being able to let the objects be= serialized according to their different internal structures) that comes wi= th it? =20 Best, /Stefan Date: Fri, 4 Apr 2008 10:23:33 +0200From: impalah at gmail.comTo: opensim-dev@= lists.berlios.deSubject: Re: [Opensim-dev] nhibernate progress, baby stepsH= ello everyone:I hadn't any time to "nhibernating" opensim (as I told months= ago) but the code I did is there.Sean I know my code may be "complicated" = when starting, that's for the use of factories and DAO's. My intention was = to convert every nhibernate object in a DAO, so they will know how to save,= update, delete... themselves (a simple call to AssetDAO.Save(id) for examp= le). Well, for testing your approach is better if you don't have enough exp= erience with hibernate.Second, my approach was to not modify the current ob= jects, mapping them to nhibernate classes. Of course the better idea is to = use the libsl-hibernatized objects (with getters and setters) throughout th= e code w/o intermediate mapping classes. I think the advantages of having "= intelligent" getters and setters where we could put validations, or even cl= asses than can serialize (to XML or whatever) are more than the "overload a= nd memory use" disadvantages.Third (fuck, I'm making a list) the ID questio= n: do not use the "auto" ids (generated by nhibernate). Let opensim create = them. The overhead of letting hibernate create these ids is higher than the= CoCreateId call opensim does. If you want to use a byte array for storing = ids (due to better performance), use it; hibernate hasn't any problem with = it (the "recommended id" is an integer because hibernate is often used in "= enterprise environments", there isn't any other reason).Four, I tested my p= revious code (apart from .NET) with mono + SQLite + nhibernate w/o "touchin= g" anything (I used the included sqlite drivers included with opensim). I c= an't help you here.Five, instead of using the hbm.xml files you can use map= ping attributes (that was the point where I stopped). The same with the hib= ernate.cfg.xml, you can set its properties "programatically". The advantage= s: if you change one data object you don't have to change the xml file too;= and less files in the bin directory as well.Six, you can generate the db s= chemma automatically (I think I provided an example), it's db independent. = If you are using mapping attributes instead of hbm.xml just serialize the o= bjects (there are some examples looking for "nhibernate mapping attributes"= in google). It works...Seven, sorry. I wanted to help you developing a hib= ernate base but I had only 1 "relatively" free week to did it. Maybe in the= future.Greetings and good luckImpalah "busy guy" Shenzhou 2008/4/3, Stefan Andersson :=20 Yeah, well; I'm not saying it IS, just that we need to check on it.I glimps= ed that as I was trying to find out what the 'best practice' for storing gu= ids in MySQL databases was; I actually didn't find any good info on that. /= Stefan > Subject: RE: [Opensim-dev] nhibernate progress, baby steps> From: brianw@= terrabox.com> To: stefan at tribalmedia.se> CC: opensim-dev at lists.berlios.de> = Date: Thu, 3 Apr 2008 13:04:37 -0500=20 > > > Ouch. That's not good. > > > On Thu, 2008-04-03 at 19:55 +0200, Stefa= n Andersson wrote:> > It seems the MySQL connector for .net assumes the db = field is a> > string for its internal MySqlDataReader.GetGuid() implementat= ion.> > > > (I could have been looking at source for an old revision of the= > > connector, but that needs to be checked out anyway)> > > > So, that mig= ht mean that going binary could wreck stuff like> > nhibernate, if that's u= sing a DataReader.> > > > Best,> > /Stefan> > > > > > > > > > > > _________= _____________________________________________________________> > > > > Date= : Thu, 3 Apr 2008 13:49:03 -0400> > > From: sean at dague.net> > > To: brianw@= terrabox.com; opensim-dev at lists.berlios.de> > > Subject: Re: [Opensim-dev] = nhibernate progress, baby steps> > > > > > On Thu, Apr 03, 2008 at 11:19:58= AM -0500, Brian Wolfe wrote:> > > > *nod* sounds good to me as well. I just= have one request since> > we'll be> > > > changing things up at this level= . Can we shoot for UUIDs being> > stored as> > > > a byte[16] in order to g= ain the 10x speedup in SQL> > indexing/storage vs> > > > string(32|36) ?> >= > > > > That's definitely an option. It did however seem like there was so= me> > > speedup on LLUUID processing if we kept strings. I'm not sure where= > > the> > > two end up colliding on speedup effects.> > > > > > -Sean> > >= > > > -- > > > ___________________________________________________________= _______> > > > > > Sean Dague Mid-Hudson Valley> > > sean at dague dot net = Linux Users Group> > > http://dague.net http://mhvlug.org> > > > > > There = is no silver bullet. Plus, werewolves make better neighbors> > > than zombi= es, and they tend to keep the vampire population down.> > > _______________= ___________________________________________________> > > __________________= _____________________________Opensim-dev mailing listOpensim-dev at lists.berl= ios.dehttps://lists.berlios.de/mailman/listinfo/opensim-dev= --_3e0aae69-b7da-4b90-ae8a-20bc57d06fce_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At this point I must, again, ask 'what is the poi= nt of nhibernate'?
 
From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID:  
* Overly complex (the configuration seem to, in themselves, be on par with = actually coding generic mappers)
* Mandating major changes in our object structure (opening up for encapsula= tion violations or forcing dependencies on hibernate)
* Totally invasive (as in, in practice demanding its storage philosophy to = be acommodated for and coded into core objects)
 
It has been proven a very bad thing to let objects take care of their own d= b serialization. More often than not, the object cannot be serialized from = within its own context (it might not have data like 'parent' needed for rel= ational storage) - and the object itself should not know about any given se= rialization method.
 
It IS a very bad thing to rely on 'storage' as a prime db serialization con= cept - you want 'changes': the first thing we need to do when we = get to optimize the db layer, is to introduce more fine-grained update call= s, like 'ChangeOwner' and 'StoreTextures' instead of 'store object, with pr= ims, textures and shapes'. I have asked several times how this would be acc= omodated in nhibernate, but have got no answers.
 
Now, I've been asking for some kind of overview of the wins with this and w= hat the drawbacks are, but have so far got none that gives me any idea of w= hat impact this has on our modular approach or on performance.
 
If we're not going to let it 'hibernate' objects, as in 'let the objects th= emselves store themselves' and if we have to set up config files detailing = out the mappings, why simply not just CODE the thing and get the granu= larity, performance and customizability (as in, being able to let= the objects be serialized according to their different internal structures= ) that comes with it?
 
Best,
/Stefan

Date: Fri, 4 Apr 2008 10:23:33 +0200
From: impalah at gmail.com
To: open= sim-dev at lists.berlios.de
Subject: Re: [Opensim-dev] nhibernate progress,= baby steps

Hello everyone:

I hadn't any time to "nhibernatin= g" opensim (as I told months ago) but the code I did is there.

Sean = I know my code may be "complicated" when starting, that's for the use of fa= ctories and DAO's. My intention was to convert every nhibernate object in a= DAO, so they will know how to save, update, delete... themselves (a simple= call to AssetDAO.Save(id) for example). Well, for testing your approach is= better if you don't have enough experience with hibernate.

Second, = my approach was to not modify the current objects, mapping them to nhiberna= te classes. Of course the better idea is to use the libsl-hibernatized obje= cts (with getters and setters) throughout the code w/o intermediate mapping= classes. I think the advantages of having "intelligent" getters and setter= s where we could put validations, or even classes than can serialize (to XM= L or whatever) are more than the "overload and memory use" disadvantages.
Third (fuck, I'm making a list) the ID question: do not use the "auto= " ids (generated by nhibernate). Let opensim create them. The overhead of l= etting hibernate create these ids is higher than the CoCreateId call opensi= m does. If you want to use a byte array for storing ids (due to better perf= ormance), use it; hibernate hasn't any problem with it (the "recommended id= " is an integer because hibernate is often used in "enterprise environments= ", there isn't any other reason).

Four, I tested my previous code (a= part from .NET) with mono + SQLite + nhibernate w/o "touching" anything (I = used the included sqlite drivers included with opensim). I can't help you h= ere.

Five, instead of using the hbm.xml files you can use mapping at= tributes (that was the point where I stopped). The same with the hibernate.= cfg.xml, you can set its properties "programatically". The advantages: if y= ou change one data object you don't have to change the xml file too; and le= ss files in the bin directory as well.

Six, you can generate the db = schemma automatically (I think I provided an example), it's db independent.= If you are using mapping attributes instead of hbm.xml just serialize the = objects (there are some examples looking for "nhibernate mapping attributes= " in google). It works...

Seven, sorry. I wanted to help you develop= ing a hibernate base but I had only 1 "relatively" free week to did it. May= be in the future.

Greetings and good luck

Impalah "busy guy" = Shenzhou




2008/4/3, Stefan Andersson <stefan at tribalmedia.se>:=20
Yeah, well; I'm not saying it IS, just that we need to check on it.
I glimpsed that as I was trying to find out what the 'best practice' f= or storing guids in MySQL databases was; I actually didn't find any good in= fo on that.
 
/Stefan



> Subject: RE: [Opensim-dev] nhibernate progress, baby steps
>= From: brianw at terrabox.com
&g= t; To: stefan at tribalmedia.se> CC: opensim-dev at list= s.berlios.de
> Date: Thu, 3 Apr 2008 13:04:37 -0500=20

>
>
= > Ouch. That's not good.
>
>
> On Thu, 2008-04-03 a= t 19:55 +0200, Stefan Andersson wrote:
> > It seems the MySQL conn= ector for .net assumes the db field is a
> > string for its intern= al MySqlDataReader.GetGuid() implementation.
> >
> > (I = could have been looking at source for an old revision of the
> > c= onnector, but that needs to be checked out anyway)
> >
> &g= t; So, that might mean that going binary could wreck stuff like
> >= ; nhibernate, if that's using a DataReader.
> >
> > Best= ,
> > /Stefan
> >
> >
> >
> &g= t;
> >
> > ____________________________________________= __________________________
> >
> > > Date: Thu, 3 Apr= 2008 13:49:03 -0400
> > > From: sean at dague.net
> > > To: brianw at terrabox.com; opensim-dev at lists.berlios.de
> > > Subject: Re: [Ope= nsim-dev] nhibernate progress, baby steps
> > >
> > &= gt; On Thu, Apr 03, 2008 at 11:19:58AM -0500, Brian Wolfe wrote:
> &g= t; > > *nod* sounds good to me as well. I just have one request since=
> > we'll be
> > > > changing things up at this le= vel. Can we shoot for UUIDs being
> > stored as
> > > = > a byte[16] in order to gain the 10x speedup in SQL
> > indexi= ng/storage vs
> > > > string(32|36) ?
> > >
= > > > That's definitely an option. It did however seem like there = was some
> > > speedup on LLUUID processing if we kept strings.= I'm not sure where
> > the
> > > two end up colliding= on speedup effects.
> > >
> > > -Sean
> >= ; >
> > > --
> > > ___________________________= _______________________________________
> > >
> > >= ; Sean Dague Mid-Hudson Valley
> > > sean at dague dot net Linu= x Users Group
> > > http://dague.net http= ://mhvlug.org
> > >
> > > There is no silver b= ullet. Plus, werewolves make better neighbors
> > > than zombie= s, and they tend to keep the vampire population down.
> > > ___= _______________________________________________________________
> >= ;
>


_________________________________= ______________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists= .berlios.de/mailman/listinfo/opensim-dev


=
= --_3e0aae69-b7da-4b90-ae8a-20bc57d06fce_-- From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID:  
* Overly complex (the configuration seem to, in themselves, be on par with actually coding generic mappers)
* Mandating major changes in our object structure (opening up for encapsulation violations or forcing dependencies on hibernate)
* Totally invasive (as in, in practice demanding its storage philosophy to be acommodated for and coded into core objects)
 
It has been proven a very bad thing to let objects take care of their own db serialization. More often than not, the object cannot be serialized from within its own context (it might not have data like 'parent' needed for relational storage) - and the object itself should not know about any given serialization method.
 
It IS a very bad thing to rely on 'storage' as a prime db serialization concept - you want 'changes': the first thing we need to do when we get to optimize the db layer, is to introduce more fine-grained update calls, like 'ChangeOwner' and 'StoreTextures' instead of 'store object, with prims, textures and shapes'. I have asked several times how this would be accomodated in nhibernate, but have got no answers.
 
Now, I've been asking for some kind of overview of the wins with this and what the drawbacks are, but have so far got none that gives me any idea of what impact this has on our modular approach or on performance.
 
If we're not going to let it 'hibernate' objects, as in 'let the objects themselves store themselves' and if we have to set up config files detailing out the mappings, why simply not just CODE the thing and get the granularity, performance and customizability (as in, being able to let the objects be serialized according to their different internal structures) that comes with it?
 
Best,
/Stefan

Date: Fri, 4 Apr 2008 10:23:33 +0200
From: impalah at gmail.com
To: opensim-dev at lists.berlios.de

Subject: Re: [Opensim-dev] nhibernate progress, baby steps

Hello everyone:

I hadn't any time to "nhibernating" opensim (as I told months ago) but the code I did is there.

Sean I know my code may be "complicated" when starting, that's for the use of factories and DAO's. My intention was to convert every nhibernate object in a DAO, so they will know how to save, update, delete... themselves (a simple call to AssetDAO.Save(id) for example). Well, for testing your approach is better if you don't have enough experience with hibernate.

Second, my approach was to not modify the current objects, mapping them to nhibernate classes. Of course the better idea is to use the libsl-hibernatized objects (with getters and setters) throughout the code w/o intermediate mapping classes. I think the advantages of having "intelligent" getters and setters where we could put validations, or even classes than can serialize (to XML or whatever) are more than the "overload and memory use" disadvantages.

Third (fuck, I'm making a list) the ID question: do not use the "auto" ids (generated by nhibernate). Let opensim create them. The overhead of letting hibernate create these ids is higher than the CoCreateId call opensim does. If you want to use a byte array for storing ids (due to better performance), use it; hibernate hasn't any problem with it (the "recommended id" is an integer because hibernate is often used in "enterprise environments", there isn't any other reason).

Four, I tested my previous code (apart from .NET) with mono + SQLite + nhibernate w/o "touching" anything (I used the included sqlite drivers included with opensim). I can't help you here.

Five, instead of using the hbm.xml files you can use mapping attributes (that was the point where I stopped). The same with the hibernate.cfg.xml, you can set its properties "programatically". The advantages: if you change one data object you don't have to change the xml file too; and less files in the bin directory as well.

Six, you can generate the db schemma automatically (I think I provided an example), it's db independent. If you are using mapping attributes instead of hbm.xml just serialize the objects (there are some examples looking for "nhibernate mapping attributes" in google). It works...

Seven, sorry. I wanted to help you developing a hibernate base but I had only 1 "relatively" free week to did it. Maybe in the future.

Greetings and good luck

Impalah "busy guy" Shenzhou




2008/4/3, Stefan Andersson <stefan at tribalmedia.se>:
Yeah, well; I'm not saying it IS, just that we need to check on it.

I glimpsed that as I was trying to find out what the 'best practice' for storing guids in MySQL databases was; I actually didn't find any good info on that.
 
/Stefan



> Subject: RE: [Opensim-dev] nhibernate progress, baby steps
> From: brianw at terrabox.com
> To: stefan at tribalmedia.se
> CC: opensim-dev at lists.berlios.de
> Date: Thu, 3 Apr 2008 13:04:37 -0500

>
>
> Ouch. That's not good.
>
>
> On Thu, 2008-04-03 at 19:55 +0200, Stefan Andersson wrote:
> > It seems the MySQL connector for .net assumes the db field is a
> > string for its internal MySqlDataReader.GetGuid() implementation.
> >
> > (I could have been looking at source for an old revision of the
> > connector, but that needs to be checked out anyway)
> >
> > So, that might mean that going binary could wreck stuff like
> > nhibernate, if that's using a DataReader.
> >
> > Best,
> > /Stefan
> >
> >
> >
> >
> >
> > ______________________________________________________________________
> >
> > > Date: Thu, 3 Apr 2008 13:49:03 -0400
> > > From: sean at dague.net
> > > To: brianw at terrabox.com; opensim-dev at lists.berlios.de
> > > Subject: Re: [Opensim-dev] nhibernate progress, baby steps
> > >
> > > On Thu, Apr 03, 2008 at 11:19:58AM -0500, Brian Wolfe wrote:
> > > > *nod* sounds good to me as well. I just have one request since
> > we'll be
> > > > changing things up at this level. Can we shoot for UUIDs being
> > stored as
> > > > a byte[16] in order to gain the 10x speedup in SQL
> > indexing/storage vs
> > > > string(32|36) ?
> > >
> > > That's definitely an option. It did however seem like there was some
> > > speedup on LLUUID processing if we kept strings. I'm not sure where
> > the
> > > two end up colliding on speedup effects.
> > >
> > > -Sean
> > >
> > > --
> > > __________________________________________________________________
> > >
> > > Sean Dague Mid-Hudson Valley
> > > sean at dague dot net Linux Users Group
> > > http://dague.net http://mhvlug.org
> > >
> > > There is no silver bullet. Plus, werewolves make better neighbors
> > > than zombies, and they tend to keep the vampire population down.
> > > __________________________________________________________________
> >
>


_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev



_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev


------=_Part_6417_11978504.1207318215374-- From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: I think a number of people were thinking I meant something a lot more complex than I do (at least to start with) So as soon as I get time I'm going to try to write a more clear in depth email. Just that won't be for a few days or more. But yeah basically as you said end to end funnels with servlets attaching to the ends. Dr Scofield wrote: Michael Wright wrote: I guess in some ways it could be thought as a network bus, but I wasn't thinking of the messages being broadcast on the channel, where all endpoints had to listen to all messages and pick out the ones for them. I was thinking, if anything, of more like a cut down web services protocol stack. My prototype channel is just a basic HTTP based one. That just finds where the url of the channel receiver, that the required servlet is currently registered at, is. Then does a HTTP POST of the serialised message to that url. But the implementation should be up to the channels. All the rest of the system should care is that a channel can pass messages from one end point to another, and can map some standard addressing scheme to those endpoints. Allowing for a dynamic system, where the addressable message receivers (the servlets) can move around the endpoints on a channel as needed. And new endpoints can be added. ah. ok. so it's not a network bus, but rather a dual-ended funnel --- like >--< ? with servlets attaching themselves to the respective funnels on each end? cheers, dr scofield? Dr Scofield wrote: interesting thoughts. question: would a channel be something like a network bus? cheers dr scofield Michael Wright wrote: > I'm been thinking and prototyping about some improvements on the grid > servers/protocols. > > One of my aims is to try to separate the network code more from the > logic code. So am thinking of what I'm calling a Channel and servlet > system. > > A servlet is just a class that performs some service. I'm thinking > more in terms of breaking up the current servers into smaller > services/servlets. > > So then we have a collection of servlets that do the various functions > that the current servers do (except I'm not including the asset server > in this as think that is best kept to a proper REST resource based > system). > > Then we come to the channel, maybe this is a bad term for what I'm > thinking, but anyway. The channel has two (or three) parts, the > sender/receivers, which are responsible for the > serialising/deserialising of the messages/datagrams, and also of > sending it to the correct url. To find the url that a message should > be sent to, the other part of the channel is responsible. I'm > currently thinking of this as a basic central hash table service, that > just keeps track of the servlets that are registered on that channel > and the url of the endpoint that they are one. Of course the idea with > the channel is to keep the code separate from the service logic, so > how the servlet tracking is done is up to the implementation. > > While each servlet could actually have its own endpoint/channel > receiver, I'm thinking more of a collection of them sharing a > endpoint. So normally maybe only one endpoint per server instance. > > So all a channel really is: Is a managed collection of known services > and the url they can be reached at. Plus the code for de/serialising > the messages in the format that channel uses. > > The third component is the Router service. Each server instance would > have one of these, that is tasked with routing the messages to and > from the channel endpoint to the correct servlet. A router could be > connected to more than one channel. > > Again a basic concept. The task is just to keep track of servlets in > that instance, to know what channels they should be receiving messages > from. To be able to route a message from a servlet to a channel; > either a particular channel, or the servlet might just say any channel > that has a particular type of service registered on it. Also the > router should be able to do internal routing...from one servlet to > another that is in the same instance. > > > I'm also thinking that the region servers will have such a router and > be registered on a channel(s). And then region modules could send and > receive messages the same way. > > My thoughts and actually my requirements for some other ideas. Is to > have a dynamic modular system. That keeps the network code completely > separate from the services logic. I really think that the current > servers are too err monolithic and really group together a bunch of > services that are separate. I don't mean they should always be on > separate servers, just the code should be separated more and more > modular. > > So my thoughts are lots of smaller services/servlets. And once we do > that, it could lead to lots of url having to be kept track of by each > other servlet if we used the current approach. So thats why I think > the network code , including url management/tracking should be > completely separate. > This also I think/hope could help with scaling things. In that as the > servlets can be grouped together as needed (and even moved around the > server instances). Then a very small grid might only want to run one > backend server instance that had all the servlets that it needs > running. While a much larger grid might have a server instance for > each servlet, and maybe more than one servlet of each type running. > > Also its possible that we could use the same servlets in standalone > mode, as they would just use the internal routing function of the > routing service. > > Another benefit is it helps to make the whole thing more customizable. > In a number of different ways. One of those ways is something that > I've done some prototyping of. Which is as the servlets and router > classes have no network code in at all. Its a simple task to write > different versions of the channel receivers/senders for say a ASP.net > implementation. > > There are still a number of things that need more thought. But thats a > general overview of my ideas > > > ------------------------------------------------------------------------ > Yahoo! for Good helps you make a difference > > > ------------------------------------------------------------------------ > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- dr dirk husemann, mathmatics and computer science, ibm zurich research lab SL: dr scofield ---- drscofield at xyzzyxyzzy.net ---- http://xyzzyxyzzy.net/ RL: hud at zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev --------------------------------- Yahoo! for Good helps you make a difference --------------------------------- _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- dr dirk husemann, mathmatics and computer science, ibm zurich research lab SL: dr scofield ---- drscofield at xyzzyxyzzy.net ---- http://xyzzyxyzzy.net/ RL: hud at zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev --------------------------------- Yahoo! for Good helps you make a difference --0-1037203-1207604039=:17696 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID:
Yahoo! for Good helps you make a difference --0-1037203-1207604039=:17696-- From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: That would allow an identification of the scope of the problem by a grid manager. From there a query to delete any that are empty, with what ever logical qualifiers might be useful. In any case, perhaps I have or have not diagnosed the problem correctly, and any suggestions are appreciated. Charles --0-1656819267-1208732199=:62460 Content-Type: text/html; charset=us-ascii
The situation exists where a number of avatars have multiple root inventory folders on OSGrid, and I suspect on other grids as well. One of the implications is that this obscures the inventory as our search stops at the first root inventory folder it finds, that is the first one whose parentFolderId == zeroes.

Having a query to identify and then remove completely empty root inventory folders might help make this situation better, but it involves a fairly complex mysql query that is currently beyond my abilities. I am hoping someone could help out a little here with a query that can be used to identify multiple root inventory folders in a grids mysql database and a query to would allow them to be deleted, perhaps one by one, that would be fine.

This query involves finding all those avatars with inventoryfolders entries where more then one parentFolderID is zeroes.

From there, it involves walking the subfolders (those folders pointing at each root folder whose parentFolderId is zeroes) and determining if any inventoryitems are pointing at any of those subfolders (Clothes, Objects, Trash, Scripts, Clothes, etc.).

That would allow an identification of the scope of  the problem by a grid manager. From there a query to delete any that are empty, with what ever logical qualifiers might be useful.

In any case, perhaps I have or have not diagnosed the problem correctly, and any suggestions are appreciated.

Charles
--0-1656819267-1208732199=:62460-- From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: each root folder whose parentFolderId is zeroes) and determining if any inventoryitems are pointing at any of those subfolders (Clothes, Objects, Trash, Scripts, Clothes, etc.). That would allow an identification of the scope of the problem by a grid manager. From there a query to delete any that are empty, with what ever logical qualifiers might be useful. In any case, perhaps I have or have not diagnosed the problem correctly, and any suggestions are appreciated. Charles_______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev --=_alternative 003FD97485257432_= Content-Type: text/html; charset="US-ASCII"
Charles

I think you have captured the technical consequences of having multiple inventory roots, but to resolve the issue we need to properly understand the whys and wherefores of multiple roots. Why do avatars have multiple roots? what are the functional differentiators? I.e. why does it matter that we stop at the first? I was recently looking through the new inventory/capabilities code and had had the same thoughts as you expressed. It seems to me that there can be only one (apologies to the Highlander) root directory. Given the information that is in it, there is no reson for this directory to exist outside of an extant presence, and all of the other hierarchies should exist as (apparent) subordinates to this directory. This then raises questions of convenience as a result of having something that is an unnecessary empty layer for the majority of inventories where only one hierarchy exists; there are a number of ways to address that such as collapsing any monotonous hierarchies. I assume the overwhelmingly most important goal is that at the end of the day the inventory is complete, predictable, and unambiguous.

Best regards
Alan
-------------------
T.J. Watson Research Center, Hawthorne, NY
1-914-784-7286
alan_webb at us.ibm.com


Charles Krinke <cfk at pacbell.net>
Sent by: opensim-dev-bounces at lists.berlios.de

04/20/2008 06:56 PM
Please respond to
opensim-dev at lists.berlios.de
To
opensim-dev <opensim-dev at lists.berlios.de>
cc
Subject
[Opensim-dev] multiple, empty, root inventory folders





The situation exists where a number of avatars have multiple root inventory folders on OSGrid, and I suspect on other grids as well. One of the implications is that this obscures the inventory as our search stops at the first root inventory folder it finds, that is the first one whose parentFolderId == zeroes.

Having a query to identify and then remove completely empty root inventory folders might help make this situation better, but it involves a fairly complex mysql query that is currently beyond my abilities. I am hoping someone could help out a little here with a query that can be used to identify multiple root inventory folders in a grids mysql database and a query to would allow them to be deleted, perhaps one by one, that would be fine.

This query involves finding all those avatars with inventoryfolders entries where more then one parentFolderID is zeroes.

From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: at each root folder whose parentFolderId is zeroes) and determining if any inventoryitems are pointing at any of those subfolders (Clothes, Objects, Trash, Scripts, Clothes, etc.).

That would allow an identification of the scope of  the problem by a grid manager. From there a query to delete any that are empty, with what ever logical qualifiers might be useful.

In any case, perhaps I have or have not diagnosed the problem correctly, and any suggestions are appreciated.

Charles_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
--=_alternative 003FD97485257432_=-- From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: ared LSL scripting lib (I suggest calling it OpenSim.Scripting.LSL in accor= dance with our recent ambition to remove superfluous namespace levels)This = project can then hold all types (or extracted basetypes) common to both the= DotNetEngine and the XEngine. These two projects are HIDEOUSLY duplicated = - even the LSLTypes are, which would DEFINITIVELY go into the OpenSim.Scrip= ting.LSL baselib. =20 Doing this would be a good start for further extraction and refactoring eff= orts. =20 I'd do it in the blink of an eye, If I knew somebody would catch the refact= orings and validate them on both engines. Best regards,Stefan AnderssonTribal Media AB Join the 3d web revolution : h= ttp://tribalnet.se/=20 Date: Mon, 9 Jun 2008 19:41:33 -0700From: cfk at pacbell.netTo: opensim-dev at li= sts.berlios.deSubject: Re: [Opensim-dev] Two sets of LSL function implement= ation files. So, how do we evolve this mess back to sanity. At this point we have two co= pies of the LSL function implmentation. Some folks are patching the Common/= copy. Other folks are patching the new file.I looked at the first 100 func= tions (there are 300+). Some in the Common/ are not implemented. Different = ones in the new xengine fork are not implemented. Most are identical. I hav= e been here before with a source code file that gets copied, renamed, then = two different groups start morphing it to a different place. It just gets w= orse and worse.Charles ----- Original Message ----From: Justin Clark-Casey To: opensim-dev at lists.berlios.deSent: Monday, June 9, 2008 12:49:33 PMSu= bject: Re: [Opensim-dev] Two sets of LSL function implementation files.+1 t= ooYes, let's make as much code common as possible, please.Frisby, Adam wrot= e:> +1> > > > If we can avoid duplication (and only splitting where the en= gines > themselves differ) I strongly agree.> > > > Regards,> > > > Adam>= > > > *From:* opensim-dev-bounces at lists.berlios.de > [mailto:opensim-dev-= bounces at lists.berlios.de] *On Behalf Of *Charles Krinke> *Sent:* Monday, 9 = June 2008 1:43 PM> *To:* opensim-dev at lists.berlios.de> *Subject:* [Opensim-= dev] Two sets of LSL function implementation files.> > > > We now have two= sets of the implementation of the LSL scripting > functions themselves.> >= The original one is :> > OpenSim\Region\ScriptEngine\Common\LSL_BuiltIn_Co= mmands.cs> > The new one is :> > OpenSim\Region\ScriptEngine\XEngine\LSL_Sc= riptCommands.cs> > In these files are implementations that are duplicates o= f each other, > such as llSay() and dozens of the others.> > Originally, th= e Common\ directory was defined to hold all the LSL > function implementati= on and I concur with that decision. In fact, I put > all the prototypes in= to that file for all 300+ functions.> > Now, we have added a new copy of th= ese functions and they are beginning > to diverge.> > I believe it is of so= me importance that we put common logic into our > already defined Common\ d= irectory for various scriptengine > implemenations as we move forward.> > C= ertainly, I am not advocating a fire-drill, but rather an evolution > back = to our original mission. This is not to preclude any functional of > Xengin= e or dotnetengine, but rather to concentrating on resolve the > current dup= lication of code from our Common\ directory.> > Charles> > ________________= __________________________________________________> > > -------------------= -----------------------------------------------------> > __________________= _____________________________> Opensim-dev mailing list> Opensim-dev at lists.= berlios.de> https://lists.berlios.de/mailman/listinfo/opensim-dev-- justinc= cJustin Clark-Caseyhttp://justincc.wordpress.com___________________________= ____________________Opensim-dev mailing listOpensim-dev at lists.berlios.dehtt= ps://lists.berlios.de/mailman/listinfo/opensim-dev= --_dc5ebc13-e411-4a88-abab-c358d094219f_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From just glancing at the code, I see no reason w= hy we couldn't create a shared LSL scripting lib (I suggest calling it= OpenSim.Scripting.LSL in accordance with our recent ambition to remov= e superfluous namespace levels)

This project can then hold all types= (or extracted basetypes) common to both the DotNetEngine and the XEngine. = These two projects are HIDEOUSLY duplicated - even the LSLTypes are, which = would DEFINITIVELY go into the OpenSim.Scripting.LSL baselib.
 
Doing this would be a good start for further extraction and refactoring eff= orts.
 
I'd do it in the blink of an eye, If I knew somebody would catch the refact= orings and validate them on both engines.

Best regards,
Stefan Andersson
Tribal Media AB
 
Join = the 3d web revolution : http://tribalnet.se/
 



Date: Mon, 9 Jun 2008 19:41:33 -0700
From: cfk at pacbell.net
To: opensi= m-dev at lists.berlios.de
Subject: Re: [Opensim-dev] Two sets of LSL functi= on implementation files.

So,= how do we evolve this mess back to sanity. At this point we have two copie= s of the LSL function implmentation. Some folks are patching the Common/ co= py. Other folks are patching the new file.

I looked at the first 100= functions (there are 300+). Some in the Common/ are not implemented. Diffe= rent ones in the new xengine fork are not implemented. Most are identical. =

I have been here before with a source code file that gets copied, r= enamed, then two different groups start morphing it to a different place. I= t just gets worse and worse.

Charles

----- Original Message ----
From: Justin Clark-Casey <jjustinc= c at googlemail.com>
To: opensim-dev at lists.berlios.de
Sent: Monday, J= une 9, 2008 12:49:33 PM
Subject: Re: [Opensim-dev] Two sets of LSL funct= ion implementation files.

+1 too

Yes, let's make as much code= common as possible, please.


Frisby, Adam wrote:
> +1
&= gt;
> 
>
> If we can avoid duplication (and only = splitting where the engines
> themselves differ) I strongly agree.>
> 
>
> Regards,
>
>  >
> Adam
>
> 
>
> *From:* opensim-dev-bounces at lists= .berlios.de
> [mailto:opensim-dev-bounces at lists.berlios.de] *On Behalf Of *Char= les Krinke
> *Sent:* Monday, 9 June 2008 1:43 PM
> *To:* opensim-dev at lists.berlios.de<= BR>> *Subject:* [Opensim-dev] Two sets of LSL function implementation fi= les.
>
> 
>
> We now have two sets of the i= mplementation of the LSL scripting
> functions themselves.
> <= BR>> The original one is :
>
> OpenSim\Region\ScriptEngine\= Common\LSL_BuiltIn_Commands.cs
>
> The new one is :
> > OpenSim\Region\ScriptEngine\XEngine\LSL_ScriptCommands.cs
> > In these files are implementations that are duplicates of each other= ,
> such as llSay() and dozens of the others.
>
> Origi= nally, the Common\ directory was defined to hold all the LSL
> funct= ion implementation and I concur  with that decision. In fact, I put > all the prototypes into that file for all 300+ functions.
> > Now, we have added a new copy of these functions and they are beginn= ing
> to diverge.
>
> I believe it is of some importanc= e that we put common logic into our
> already defined Common\ direct= ory for various scriptengine
> implemenations as we move forward.>
> Certainly, I am not advocating a fire-drill, but rather an e= volution
> back to our original mission. This is not to preclude any= functional of
> Xengine or dotnetengine, but rather to concentratin= g on resolve the
> current duplication of code from our Common\ dire= ctory.
>
> Charles
>
> __________________________= ________________________________________
>
>
> --------= ----------------------------------------------------------------
> > _______________________________________________
> Opensim-dev = mailing list
> Opensi= m-dev at lists.berlios.de
> https://lists.berlios.de/mailman/= listinfo/opensim-dev


--
justincc
Justin Clark-Caseyhttp://justinc= c.wordpress.com
_______________________________________________
O= pensim-dev mailing list
= Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman= /listinfo/opensim-dev
= --_dc5ebc13-e411-4a88-abab-c358d094219f_-- From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID:  
Doing this would be a good start for further extraction and refactoring efforts.
 
I'd do it in the blink of an eye, If I knew somebody would catch the refactorings and validate them on both engines.

Best regards,
Stefan Andersson
Tribal Media AB
 
Join the 3d web revolution : http://tribalnet.se/
 



Date: Mon, 9 Jun 2008 19:41:33 -0700
From: cfk at pacbell.net
To: opensim-dev at lists.berlios.de
Subject: Re: [Opensim-dev] Two sets of LSL function implementation files.

So, how do we evolve this mess back to sanity. At this point we have two copies of the LSL function implmentation. Some folks are patching the Common/ copy. Other folks are patching the new file.

I looked at the first 100 functions (there are 300+). Some in the Common/ are not implemented. Different ones in the new xengine fork are not implemented. Most are identical.

I have been here before with a source code file that gets copied, renamed, then two different groups start morphing it to a different place. It just gets worse and worse.

Charles

----- Original Message ----
From: Justin Clark-Casey <jjustincc at googlemail.com>
To: opensim-dev at lists.berlios.de
Sent: Monday, June 9, 2008 12:49:33 PM
Subject: Re: [Opensim-dev] Two sets of LSL function implementation files.

+1 too

Yes, let's make as much code common as possible, please.


Frisby, Adam wrote:
> +1
>
> 
>
> If we can avoid duplication (and only splitting where the engines
> themselves differ) I strongly agree.
>
> 
>
> Regards,
>
> 
>
> Adam
>
> 
>
> *From:* opensim-dev-bounces at lists.berlios.de
> [mailto:opensim-dev-bounces at lists.berlios.de] *On Behalf Of *Charles Krinke
> *Sent:* Monday, 9 June 2008 1:43 PM
> *To:* opensim-dev at lists.berlios.de
> *Subject:* [Opensim-dev] Two sets of LSL function implementation files.
>
> 
>
> We now have two sets of the implementation of the LSL scripting
> functions themselves.
>
> The original one is :
>
> OpenSim\Region\ScriptEngine\Common\LSL_BuiltIn_Commands.cs
>
> The new one is :
>
> OpenSim\Region\ScriptEngine\XEngine\LSL_ScriptCommands.cs
>
> In these files are implementations that are duplicates of each other,
> such as llSay() and dozens of the others.
>
> Originally, the Common\ directory was defined to hold all the LSL
> function implementation and I concur  with that decision. In fact, I put
> all the prototypes into that file for all 300+ functions.
>
> Now, we have added a new copy of these functions and they are beginning
> to diverge.
>
> I believe it is of some importance that we put common logic into our
> already defined Common\ directory for various scriptengine
> implemenations as we move forward.
>
> Certainly, I am not advocating a fire-drill, but rather an evolution
> back to our original mission. This is not to preclude any functional of
> Xengine or dotnetengine, but rather to concentrating on resolve the
> current duplication of code from our Common\ directory.
>
> Charles
>
> __________________________________________________________________
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at 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 at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
--0-240244063-1213105201=:37311-- From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: =20 I'm working with Melanie on solving an issue related to the script engines. =20 Intro Currently we have two script engines, each with its special purpose, that have very much in common. DotNetEngine which will assure that script engine does not bother OpenSim. It does this by queuing its work internally on multiple places and processing queues when it has resources to do so. And XEngine which prioritizes script execution, more suited for applications like gaming servers where for example the bullets needs real-time execution at any cost. Making one engine that supports both will make the engine less efficient and more complex. =20 When DotNetEngine was originally written the purpose of its "Common" component was to provide a common base for script engines. Though it very well could serve its intended purpose there are some problems with it which lead Melanie to rewrite portions of the engine. This is a positive and very welcome step in the evolution of the script engine. Believe it or not we were not able to foresee all usages when DotNetEngine was originally designed. =20 Problem Currently the two script engines share most of their code. There are relatively small differences between them considering the total amount of code. This means that we have a lot of duplicate code to maintain. And without a proper interface/modular system a patch that fixes one bug in one engine may introduce a new bug in the other engine. There has also been some concern about understanding the code of current DotNetEngine. =20 Goal We want to support multiple script engines, and development of new ones. It should be easy for people to write their own script engines. But we need to ensure that the code script engines has in common is actually shared. A preliminary draft has been briefly discussed and put into a picture with boxes and arrows. =20 Basically we do 2 things: 1) We cut the engines into multiple modules that provide services. 2) We create a place for modules to register their services (commands, events, schedulers, compilers, etc). =20 A script engine that starts up can choose what services it want to use (if any). This will also allow us to create new engines which do not necessarily rely on LSL commands, LSL events, current scheduler, etc. And third parties can provide components such as compilers, schedulers, etc. It allows us to run experimental development of parts of the engines without affecting stability for running grids. And if we break something in LSL, it's just a matter of sticking an old LSL .dll in the bin-folder. For example if someone were to write a lexer for the LSL2C# converter it could be provided as an alternative compiler so that adventurous people could test it. =20 Hopefully understanding and maintaining the engine will be much easier for other contributors as each component is fully isolated from the engine itself. =20 So now to the hard part: Should we call it Script Engine Services (SES) or Script Engine Component Services (SECS)? =20 =20 =20 In case you are wondering. Yes, the tube is angry at the square. In fact, that is the only reason it is in the drawing. =20 BR, Tedd ------_=_NextPart_002_01C8D00D.200DC7A3 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Good news = everyone!

From now on there will be lots = of SECS for everyone.

 

I'm working with Melanie on = solving an issue related to the script engines.

 

Intro

Currently we have two script = engines, each with its special purpose, that have very much in = common.

DotNetEngine which will assure = that script engine does not bother OpenSim. It does this by queuing its work = internally on multiple places and processing queues when it has resources to do = so.

And XEngine which prioritizes = script execution, more suited for applications like gaming servers where for = example the bullets needs real-time execution at any cost.

Making one engine that supports = both will make the engine less efficient and more complex.

 

When DotNetEngine was originally = written the purpose of its "Common" component was to provide a common = base for script engines. Though it very well could serve its intended purpose = there are some problems with it which lead Melanie to rewrite portions of the = engine. This is a positive and very welcome step in the evolution of the script = engine. Believe it or not we were not able to foresee all usages when = DotNetEngine was originally designed.

 

Problem

Currently the two script engines = share most of their code. There are relatively small differences between them = considering the total amount of code. This means that we have a lot of duplicate = code to maintain. And without a proper interface/modular system a patch that = fixes one bug in one engine may introduce a new bug in the other = engine.

There has also been some concern = about understanding the code of current DotNetEngine.

 

Goal

We want to support multiple = script engines, and development of new ones. It should be easy for people to write their = own script engines. But we need to ensure that the code script engines has = in common is actually shared.

A preliminary draft has been = briefly discussed and put into a picture with boxes and = arrows.

 

Basically we do 2 = things:

1) We cut the engines into = multiple modules that provide services.

2) We create a place for modules = to register their services (commands, events, schedulers, compilers, = etc).

 

A script engine that starts up = can choose what services it want to use (if any).

This will also allow us to = create new engines which do not necessarily rely on LSL commands, LSL events, = current scheduler, etc. And third parties can provide components such as compilers, = schedulers, etc.

It allows us to run experimental development of parts of the engines without affecting stability for = running grids. And if we break something in LSL, it's just a matter of sticking = an old LSL .dll in the bin-folder.

For example if someone were to = write a lexer for the LSL2C# converter it could be provided as an alternative = compiler so that adventurous people could test it.

 

Hopefully understanding and = maintaining the engine will be much easier for other contributors as each component is = fully isolated from the engine itself.

 

So now to the hard part: Should = we call it Script Engine Services (SES) or Script Engine Component Services = (SECS)?

 

 

In case you are wondering. Yes, = the tube is angry at the square. In fact, that is the only reason it is in the = drawing.

 

BR,

 Tedd

------_=_NextPart_002_01C8D00D.200DC7A3-- ------_=_NextPart_001_01C8D00D.200DC7A3 Content-Type: application/octet-stream; name="oledata.mso" Content-Transfer-Encoding: base64 Content-ID: Content-Description: oledata.mso Content-Location: oledata.mso AJAAAHic7NZlUFxhlydwGgju7hYCJEGCaxonWCC4WzdOcNdGAsGCuzvB3R0ah8bdIQSCuwSbfmdn qt6aDzv71u6Xrd3/rV89t66dunVO3bqTE/ibuTUUWwj/JUAEJITnF3QElH86BvgP/x48BPj5l5d/ 7P7n+o+8/P/8X5UnuH/0DwneO2S4V3D/6DkqHBocOhwGHCYcFhw2HA4c7v8YAQR8OAI4QjgiOGI4 EjhSODI4cjgKOEo4KjhqOBo4Wjg6OHo4BrjXcIxwb+CY4JjhWODewr2Dew/HCscGxw7HAfcBjhOO C44bjgeOF44Pjh9OAE4QTghOGE4E7uO/zzYCgiicGJw4nAScJJwUnDSczH/M9P8LUUWwh28u8F5I I9jBVycEz//6KfifhgQ+Mf/5LMB/cy3eDyA19uQQ4J+/F0bwDnLBu8ULX/nhXeSEd4zzX6hPhoAI +Of3+V+5BxHuKexfKPLf5F+t/386/1v1LxAQPDKO0jy1CRe6XiZSU7+ymr9hCSTnA0j3nYSjhzaD 8EIVykLYMBhQdMpVeelycqZz/DWlxQNKZ8M1Kyo0eirkK2wMWi378rTjNOOGSntXCSdPj0+9Ty9X b243fLO8fQxNnbi498YEsy/v20Ut2r2/r3icFRgQ3jVxvdrMyQYB/hodbAqjYKAiHK3d+oXnrWup vWg9ayUCkc/tcES9bq2ynFECw4zpWfGS0N5/4wWhBX60RPSP2KS/QwP0otBLLTKEMITQH+H14d+g oULRvqGJM1DhK6FZfMPsJeYk2Apx+ORBJ0Mv81oEH4wHxgd9I+2l3Ao6k76jf8QHhDqGnoeih4aF yoUOh3YDVlDEAmMYAvF6QktC8aA8UiwgIRAKiAlEAuID4TAcrZENT1oIgGgYEPHDQiWG8C/xMfEw 8SPwaOmAUqwyrOKs0ix4U6FkUqwMOPjRXxiS6JNeE+CFhRKHMkLlpbhAxBLBsuLlMgUM03h/QrGg ae6+Ry+Ul7QBJwUSWnH7w1q5E+rVOI/xDMj1kArPOlG8RROk6+sg0e/P16ttIWKoh238dFFRdWc9 Qmim+y0JLz/Hu0gw/Xu6gBMbHUoI602ixB8hXBQK5GnfiV+afWmsN46Qxm32TxvtgaLHa5zPlWup llfJ2GMHovYv2cAuz/2Nh+tn98ubdcNn2N8XYbdryC7kU0CQyePL2xVgKJdSbbVWF2/U1LG6aebo s1wrwZjgCyGC1p8aAQF08c5rDa8OBb+tshU8HSQ7TsuHl86b8WdRVk52jcQi3SQlmLKignosfQkn 7ZtKXSAeN4pNe8egV2wsOufbkfoAS64vwjdrnuCODvHBbxxaLw3eqZlCuY9smhvx4BPSWnObmCdC Mmvfi18DnQsbwT+8//q3VTjMypA98Vm+IUcQ6BNPuocep0MoXvJYx0/6qjQb1+46Xa7ObBu3NbKe EjyPn5PpyVj4B/28x7ynC4wiZunEZ0SFdmzXtscaDwIs+PWlIxhJRNHHF2Ze0g/HeRf79HBHB3D2 iE7NA6eyOgbHz4Nv7F2lLRF/d/dcm91gTp1W8j74OWfwPrg4l48jBnG6PrQ1aCOi7NiTk0V2aBh/ OKHxbpJR7tKrCnQnfIwki2yDtj13iGZFMyhSSATnZWNI52L9wkxEit08JfZ2ub19hn5FguxRUOS5 DW6eQxpf1pGK8migOTfjrmXPg96CuTcv1hOQYl9ELOvYnk4pHJG6ls/ORw/FHQ6fnhceRcwh9+4r 2REphM+dTxDaW8h89vkL7YT9Ccde5jBOpfjtzw/Rtwozy6Az0tEewZFgpJoL62l6Hy/8WgWBn+7r yajKxc9Nto9nyV5flSZGAoLIp5BUXha6Mm73dDPx3S25cyv3EEpHpTq8wMbdNK9ZhqbJg6WS8N7G m9BFIF5fX+c0NCQiNtmtIRYrZVqjet+euEodgsgbvpKjYWIidSZUcVTX1SEJl7RtGWsdU38pbl5D VhIhBiGpXkHeQfaoWjLXxVKxkryCnk6r3hm6f1j0kkyuaXCej8AB5a3j5fGL4e3iQiCJZlwwU8gQ HznlhkffPAx5LQInar36i323mPr6lw7xUl89RIVJjrM7Gh7iO+3AIv5JmyuUkPXuWUptryDpH9Qm hfzah9iSVyh8rZ3NhZ98kOIlFzE5+kjxkGrwRI7cN8Ut6H+zQsHu+UPl3L/nCIV2svxwNt6rOfh4 qRU5V/5iMJTrwqkRfCRICQro743l66Gy1+PFNdKXox1mBnFqASrUteU5iLnkg8fsm61pbIrAP75Y rPoQr2F2IRb4VIbTDDQ5he3F02z9sHcIgiqpg0SHbxK6+39zcUiM5x9OPZGtiKSuiCi4SFJ7kCy9 Zsv8RLOttwbZtzqOxgnZf4WCTtK74hT0YfFMEAaqYYxUluvUEXG7Hd8b10VHF8sfnqQhshsGWtSo nE0SAq+gk0aPuSvWjlE2HmJho3n+Rl9xjmtNEjG63Bdwqxa7vyJT+cX9IjihWzRT4/qaPC6P+4c9 fTQPte+BcUNY8IxVIdipTDXXtcRBtiTmR6eDfPCqKn2V+hBubaqOK+nHdI61lpYm5WADE3w1hkJY D6HeZDV7KOApHO1nAli+hUprBL0woyhhJvHiawhXu6qb+QlHrahEa6Q2I3NrUlno5rtdERcGo7ek LLt88i1f3kIsyxJwK+Jw3xMv98PM8cdj+1YmyZZmmHh/AcUqnJ7MTPhyuA6ZexMH9hRTtRKbvVQV kEOtIyzD/PmTwPxJO7b46S4Dfcqhc+hqv+eqJskn/vLmYbYJ+sSVF0TM5Sa6MHHLdqhTH8i0Yrx3 UsW5p2mocPlyGWpwaCUZtTwDTm2TpC1WFz7VNRpZblgHLXiN5jcK7QRHWeyzMy8wUjDeP2b4+OWw 2tYGHSsZdeTU/E6lbXQT7hyPX/wtV7b4u0VDn/tR+xvMYypK0J7wk/+b96RWQ1t7AmXJ3XmfnayG ozyFwGu0+3ZVPRRzaReCfBj91tJReeqO2rGuMm4G8zmTo39Nj6RxRAKkSyaZhorWxaROr/Q9XqlO C76OoNz27XRM/OU7VX04JLLx8CnqK9AulanL9+weN7uCDaLT1kLlo2uo5tf56OYJbinJENgHcQep HaoX/nbsfDrCy9ZzXg9qoqQ+6xLlEAgH0i7vwzBtYCvzGbTyIaulQCgt30Erj1/yuAPPn5tCie+q W6F06ZTUyL7NvyoLzpTu3euAWI7tiBn0ZaZLxM1W22sWfm1P4pcNfc/jCzAGnD0dT98W15DEZCZo f8jWWMPfuGHh1xbnMO0zmDZMuM+RhH1zoJbJdyBlZGOp71tLVjhHveuy9zKJbXHSFLB2D3P1L2c7 +tbrsbIlFK/G7awKKNiDWsnqPBDW1RvMVihPZZ2rpTD7dz7aaPNQL4z9zbNBx8Pi3qBel0cArf2b ciUDH0NAplGOs0uFLYeDwXvO9YCXv4JS946gj46v5I0oR0NZNanZIEsRUXFJWa4qZtF1ZFT8m64P k2/vG5gHrZ5dDZUfdMZYvZ65UAHnuaw6RVkHpYknKZoH+pO8kg8Bmg4j4e4DA2nu5minWOnueQez ewYqxUqQwz96767eE/+1iM4gd/hpwwiRsBw7TCG+2DvpnOUpvfn8J/njzihNdPIRBZvLVWavt8bM kycpcoAKalv2rB/rX1lVuiXmexB8nqr5Ps6EJw2fvVSowMasI7R1B9PVUOvBfNm+1PFQ8pm/mA+4 N2EL90Y3poxpur2kimv5VDZEFJLsUBlegcAsAa8RQs6P/SN3TorHlLmxTTXcucLr3EO+Lekiv03t my0mraMVKlMg58kfwQ9OLWfTZg9IsMLF+k9ZzEaDLr9330SeT3A+iGI7+bcYGX3Wec0DOqm5ty1a 4Exv2Sm+3c1SxBEk59clMnwoOlGd+cUWMWgkVLP7kFs7xx0nuZ5hnYT1GrNu/+2xeLrUitSDtGnF /vSZ8QRQrYKQzWXZAG1A9e32ZxBmG3i9TxosRYDfmFv2Ijkl108cbFzF1vgJnWaSAso6lw2Sp2pO uWrikiAtfhWhwO+mS95ByNEyICcWYhphGv3LefjVMLVc/K9E5EnTYQzcJcZUIKjEJhqUTJFQeDIm 0Akz4uX5Yska2zokPne5ILdR4l5aqm5UYleeQZng2VGnqHMEhvi6epH4KcYVDa/4PM3xLUm7VpQT IHmmQ9A8m6m9m6lRcZse2bss25nYNXE1fqjqKPizGGvO7MkssNx6Mntb8LL5KkmhGPJMI6fFpp2n 6aTRxjO3Fj7IDqh1N2q52lxK9Tnc/cSMaGhQaSvpQb7+ek3gGsraKSRd99bG4jiMuP+B18iG3eoD 6wyG6LpddJ7c38RS148Aunyn/qyLIZTq57q6hUpXEevGYM4vJ+ruJ2o9w1iSmn0Np4chRCLWgl55 F2WfxrX7p2byWfj7kaVdIAf0/IF/dFNnaiZa/FA15DJzK7vQk2lrmQkqhzMpYL4U4iRBQd4j7Mq3 Rss+JoPB1Fqdq0YjZdYkaDQ8fCsCwGp+AwdTmPW7NsZ3r6G73+c2fupVBZnEp8pMBElWeXnZUKTI PMDK83c3SCas5S2XV2bvHpdpHPufLix2Dd5wtEEUs87Bc/rWd6fFdXtMciHOMkY35R0NgkeeXaMd G4qebB7mSu5XY5PEhe95jepJrdDM1wyTGyONuhZEptpn/S+ivDUeMpixdnF9l30iEPuWf0wg1Jct +n2YUlf3/nlzJV54QiQ74jVP7btfrEDshyprW6+BFyoM/oI4Uv44JoxvoWnIVaAknHBv4+5yw6GZ 7HcSVUll0kz6oI4IShc/quhNom1zIzVrIOJ9o5UpNHseUDIg0JLUKtWPIQb/cWxT/yocyhuYtGgh VPpTbi1yUFU/JgQynWfHNF1ORDpdtsqLnX4gD1sxq3Tbb6mnZ2sK8+Nv2F4t7uPwtTPT8XCcD1D+ bqZugnqb8OIA8BZocbx3r/fxA0JCLdMsKYd4y11zIk6K2CN6isA6dRFZ2QIlEIGLn2jtRGs6g+1g 98FLWMLKbZkTxHQkHVwZ+UegqjXe90HjsFN4MVctKaJ29liYoquz1onRAmgVg0sYTaKsBhX2bZfC pxse0STicLAv/1LfQKrAgy2XMdYgw8n+tjXWyCXI7dRZ4WxQZLkDfXlp+Y1uIp+eXvmrueW6ZZTj qmXRhoSklZNVnMeV4iYOa2XrjclKq88/x8tN62I12+M7K/giSp9WsQdqD23Krsz2sg+JosyaVihX Ph9LGaWOrwjKby4JfhJscVa6sjv0aJs5Ol2kmy9MXmN1wguT/lEqG6uKnPXz7sA3j0PKNc+bIVVI HptsO4IlCjncbJvMMU1AGcstIjqc9J1dWMM26YFhww/kZjkmWXOFJFl1AlViA0M2gJHNGN9F8TeM X2vC6bbCqCC7WvTapdqs1+i1iktu5AJ0wvRtrN50NonXQ6xEfjodDRZ1iKrtsPOXn8I+wqwlQtP2 +PiMRk7lRw23HRj2ANO2Xg1exi/LAVc2Ra9ei23vGd8XhF+lZyYuHmyj1NYtTzYR6SYU+Ye3nyMK QMtgieeSkKGD7dLs91i+EesMK+gVnH/n0eiKq9nbe2NOkBPwnQ+1gn1dT4jaXc77zovALmmWhsFd CE7Xrvj5iMqmMXTPyQkaM8ra64/5nXaOfDL1c4WBVhsQD8GL5ISxjqKVIr8J52Bhy5Uvtmdo1SIG jvd3DSrBwvtT86SnLur6951lL834YJnLVVf3E8OXI039LRySTDef9T3iAETL15MyBvxQKmYV9hRV E1nqgP4t48yLqPPj0jcLYERVKL52HnqW91cNP0VHx/X5z3pZcu6262npMD8ftPZV0DjQW/BlL/wp +pT9b03rx46OrSUHh8usBmu7lqaROKcc6OxOEsdAZkcvTuUHaElEEqkBP2u7pt/5CobPy04GdI0Z qEWrmmno+Y7S3UMXY0906dUWs8Eis8Eds4HTdjz7MrPBlXJryr5/g3XDLu8M8RznNaZGFYZ2KfUs yDXGC0OvZGDplXW18mdw2dLt7P2u9yh5mgnFB13Cn7FWIJ4hfhs3myg7QJI4s8f4LvXu1XJuQ741 80JgS8NUQ0lDS0ObdfRsVtlTbuP3Oo9RuZ0ewB+/N9zu5RJCL5QqwSRHSMC729s/nQv10Q22y6OM XdTNii2nvxdPVthpkgkvxSpVcqX2E0p35gCUkWzG7rcedeKkejgfLTmPeNyKvvJ3hqKULlksYdc/ 1WcvwTCM2touq7kW+uXUdhgxXkm6Nq9JihMw5A4Z8KgQ9ekR0ofv6XgNB9csaEY4SRXm9TE4iG3v 3F5GRcAgoX+lqWriye7CJPsx+99DD/uzQ99DjcJTtfqjocsTQW39rR5Rpi0HMk4hQk9nE2oTwbQx UdaFuno9lgn1AXQPr+Kkhgfjowwo/Pjy/vxyLPMewlUSwE/2FP3Y04Hq7bJ9hNazq1nNxHyAmr1d PEy+B7QUEvQs/Z2nD3ZzVt7mrYF5iytE6TqDMp6a4vTi8CoY00Qzq6pjliZq3n/At9Ea5OuRLhEU TmeA1uZi4L1VG1FKIB26GY5KbErYiA8g0SmOzMWba51FeWca/lc3pmhI7WqBRsOnrLlw8l0khn/Z V3W7UvTSpdI3pSrxth62TOlJNN+ZURCiRmc8LyYDWPE+oW+cViV1nCA0T/F8+6wiBG4eaj3/IUiv mNLrMkUJZaGUGs7SQBCGSuCoXNzmgS0UlJUBMsOSlCttG1e2Pn1JNOZEBvaclcdZPioX2BXsswxV 7HfGzd6Jv5gyzy7N8r35Ojll05Y+V+H+kkzAdsao7rt61sn3nFyheQgBxkYbFUFW7VUQ/tQga/eQ coMAKUPMdnlG5tMXMQddW5b5/GMCoZBPaCfynQRreDc6FIwWmxaIMnw/QOkeGt8xUiQvxYktT46Z OTWppvakB20v6XM5/GfP9hMcYjDUXelwWMR1Gf/ooCYFYFXLyxQdioPIWqwBqTgga4bhglemDrVq eZFX5fcz1VyRj7IyTIzxJTvgoeCoFlgWHTBV/09zN2HB2I0+vgwTO/3uyFKBRa2aboratnjx5/PK Gtq41KjrKBUYL5jB1fHX8itThN1aKsbD0kxzCY4lRCfEs7Sto7qsfO53l6E+ll0JjjslDV0QZ3sl BWUC3KFUZRO221utUsTeI98G+8uo+isfV7xbhyuHq54ti3sECVwt0ixJAMlxzzKj4URNxlgEzVYK dOVHv6oV4iPYjiCajBpzBrn+ba5L16TiejkjjbM8i438pB4tpiIKco+IXUjnuFSnRMhZ/bhUogr9 R4QPWCiBbKZtdb6WQ2jhbzFuvo5+T8uwsxaOER9al99KMQEKB2QOr8OA3cCedY/UBuov6jhz7oip eBTrZGJsn9TScQjEQmoXYuYtQgFvE6wCMMq9wF+ub6BdXNTPaIxO4tGchTMFVNgDB9iOCfTYqPmW mJMuDuKrlJIMlDOfvxVM5XB1qWqX5GOBEXvkcXkc5d50MNFHOiKf4yn4g/fXTxs95C3aV8b3xdYW S/nxvJDKxk25nCrIx25wLObr7CzX19EK/kSGoXMIaTtcEI19nUA1qLfXiQlWBhl7IQExKRfbJikz 6C+lP+11JtG80PkDPFl4LbcTCl7CXdsYr6hGrmnzTV+YPj8kuBmpUtMYD7+FVk4+pIp4QEI/3sTY jQ5C8m8xu959k5LBD2WCQOaalSXSYcVmCf6hJiQKmLE/kGIGLEwxdscU6d/HC7uhQi2/kCHTOw6F iBtLn/FA/NBN/blo/GRl83vGhV4j0RA2nlVe9FavEtel4ASnrG5QaHueHdT+RqA7XiB/r4ChwvAQ urtqwaXoenSasrVtr/MhkpQtFYOFWBZwOInlyhy4q4J0Olx/Yin1kUuOlu52WRHFNM6kxFQfo0Xv 1bRmzOi80BuhIpkKxjJq8Hxc2PshDeyMN6ZM5Mia8/Gm4W0ix6XxF2qqqRKVnlLP5Bvdh6SkoKn2 +6cSUwqxLIxvB+IOSMzsGIxIn/gcUJ7TMzGoRGWYNtw8UA8YRSexEQ8NvCz2zXaMgnPTcrK1aUya x1Klh1ax4nYIyRjppj0luYK/Jiuyj0zd5jjL1EKd96Hp9ELgfr8rXsA8CozeTZLOltsWGPoOkXvF x6Q5X4e74zo5RLgKU5t0cnTkDP31RWmqL8y2E+g8Hq4NToIGkNla0wfwGlE1OWGoAIo9JOlQ0T8A +G41u2VefG56HDmjTioyC+J50VPJ3DKojtVbXUm4S8f56xucoT4pE3hju2ZOlo2BHoabPj6Hdq2v gr43nZF8+mayEtix9hQi8zGv7T0TLIjgFdlxvXlW/ktRoe4yUPosL/9SrPSRNP2z09TjBhEhsbZq 4YtKdm64HM9Nx+YsneU52eytfWRwi2M10KN+Bs/+1qWSoN5NtyCuRficzpJ29K7fHLGMvdrUXmGi t9ER+U5A235ztgXgTLIb49RpaiBmUwwuNVojOuVTo+ToTbw21lmDEnMPMIu9iW0TX7tjKgH5pP3V u46ImoP6BaKsgclxH/WErc7EGRzdi2DNxYXFpPNBR1+Q1oDCPMJE/k1bSp6Ot0GhiidYNJFEA5ed P+oncPJ7QlfC5dI+fB6cbWlH/vxbc3PvIOsh0E/KWTXIh5cj3vQ5jnmnCGPTDvLw9RNknO/oTUeq yol6VC1K8Z/Y/MzAONy8G5vZY0o9YUpdL8v801efErtf7xuRNWYNnDvL7xU5U/t2pvV/w6v6GU0E fVByTbQQDjojkmUvkvvoU23JMMVpy2Z1zcncjRoNk3j923dygrj8EqfU4MvbCRnM6r87OYnEX83R hgT43p2G5kMK7HcClgnnTKw8PsygR5gvSYk4qT45sJzExk+e7gVNv65GW2ex9zreW+7MxnyXKl7P DiZzcyG57LZuB7V+Ag9ZOPrV9c+kyqnlV+izSRS+VshQ9XMU+sMC7OBsxIl+Y6WTvmoQ5M33IdVy ubNCfwYSIe8n+DodQOrb1xhOzO7+kUB34Wp5KluxUg0iLeSmOEep5N1mH0nopt6msLtUDSvmaBy/ gv2xPDxAvSGBdHD82Y/xWbsttWPRoJU8/phfcaji7dfK3/P8Kcz/TgPk0H0YE13W933uYUrI0HUh ePIK4yc3zt2d59MxU+8jhNEJAYf+h+3ojbEy6HsN8dHb4XI2IlMbvhqFxSfvHk0Mtz0/5Ae3bOQD kXekxsflH1s2WZ2eW6wxkva+pGxhJGVCIirMKJfuQinH7MNsJSm7adxybIGFdHQIQ8T5xjnYyGCE eXMvzcIFWReZkUcMC35XtztcOUrFmk1sf19qhIRfTG/N5T4YeTpzODX7ykZKHVcNPC3R0jvb8Isg wobK3C3DHezZETJNCMYk7O/y68hOV5uRfagkRcd/DtDesAOGlr6TfT7/Tqu146vQ3aF/hvaVrILf XGOrKVi1nZnseZ701cey946AFRL/hPyr6XMk/MDz0vxxUwMkNEULIl1CFr5FkBvyZdh510+GO0Pi tafkd737CJE1xbhS+BIPbvg+1WiCOAVhTuPCOwn6Fxwa34iuvDVcnMSI5VA0poi9AhvWIqIAKleY wsPT6NoE8SuKpVi/CRrD16bBQYHPtR8FnHbJ9WkfSYic6cY2p6ubkiw9qG7oyjKF4upM5sSjCFrO r2IzYOoduV0pSB/IqFVH1/rrWAip9+iDa1CFQevL9x5oBKQk3g4U4S7crN/+lt4W1WCmytA38Ch8 VlHPTDsYnJtdWUjKGSTIoSWnJqo8OTH+2dY2kRAvJkWgY4ylZKt9ap8IWvksPQH1I5QIDycZRyWQ V7AdyjXm+ZY8NkJvwaZufyjzmwiJR++t0LV1exVH4bqQcaBA4dscloH3PD8FCu04ciz1gIBItiE8 XkEiyfGTpwq03ypfDAA8OT7K+OnTs/5OkctB5g8smYjZ/nVYki9mKJW5WIKdZ0pKUadF9h+Aq1jh 6I8YQ/6e/Cb4OXyJSB5E+sia+oqMeFb1CfY1VVA1S2PXU0AcvgSSht1+NmytNilLQiVkzyYC4Pt2 D10XkKJrOwRYYQExFhvUZTKg5awr6ewdoRaXdI4PycQ2yyGrU2DkOoq9+lXGEnTxg75jImbZRhsP iYtMm4uywJ3il+PX6mny8kPeghtyF5GfR3z92ywXfupBSG/M6MjpAKi/ftpJIlIW3BGEYZ21Rmei DHRqcUP909A5MUkFWMxjkmLT+rEwcazJGc1g1Vchw0Hm+wSVvm3I7AGE2uacQfiFQaCQXP676ZsO uz/nJqn9keo/193Ybn71NsW9x7re1MOcQfKSWZPMuwdUtLCLdG9jmxuFmtGZET8x9YX39WT3g8Q+ T2Bw2WAx2QPGqn85VNge2WLmog7sYW/hE37fBq2zrN9uIeKocprFBEspXpy9zAIxKd7Uf8v1aI1p jCW1ShK7f/01BvGgEPIhULQAjwt0ggu2trV2GXiqS8mm07icpFihayAHx4k1ruGwMhoIwLAvHeXr sCmQZoJ75Oyao2cAK1jumTXlMZbz5GwceBWZXVO+qsclh2XHVfxyBbu0bmPt0uux+o4t7jPXC0Jy VcFE0m5Y+rJPqaOI10usd2pEw8dOgfaZ9EA/dbwuW5zvkneR9II1PNX0GhZQ8uv6I4ZmT3SvX4J2 iDAUJz+E8zoHekike0ho3zBFuoKT1h0eOfBVYzbOU/d3ktbe70kq3UtCAPR4aih3Zs2oDvA7MAi9 3+RS9AwlsWeMdt9cxY0c88Di250eioeVGE8yhY9FOcKB7AfscWECBSJVBVnWe39MQ3F6hCuLtou8 ErnfTzwF64ZKN14c69aM9OujBSY0083DhqUt+YUsVlG4SaiF7AnzRMj9UAXCPQWte/nhndEC2WoN ueF+7mnrKOT3nxQS4zvmM+IHJs4SYXEHkRrmKsSy7nYmDD2eQ0sMaEjlomH0M9hx6C5F3JzY5dtT I8bZMzzldqKO5H+q9Pz8JB/LMZE3q7N17M83ooK6I3aofgEskA8jW+YUIUbS6XKtBJUOjdEZtHS0 VdyVGb0FLTOcnoj6/bYnx1xK+QbjTfPkmLpe8jG9/pMoZiGymuj77EZRGWKDNwK2791xDQoL3yYZ XeNqEESH+BxkqMoSide5tBSHlzr8GwAFIPrf0xmRTuAWYlEsuPBnLppRyK2ZxTRRcV5rVR7qMrgm ogX4uPU52cnHAf8YDHvrKvP9aoGnYpxfLIYL/PtfGjdxZo0JuEZyovWGUJ8rJOeLg/4xGYs5nJ0l 8NB9Kbdi/byJXpVsDiiuQyq9qN/jd150MTvinLQwKM1DWjqNnA2izknXxktvhiTuIKQsiMI8QSQG 0qYvKWnp+UEOA6IIsBFpVo7bPuBzzWn1eWI+kmOX+0LqZgStsgoofBmJM8ClBQ9iHv6EnLHegGLG 1+CjgXjJ3DGqzdQ3EC6Py0C0mtnQeRQAlL3026PY+kXLfe60BRYe3c299Bcd5jBlX1WNzx6Kkrhn +sGAWXZMXYmLhwEwzh50hwIUMqP2bMZFy+wAUEqwZcjrN9xUAZ0x5AllNBGVw6vxLKjDw+EX8F3Y w/4V9rD/uhnwogM5lQueA2+HkcsRhJtD3yLz299gAsXLh8TAvkADmm4JtchTiDyNm5SSOO+Y4cIr IClp6EAonPzmouTSQCgMFg2Ewh/p61ktPbcGQqGO3fQajnu5E3lXCzpKk2hvQL8vz7wX0P+QUwhp iyBfbzCBmuk8IsyWS4f4JTq/GuU+Z/OQPT4+ipMtpLS1c4dor+B3CbOJ+dLY1nVAdIIHAT7Wlwdi yUkC+Iw7nRuJYXuFRj7eY0/02E+gHRNO5tNjmZOEE8hZJp5Fj72lO7Kz+mBmb9FRPIcean7TVxvv 841k85iG3e7fSAb85v2j7lvGWqbJ7zg+vzXSTtQuzsWLJ/4HN2ce18S19/9zZiYbi8kkYVOUkEBY 3CYRECuaBcQFqAQM4squoiiyanu1LIKCYhVFa1WEKtGKbam2tm4VbGur17Yq1UqrCBXXYCVBcMXM cybB6r23z33d3/M8f/18veIkITOTSd7f7/fzPeeTQ29EX9YZpg+bVLGfuPvwgspLFRTEGmQ68Zug DGA8wAxWOPETlXWV3O3LfJ85SbDvecxIhT0zUrHYwoaDEhUpIAMsSwI5X6GAT5kNCpZYrY1ps4E+ +Sy1fDbIPUXlHqXqf1KkHKeW/qrM/J4aVn+cWvJ9QFJncMpZavEUvjrteyrXQlpHGIqtQwxVrEJe odPt3lXijifXRfoZcGKPvHPxSxWQgFRABb2gHZX8JpzvxPfhj+FH8GdwvkKlvKcijJhK01d6Kugs e3Y2pHsKSsJK3uROpdfgpWtLCct21vv8A/yvAO+dBpw28VeBki84JyrBZXwVgKbrXId3f2YBvqmV 18SXDl71MGzNMofwgWFw6kFIvzj0Pxo3OMCMG+SJsMW9ptx6P5DSa8qYCt6CWHoEeJs2pTKDBPP8 wODcp91pYPlz0xtwGs/hGR3cb9VkxLV1pCqEftB4xPpVdt5gxHVfT2N7AY0tS333QSPXqTHK/cvR HUhbqyzuROOPa9+dcVFBuzX5m0awrhueC5sCcKemae1zPOxORDg26Sdag4dnDR42Ch6OrWQ/Mns4 Xmp/Poq3YDw3hAmbCGupZsbR2HOx6QAwtbrThKJKT7AJpIJ3dDxxQ9qFqdTMKemLChe1Gp2TRicV MAFEM2/cogo/WmAr3qqLROuDX1k3VNEdTyB+FTi/LLzX7z5EhddCCFl5l6rAADcUPexetsUuDpXc 5HFO3HBnXjjp/d0WiG2DFRDuBN1mUMaqgEsHbkR362CZ2yPzheVudc7rxdugfafJhLNgpjN/LtyG /oxKqJu6Dv33yIzukC1uW7eg/izVuVWc61wBlg6sAu1OYLzfTHmsV5VzrFcduqnJI+P9vh3cQmJ4 dgkGO5ssx6RYkwy1ujGodJSjiGGGNG48fdYudfi71DqmEXNFuocJpUv3mOrZLFNYfAO6hg5fj/1F 8Yx+WTwDQMEYVEEDwegQ8kX5egiZ8Y/MRtv4xxRq/slo6/CHbxzl98kaSgmozVTQGirKOIVKWUll RlKoltaVKvMV2W9RhxRJpVS6cRm1ZBolWUOhWlr/IyVZGZxzUZkWSaWtXUnld1Cp06hxAqP55LZK 4nPsngxidazH3GDsTo+1umpGPfACinGCLygljxg52qR66CMpHhFauwX9LRXeH9bmDQ0SvqiUSV+y FaEUbXO7lKgMg15gKJNthFibHFQ3sVHDsXHFpAqopvttB6pNPVFnWfFX8WaX+N43c1j6cbpbY+Ou 0XMS1k0ymp1Wf8AdtyJ0IKU4FnpMy94UA8Cc8DnhvbwZ2nYvv7RyYhscNpcjbuvbBjfmTHjsvZE1 cgLqENRCwNKXwUm3Hg1Javf2T+VBELhIHOifWgcDF9Fo+8gsCVw0coJ/qpoMnL/0u/C3QqOTiF8z haNfluUPplXAM+QZsl1a3+p7bRgn5yJxUtUUHn67tyn8V04ZkClgQBiGsRclgTMyGC4o1HAVdce8 zpC87yRql9AIYWKse9Qy6r5CUkplrqH8pyuSvqHm78qe10GdUOTl/a6URKKs+Db63LuVFIlfI78X 8vBL2anvYeysbnaYIj9b2JUd0cS6Ik2tJCqYzBc9csJDv9z4e927kOZYERp2kc8XgzVUzoYe+ZD1 2Fu59qSaRBo3+0FOWxMLv2l5rxjmqj3J3Rt+Xv6m7OayMidQRIHtnPOZvz+7NuHRYpnGbulOqGZn sbPapUQRUSRWimZXRdNKoACK3drPW30/HbpC0zcz64pwX2FB9mXJplv5RAn+6VY4U87Fxstmyvna sOWiKmdY5VLnUucMP3cp3C73Sx4vU5MlrGWbxYG5Yk4OX2yqqorYuTmhklu4iy9uUjnWEuQCQ3ID F/AqkU4ZXFQ7x/FUEQR7WsjNCwycjZaBt/J3b1aTQGFeVfJWJR04Jqph28aPP9hRqBM7CCbtjumt Y/+c8x5GrKLytuyesGNzjMFXvWVTu7RoyRbiXGZrpqwGFoiW78dafW+WfuYzZtXqiWFDVb2+fyi0 o0QxHcp0IK/7e/YHefOmUKsVuR3U8vyI3ZZ5x6X5AO71HlImakq0i61RnlBMV4weAeLvHCp8h0t5 /PgxTp0HM8K+x1UiQhjuzApHJUlbM4kiUcaPwZ+PPV3dEUavmRC00On0DmlR+geE24ahG9r64otu 967IXjGR2Bpbe8oHKMfFLNKfjpjrGRfWSN3u9b6nDORd/O58uJNG6PaLfWFHbj6WmbW0eebB/tYJ t7ZOb1jbfBywunpIR9KufyCYjY3lGM2XkZRBnVEAMw6s7TS5/9k6aYkqFrSHbCYTP9UAjAZ6m2qh Qx6gpItybsO5WzdUxwnLN6zuaT+wvubqguw91mO5G0Fvoj2UWJNuYZu1WwJCmPvhI5Odh7vAbT3E 2M7JERCMdsO9naNcUH+UQuRxSP7gpShBy8kp/MFMU2Rmu4n46+E5TvJnA7mnnFE24W09JbAI2BCr hRqINHCHEL/nbA9B6RTuiziUMJVMwuhiMsZSEkB1nTVlROJ7hWCgvNC740tnLEoQ6YufIqOkzUbz aiadzhLLXpvF8naXSQd2mzpNqtu9u+RRVhWmATFe7jP9trDm+5douYPFskBHMNxBJSyMzPCuZUZr S5ViGRxOqaFy1FiCP58HBlYI2c6FsYMEkwuBYIlsD5P7Dollk1HezldY/hYQaF8uEdLWVIwycQEz FG1tZlbmDhBYB6IHCKajXHyUChogiDJQc1L2oEScU03NO6CM2anIrqFaFEkHqPRq6vESMGKAQAI0 QJ/xkJLsCc55rEw7R21J20Pl89SpnVS7wD4GVQg3DepvqrnDH450Lh7FI4pHm3bJNXCI0s863EuN ZzqSBbCQGe2tZZXx00ZXKW73DnkwJgwC3ofaJGCZclkLr07Arqqt/clSmeYI0rmcOAicP9SK8922 A8ugGFjpNlzXIRxWg9lDO9AhhFFxUVjRujxfP88jnEuATNjsYoKqkQlDY+frJ7CWzb3C2pgAdif0 Tp+vHxK4TM+Na0uQJdTimfP18wPlAZwE+I0M6LI1UAaOiWB1CpSHwvQPwzQwA33xQwLH8IKDFlpd UivGTCSATHqy0yRA0aF3yz5dtUuOeoyjXo0rNPe67xWXBvIuzAsOivFa4L1XyAGu+Qt9/k1s8P4l NtidJoqJDXWniRkR/zM4PmSCw2hGKmXsPwbHSVW4WiLgdhGYWfUl8ZMq/NLt3mY+ig13RH7yFQws tYcko9zpJpZtLOFjFBN47iMTippk8XYgFDH8/8EWihbAKnyQUCRFpXuIM8uN+GWoq1XR+Liz8qo8 SB8XFCAcH0GdK3fhp8526yHPxxogszDOeAISzUK8xdm4E0PxYQ2PVyaYTeP6C2okrhCCRzx5Ycde ZywZAulYX/xTMkSKgGHC495wXHbjqaUbyWLeDKJYZjSjfpgjIbChoFbLVeIyeEyihicaZYh8BP5W YW7GGtIeFsaKBYUes7z99jABcghnJAuuuFvsudZnLKs8gZmGoUH/NEyDDf7cGolvAwN/jUSZCKgD IKhGEqWkUigqMwLk+FPzgpV+iuxhlDFNkRRMpftTiP2TNRIG/oxCSlJPBeeUKNPiqTSKyo/ZSqUu p84L7BH7BZ7+KNTf587CZQNXeQplkULpD0oAtsi3yFF4hzLxrRm5TRDnj5pzJy9rKDi09TG9eXQZ z2j2ZCLhc28gg20YSIKWEi1MMoCKUGyzLRbeCMZlV9muchQK67HVwi2S272si0LMxWeudF1iqm/D hL+zGqdenGRSXZ+KGc3p6wkN7EMA93iP4U07LbcBvNSHuDDKYuPX/fusGEP0iS0Mwe96NSZBO2bW IpA3O+60nBc23RtTCDl1cTP+rwme8DrBzPjslxxmaq+GEdXhVnpnBtnLEb4otyNIG5LZLyGmQROL YCgerbb0U8wWIYbd+xl2RwyfxRwHTnGFcR5jhUReJE4qEL1+pIKBdz9HwdBrg/cLhcAyEKV3LoJ3 BiGD14QYgvk/YHgsYlj0iuEJDMPhrxh2fI3hin9m2FEGv0UMXztrY7iZxFhfYCh9D0EEp3nvEVsJ dmQIdlRUePZUMQSn/+NE4hUbwfslvuAKIni/lWBwOWi/JCqESnkDZW/vnABqnlY5SpEdRGUq8pK0 VHoAQ/B+SYKV4LWU5I1gfc67yrRkKu0NKr+W8kst7ie43JORsIhgR9nA9Z7uMnfp3l8QwTXyGoZg 0weI4AhEcCJDsJfd6wSX8T40mocyBJ9kCMa6GILfRQSDmK2hWHU/wY6ynVfZ0pcES7Yigi33SczT ZwFCeInvUYTw2alXEcJ3pwr7EXZP5lgYgs/3E/y2D/HbqJcZuCHmdFUNw+82hl8mA7sH8ubFnZeL wpK8x6IM/Elcyv81v9P6+VW+jzoC+myPykpy43ImF1d8jV2P7ac4yF6xHnb2U4yEbu/LVNzEeoYJ uWx4k2E5E/zJsi9btB349LPsIyqXr8cwF5bjILl4AcTehwPc1Cgh42SIO8svL4AMsebjEMFXrpe5 Z61Ih6B8fAghLWMUC9EpxC+ZnV/BTL/ZD3PUIKOZ95Lm38KFQIpobkQ0r+OBab74WVLP0OzF4Dzc 3UbzCMkMYsc/w+wugz8jmENa+hNygxBznlUY64dYzvVGydgOsezOsOyu2OG5x+cZYrnYynIm3c9y eqeV5SOI5ZRO4HfExnKQ8YgkKoJKmcwokU2h1DydUqvInkC9o0g6pqPSQxmWj0gkDQzL71OSycE5 9dXKtCwqbTKV30ClVlVSd60sb0Msr56CWHaXDdzpOVQKh0r33kIwfyL/xArzfgTzTC+Y7MfK9M/w Rzy/wrmW4dlofoPB+UdvcBLxzOBcrYURScAQin1kwznrDXeUkBU2nBfWCJmEbBRiUCEvXiZdt9L3 DMK5Zapxkmmy6vHUVzhHOyJJcb0f53Kfp8S9Uf0JOeL7rJPRJz5hgN7n5WcjemggLy/uupw702up d7iQ81Vc9kugOa8Bzf4noG2+i2brZIXM5rtAeturrU8GR/E0EOs06XAtYZXcnaZ+28WCftuFbbTw pIq2SgukLGhVePWb+36+lzv2meob4gHD93X2YQT4YJSls41m9nOsaYAIMAqjwTZdgQ8Q4WudBtvm GzxQWsY6/1QiTTM9rCIjt4oJjN/muBEhNqGRnLELhLiy8vLJZLjLycDgvVNw2BXpcbuFCO+dAksG xJHii3cR/UoyiP9KOoyHetwqzeFDZ9YLZ2PUXyXvGX8mby1K3lqEO5LnyTwgzWUEet7L5D15eIgN 91mAOC775U/cwZpcxjsxO8QLVcweScdHqocjWUF3H6qOzqatPz9RSUCE9ecnEsHNx/e+81r7Bsvj Ts9OjEiSfoVPttwdoL5af7Gt9gL9WKUud43qDpjo+4dqXlBR0FMHf57wQF7k+2TqbJEwRcQ6W7QR fihRe4giPDHc4aDyPWHhiB+C0mTzgjxE7GQSgx8J17k9Uu0n5VQJf/LEwQO50hfOEukwkWDSTWFS eK20hDFoDN0/svBet07rLIXSpVqIAnePmJk3OBTChOMlzXHPnm+Y0rL0L0tLCwrHZai0tEhQY+AS fTmoRRKFR6fAaKa0PFfP48U802S/UAfp8pJ40enP1SgcW/pLiy5aAuP1OfqYNL/oNBidPz/aL3Vy dLs1HI8wpYXJGyEyWB2thlGs/HEYH+7WYqzcbWQ4I+R+UERQW2WrDVzvWSGygSc8I6QwQno7ZsEg 1Hz+JO/vkPzf9oLFfqwNqAQRVXBABoQAhS30vPG0CkpuejNx261BcfuefjZm01G7khkdtTcF+zjR GrYBLSGyO2wdCttFGgxMec/ZcjMZ6uTvSddV+xZRf8+4zr6RCT15Ye9JB1yo9h3ryXhAwp6r88CW ZF102j5Jii5aqltU3yJZsCgmrUWSNDE6FT3IpdVLy7PtJkZnevGiF+hGdAs+yVtYiSJeg0J+Oop4 wwyjeUvHk4N/q5j4IuEnuecoefHDg43iLH7+5/7A83uvRsFP8tGqCyt13ukY0VTQXODf1sdkiIqJ hDG20+SCMgQr4ETMWs/iKaXEiNVjg3g7Vxvi3vba6B2i5XFurt7ks6iaWL+hBvXxZFnHk0fmj4am fkDMqllcs7Ctb1fHk+Ff2f2k0smHySmj2V3tUCcQG+z2DlRBl/ghyZg58YG5gdoeQSU6OxWO9xTs FNhH7VZ+UOvYadop2PMrmbf5oGDj1Hp24ThPAQuftAdXaKc1zGtYvnvbft9yw6KJj4VYvg7vdrm+ D8Rp+aKkyDjtiz0LixLCbdaEbqs1IZGZapkbemWLaghKYMxkC31y7bfHB2XtibsDGG+CAETCqSPF VHDgjaf2d3rRi+p2GXCtBwCtD/udCVV7C/bggZ4AFKmwlXadpgzjZvyLOeBFVhJ7J9eA+0iXAas1 AQztNCXcLKnDhxaBaeilEztNPTUGvKAIPFzDiobdZoftBryR7QuAO17P+mjkTgMuXQu+tpg+wunZ Owz4zeEAvGj6kZ3xngGvox4DcPFH9oltBjwhbxQA9SXgl2vd///ZOIP+ysbJ43vSgxILwlDvlE0D q+0BDGsAqSApVpKkl+TUx0oyo6Speml6kmSRUS/NjpDkT5UMA8nGGZKcCEmKXjIPZNSnSZbpJAtm SLJjpemxYEmlZJ7n4hnS9DTJnCUbfIeBpVGSTJ1kS1qSJEcvWZgm2euZVh8lGbZGmnNOmn7QPzkU 5JVLr3s2y84Mj42QXF6ulwQNDpjfIB0G8iZ7UFP1jLlTo/R63dzZ6ngz9pW5k1Xykdjq7WS8w219 H2pf93aWgZ9feTt5fuGbR/w7c+fscHZMv7lzdjhvtmag1k4yFSi1QrLT/uXEzgvLve5quhioC5hf eKv6APB4kgkA38THOe0u/JLBkIQeSjgA8CCLWYBhK11WBjesLqChqQzAsihAc9bQOIe7ocTyJlhD EybaVLYiAcQDgkPT3ATQxl9D8/jZYAPa11SwmuaZCq7Q9NJCuOZNsIrezDKt59c4suuwEsASl2F5 OLEC8BdyLsFkcBSfB/Q4xuFH4TSHLqVfnPyfzwVJek05HlhSzHNTEsTEMJs2pToSRglMx8EiDyId 5H9Nm3LGENH8ZH4u59Us0H9rsRK/tFgtp4fbLFZ19IGt3atH31CtyH9ptGoKYLFtRiv9S/+pKfLu Q6cw2y9fbRNAJMcmhDBGCBnNTNQRd3qQGEIpY7h6itW54dvWlwSjk+Dt3iikmPE3GRtqltWHykJv FgmiF6VRVkXU3tVoM6Kec+yibUbUc7fybvzMarvFalZFl9rrBeMh1sq2CIT4bfZKC/owGKOph2g/ OIfUD1S7OI+HxB95GpsnVcUKnyFi5W0DqW6UkBNE1lNCboUzL4iM2wKxYbUwCkmbWugwBat3gpwa TAO/Ex0R7hfq0PYQEls12DbIAXVCfG29M+tzZ/i5M416JQ4QSb8WiqQ96NaObkbR10bzzinEOOy0 3SNu+CFVPDMvbLzFfVt29rfH/MmEGylMFCZjz0F2FLRjGmv/GSI838202AkkekSSH+UP/khKZP8i An3DWULHUbh4jEDIThOPFn8o0h4REpOVtPCI8LawdjxRazRnwDOg/Xm8DKZiQARKmFmWwW+r4qVH yC8xrPCZyWqTnfIm95f9o5AC6VBY7gY8Kx5bHvGv/UA8yBVTqB84DvzEzCyRXB1kFFNRQnWKQM30 A3bqea5anibbQT1Bk3TMVZ1uxwgQMWXrBxKRYp2UU5+qTQtWpwnU+fnq1Nx49WjByPGMS1aopvtd sqBXG69OiWdcsmCZDATKtQoQMEEhZMYumdmj/WPiZV2jrvKIrtEmVRlHArYQlHBAhTM/iDSa9z2I kAMgah3NWGnXhULq8IRGA2OT3bhfNV2OD0FtB2Z1xUbGQpOCccWuD1SbRnWFd4VDt0vSeK/Sj7kv ZJGxr7liJ2NbR40nsBtzp2dMIepgkI5xxWbADNSB1kE3fQW/cSLU+N7ubVK+QzGu2DfV55SGtXrf rMjY28ShWxzYckDWLgsSsLKNoiY8YLI4X5h8QmDx2oLVMiPYdhc9EsFkpUj6S3K81HPdkuAg3RnO TS5MTf1dKj6+xGiuqA6eTK683bshLaJR418A5+d7iLBDaZWic0oiS8caVb54zHy+ZDx2zHv1OxPz bjtFlGfeI3yzljWvaM6Gx2SwLXfnCjhgSXASTAfLOWVJ22AtLB02j5noak4bkzmV835xx5MpkbHd cVXy7rjuOLAK9JmUx2UqGOR8KhXDAfucsrEo3vuZOXXkfUDd3PCo/A3RIW+2pUn5SAYGbc0KPFcy Xz6h5s2axJqRoovQUd9YVBs4Ays50eqx5Murf5g2+3xY86gc7Ek/ITiUKa7WsYbtuMnmNICedX8r CD9gl6SD2+APSQNTwRHyxlP07gL3lesz18YungfhsiWFRakN8ndyqiOysgK5D8yzChYvV71VsO6t 5uyd+cJzytRqIgq6z+PoWHvK7RLmICm1CavojlMFeZz/SRUEgfSa7JtkLjjLPiTTNRVpYBJqgWDw j/M02H7hL8n7hdtgwffEdyJLKTCod+M69K2mE9OOnr90/GzHk6GoM9sGC1moCsRLeTAzZSW3VvkF 0PtCaGxSjb4Z0KF4UiQDNTwCQEka8IzB1iUSPE2OK4J6RAwOE80x55SuF7MCuzS+beN/bn9SpAET L9/XxV7ghgGYFzklo6U28Gxoadt7l9lw+aQLqfBDJSpxMflaVuZnzSn52i/Cmi4yAwbBDecDBjSf B4C8800U9H1kfmSOl+7X+y66880d1dIRVzZ3lQVfi0108P4yulQeoF36tlancb7ZnI0nWI23ZwK1 K+P7BGQ6+Hul2/kddbRGU2h3KGbyC879p/PZxDY4vOviJ9FdgmTjETItpdP0+ZLg5pyrl2W+6idF jp92mtITV59tnHa1Mceu6uqZ+MjpxP7md9jdtkFKDPid6Ar/udTzoldjkG7+IcW97sCJF+ITAHjd yPPYqi6PfrZB1cvrV5cbP6N9ZxaOr5mJyo7V+frF41vqqV3bWtk3ng5nMeqtr8iA9wUjeSm02OTl isNIXg4YC8DnNnl5KbEE/xrJy0VJbC/SgA8P+VNezocjC+twRRGIVGHd5oSqKgO+sgjA4QAy0nDg ve4/V2JwQsdBNcqB+fkP849ZP8SQ22kK6OpB6RzJQQvjUCjI+eqtaNpZPcyNl5R3JdRV3fEEgxjS E2hXmpDsw11CAeh16TSFDsdya3bj+hGjGZuR5l43vNbzamG1vzgF9rwH0rbjO6tp2/Fd1Xc7nlh6 rUev2rW7EV+Djs4cbvxwLKxiN145mm00Q3Rk5kqYN99pQs27k7DTJOo0Of8vriRsWzX++6sr8foA XcmT166EOV//AhbofLYzu/wvzldSXo3rwv4838330PkWvHY+ZnGS7/5plQ5e/1aNbiFbDHgwer/M gm0x4F//Ma8hjPX4jlDbamV/9Zq/3mtFVz2Ohf33R/7rve6jvbL/YS8WioCQa7T1J0QD/sMH/+6q mSXsCHTVqybYqPqr98a8Jgy9k43/5jV/vdfnaK/q/+e9vEz1eP0/7JWAEi/wRQh0maY9pW8+RkFp f6eH6StXVBjwEhcU0/s6TbHgLEoPgQXb8KGuAEg6TSu1nljuHgN+WAp+Xz8Sm85P50uhwwcGFe7B pIFY/na+ZTD7260G/B0t6ATvj8RUKNobDI34KfShI6kc/QL8iD6fNQb8y/0TfmKh6LLaiLiglhD/ 28v4zxaIYQUgXWr9lhz0TlZ1iy4p8e7Dvmc95m4AdroCio0awcZrdPvzbjMPj+THAsB0muF3etBH UG1bQeYtBD9eqGVvdGRx6jjtz/OYJWQeFLHRB/nnCjIObX0tsIXxEF5qxe4+RA3p7VJMH/4qUYT3 Z4rX/YPBTq/5B6c4c8gEj3MgWuSgSvL4/RmkG3FAhABtKXSczSFbIAS8IhY8RhZ/KoQd8KSoA55x sSfxHVBQClmMn5Ds9gb3hQADIPzfRDdqT3cQYtS6VUpE6tu9suEmVeBwd3/fHDd4Hr8vtBdyyC8h 4dwKiTx7QeJ6iXXaQPgcy5aywpdLWXktoNjPaG7iupo3SkRrJSwRs0ZIgtWtc2n42Vu+/Y7r5se+ zpdH5OgHK24NCqr0GKeqwEX2TiCTcF3l2U5wo9v67Mm4INKX+QmARHQRKdWDioM45AggXHFQgQv7 7AEY3Iq1JfLCQcZcahlYmXLeus4SSklzLOcpgMFnZkuzEtq1qIzK7YGznepVJ1Q/jdGHzqWWzFSn /U7lzqU8sztVL5TTp4rD0rjiDgiXt3Ig63ZvB/zJCXdrgcPy4I8SwBjIcwKOkTpmhENzB9pW8dnP 7zTdJ1EeFj4Ui8WdPcs9Xe70oP72oUYmwDjkpFuPRupmO42dZk+GzwL26E4LDJ/1nDV2Wh7agm/R nTZN+Kw2zej4DrQFHejOHXTnDtrmK9AT+YFjpz1ETxxDux5jjvEQ/SUDPZHBvJI5xh10DI4ufBaN nqCZY+C60fE4eoKDtveZXe6To+P56Ak+ekKEtmEidMctdG43en5g6NyyQehhNzlx4swH5tHxg7ih c5d7jo53D53rox87rVlhDJ9+9gl3LUeAgeiNHfCO5o6GQ5KNE+xJsozW0JoWSFZlVWXlQbLscNbh rDYN+TjrcVaHhixzLXItuqMhmxXNinwFSXp0mr4rOkaSjI55qFGQqzxXeWZoSM9O0x9F4XcgiUr9 syJaQ16DFdcgriOlnSZxJUdHkt6dJs9K+xh5p2lEJV8nI306TWMrRTpyuedyz++6SRKlHH1lVRbp V9ZpSq48nEX66Hx0j7NIhT8SD5WuReTQTlN5JWhWpObtrPmkpqmm1RKu45CgIm0lkQfv4LOdus15 cCNfMsHx7pYm3gVWh2ZYK+f7PHWJ/FE87nRlsoP37d4Jg73o+Z6K+yuW96poteumhXvOZxlpldrW ODd0qdTHnklvHDO0yb8xNKtm+EtzSkjfP4rUZ6QVIe/KCovfhruS9z3henWTQ8OgRfsLBYXwM6mh 7hR3HL1/tshih/EmEzmfvTMILlTcFw7+1Nk4W7j6cvwxich104XGaDDo09ZCkRdsasCHBg0NyhnC ERxGKoxO3gSSL4Dk6OPg7ZHR6sIOf4lFH7tYm8ePTgSadFydkgEKNIRmvubtq/6SRYl2HueV1OnC Nt6polbed/eFRXt3f6avnO0U7NCKz/YA4IThtGHQxxzyLq6zd7ohmna7dypY+slc1M/FSpoWd6vT 1QedP1nVTnzLWyK3DoXeiqf3EbuLhYeQLnRBwnDqhRNDx/9RNAQzCtn3DrLE37Ih6JIUBeHqHLxD I4TY0U+bIjdONeR//HOU0Vx+fwBxeO1G0neQTjLy1qN1XNcBHTpwfJ9H13PWmAenDT53vmWNuSXx kud1tegHdP3+LOtaWB4s1Fe2E6F5J3jf8i78ajS/DzqeCOFJ4xXDqa6sw7d7JWZQcXpY74mPQmk9 LTHbO+U8B5dqvUZupQc+fs46Zjm99xKN3e5bnFB24dtPW98dF1o6Sj+gvBIHKDbzEakVX6uPkcdI e+FDzdhY9+gl67hgEn8mP4M/IGYVuLslQ1PxNZxvCjvKP8dv5Xc5Ptc814AT0nDdCc/7NSdTT3g7 Nng0AEVDiz6iYU5DZkNRw+YGw4GCjGWR1T8e6DvWMOmHhusNpgN/oxsqvl7ocrzIYXtxnfRzdHuo +f13yMK+kuNX0aO7xZ6HODrilOyWHHffVCeVNwY3Tmlseufib1mpjfmNZUcPZ+GDm3+eAJv/i6nz DGsie8P+mSQgAm4SmrqWSWiCq4bq2tYZQMFKqIp1EpqiwtCiyCIJIIqohKioi0gEBLFgAMW2qwNI saABBAERQxBUbCEIigXmTfT/vtf7ZT7MxzPXuZ/fc5957uOeT8ht3NhOQsEjYB58vKOGMHlKvLnN 8VqyilW5yWXGYzjQDoiej5dPkc+WsxC5tzyoNmnhbrlf+fAxeWWRvNi0XF1zf4vx0zpf4B+0FA3r roy1ZEUYMC70O7LMXcO7K/G3DhEXelHWq8qQpejOqWgQpacy5r18TM5QmCucFO4KEKDYpkhQZLR3 KMFwn+qLCownp5CzyX2kNT2IFJCzcHQxfpG8TcrJffin74codJoJ/SE+x8ThNueLRf9sy2gImilc JHzEzmodNtVGgYBh7FcWyG2VhYqn8lCBdarFnD0qsSpPNSikiRfQwVR4DhxJ107rFdEfir2lQCX+ SAcwIr0oDZIKpOunAyl7mBkzNTdIys7lZzKHmSAXLjZ+vtbVm2k14P/YFGeCzJhuo1PC/yYu9r+X ZCSBJQOzJKazO5S2Mxd1i66T6weHEG3ZIjRl6z6CPvdt/3i/8CaCGkkAuHeZ/wcApjbelAdFogoX fZeJNt5UAcuOt1qAM3g0wysXvE/vXFZRbj17wd18NTJrxuLBu/lfhkpxbwoQhD7/vexYJk8QYobG R1rqu4SWQzuIxArKoStp5a67/qPmE4G1ueauPlS+K5oY/fwK1fleEh1hO9nbOgMB+1VBa9b+mfk7 7e1hyQXvaUrqXT0KBZTmBnnZKyn+yF9+j7xG8w1iPVeZoa7e8TH6LqP5hhnVxbn8E3ctow3GW0F6 1hAjMbrK4kadd4zhDfkDuedOif4r+Yg8QZCTXWxl5fX5RYlD9N8+2gGii0PL8UZ5cGtTeCsB+DPP +ZWXng7M5Z+R5sanLec9lCYfqXSpdNEs6YWdy+wU9gaZvm3Pfe8hvophJsPLPjGm0YcWssjGlxYi 3V1yMypwEAnuJaxlJJuUsvdGPfKWsi0lu5KNGa17yoRyIa0airD4IPRpBwvW0AIniX3aWwoTY2KY j7wBDieZDPhnwvnwVbgObocH3sI/4N84rJkmlXzye3bFWlZi7toZxvt36KFrxF6cQE7szE2Ws+Vr A1dlm5+3Nqh0qbJITtKlVroUWLRJJj2RanSpTaKwoCI0+f+NdunGnTP7Uqr3IsfnT7v3FHkF4Dbl e22gE5AjSse53K+IAbcA5nBduEa+XOqCqQKun8Omk9wL3O5H3pXLA70blw27hQP+hbd2weF2kSQD /80n+I6+TwywYdlEAt8VkWBWuB33GXrbam3hgBW/Fw35zcvA23YSNhMDizBPjIdFY3ux41gxdgsD DdgLbACj4Ca4NT5BuAIHG/EInMrVhkW5cldyn+G89/gYfpRrLkiiQ1QpnQpBPjFDXF3MxXSv8LgQ FAtvCe+pXggHhM1cBmktBvPE/dhGcYRYJD4irsauicE9cQH+n3RMzNDOIEtP4aAEJ/AEaYaULmQL HYVPpeDNyUfD36VcPxOZSjjvYtMwzbPklcRpcIaaHbbuCL+gv/uw7NgX9deSylmuOyTjyUsvQz4g 6O8fyLFvP3hUFK0hA8sCZpm9Q9Cu4EUu0X3Eyb2dyCmUV5DcSny8ZFROmSB4pdkEn3nsCiPCkvgm sGseG33dHHV13Re6Lupz3XPcIRf6mXKAagXvL2k2sewSESNtvEp5pDZ0oEyxAMU5OynPb947MUjI 6WZyGzltgXyVnIrJTeCURyfsT8jB+YZH6klPiovajozdLS5S1Ii0kSz6bU9lb2TzFCvaPihUWZtX O1uDs9OQm7OV1jVEiGKXwuyAAhBHR6xnz+0fHmIBxl/JVSaFOYpIYaXimLBXAT4r9LqX3PlTPkeF fsi/tk4FtqsK7j1SH1LlqkpV1aoWVebVjSv5Mfhbc7M/j25FeU42jPqhsb+aIUE7z+OpgUjnFeVu yLIlZ0/uv5pC9hHUxN27jviVNW8MnjoxqLA/fesSaPWivxQDiLfi0ZO4QTapm77gzo0ptXUFL5F2 XlBNtGPjQtfqZYfKDvzuZYnoqSZNHpihAhNNXlHK1cVZOH+YdXs0dc9w07YA0acjXslQo36MQ2W0 o/uAgqJyUlmrwDzVsOp35kq1wNuDXDfUNAy2kvHkITKXLCWryRbyFTk28g1ErBW6d5HjEDSBTmfT HelL6VHGlpvo75dQj/D/phr9uSZcF4LCoev0j9JO+gc6Sd8sAxZTBN79FqTuEngNvBWOh8EhOBcu havhCPgVPALrc/RyKOOncDh+t796cngcPzVL4B1ve8pJ+aWTHfGUVcCBYno4QxxdZBIyE1mEeCKA h0Qjmu2IFCO3kAbkBQIGkDauCdeaO4+bh2zkRnBBN9KPnOXGsW5yH3KdPL9SwM5xO/W+UkSUqAkr sI1YBAZE2BHsLHYNm6F4hk3El2OAgZvjTrg7HoA7Ye5YBg46iVRVDf4Uf4N/wyfgMA7scVehnzAJ P4oX4jnCywlAj18l1Fmix38hDBFSxCbiyl+5atrtdM/pqoeipkJ54VtGmsM/Qu1EQi+BdjgsOpdE T2kh0IAKcb2Y0SF+Jx4Vq0b6pkhnS9dLgbemRGVK90v/ydELKc2angMCKQ3/LD7RIz1N/xUkBBbJ PGVKevTldy77Zf9c0uMDvSvTi1Yf+VgwvUh+drrMTtb97dwq2WaZDfH6S47pGDn5rfIZgbZdgWes PDWu0Y8IJeIIkE7kECq8kujCewlIqCcHv8tn3b91uYTYIA9/xMtKlYMT8sn39fg35Q/lXXKVHFJU GiveYH8qsLYnihAFAMyqe070fTNT+r6pChQVioF6RUfXA/aHxjDqfezPS/1PqrshaNtNYxK8otJT ExXrVTtUajxTlcsAharrylBFnCJdkaOw+OrDB45kZWx6lh8ZSsaR6WQOOXCZrCSbyd5vmYlie/rU P/TRr6QBfRqdQ890oftO2MFPpU4ucS/4DIECdSo9WHqe/i/9Eb1FqjYAPvz9Fs66RrAlPBdeBq+H wQ44Ec6Ez9J/lYbmQRpiMAr7pWdN4szk5Pf58G8ss9VlBtj4gqD67pCZcSwBCcLieFt2cBI5IJOT z7nKqeO0c95yfnB+QwALcUCWIGuQrUg8cgiJ4YJSZDy3BVFwRhAqMpU7AwEo14cbzMWRNI8C8uzS ZgTc4TZye7inObqYVsxPyYEndvCnmM8jtWLegIFo7l4uBecSHYp5+Ap8Iw4i8JVYE4Zj1/B7OIH9 gYOX2DBmnij1DlNllpeeSFeBHNVlVcaeZd4Mt2c9U7ibT4x8V832MCb90ZYzLDIevW2Aojt2kT+p EkHvjwbTk2go+mxbBb6+ZM3r5YIhxDe2qm0DGf59IVtIJltQqWAX/99B9+paso3sJ7+TE+goTLeH pN71xrb7SPP9eiOTN9bFmFvmIH7i0H2kxdPfanoQv8bukzyVSxq8fLV1rwn5d8wqyqe+J2N1MdYf Hj0EMwYLnnWE0f+mH57g+CTGQOCSzQi6xYgAsd10aqBfJb2Z3kv/TNeDf59EczzoCPtlhnjCPLg0 ROqdnzhZ390uY5KhJDafwb+wLZN1hxEUkRl2mRE7dIlhJNlSZBSiqZtrbVhuBmciLhmFZTMObL/E cMjbfYnxD9OscOlMdjEr9Ej4ZQY+I99EsnTWJYbgDoOXJ2OGXWXY8k0zeXlBu/NjQ/Iz8xaElsQI 8kNAXFh+QkFemCw/V3av4GQea0dmbH6OUTRdxi4uL4zNZswxv+ilL2acZjYURNCPjBV44CAUyR+S BZzftfTYMtey0DyzsrDw8gd5gVj+uvAdR3h501iPz8XU5nuHbc+fd5MhiTbN5BcZZbqWmZXNq1hx nuUvK7g8DWJNLbtr6m7v1/TExH2auz1rWj9pNTZ5iff9SNNoczmTt4YPc+w5bhx/21Eyw/vvOEpA FQUKBHtK992oik9xlHwzJa28a96brKufaun/sboiSp7y2K8FnJKXyIl6mouAbcidzrXjoq5cP24o 1xKr4Oas9F+xCzxR1K/81O4neMOtfmGrmqYhCsU2S5VSwNnP2a24yLnNofj0tZUgccgPDvzhi2o8 CVyRT61BkRiygkxBIsb8du5NI7N/bItqeQh3wSHPs3hh7auh3yxfiIfr2I6bKZM/pdcfrINAQxS1 Y/jB+5xD4w3JxYIgih4PdAqWYNb4PDweO4TlYqUYq4n+kj5MH8H0t2xnmYyQNH16yPO0sPYGSCIY czTBARfmwzHwRjw+0I4Z2/T3DuDuaMd0tz/JlyiL8NKgs68ZBDOu9XF4IN+pcGJPbdtkcDX6xqQG yIxpwbRj1oVY7R6NOe6UP67FtySGpKAaBtEgCKllkJudH3Yq/u0aI9BzDtF9t4k/nD5qNHmuQ2sX EREPwMRCJkWwM5DHE9hpoF0kFnWiY5sdqILmSJ6geBcv3NlEeVp68qNDbCapUSmtSKFkn5ZQNIBC ov/zA0gE1aLKmXIFQCEwpdBIw/eh9mqGhu+RzPjIs46S+w6QHHHKtMUcIm+ktTYAHQ8IiHbx0APx tMxRJ6oOd6JnYTSlaNgUoqQfXbuKutadmlwYDe3yqBBAglphW6S9Zk2ToqbVGhgfjTfusUje6Zqc pYTWuH5wnWf0MiozpDAj303TBPDtQj9RkiiR48S3TLK6nZo1TQCSud6MGW9kh445NRt6+KSFqr18 LZIN+t05Rh9coSMWyYZRWIqf/kHsnTFBm21iorTuNjvWeo5xd5qU0WcyrTbn7lZ7wUrSgLQ9HKQm 0D+/ks/gCUPVhEN04rZqbYMwtNyW94ccgYObZoQQ4fG/twCF3ay6UZj1mMVxmNkv6ZeYEUzmBelJ jqHxBLwGZ0mUlCSx28mehr5FhcZV/le3dghTBhP3DhIpHJJJ2jFXtxoxLde3vbA92zbpluqkosAV gkqSr3U8Vp+NVp02MnvgGDrAm9QqmqIz9iAaEhgxWnabKGvvBo0orw3Nmuvh2EcI2TBxd35B74be HQ5rZ/n3p4cOQYseCJ8MIC+E61PiCpm66eSEgw8G474NIbbUt4yo3Y3ODtW3vYfSoRuIU5Z4ju8s 5wrN86ADNCujl2BGKIsZEUoFtq1tuCmsXZTv+hOrjHsqjV667xGLxXniK2JQK06W2nkHsA8yJcoA TpoJiOJ8lGb9caxVu9fkHCVn4BNHZ8Fh5Zk/gUa4yV3/E26CNpZIKFSLB1Z9tz66c0DTZg6M6mfn 1UsLb7pu24CEOzs1N1HPFO1DTJTl14awaQRn+6KAUSTjXCQSsX/27xegw+fqkbQOZAGx6ipl3RX/ 8iX/UQFOeLqLTbGlhdcl3AJuBRckTGzijq7W3WuCWWPzMGyd3poAC6aX75wdPgeZYt/UOjaUWne2 /IubsNowVX5CTjlfp39FXis/vPQ21mcc99TmBVbw+hvmf/4cevXsT0Byw/3xLfhu/CB+GpfhoIq/ +YWJSgNQ4dsKjYSWQiDqP8h0FwYItwkThBnCMwmWY0lX4r2unhW7HQwaIfvAySLG9xqJm2a1anJW FKwoBN8k2UqR6tvRu++2FdIL4UIwpB5MKjbROf05yerpaRMj5kC2kl6oO183ZMlt93YyPNUIRRNy 15IzjDUdH9qtIrU2nNaFW+Ps0IOwaAobneZbF0W50Xdcdfo8qkb/0+kRVlMNc6Oc2JBBqrfY96Du Xh9WKpWoWNknJ5Sldn0VkDdFZuoRPF7n5aK7C+T/GrdGGqX6THNjIy7QYnO2kU7P8D7DYvktqqY5 fIX9bA5pvRBJTfOo86g7+nzArtSwp7t0/Bd3EJbVvQO4gU14VjcOogO9Oy1RxU8PxhIVvTxi6eLL T3Fi8Q7Cp814FfpVsEOuqUhxkdnFumjGd5sxxUOp0zfvypOSD6ACYuvM1BGNBqsT88zVmvXxUF5r yZrBPDex8H7/yr5/wLM3j6Er8Yt0rgmHdLr6SthAp++mFduwkdPDKWGbD4OFrPngeqI5UmSzsi94 2V8zdVl8JGZeqs+xcccMqXt95H+JKqCRppV9wqprjV19Wcxwv8LGu8yQdwxWYWP0cYb/zmpGsIVr TLxXWNGaM04F11okttE6c7qOPXsTMNg7juZQXgFpf5LeGdUc9d+cQwCw+/aeJx5DVyn9kmETiTVE BaqGtuPKtuHHUFHvzS5g1dQ5mmel+tqhIis+qSqEtHLadNKbNS4CW9mXtnmmDti5dmJhmn/VrAfr 6IWbsNK3VeE1V+2Y5QpD6VMF+AO8ffJOrS5Tl9kZTa6aXGU+qMdsYjZNHozYtfUX0Ou96fhPUlgB DpYymgvx6zi4j/d2BauD1eaDNZLnZd4kWH72eVkEeUB4hDxLXiPvkSPPyPfk2JjWRMgerZgPnmZL dO8aJTE0ZER3o/sbXGVuoWs+pWsCZaTJ1e3gPs1yMVKpUJ6r2/l9EJRXQK+gg3p6B/0dfZROn/K8 jG288PgPO7g9xebj4BdgO25w+Ks3HAQL4P3wP1Mgv2L4FtwAv4AHYIrN0lOUKRy/WMFczjJOuuB5 WSgHxHHSOTmcy5xKDgOPRqivQcbC35Avssp558VdzhuI1UfBwvkZiwMQF+Ku80HNq6cE2H99ZZ/H YinyH9GUMjq/LvZCV9+qHaJVxgyX+ejutzm8IGNG+HFGMBAAtusC7iruZm4kN5l7jFvEBTe4D7jP uR+5ADPCBoVzMbAM08V3YIlYJpaPXcXqMNCOvcV+YOUKFk4RFsmthWArHo8fwnPxg6rTKo7wFQ5G cFLFJC1IVLg5urtsPhNgCY1Pussamzaw5zPThRss0FPnPCXzTb+m3hLMYTv5fwHZVefvJyjn2HpK EpR1yifK7m7lBYHOgb15pulm2/4isxuWGaLoKmvy6C/TbeTpBvM2Ipl2M12nnrjsmQ6Aqb+akqwr qnBh5030V1MFvSLeagEywKPVUJ8knc5vF7w1Omz6N3RvAhppSNzT15Rk22uUyMgO++GohG7LiZrK iwzMQOMd2XnTjajaFsLVfzCyN8XPeJdZEAzthBlp08eZpydXVFPHmecmNxgz6lMTlE/EfXvtP6Ty k+qUaHJW1CGa+wHxqdQOB0r3tcY3PcNJT5QfmWs/GetRmJQboPHJVAllsnT8sQ67xxUUTRF+ltmb FB+zl51XQTG8ZN5hX2HxkUns7er9yLSexrkuL937wSin91wcM9XruM5743uEw2j0x/8V1zWonRyZ 69S02JlYnU55ZxL5qKWxyY8sftDY+jc56fDn7rJ7pswL+e0FEqJbZIl0IqNRh9ndxuJ8w9pFW+Md u8s+z74Zlj+IOC85TDwjSbK7bF6Tp6klurTNeby4LUSRohgygtanZOQp/NFl1gtfmDYo/HWPTWgj uo2xqA1JfVEyEjD97pHu2PvvfQJtEK01vXsefQWdln6NZZKcq+NLGh9+OQ79/3yfFrI/dsFpT/1K 9GNYfnQfofL7RqAhAd98WgsnPKBQBNkDKTxBd3eHzgP6c/rjyI9jRnu1mq6RdBJFf9EVqYv+oisy bvgXXb0+Uw6mMHqqKEBwM9SFv2xAQ1fPMuOPh2vI5nAgdBRfYkphRxKFa5gPQg/B1Pt4GXzkE5Oy IamimmJVMCWBCqbsbDJZuKsHHoJ1Oddfm3NYePmCaB+Lkp38OYXazGfRCc55q2x1xZzGpgoLvNxg WclOY5+wG4bO4vCr+lxx5eqjLZxxEmFrgt0wB5j8MLFiIv6o7oSW22T/4HcCXV5+nx7Fe13tjHgg 65DtCNiDiJE85ApSi7Q5NGekSQGJMFdXuGrNi6GcCpdNXIBzk7hHuYXc66t4yk2qiz4dZhlBjY08 1uZYkc7hsYx8SLCr8eR5ftTdnkftym20gTUGQX1EC3K08qtbhnq45vOuawOC/vTGFmhRhmygH8mX Tb8SN0Oim67ZjuMt5xRDKNVkR6nz+Ubr6uqkpM8XKCGG64jtN/UrdxODMXLzDVUiYZObep1yZuY6 ZYH4QFtTvGexKDRaCze8aJ1KLMbdhfAlUoldxAECuMuHoqZ6v1dPwuQt79XOmE25fB22HQNR0fNm nPinUHSwtU55iVmE3diQ7/8A8yfRPZf/Pau3FtJ80vcBxfC/F0gGio4NnNF/R3ZrCL2yus0cp5LN CNYyiGxtcanWzYZxLVb8u+zGNhrxre3SnlXZzO6nip96vKnxhzVpODOxXsPfFHIiMe+KKxOFIMPI Sb+3UF8r8FxjPdV4IXivhnf7v18S3TBZ8NpfuEVI2y08pXTOFGb3mOXFvPRN0Xv9am/PQTWU7xNq G0Zrj4YgrT+a013EufHHe7VtGjTtdK1FzJ5BA587Samp05wJ6MxRvaSRuEYrJGepZZbOzaHUt2Lw Q9x0Mymp2v/wgUk1Z8TlB4ZTpQFdZ15qg71VxOPV27/EMNzFwp/H8y+Q6UeHofg8/oVmPhD1Pmtg 5XsNgDP3lTymQjv+HZEAQrSDHbHxIBr4xIPTggQQDMISwD88sCG+s4FVMDmn++gqXUFSAL+jgZUp etnAHr8ONgrVccchV8aWgd10fy8MxO4FIWkgIlt3ulR5NJAByiaYSW2kYIF0lXSzNFLa6lQ4dgi+ JAXM1bX17dK30n8f6sumyubIACrzkQXLdsrSZLOtzIl8i5FbsoYU3oul69beiUq58vyt7IfsCIdF OPx3Q2hQPW/TC42MWAlXMpUhf6y9+nnW2OiMhNqV5f7Rz0lk+9i1K7PfVo99nvPqn7HgJuseEpnQ 5H9ygXEX+nlOGXGXaCVeE18J96UI+JkUjRxGpEhcLancKwfLTEhlnvwat1beJu+Xf5cPTFDACnvF k4AVxOwMMstY01/9ftv8C/e15aZGd67/4+9zrHu94rSDUNdpn5Egvy/IDr9X3cmKY4oixQ3Fg05t Mdf+soygZttUf2U33BtoXLbfhZzTM9UARW1rYWvvrX1G39qMrL7zaXqhk1XQOHyxyquH7GHFUdbt oK4LXRK7e4v2oOmKCtSq2j6QSt+Ud6FpgdpKByxIZ9Lj264kkwxqVPjXvKVqKCBwP1l3YGa6m4y8 MH0UQVWnF9JPifRrKsh6soN8R9Ik4iaEZk53orvTA+jb6CCBnkE/Qy+n19Cf0t/Qv9GBITwdtoNd YT84FI6D0xkACSD23+B8Yqa0FK6eRo16Cr+Bf5wG1KjfOJp2irOEs4azlRPPaTzEyeWUcqo5/kHY UATs2vfs9cePHIAcl/2wROYuMvm28MHIlK/AuHLhRds7nXHVjrv+/Xb5rpsC4RMLdkMDIuIyUok0 I73IZ0RvqWg5sYEIJ4SEhPCUJyw1AqncEx5pVYXcW/L73E7uB243yWViFpgz5hHg9aCX5J9J0kHR rW9VJ6No9q8b0dW9X9KGVsZ4DV1osjBWB8d4bX3yCm9NxU5gIz/ztzf+dJOHuwK8TF75n+matvf7 aZMhr3rY+Hi+y+hoQGeVc4jhq2k4ZKBiueJ+gWlVm8I2vaduepUcDPa81nqw1/H7eGd4WpUqCKhe HeqhCrUXV8wXrozvrGJsTEyritpdWAtt7DkoPL2bNJYKHzk/GkBI9EXM/rLepS3gpvChsEuoEkLi VsJK/KcYLBdvEIeLhWKJuECsdWfBL3eWLmVLHaVLpWulIEz6t/SwpGTsGHxVWnc6rQo8k76Xgtlp VUYyS9lc2TKZaL1shyxR9vMOCFmdzH9siyLUfWPNGrsX3YMyGpHNsSEW/NcQdUMeR3dQT3R3tlIf kh4uuSOq85Xn93RDSAiy+WEqcoWoJdqIfgJ8JybUrEYwRIKkIFmID5eCqj3O9s6ETlQdq/mttfAl KKstkxMeNIWz1bva6TPmGXXP5iAcb1PXjjzBUKnNl0TXO0Ne9vdtmsliHVPU/WLrNkXF+hJd1I82 hpj5+n1G/Ggf0zurjGuVaIN/mHHb2/65DpC3qQVC+38hO+wp05v3WW+ivawNgVsMIFBtP9ek9S8D yEB3hU0I+2UtlLLexqHpeeNj+8wq+y2NrcAteHWU53ZvU7dgO3vP7axazYuyJs/tL2vdgh2Ynlus TUFjkwP8HFkDb538Vf1V3dgM8qBPL1/hI7i+cKgmnMHhg3HqcYN5tYW1RT3nXpJLDNWgsxow65zd hFr1ni583DI+uL2msWlq3S5OyPPdZhN0cvFEf1+s0DpWTHlezwTSvh71/chzypY9m/w/mhJcKkme Uz6291bb2Zc1PQ6hPXbMeEzL3VmxtLOqTfxwNVht29j6rtYA+sIdv35i2B9hrDkYP3VHQKD4jtS7 Q1irZLFqj2PFGzghd/wc6rB2jGZi0VZrZzGjYU9nVWetpvEdP24dp60vxvaxPZak799XRMl7edBz 0ovCpuMqGat2/B3wLOvLOU7Ii8tLCQOdF7K2eEZmlbe6senYKuq0XKlynhQ85L5e+K7Wm7nQ/n6s Yvmac0OfiYtSfz/aHcTdjPiVRxnu/zgJkRDJdUNSe0pj68JCT+TX3OQKmWI9KOP/7mggnZY7E+om lkjXSEWG8ulyO7mr3E8e7h9SiSI/B0ShSdcrFOCYvEiuPd8NvjCdo4NlycAVWahlgyz99j7rL7L0 ipJW1vH3ZfwSvlagSVP1JIXoPTFGrFJsVkQqkhU3ju2RLpbKX3+60ojVZYI1tDuKekWH4p1iVPFE XhtFy0/60GAwLbeeP460VJzZD44Vbs1SuIxg+tsUy49KjuUN5CdtIyWKLfXasWwNz9NQ7cwq/Ul/ 7DfpSL/Ov+QjElWQajJ1zdEsY9mC1/slxV0bF52dWh91iHEJ8dL2x2uMh016YpK6y9HtKpcpX/sb V0JkhPk5AHKkaQv8lg/+hpLhrW/w9hEKSqJLDlnvrl78NQ8ZM5tsTZ3sb/KbTC/3xuaB+5EOa/kg aEsm61/gG8KKBmGdvNgL870i5kaGvfOKSBW5cbQXxnby8BuRIvam2FRRGIhJFfFTRcNzjEU7tp6Z A2xYtjbbWWnskFRR0P45OWz/8CDW7lRRzJZMPs7Kv8GOCWJdszg74/+U9x1gURzv/7O3dIGjWwJy ICgQpagUjQqo2KmCkMQEjo4iRxWwHdhQgwI2DBaKkFiiKGosMSFEYzRqiMYW24EalRBzJ2j4Ytvf OztwHifNROHv83+fub3Zd9+ZeT/zvtP2bmctd/F8fSKywy6a3jQPvciLuWdaEhXG439peskkOoPH 36GbFqabNnCzaYxuGs9iF6/KZJ5JwmlemIC3waRgoUm0ja/dIZOlNrztafE+Sbaz43jWdvE7TdUC eL8iu6p+hnYLTYIPms5CfkmRBYlxptEHTWOXjzi/ySQ8ydbLLizEzIK37ajNtiFT7CJEg1O38tTm nAiaOsxrDOrN22Sil21ia8c7zRP8NMphiM+Qw1HfDu5rF4XmuA8Nv3XYNiaM953dKhMLXqLCNdP1 A5I28qwmTvEcPebkENeolbZKY3yGTLJzsgs5aJouuGE7ym626yGbtSZ6rlF7Crcl5n8gdhejtfz7 s24dWnNtYDAvfVWc1gB0frPe0eT9+v4m03Ql5YlJhb+8p/f+Uuo5E109N4Wzay++xb3XNm+39xzH IJcXjn5lijkFs+75BIYGzg5cvEx1rX/qlfzAvf53tDmcr7zSbisc9LYKVr49bUKIo9+nj0/7UoLf Av8IbAhM/2xNAP41bzGs/qNnGPp+wLgzCsbox3X8+0sn+K8JDxOaDIlPj69P80+fRqHnHvSe4vA1 M34z7P2MGaW4iLNIJehDrSM+HnFlih8lxqKZwkThUqG/zmYh/35W5ikh59r8mbbFV6rT+Cq+a6f5 qowd0BigvYx/X6x9soQq4xSGZq/NzirKijTcwr/vFP6T2i/OTgZfh/Z3+TqUMpy4zm9VVOHaQnOx TqBZIPpYPEssFOeIt4pXHalR5ChTvXOKH5wZnmBaODxuMjVIUdOnlGG0cnesLdH/Y8hjSsN8rYqv /8o8amXhVI08quB5tT11PW7huiOqcfb7wNXzHAuYrWoQuT170LIGF62nLi63KHa9zJzUnH1l+Z1/ nIdT+w+rHrjr7JW78XzwAQ71ddoJLZcXF6o51+iklQVBSddjgxQujNkXoL25VGVDTXH2AjG+wf1P gd6MkQ0wZ/qnQHJApMncxnOmo04jmGPLjHRdKHXLH0brxOZRR3LEWlsPUmhz2vVYWEof9N5cRm3Y Wn7gu4hCmjYtVFlN64jLqMcHA7S//KuXJdVf68nwdCqziIOCKDuV20le2nmK9p8Y++sk59Tv88pc FHFC4Yfp2tTC1cU/Fnvc2abC4VwMGp7wwgOlcwyCtlWk+q4JL+OcD+6xL9HDe08eNSehLlx9W+UP poVXjvWxzDFyLqEqOI0n1q+u1banflBx+ZNx/OvJKsdjUBupBTbhc3fedX46OH6dDrui9pvo8mul /cVzoy6Wmx3h+OmVny0eu3rSCV997erQVVuRQp6igfbCdTcs19gK8at6YEK/W9ddy2btTWfNO07a /EllpXgqfyu76Nfv0aCCiRVB2ol2MVmmM1x9qux8ztqGu4ZOHRxxsWKah5fLVtPCNWcupV+p1v/9 Vna2JOTD+8F3L5Y9/KSgYg8K0moUeSmOrpsyJKbPXUsKT9uR3YMA7RdxDkkLclR894ud5i4/Vbph uq5vTfp4k/Hm2oo7SlVsbt02E6kzvtrbKgw0jiGLNRtGKE41LYw0uvq1bt0BvbpyP3AjZFo4M2d+ YUL+kvzc/O3536ytpu7onPzcSfuvwrQgY3HNg/eLHXMpZPBktE7S8Ngg3qWNN4T7bbecclZ8ocPZ SSUdyQ76OlzxiM+xJ44p1TXFPI/JnlFPBxxXPZg3e7FGWEif33brHflp/481K4YnPqVG6Kg+3XDy fELChhpz7sEfFF+kjNZmlFb09Zq0nLKv/8P5wOO+ig9qlmtlJJz7ZbbmFsUbXHGPEc4jtYOtr96e rXnEJ33grWVMjj+PyckS7Ww4N+f8/9Is2b8tXL9FfU+Z/ci9zFU1fsrVMDY2RocqrArrK/qXDkus rxhT6mCDIkpTSz8r3VxaWlpR+lvpzapnf39fW7Te1dK/r+oCpuBZP6fpKY5MARN7o1Zl3q36cqFL dvLplOwN2nuC7/S7XWve77uJZZykEnw7Yjcv4ACeBt+sOvSiprjpdsQC4aFfP+v51ebe2Xuc/17t PXOF2ueHSh4uO3dgmcPhcirD+Wa5ZQ5nbH2FymqOuIw2veFE/+6AXuxvdORWmlQOqXSr9D9bX4Ey F80cpzJaWJlTubXyQOVPP/NKHl75pb7iwSkTc+rKYGXRi96/Fz9QzTxCSZhylwqTSdyfLaiL9qLx og9FM0XzRd7GhSK0T0ReE/RUpCE2FtuJ0RixnzhCnCrGN+JKxRVi9JsY/+9O9aHlp1pCW2b0c1Rf MY2JZObNr69YBVVQxqDjzCXmPlNbdH2LVo94/S+4/3PiTlK9Y11pP2bSA/ry1RhuGtcg6wg1MOuI inD4XrfpX/8jztV6Th2dkxu5sTL5sknFnFX/mFdn1S+vR/nWxsjF2Mc41Hi28TL9U1nXsjTyvZgs 7fxf8p/pv/cgdIrGALRqgErhhQpLmw92Hpsp4VfzUZllhPkOk1E5ZaHemzO8c9yqDiT5mxSZX9ll dPG9M7eZ5CRKz8Xl+FYm2GKNZpWzSxUjbrqlf/HIzPhbN0tE90rOOzNesQmDnHwqqpTKXSnPqmBX 12+T/giZOom3elpPV3/zfp72LrbD3HZ7P3nPrV/f39jH+bh4xwmVwptTT4bf8JVo+7m5GV2s2+1S FjDQEz9+eW/byX1XG7ctnJo/y9dsXM5uQUD+eQGi3r8bskH7QsWFCnHdDpMdJuhs/G6T3Sbfxs/j v+eqVNmrssCqsmpWkneSt7gu1P2koVbaT4Hmky1Xf7LlUkqCSdleTs3WMiVlx6XWogUDjfiQfm7l ysp8SLI9bnvc2fgxcWm9/SY/WlzmN6WqpKbkg1KGYlQKV8clefubBO4tSpx5A/mb+Jv/mLpBO9Ak w++icKobT5w6Kaf31ZoSUchnP6ck37b0FpWKQjKPpBht/WsqH9XVG12I815zJ9C86A+jizfuom/u ZfidvT1ffK/kwR+r4/baoy3CPcIfhF7iu7Fh4iLx/r9R1uOBjy+KjS6uGS8wyfCeW6q1ckfGNAdx VfDnG/4XuJeZg8q/plftGBPX8DFVnxShWPcVEhekc9dwV/2zW5Ne9SvXV+WZ8HGE4tEb+HE/SvLt Ia6xifGn/Xf3uPvFVGMUZqxucrUiw1vd5vKJ90uH2WhNtszwCxy0w2Ro2OWrFaEfVr3nmrd9i+Vk je9s/Fz6iCyeDX5verCtg7Fo77jCq38/4g3tw6wct/VcucuE/oH4XvDvm8wrSsxdTzX/PUgUEg4r rW8bQyPsa4Jtixm/KXoqq+5Dlz972poXqFIbBsfQRytGbF5Tl+FMcX8bcrXixjDXEXSBqwNnLN9x uVvWY/+88RQq8TzoeWrK1YrrHj87avsJH6PdB/ZYDw+cElhbHutjZD7fn6Pcn8oJ3Bowam/0gUnl 0/dQdkEHDPaWlbgeszhSFdwwWj1o8B98qsfVcTPrigQzROiEYJXoT8EzgWbsHuugwKFCNG7+iEHh whQhB6pjtTCcQfj/L1eFu5kXwuyFGsHrxcp+LkH5g1KH/Kx9tvqEMTIMPVt92/i0QNkGv1JvpI2E vJSuVOEc/ed25tIwXRcXvTOzxYN7eT80+3XJ6EJnL4sL5S5e28yTEtKPz0sqtzlnc9vmsY3yiEZR z0fWva9Fxa79hVk2ONfvL2eX7SKxyGzthtW8m7bG20+HJj9ycjhb7TaM0yuT7rV0xlCnDHJjBu11 Pjb0bPUvowozapzdQ5fNRzqeZp4OnhM8P/KM9lzgme2Jijz3e57wdFh0c8ze9Q88GU/UdIcg8EO/ jAWOpYsD0fpPzlbvCDwauHXX2epbgY8CkZIAv61yhMBDECToe2T2fOS1CL8fnYNevrBe229FTR2n +ZXJfuSRM/LEmR954AI/agEn+JG3WknPWkkvOOldK+lTK3mvVmIIJ0a1+Pkc41oJD05MaiWmtZJ+ tRIzODGvlfSvlQyolVjUSvQtayVWtZL3W32MzbRTj7GFbllKfzsHIfy6iTGDOAqfF9GBNnNR83Ns TQ+yGcg9TUQ1fbvAx7eshB4GKbxRqw+OtZccP4F1Z28JfXSu7BNYOMV0Oenm18Prw6d4Xwn98Xgo cAhCv6FTwBm7PZP+CkBosyo5w3HtnhJ6BeRqDXEvhF9wbwhqnpJymsnPrnmrDYv79fqG+GFKBuFn O+4+btpQw9NUZWx/Dt/PlbpfX/fQj8swHorZM1SrnlriZ59MVSiK05PdhUNhPvcztT8fHjh6+3/v G3D8OIMo1emlGvM0jZVUaupOLVdZ0rc/x3sQVa7WW3EQZwKyUhjJtUAB3Cjdfx4mG+3lemVzi7j7 udVP8E52BhwT7ydcFZs+NgNt0PPwWkkYVIIrYvAmm3wUjUQ85IdiGiUhSCRAofj1E+4oaup1RvSM caBrnG0UGyjnoKEUp4eSgiLHh1Iwo3AmipDJVMSkolkoGNaKhdHXGR2uGdeBm/bnQ0VGEXxCWYmj SCk7SqX9kTAKxaAIFNrwqDDhOtOLa8W91YjFkaMaFnJj9RI26XWdeabFNeUixgpVjRGnoO9VbSAX lwVDEYNVAU2aVSlhVUmOQrMeS5JQzHUmUYd74wVdU5dloXTvUQOFFKAFUUqIpqmp1MskXogBoKxG P05plPhdZwygxhiOEBU8eVZpYXDvUTKFtCApR9FMpTmRO2KmIh6kHY+3JEpkX/fxMOQ604f7xz8M B1WJnj7/aYbOvUf5oCU49GURpwejhJQ5iiocBfSy7LFIiFMnoVnNMEs5aM9T8bzLUbY4sQrTlFhJ GXy2WWs3FmhDKop+IOGjMPQQsOpxRc8ylJDCzVuN+Qjx/nxIqTGKHEVaiaZpKPABm0wiQQmISWQ3 0IjBW2iEgd0FyI/3WBJKo4QGCf8607f6yRgeAnMMg97GsF5SU0erKBHguNxpxGFiwEPs+NjWUMOo XnL7f5pOihSl5I58WijJREJhSQAxLqpZWKH6yTycbZP1kBOnWdwdBWK9IhokYPVMVjqt6ikryygo 0oocmoZO5mX2vkiYxNoNFBnB1h6NXKqf1OMmpkBUHs9qIQrDCjdKUtFDPqkq8KZqEfSt36uAN1EM DyELHijUQ+GlZ+MSfJARv0EyG4HyOP8sKICDCwCNaKT4sgiwYyTChSTJuGs1R9xcAI9pKkC26eAC piBjPnafBgnDaHO39OPSSCvtVmO9hPfdnw+baqjZYbD8eCTi4/pskMxCD6MIFhrx0pxwGtCqWSks y+6WFY9/NkEMH5zVA7tKMvFRGqH0uluNlBvCxdCyao1/6d7jwE+M48FnopoaBYsKQD0nqABUOU9O yxJWSzBMNJT72m7tixhIhd++iC6Dxk8lyYzEB20WNIKjg5ffeCHG/YAr7gZu3nvEQEcwFloYw1Gi FQEDjTHgJ1e1OOgVavuJ1svwmfd9Nt1jPhk+RrMcsyfZtNd80rkTzibgLACOuZSj9zSb3gocJykn EzjXgDNEylF4lk1rLkDIXsqZB5wxC3A1NXMeAWcFcIZLOWuX7qSPA8dRyjEEztMFuGts5hQv2UmP ECI0SMoZCJwo4NhIOfsX76Q3AMdWyhkBnJPAGSDlHF+0kxYD5wMpZwpwrNLAvFLOhYU7aR/gDJNy pgPnszTZnO+k76S/Ac5AKScaOPfSZHN+lLaTNk1H7IDaVBvA4afLYlcAzkbgTGY5zcP1ePD7KDww QfwxzHQo8polYRi0PgEKuS5pYnqB0wpx1zYI2QHTlGWOh3NhAtvVxjdIRNi1BQy0IQ3+UwnJfjQk A0dHITh7QzbROPBh6J+TcdtplIjiwTGhN4DLvdjL+HfK+TBgsrtMNUioeChNrxa/HAW/RRQSsm8R ZSTQ1vBbJbA41gDSG7AvdBgLyjC4K06EYpUF4N8SnDNc8YGETALIg7ZII6ShjkxWfBBWJhDZ4Tz6 sFspQteEcU2DBPGNEuMoRLKxYNUYi1Lxy7b5oHcU3oCVRyFoSDFIH0b+RGWE9e3LCvri8lJADy9I 7w+18FQSxUhimqeApL5Bzh1XbTx0uFHNygLTFQ8lGMJUAGyMZxJh1yW4/eFz9hRnYMVW2WjIX4S7 pLBGCQ+JsKkinkNM6IHHQBT8vA5q6nH/VmT9IqALeCpJUkaJzyVUKJTeny3dA6SEiVAGDwU3SJ6n PJfgF6PwkX2CBopSbrIlWxdRuLLJjmCBPLwjGAPDnaTJli0tpmyNBrd9aShcGsheaquCHzdVMPQd lH3bGTm8VkaObWfkBJes283oYlNGDyR2iLJtO6dhHebk9zKn3tivsSO+kpOxNTjp4NfTCldUm3kN eb28hr6euMPriTu+nvjrWGcwqYfXEH8d3Qe/tjLgD3jcTIHuhyszYg5s+mDCI51vfiZ9ZBGMuwiP oJhzZlsm/fMisrgaz3LuAEfUgmO4Lpd+tIiMp4SjB4uu3otl81l8MY+2BI6xVKb4Sh49ATh9pBx1 yDl4MRnhCefRl5n0nMVkkxmSj8KJPHpZi1Sht/LoohacM/sz6aMtSj8OMmeAYySVuVBXRNcAx1LK Gbsvl9ZZAnNuKWe6cgk9eAnps0k+vr1LaIcWnDtQ1vAlsrVx/I882hM4hlLOM5CZuURWn9D6Inru ElL3RGYtcL4ETv+X+QDn7BIydjchvZ9HP14iW4djZ2+j9ZYi9N7LWo3cRtu04Ay9UkRPWkrmP02p QrbRKS1k1t4sote0lAnfRle0kMms3UFfX0rmJISjADI9MmRljoNM/wxZmbEzt9F+GbI1P/SvHXR8 Sxn3bXRhC5likPmuhcx14DxowdF7sIM2XCbLmQKcyS04i4EzpwXnKHC2t+Bc+HsHfaUFR128g1Ze 3szB1HwXB4//2PaK8FGCDx6YVBDZxga/n7oHTo1eboyE2xq2Or75oAMfXURuYWBvwTc+eiLi7b0R 8V9ck9hvcE30RcTS2B9N4GMKn37wMUOkpWFPwXM/7B/Yi63g8z4i5Nfnj38U2D1ilOAIkxn9/7IP 1NLNtOlKGCH02NtAvuuLaD+HFvtAUU1VA4pJ93/Ck/xHLx6+eAxZFOM7R1kryZ2jQZz8R4ol9OeO 6MVDVw7koMVuYjOp+cZPE3HR2yYX+MwrLaFdVr7OfkhdSS7weTaziN4IGjqgjvde6p56xEut4q9K aGbV6+yw1JWENbwOGqpnyWo49yoH+z76pV7iUfWUQjBhV1OEVjNftVaSTOEt9pgq8pe2xhd3Gjb1 Qg9tl1KR3Pv1FnNVHzAlnIDbLhYa624bfbGT86XSl5oqul6bFRueqezJVaNq6vTn3HtkoEup5NBp tZIbEXga3BPG6m3+BfQ99s6tVw8dY9/DBXSPekkvXRvjHa7GMGnK7KdlUy/5pxyUPI9G1EqimZJM 2hxMqPY3XsaMgaZUUDSTthFoKWloIyNonMfLSujUcQjdWIOXG2a1kin7hQAUui3D942taupMaiV6 hVoDS7R66c63rJVc31dCe5VoXeyRqzOgVvIsS+vpXFipRfbWsauVJO71LKEj5s3RqpWc3238FF2p lfwFzeOuGJZwv9bDbG7wk1rJfmOeA3SN9/9WgzW+c63kwu6Scvoc+KfVANOxH9VK1I15vbMmmDO1 kp5Hd5XUKAWpmL5xc+LdbZXQq7cGsOdXLcmva/SM1NqZo4LeH7Dvd1vgGXqRnhlfD0KkJ49EpMvC 6zjcJ6Yh0quvRaRnL0Ckd/8KkR7+ECI9+BlEXOgOIr26pCm/Owqkx26+GS0fx6OCb1hoKG8CPyYh LKZd2Y7SacHHPSokXpAgCE/kTYtKiBKwXUXB2f2N6r+epPCYZQY9GgOk2YQ7U6aepsDHT+Z8Lgxd +6CCeG7u47C0oSepG5wOdx/RTXLZUDF9QDlvABwv18306aGKJF8owgp2IiwYJ7IdKtnhN7nppuzL sud5tK2LO8L3JvGod0aGm+bcWhzgsd+hiIyCGCOsbdl4cz5U0/0izP//lZh3n8rLyxsaGtqXeedx xsbGuri48Hi8L7/8sh2xdxsngBQKhRC5d+9eQECAk5PTTz/91KrkO4yztLTUy8tLlgMgASoABthy wu8qTmiQ4Kuv4gECB4ZLYGfZRvuu4nzVmLIECAGnbKN9V3FGRkbm5ua2LyNttEePHu0YJ0g7u422 HzmswzDBY3KH/fubIltbWxhOOhQDfYYPH25qatoxTsiup6XJiE2zOgya+joikei/Y+gMgd++2gjl CC7BkBMSEgLG7xROY8eBXr+u7jDoGPbsMpxMa41QjmDUycrKIh7+DuMktGvXLnd3d2iElZWVsnw4 Bd+GRgcVATXybuOE4gCMWCyGkRMiYDrpSEOMGRQUlJ+fz3Smv5XD6ZQdZp3qN2TJJxCHI4l0F07Z CRBxUQsLi4yMDDBgr169Fi5cCBxy9d/bc8LRxd1rTyFLUiWhy4EI2DYlJcXMzExFRUUKkvkvOLvX b8kUj8Sl3iu9euXKFUArK98xTmjQaprqAFU26PfvC0GO2YOr0epE7G3QBx98AGAYttd9tRN6lTo1 H4JcyltSIEtyzMuXL/93AJ0k6bA5efJkGEs7lP+X8z7ZttGNVFVVJeefbdG7jbPz9C9xCgSCOXPm tC8ze3byyJHObzu4uY3vTKfQqXm8m+vIkY5DZMPgQVb2tgPlmO4Tx8nONo36Gi9ZunFDXtmcuasg zJg5D47LPyuUxiHEJyyBkL4oF+JwBD6cQjzgwwg4hTjhkAgwySmRh5whWFpad2ZC36lxxdJINy9g QIdBX0tddlwBnGX7Kk+ffbBr98+g0Oq1Ozdt/vrg4UvLPytY8VkRRIq/+H5pxubde87MmDEP4isy i9iKKAAmyB86cjln9XZIBacQydt0QPYI2ZLg4DjyjeF07N/nbNLQDoOhvlarOCHMTl4BAbRfuCgX IitXlUCk4tgtqAISByYcIQ4WI5Gi4u8WshYmV+GUyJBTqKa3ixPstmiySfGnVhBJHtv3mGBwhzgB j1StTgZIAc8KMPXSScm3hVMWmFxQV1WGIduFJWtra32DntA+iR3APmBMsB64HERkOSAA8Vc5ECBO TsGGcISrYF7ChIoDDvj2W8EJZlzlbQb2JEewJxylOHvpaMJSkMwZKioqwJ65G/aQ3gLgEVcECyxc mAscrP3CXFAXGi00QsLBjr0wF2QgTuBBKhAg+KUyBCqEt2XPdozZlt/KWgxUJIYiDZUYh1hy+ifR xM7AJEdiT9J6IRBjklOp/d8KTmiQu0MHQgCrHp5hA6eklUJov30SM8oG4ngkQszSqliXtk+Y3Gr2 UAWossHG1ACCHFNTXU12yJbtb99eeGM4mdbm8erq6rDAa38eD5OVrvkprMPFSmdxvkr29vYURf2X u5j19fWtxt8S/UucDg4OgHPhwoVvVpu3R/8GJ5hRS0srKipKVVU1Ly/vjev0Nujf4MzKyoqNjQW0 tra2mpqaRkZG+fn5XXYn4d/R6+GEYQNAwnRHejPm448/pmnawMBAQ0Ojb9++n376KaxLoU9q63fI 7qI2cYKukZGRLs0EEzro2Xg8HlhS9o4T0O+//z569GgwbO/evQEt6QM5nFaeqgFSU1PTYgkqBXKz srKSThXbogkTJgibCWoZFOtMB9spnCkpKVBAbm6udMzo0D7gtxkZGdJfAcCry1ujwsLCLJbCwsIC AwOhgnr16jVixIjDhw+3Kg908OBBKU7yKz20F6gyLy+vzt9eROvXrx81coRcUO/Rw8nRQY4JknKJ AfyoUSNlZUZ8MFxTQ8PBfqhc2ojwcJIE8Ht6uMtdNeHxIMgxnUeNlIXxqp7vW1lCWa8q/6qeGGfg p59Eh336VcF62fDlxhw5DsiApFxi6H5GjxreYdrczEXGfY1IElC9p4G+nECrqQZZWchOdP6Lnk04 s5bMv3vpJAnXzpSvWZ4Wxf+4YN1nEJHyQaZVnAE+HlKZtsKpb0plcfY1MuwwCYQPnBzkcMrq2VZo Vc8WOCsr9h/aWfBa6d9JnP8i/X/ESVwGjlDF4HIQh0iHOI9/vQOSEC+F05TYSOC8Hk5pMRAhoZM4 ocgl8xKJrkQJSAsconpn7AntpYvsCSWB30LdgGagK4QO64nglK2OVlVvCyfUAgSoFCgIAildWmg7 OCEJCBOTgp4Ql5b1/6Lfdmn7FMTEmPczhUzth9gNtLKAo5P9ED1dnSG21hABDlyCADIgKZe4tLTU QF+fCEgDQJKmImGonY2N9SCSBKYTXK6mXBLrgVb9THhyTBCTnfdI9ZSGYQ5DdXW05VK1qifG2erE BZbRSkpKsPiCKcvy5cth+rJr165WV5swVZBLSyY6ckzZWT4sx+WuJicnw+ROjik3uXtVz7i4OJg2 vqp8q3q2Pu+DWRXJF6ZaQUFBZJ4JE7TOLOcBEkxfYYK2f/9+2QkqGL+tHw7hUkBAQKuXGHamLUsw r4TcyH80O79aaBNnJ9O3StAIoXYgE5isw1zUx8fH2dnZwsICakpFRWXo0KEbN26UxQxx6Y/ThKCy oKZAHqpMbloPc2/ASf5d0Xl6KzilBOoSI4BaZCKekJAwZswYQKusrLx06VIiRhbuUn+D9RDYClZL b/BfACg3d73zKwSN81UmSL6pUhm2rwZzSc0C9pT+LA2A/8XKq31CQYGBifGxhw+UyYZ9pV/JcUAG JN9s2eCu5G8wDPtn0nb+f/nfCePMy13bUPd3+wFk3jhOhnVscFGwHom88fyl1M04GbazJd4LjfZt 5E+oBc4tGzeAi4quXoZjVuaKEz98J8WZsTgdmpNc1wedKuldwPfaGbs6SeSPeG8Qmyy9hj0nT5ok N5RJe1HpMAvtDfpqGEvaf/qgVQKcb+9vVi1wnv/lNNiw9t5tOBKrwvFf+C2oK3evTJZa7Utzc3N1 dXW7CGcXtE/wAnIXCwYS4vYHDx6EjhdaqZqa2tGjR/97Ea0Sio0VDBjQH9/OajeADEh2MlOCpIup /X+FtT6Pb5U630lAqZs3b545c+bsN00CgSA+Pl6OCSsNDw+P9v+39VaedwCcsGTR1ta2eNMEE2ZT U1M55kcffQRzjO7BGR4ePnLkyK1dRd7e3t2DE2bho0aN+qKraOrUqd2DMyoqCqb+C1iCdUlSUhI0 V3IMDg6G47Y3Sr6+vt2DE5DAtGFnV5Gfn1/34Jw1a5a9vf2iRYvWrVu3ZcsWmB5BhJwCZbIEERgM UlNTCRNkFrEE8kRYKkMSEk5pa+Tv7989OGEAgPV0WVfRhx9+2D044+Lihg8fnpOTs2zZMugPDxw4 sIylvLw8aLGETyJwFSLAhzgcgf8VSyQOl0CAJIRMiMyBVwiGlu7BmZCQ4ObmdqiraPr06d2DMzEx cdy4cUe6ij755JPuwQnTsfHjx3/bGsHSBHoU6H5iYmIgAsdp06ZBJJclcol0SIWFha3m8CqR/0V0 A86UlJQJEyZ831VElj7dgHPOnDkTJ0481kwwDYSeadOmTXv27Jk/fz5w4DQjIwPiq1evhggcgQOn JC4VAJ8kTDgFPiQ/1hrx+fzuwTl37tzJkyefOHFi37594FcnWpIsh8RflWmV2hILCQnpHpwwHkyZ MuXnrqKwsLDuwQmluru7n3k79MMPP8hxoF10D8709PRJkyZ98803P/74Y2VlJRy/YQkiGzduhGYm jf/YTMCROyVHSJ6dnS2bD4nLUkRERPfghFHB09PzfFcRLI+6B+eSJUtgjX+xmdaydPr0aXIKIwHE CwoKICI9hQhwyCkcd+zYAREpB04vtk0zZszoHpwwEsAa/wpL69evh7EBBoZdu3ZBfMWKFXBKmLAW hUhRUZGUScYJiIA8RCCJ9NKVtik6Orp7cC5fvtzHx+fatWswAEK/f+11CJK0c+ncuXOv8mEZ2D04 wQiwxr/J0oULF7744ouTJ09CHNZQq1iCOIlAj0VOpZdAGI4wQ5bygW62S7AM7B6c+fn5CgpNe5/B 4rC6uvrSpUvSI4lI41JOdbvUjoB0I6KuxhnftTRs2LBuwCn7+1KXUfu/zbA7suo13brXaopHIh77 0o8E+I5F8Qi/xgPvWoe3Fw9DocDlw1HAbn+ewG5lHcMereHKFLiGX5YSjwbCWTgb48G1FHYz5lg2 zUA2fz6bP85pNt7jnt0rnuQeBhycJw9S4PR4A/QQvPs7qwculwdHLBPfpGEUWz7ONxilsrkGs3IY Q2TTXntYmzB26/xYuJ4q5caye6qzG3LLaOyKktgd7ePZbd6j2JeK8BDZZT+U1S4RzqyRBlJD41hN ItgUgiY5PrufP9YomdU/md3xPprFh3PhQ4pEVlOMLZ6tjUhpfUewnFlwnghnuB74aCabD5afzeob wiIgte7P2k92n0Sy9aw6u8cjpra++2qRPR7xfo5e/IiwQXbIg43HC0LCEhJYfxibGsOfFRXCCxHE xISFJAriQVPM9xAkhvGCBSm8kGh+QkJUCPYcvDfj2Kh4EOOF8hP5SF2L6NRXpowE9HIvxWa+Oz8h MSw+QbqbcJoMFgvU9j6Vze+Rwn4c6DVxbOCUiR6TR7tOdWMl8J7CgdMw23WKr5uPh6uvm4eru9vU l/tTuqKX76GSrT/sDcSfwljfxLYNY+2BX4aCfQy/XUbAWoW0iETpVWIh8o6fYDhi/0lk0+DcElmP IP4dwl6JavI9PvvqmWZfx3v9E18LbcpZtoz4Jq8irSgB/R9uw6O9AwBz/gLpvg== ------_=_NextPart_001_01C8D00D.200DC7A3 Content-Type: application/octet-stream; name="image003.emz" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image003.emz Content-Location: image003.emz H4sIAAAAAAACC9xdCWAURdbuZDLJHD3TPTMdCOFwkENEjogRUCAZGAIBwn2qCImA3BAgXALrsCDi LkI4FFZRuWQRRcSsXCKOXKKABEEOdSGIQlxBkUNRQf7vVU1NhgnTsAFW/Mt8fFX1qqqrXl2vu6vH KEmSBgHkooDEaEnqBAjXuKUkjesgSe601s0oxaDTkmSKlaQYkSDAuYhLRGR75B1OBYW4RKtZOr3U KKEAqQbgBlDcPVGeKKkc/CoQrfq/oGyZAVDabKA3QGmTPNEsHb+uL/UOT4wkQ0augscY9Jf3SJKG OBNAzeiCfyweyVcZ/gSgXf6sy3Sdo9WWNsmOPu89/8uGJrlbH2tSEXGU5zGAyqU0lIcgSb5GjML8 VP5dAJVL6cnNym/HuAr+FeUIP8r3dUF8EtAR+A8yvQ2uhIKM4DrGhRXqGGvcmWglkH9hBZE3DnmF H0lZewJ1a4xwwPmCfqob6XAZMB8gHZo8UrQH/mSA9A2SPqF/4CwHFqdQnlBQvEgH72WTJ8qQDk/D QDzVmRzpcuYKU9OBM+/1CibdCh0LuRQVFTUR6ePR7yo4BiBH7Qi0JaKeeyJNfYDqR0xOMGlf1IVL iv4VOqN8wo+0wX7ogPhC9EMeuDISUTnhfUBhkbck/VANZdJYoDpQnxQA+wDqk+oe3vYEhCXJ34RR wC/0Z/JExyYhjnTE+mP6sRA98To3ljpILaTGUgbS1PVE+8aDswE4Nt7RRAl1l9oito80BOOvvzRY 8j3+VIovdVmKb+kqxlLLPTx86jTndFMqyT2NyzKWZlfkLPlSqWjuQv1ORFFb6XrUJvKTKwWQn+I6 ANlIQPo4f/nyZVDQ5VJGuDiMjsbScNQyK7g+ccl/8+/6gZS6cKSMbh0VUyFKuoPCmQ6zkXBhs8mI OHI+kpPnwtflpSPn149OihoVc//P60c3eHdlH4on+WmUkwTfeKTp/i+rcU6e1TgG/i7SuwOpvH53 joopHMWvlY78lKvOaiuLR1ujE2o27fRbRbPn1A+vj3RDlv5NeTYPfn9l/cBU1KOrga+FT4KTIZOk N0aWUd8YaYKPXI3j5aV7EH6ydCA89d2BzdpWrL3h7VExaxFF9aN6kJ63A71HsSUtOO5J352AMcAg gAbGc2AZAlLD5iRbk91n5SYksyCOxksGEOrQXcx1R+SVY4mvn7GIF6D8dE1yYv7YoGuaAx4gGaA5 cA8CMvzkLJ6itXrXyOTgWv3+a9vYWj0Va3U1pKP0VOfKAaDYkDlR5Kfr3wUkAJSeXPLIXYxFnShe +E0oqAvCSQCt0c9C+Db4Q7ARXMe4P6GOMatcopVA/v0JIi/a6xN+JPWF1K0xwgH3x63R2dHHvLRG Cyad0hojmOJvxhqN4Rtcm+uLZkP7pL+rOaEzyif8SBvshw6Inwb954G3B/vhyj6gPhF5S9IPYkxR HWh8ngQKgOtZo0l/tOauRfo3ALjgmovxjnHUi61k2VKOlIa1ty9WtSFYhd0wN+5PkX5qnuJb5OOs vcQ59i3G0vINPNz6S85lTwbk5lTK5zmYwFhaXo2x/7dajH27Urj8lTZcfkPrtdArzSVaP+YDvYHn 0BcLwIvA+AuuHyRbgAhqewYQ6sT60Q+RkfXyF7b2YAxIMQBdl9YU6hv0bXB9EfEkIyfqieuyNeYg 4nYC4WtMdY/+niv6cx7yTgPggv1pQcArDcXemY1/qReHoFfd2NDbp0i0k16eyVhavIqHY4/ycGcp leT+qipj34U7GHs+rs1Ymp/KeVJzzhF6zInrywDpOyHgB12xvwo9iP6aCnlfgPrpFfBKMOUX6z3J ViCC2hapvzIhu1q7TYgn/ZsDTP5QUJ+RE3USfbMFcWuBkvbNZOQdA8AF+4bq0hE9MlwahRnWC74R knR8eoo06WSK78C/GEvj9nEefILH/xCVSnJPYxPnJ0oxljKqcr6J/TAe9RsCkP6fA28I6weSrUcc tSNSP3SHLLyNYk7QXDEC1O/EkebFPMimAeG617s/OPjp9d0f1EC5boDsVKoHue87RGPPOe8l9j94 nO0xN3IPQGOqPiu5iGlEU5uv5qogUgYon/Ajra8rwpWBicAO6J3G1Ekw1buqaWGFqqbtN3VPob5r B5De6V6qIfxJAOmK+o7c6haXmkx66zjTFd+PY70UFvHYnydqniifirSBPJerwU/tQ9VLZA8hG3NC N1SOCxBliniMS7Yn14DsL8A2JHwa/AmY6vJd3IFyVU1Z5bJMB8qRX+TD+PRdrTxkuW4bKRmJqZ2k O4unyEY8vn87m/+bzxemvlP5b94zuJ+/GTbi9v3HcbWi8UI6Ee0RekhCHMVr+CcL3BpsBFeQ0hwV pHzNGEsgf5pD5CVdCD+SXnf7lyHxfICPHSnaAz/phMYO6Kbcx5MOH5+w1LvjJX8TwaRToVshvx1t RNKBC/p/DNw22A9X9gH1idB9SfqBxh/NCVpHmgFrgTcA6pPqnsg2hdAf2YiTkX4MAHfFvsX31sEY R0NgW7kl6alhKdLbhhTp4ELGvnEf8PCR04w9FWFHkPws7AiwfwvsCLDvedgRFH+T960EVLgU9NoS XAmMv6D9QLKKiDCBM4BQJ+y97ogMbyOlpz2KbIdw+wFRwfkmbIZ8xG0BSN+h94zVPden+1zkJf3D BXVP182GxTCU2Qy9mfUwQpJ+m5IilZ+S4nt5KefcdYyl5EOcl55n7K8M64HS/YTeAHu2uzk3rs44 Ui9IkhPXpbFEeiT9kZ9cKYD8FCfGKu1HnQCqe1ngTmSi8VcbTPmFHUeymoigNmUAoU70QyYii7e3 PuuHGMioP4wAXZP8BIonJ+oj+sOHuBygpP3hQd5kAC7YH9SeajCP6qdIWR9HHMUl018nlE37EOkt HtwQTNcT+iPZg4G4SPprhzTVyK6EC9fHHMRNBUqqD6pfOgAX1IcBgQxYfKjP2B5cJwWwaKEb3x5Y tDddR5m4XmmAdIR+KKYjkpGOeL0QCHFijFE7AnUuoPGDtZa5cH2RrsYDJdUX6aohK7lIXzRua0hu SRoJO5+04/1aV0slmYfdcI3qAOmoJjh8HJGMdER10RtHVE/SI7lw3cxHXC5QUt10R952AFxwLMUg 0BZjiY0mxzk+iqph5YKePBUrMZYS63K+iftHb1w3CSB90f4Rri+Skb6ofpH0RWNK1N0EP42pP2Jc +b9LY/rxf9r6puuJxhW1n/TUFhyuJ5Ld6LjagjLWAiUdV5ORdwwAFxxX1B9dpX6wXXKwf45ie6g0 bViKr0Ncqm/0m4ylsp/w8MZTnKdd4vHz7KmUTtpTjrF/UQ0evonjbzzqR+sW6bMpuAUYf8F1PwH+ 5oigdkQaf90hC2+jBXFij6R5TH5jgEHF5rQPcTlASXXvQd5kAC6oe2rH3ZK/bF1drZV8v2yG8klv 6eBwvZGM9EZ1iKS3dpDdLVXFv8X1sQVxa4FwfZg8UrQH8dTW8Pub630O0Q15qU6UX6wTixo3Zfc1 xLNnr/A+9dHTjB8YvoJxbsIBxiN6Sl6Sn7g32vuPYZu9koG5G3pvSeOjPkBOMGmOxsvVnNgPKJ/w I62vM8KUvzbQCoqfDH4GTG10GPI1hyEvPjUmL36QMS9+XWxefKwpL76yaegNvaOohrJlgOpCfU5z oR1A/RbpOYbjC6N38JlN7DkGPU994feLTVobN3tF/O30HOMp6G8K2jMdHAPuYeqZUNW0P6EwLiuB /EL/0PEtf45RfZjDS/fc5/7HzzFmot30HOM0WDzHSDCnORLM+dplO4H8f47nGKRDen5R+fuhQSad Ct0KOXuOYTDcFvO6C/SeBOQC9BzjDLgtGHNeCu8DCoeOSeFH0ut6nhQ+n2kBP4fMNJ+reyLfSwv9 0XOMnUjvB+CCe5GCQBrb//k7keL3mVLmoUZ0nkCaXZ+fNxgNK4HCPefx8wbRaznnf8j55QNc3uRn zolGdv7A/53GuXIlxr5RdzP2pD/AWEpswXl2B84RrImS7YvL0M75wN3Q2zfgumD8Be0JkiUjgvSR AYQ6cY80CJHX0FUBrenU/7EB0PpLoDCtU8Qkp/sMkYbiyYkxIe7VRZ1vxV7bENdLAmivFdf/50oP m3vEU5qs8E7cGuc9N2OF9/WV0d73hvM99XZ4B9AZ9a4BTARoP90Epv2U2mGV8zWr/Fr8BNPb8ff8 AXuor3+sd3npzcE9dIX79yavf7XJK+Jvlz30SeiK9tCnwWIP7WvqxfbQH+MeTSC/GI//iz10YKUp f8geKkMHtIcOBMQeulVNc2xV87UVpQjk/3PsoaRD2kMLs94JMu2hQrdCfjvuoVbon/bQQYDYQ8P7 gMKhY1L4MYRLtIceRMadwLX2UKE/2kOXIP08AC64h1oRoHMR/XAX3VsaiXNadFakr+TGY9seKT56 1nz3c5xfxJk9hKVUnNmj+K9wZo/CXpzZA/u1BMa+xysw9qytzFj6WzKXP9KUh2/q3piL+tO7AHpG 3RmoDeAvuDeSjJ5RUzszgFAn9sbeiLy6Dpqx+xwj5GK/E0x7YOg+SOWKPhV7YD7itgDhe2B1T2Sb J7S/cpF3MgAX7K/I7w989IwW7w8Y4/0BMb0/YIz3B8T0/oDJ8f6AmN4fMMb7A2IMxlR+Qfo31O9E WAZItwkBP+ia7w+qIgP1SXuA7uvxF+wbktHzpf/+/cEI1h8xKOu/sUmoL9YC4f1xq+7/X9v0ElvL iOn+fvHFKYwbDM5k/MYT9zEuPzWWcZkXor3JAVsFTwBui/uEztBXfWAiQPZKI0Dc/69z5WvrXHnx BWpefJw9L76+NS++P+7/q/8Btsuo9rHeY2qR7VL1+0tN6hdu8or429l2eTxgu5yG7UJ+sY7cSttl x65TbE15cGxnb6nOm73zdgzzqqZpN3zW9dSuHRgpRWshhktwXTRhSemCcBLwGTAFQjpfuQswItzN NjChm21HuZHlCOQfeIUuhF6Q9Lr2zGZIuAyYD9Cc15vnN/I9Aukwsetxb/9Fx4JMOhW6FfLb0XbZ B92QLf0RQOdqeD9c2QfUJ0L3NCaFH1mvqx+qISHtHeJ5Xiau0wm4lu0i9BfpewQUwRzVOfx7hIuI O82kRXunxtL1wjPxkXh3MEhy471q0UlZNyygorOy/lEPpkqrtzfyRbVl7Nnbg3NGP85vjGUsvT+Z se/tqTy8dBrjgulzGPtHz2e8QFrE2H3uVc5L3uTxmXk83GkNY6nR+5xPfcj5pXzGvtx9nD3/5vFX 7M5FO/X17NOiP8h+6QBkQ5HkD/82YgNFwt3MbyMKyvPvFbBv09Yt+VePiiEsOzkqhkWwW+GrfxtB 6SWpljRm1f1SIcpph5BTWi2R/d1ppRz8NqLg9fuZnZGNdJn4XmLQmfWjJel+KbWt5VkqYRni5iZ0 RlwtCkor4F/8pHUbyalsv3THKNKRCtC3ETlIj9Oqz7q/Ly+t+Lbn6HcneVf9DuOR8s0oV3YU5ck9 2iuGvo2gU63kL0CeJveVHUVlkdUT6dsIskkSUX+ag5OBWQD+gjZSWQRyARq7GUCoE/ZrDiIbYyRf z7g2IS3pOQbAXGb+0Oc8QkZxJKd05Kd4ChOEDN7g2i5s3hiMmQuob7iNVd0T2eaNOM+XL29E1xDu avN8Dq41FYAL2siVEPBihg+R3Dh7QidzB8JH4bFgsvTpO5/ip+OLnzeWztVK8R2cnyLNGcTYFzOd h99/lYf/gXsiknf6iIc/+ZSHKxfy8Fi8dST58phUYs/TsLvBvt54+0hh5S4evoi3kJSuXgPG/qNp gfgMHl7XnsvnPsrYM7kXj984jMfPn8B4wYbJXF72acYF5mcZ+y7MYuz+4TnOi19i7J+5mHFmzhuM pV5vM17Qfi1jj2cj44JaWxj7yn/MGAv/DdwnRFp/LmBAs54M/EPjntzNXH8W1LJhGI2KceGW3Y1J vL2W2UiY+oRsRBx7Jxvp2yxWmcD6swzlNEQErT/0HGZJyLdZOuvPdCpDZ/2ZLtaf6kinAiHrz/Rb sf64UffjuM58cD/gVQB/wfWHZEsQQXMq0vozB7KbNN+CaxOtO7T9hHK4X4RpXSC/ISyPiBfpiIVf rHNijRMywUhabG2birjxQEnWNnr+ko68NGbggmsVtbGG5Jbc2i42s/yWfN0Z5kR6GaA+Sgj4Qbr3 4d0gH4oM1MfDgPA+Jhn1MdUlUh+3g4zqSWnIVQGoHmLdT0b+akBJdXMOZRUCcEHd0HwcCRutD65L 73b6410PP/PhxhpOkhz2ZYxbyozay7V2+iDjzLTDPJz8NeMF1U8w9pQ5xcNLT/Ow8SwPP3yBh1v8 zvj0K5KHrc9zDYxznUYefi+Oh/9l4eGeNh7+3M64YI+DcZK3FOMbWyeFjknnnQA/kAMdUz/+Cwjv R5ItAUhvkfoxB7Lr0ymfK2I+UB3IHzrHKCziBYenp/lFTrRFjJeDiNsJlHS8zEPeaQBccLxYEOhV 7FupEZJ0eGYjSc7H07ATnJVKKSxceQBj385pPPz0Eh5uvIGHL+7l4dXf8fDMnzlH2P2cuD7NCXTB dc/NqUj7JbAUmQzASoDyizOiJHsTEdS2DCDUCfsvE5FXa7foi0hrHPUZufC+oTqNB0raN+nI2xCA C/YNXYvWD8+I2FTSvS9TZhxphpREl91wDRN0Rbq0AOG6JBnpkuoSSZftAvWMpJv6ENQASqqbC7j+ SQAuqJuaCPTBKTf6wo+vdv2xso2QaJUL//KPYmnVcwM57Kn9cPgj38eOkPytnVzT91Rg7P8M327S bMhLZuzJ9fBwg1Y8nNCVsc/4KGP/piwuf6svDz88nIfTxzDOHDuRh/s9zXhBy1zGngeeZ1xwF+6A qcdL4Q4Y7DYuY+w/u4Jx5n/e4uHU1Txcdx1jqeYGxgvKbmLscW5lXCDtYOz7eRdj9/G9jP37DvHw Y7hDxnX83Qp4+M1vGPsM3zEuyP2eh384zeWHf2Ls3/cL48wdFxlLj0Z5qJx2nWIYL2gVx/j0E3iO hHjPcCvj3P52xpFGcsne+XePkphdSWN5MRA+lmXE0VimsRNpLC+7pePqyv1BrDViT6D5QxBhIddb i0Ta8HwiTPLw/Sc0HHpNcb3QvMj+v13rNAcfITOcuiPEiXrJALrzuvcNWutoTND4WAWEjw8K3+ha NwfXmAqUdK3rhLzpANxlVIe1j/qrD1auXlKBRWNaSYouzdg3IUFXSyWbR5m4HtlKpKf3gHA9kYz0 RPWKNI+oHbzOReMZUcXGkg9xOUBJ9eVB3mQALqgvVA13nEnVyt4C3VC7NuICpJv3gXDdkIx0g7+I umnH6od/4MLtiFxMvslASfXRDnmbAnBBfdRFoBPb9/juOAQjqQ97lkM74uMSPefR2w/d0mjcRwwK PP2l3ZV6ln6bhr7eduN7PrrbGIyyhjOfVOevKb76ZVOlJnhqA/ZdzOPhNTt4eCZOjJH8xEnG/nbR qSxcy87Yj19MYOHVlRl7Zicx9vlwghr5/IMbcnmrdC6v34bLq3Ti8uhMLj/dh4dfyObytHGM3UkT efz0SYwzJzzDWMqZxnjBgBmMPQ/hyQ+uV9D8Rca+ugsZu5/DEyCqx6TXGGcOX8lY6o8nQdSu8usZ Lxi3gbHn842MC+p/wNhXG0+GqNzJH/HwiN2M3V1wJ0blNj3MOLPBUcbSC8cYLxh/krFn4Bke9v/M w2t+ZXy6A+7AkN/TEndg4NytMYwL6poZJ9WSefgc7sAgTzqpMo60Czsxbv7bNTY3Ct+SI986MM2R TQD+grY5yT5ABI3JSGvHWsj+l+PViOvFBEBTR/jDmWRCHu4Xaf+bvZXKiA2UKcoT5VN5Yt8XMhEm WWg68gsZXZ/k5MLXlrVI+AZQ0rVlDPIOoouFrC0PIlDeXWRzj8C6QGsD/e5G6OpCK85wSLIgIwnZ 7DnBFKHPl91hv7/iRVlX/pLHCFxRuqNSiudTWON/S+V8/wDOn01j7Ov5Fg8nbufhfUd4uPp5Hl7y O+dUYyqV479oZix9Hs/Ys6YiY9+Su7h84n1cPvQBLu+eyuUPtOLyqu15eM8jPPxmXx7+aAgPr85h LLX0MV6w7K+MPXOnMi549u88fCyXh/c8z9i3/R+M3e/PZ+xfsYhx5pJXGUsvLmPsWbuS8QLbO4H4 tTz8y3ouL/QzLji8mbHvs22M/Wd2Mc48upexlH+I8YJaXzL2lP+KcYG1kLEv+jvOq88wdr96gcs3 Sx7SY9K7Bsa+t2MZ579mZuxeKDPOnqcw9rscPLzRxfhmrkHLsL58g3FJa89rwA4Af8E1iGQfI4LG bqQ1yA/ZHzGuxfwNnf/kF3Oeph8hNC5UJvxCHr4ehctDyxN+sR6G5yW5kF2tHFrLKF6sRaIOgkW9 kaTY2uRDXA5Q0rXJg7zJAFzQ7qE+ryW5n4rXHWEls5E7oezVuACNsTVA+BgjGY0x/EUcY+1Y/fAP XBWA9lrxrG8e/NOAcH3gPjrag3hqa0m/u6qBvO5AfuoTcvSbYwn793lfMLVlTOcuboez311Rt8rA WwDN6z3g18FU70Tri4k/yi8mCt1h3PmEH+ISnbPojoztANJ7pO+m4su38SqXP2VnVUhnFK64Yj9j ir9dzk19gnaQDbYfTPckMeCv5MzEbrYXE7+S9wOZV+jOBTmNQSQNjkd4r0uPzZCQxmQ1gHRn8fB8 CQiL338pzPrwDznzPR0N0oDvgdYArWGnEtIcpxLytc8qEMj/5zjzTTqkM999FvwUZDrzLXQr5Lfj ualnoXsX8APQNtgPV/YB9YmYwzdjPp9DXxcCNCareyKfpxD6i3RuCkUwR2Mn/NxULuImM2nR3kPn c4XlSvfOZP26Jd/dfwucB8cdMTsPjrMPdB68UhQ/731OZexrVpqxZ155fv57QE3Ox3AHTOkjvE25 vr2sGupG85zW0A5ANvqC/OFnmXIRT+7mnCWwkuqkqYHzChuWWo1U/NRf149ezH6/lZ9fmka/yUoL FZwJdwo0FjwLrMYlr/D84iwTJTFDr3SWwEEFzYsxJoyKNcb8I8aoc5ZgBlLqnSWYIc4SFKCeKtKG nCWYcSvOEtC4IRv1TmAfUBvAX9BWJVlN4FrnvYuPNX4ug2wyyktMfUwgf0DFwXVe2B35kG0Bwu2O 65k79L4+F3mpTXBBO4yuf5XvDPH7Pexc/W13/p7sDOqHvUBDAH/B/iDZg8C1+uMq7Q3qnfRPk0H0 hV5/UF+sBcL742bYgd1QbgbVI+T7+6pRR9i+Qkzn76tsXcO40jO5jGc06sz4UD8z45kfR3tfHHF7 fn8/EW1rhb7yA88AdF9ytGy+drRsXvwvpfLinc68+E62vPi5OH9f8w84f5/6dKy3q7vo/H2lzN+b /PrFJq+Iv13syCeht6egv6fBZEvR2tHf1Id9O3g2rnsC+Wmdpj2F9uxbZUf+fOZ7tqbQb7XFzavH fkdw2k34renvz/yMmhfZvGhicF00oT1dEE4CKH4NkAX8CNAcriA9Ya0gGRVjLIH8T1hDdSH8SHrd dvQyJJ4P0JzXm+c3cv6edDigRTb7HUHBpFOhWyG/He1IqAa7Pv8dwTNg3g9X9gH1idA9jUnhR/Lr 6odqSEjjmZ6BNAN2An7gWnak0B/thfOQfhoAF9wLLQjw391yw44cgdO19DbGLUm/9+UW4aLZ3CKc g6/RyEKsh6/RiI3fch4XxyxA37/iOZ+qxNjz/n2cLzRmjGZe9bSpE9endtFYTgj4Qbpn4aYG0m4D twT2ApRfnLehcvYAvG3whLjQ8zZXa3cs0qJ/2N5IuiY/9SeBZMTkRP8JO2UD4t4CwvfF6p7INn5o 34xH3mwALtg3dG16i8W/6aR3W76cXP4t4MH3ua0y7ggP33GZsSdL4d8A4gddyJbxT65yC74JHIN6 lQdI702BAiBU/yQ7DFD9M4BQJ/TfHZFXtq3ILiQ9E4Q9QvnD9T0PcdOAcH3rrU/X+ztANVCuGyA7 hOpAjn7/h9Yl4j4np9x2v0dcG3X8AbgPUNAZVG+Hwag4DIdVoTv0xw2vO9Rv7QC+F1z994hP/tKh yeJRU5iu6FlAt2fuZ2ERf7vYETXRDjqDcz84Hkx2RIZht+owpDkORO9WyR+qOxelB5A0OB7hva71 uxkShtrONE4zEOcBgs9NqWC4iOOUSX2NQY1FHvjZ/2OnGzxUHsXTvCO3A7/Ju/Z0R+ypXzOu8IHD u6dLB+9z3ru9w+PbebfPbut9ql+G98TuTO9nvzfznh+0EN+u1rt1v13l5P8PH167K/8VeqY1V/hJ HULnNJ4bACagLKACRiwS9bEAPwR/ZUA4scZQnidi69nOxybbSD/JIgFYpKF15lfILyHdpdiGtt9j PbZfY5vafgL0yh0X29wWG5uuW25UbAvb78Y02yVjY6ChLSr2AZsxtr6tEa4Z2o6n0GG1A+2odpU6 kk5mxdWy1TDdZRtpqqR7zbGQTzBVBaoDtW1PmO6zjQKoLZHKrmmqZ5sdl2KbEpeqW/ZEyCfENQTq AffZJsbVtj0FhLcnBjejidfol35ml+2s2ax7vQtmk+2iWQZUQLP9Yk6wnTeX0e2X/uZKNqO5um65 UZBfgi4vme60XTRVsEnmRFsMEN6OSTAgLmLCk+5qXKVfaL14zvKbHGM9LQ+2HpOHWb+S9cbZSOtR eaz1G/kJ67fyOOspeYz1R3mE9YysV/5QyI3Wy/LzFottskXWbZcP8vEWM2C0jbNItr9YLsqTgPB2 0SK2O9CuSGPiQflDeaG8Rj4lv67bph/l5fJ5eYX8k7xK/lleLZ+T18s/AHrjbYm8TW4k75ej5cO6 ZV+yHpF/sX4JHJQvWPfKv1lRa3l3sfaMw1ibdY32PGmbJf9qmyD3tffXveZAez852z4QyJaH2XPk IfYx8gD7WN32XLJNk/9qWyhPsC3SLXusbbE80rZAzrHNl0fY5sqjbLPlcahXeP+ct2OPvUZ7NKWV vEapJR9Vqupe8zjk/1HuBmrK3yn3yoXK/fLXSl3d9qxXGsmllYflC/ZM3bLP2rPkH+w95O/tDwGd 5R/t7eXz9nbF2jNUlSR7oD2R1un6jpPW7o7jVr35k+n4xtrbUWjtg7SPO3609nKct/Zw/GSlsRap 3AaO36zD1Qq67Rii3iH3V8sBpeV+qkseqCryUNVerB3/ceD7avwIid7YTnR+aJ3jzLMecC7TbcsX zn9ajziXWwucb1qPIv1h5xrrIeda1pZIc3Kuc5O1vHO/9ZTjsG7ZhY4j1q8dX1qPOQ4Ce63HHbut /3F8Yg0fZ32wuc4MtCeS/l52TbXW1IbpXq+Olm2tq40ARlvraeOtyZrPmgTo9ctC11xrP9dC3XJ7 Qd7T9bK1h+sF4HlrlmuWtY9rZrAdDdHvJoBuLBOAHsA7QBoMhwNgYTuQHSFsCnh9wk/2MLWbt53Z VQiRK/KTDUH9geEbvPfeAv9agNvAt96Oo3sOsqOJn7FP8sY9eoLxyxl1vRSeP/svjFsPXhzkB+5V /zR2nAUGTlPMrbrQqQrYEK6NcDf4SffCCZsNYqSp7bAZagE1HSJfKQgSr5GvtKGMo7QhwZEAiHwN ke+8qn+9hoZzaiMgxXBWFflGI99n18g32vCZOiYAvfmwzfCuut2wXqU2JwPCiTbHImKnYZ2ab9ig 7jH41U8NW9Xdho/UHYaPVSq3qcgAFnno+QfJJxi+Vv8CpBmiHc0NkqOSoZKjiqGio5whGajjKGNo 7tC7bhlDK0e8oY1DNbR2yIDZ0MJhMTR1hK8nnWMk6SVVf338R8wstZxxktrU+KRuW9MhzzD+FZii tjb+XW1hnKGmAXprb3njLHV+zEK1W8wK3bI7xrypto15XW0TsxRYpLaPeVntHPOSGt6evUacAQq0 pzJ0KZzQL60NzWMHq5tj++lebzvkO2IHqTtjs4EcdXvsGHULoDce0mMnqPuMk3XLzYd8p3EiMAEY o+425qh7gfB2dMRC11vVv096OS5L9Zp66F4vHfJWpizgcTXDNEBNNw1RmwJ67XglbpjaKS5Ht9y2 kGfEZQOD1FZxfdW2cb3VjkB4O/aa8DvC12iHZn5E3QzojeftkO8w9wB6AX3V7eaByDNQtx3xkO8z DdItdzfkO0z9gd5Aprrb1F3dC4S3oyMm5sNoh1hHvNiDKaxX53Trw2orK/RvfQzoq6ZbB6heQJRB ZQ64RhltLQPUVpa+AMqw9FDbWh5WOwLh9dtLNkFI/TZj8+t6jbK3y13VHTL0KvcEeqvb5b7qFkDU bx/K7H+NMnZboTvr48BjwKPqbutD6l4gvH4dbTiPjbL0xl2hrY3axN5ct7+aQ97K3hJoA3RU0+1d 1aaAXrnf2nqonWy9dcttC3mGDfPE1h3opra1dVI7AuHt2AM7/8FrtGOCUlF9T3HpXm+T4lS3KfHq h0oZdbtSXt2q3Kl+AOi1w6ckqXvtLXTL3Q3d7ICOPrZ7gRR1l/1BdQ8Q3o4WaMNZRb8/TqMVdzsW KXpjvKZjgVIHaZIdS5W6juXglUqSY5Wi147z6k6ljWrQbUdLNUZNU6PVpuolpYn6i5KmnldaqGeV 8Ha8Dtuhd6Ad1aQiJ9Z7sjtOOBor9zllZYjzS7teW4Y5D9lHAWOd/7aPdxbYxzm/sY9xFtqpLZHK bugso5x2tFHyHMN19bTSkaMsd4xQljmGKq86Bir/dPRVXnf0LtaefU78fxcwxvSuecmZbn/A9Yst y7VW99lCL9c7tn6uPNsg12pbNtIOc71nG+r6QPe5UjNXtN3s6mgvcE7S1dW/nVPsB4F9SLfH6QPG wT/GHt4/S1yYLzb99uxyfSmfdw2Sf3U9onvP95urq3zZ1Vk2aF1kk9ZVtmiPyGYtU/e+OEYbJn/p OibnuRrr6mqVK832hqu5bRl4ictrW+RKAT9Y7PlSBQ3vqQL3XzWKhlvQfoM5Jd2nDbe20L6xCOiN uRbaUUtr7bClPdBFO2J5SDtm6aadsOj1fzet0NJEG2mtpe3TvRerqR203q19Ya2sfW51a4es5bXP rBW0PcF7sbKoqwo8hDZ1wV6kd82HtXaWXtpKcx+tr1mvPX20XuZ+Wk/zYC3TPAwYifBIrZ9Zr+wR 2lvm/lp7S3+tm0Wv7H5ad0tvLdOSqfW0PAJ00x6BvrpYxJgLv7esjbbNAVpE4f8LAmAosntCeP/U 95b0W9t0b0l8z/Lx3j7WHowr9x3HeNHoXMarGiwO8ubvbH+ae0sDbJc0rOvCDjEhHI0wjY1qgHCh a7xZjnJwSMF7xDLIt03Vz1dG3qaWkbcyiOvVQb7Z18h3nzxL5ZgZtJe6IF+fa+TrKvdROXoH83VD PrL19cb+I3KWmik/pvZC/sfxxKuPPFh9TM5m9oJHKnJCJ2ZEPSYPQ/qhqkd+UW0sv6BWk3cCO9QE 2ehIkA0Ol9xM9x7SJbd0KHIbh1Vu7YgFDHILIK3YPeQe1F9T9dePH+Q4tbbtrPKu7aDuPvm+7YCy 2fa5ssV2RNlqO6Zssp1QNtoKmT0Rqe+TbdHqT3Ip9aBcSdem2CtXUXcjzS75Dti7ZcGl1D2yVsw2 aoX9d8c1bIoe9o8Uk7JFaQDo9ZsHcq+yHdgJ7FE8yj7k2afbHjPkPe2HlAz7F7plp0Pe1H4Q2Kd4 7buVZvadSiv7jmI2BbVlc6A9lYuGSnDPonviuapfeVfdqHu992EPbka6zbBWt6gfKX51l7JB/UTX 1pun5is7lL265X4I+WYlH9gBfIj/uE+s62KfaoE1YMU1+mWoY5my3zFdqekcqHvNe50DlLrOQUo9 Z7bygDMHPBY24hO6/XLI8ZIy3LFGaeV4T7fs5o6NitfxrtLEsRp4W0lzvKm0cKwo1i9LYetVCrSn xlX6hWyJk7A/v3N+a2/g+ru9hWu0rk3WypVjb+caYe/kGmnv5hpjf8g1wd7F5WP2a6R+T3c9b7/g PMfKjTS/foac47xdrJFvoe61UXe9sb/CWUdZ5rxXedVZS1nkvEdZ7KyqLHVWKqaHXGzMFwM2YiQ9 LHHttW12TbUVuOrZTrgq6Npyha5E2ylXaduPLrx7hP8C0v/supPZvZHK/8HV0Papa4Ytz/W57RWX QVfPL7ni7PNcJvsccK7LaJ/hksAXi9mKVg37CNZGPdvHoU2Qq2qaXFf7p64tV1dbbG2gLbCmagut XqCZ9iqwXPfdw/1aadmt+eSy2lxduzpRe1Eupb0sO7SXZJs2H3b1XNmqzS72LqU52lMmYPtGGk8d tCWwy6rr2nEPaVUs3bU7LVlAH60S7L6qln7aPczmjVRulvaqpauWqKujLtod1g7andY2QEutIvRT 3tpcK1PM3u2BdryADZL6JdL1emg+c6Z2xKQ3vrO0L0y9tQOm/sBg7aBpGMLZWoFJr9wh2kTzEO1F XRt6sPaKeYC2GLb2InMW8CjCPbQXzGI9bIh6m4BUIAHYCPwd+P9m59Lvt5OdS9ys3givqd0Cxu41 C73DF/fzdsC7k7vefYTxemcq49rfW/40du4qrHtk5+qtD2+7CtV3XM+r61yddW2bda726nuu1uom Vxt1G/CRqwPQhdmH1TA2hBP2oQERW11zkf5b9QOXvh34gaulY6OrjWOdq7XjHWAVwrhfLmYHfoT2 bA3sZ8nigmBxzVj4P3G9rhxwTVIKXD2Vc64qilk7Y3doR3TXW5f2hT1BO2QvB3Zr/9fdtYBHUV7t CQkYctndkNkEsoEsFytipKBIqSIZ2YCItyioeEEWEyJXCRBSQJRBqEVFBbFoESWApUgREAGRAi6I CBQBFQGRSyQIKFqkYrVq5X/fM/uNa5Jd9llDq/88z5v3fNdz5sz5LjOb3dnvaKZ/CD4i61o4PQ31 fzvi9VbOE+mFziPpDzr3py9yvp++KeK6vSd9q3Nn+nbnjvRtzr8Dm9K3ODenv1FtvboM80ev4DOa NjWcJz6C0DrrbRzd9W9SC/TXUnvqY1Nv1gdGXLNu1otTb9PvSr1TL0wtBIr1u4FBsmaF01Gk35fa Rw+k3qr/J/UG/WLH1fptEf3YXe/j6Krf5eis93Vcrvsdl+p3OC7Te1V7ZtMb5/fBGdatPvqklL76 +SmF+vGIc3KhfiS5WK9MHgQMBUboR4HjEdetYXqrlKH6QylD9A8irltD9IqUAXplShHgB3rrB4EP qq1bRTif24PrVrixUKT3SO6n70+CzyOuXbguSQP1wqR7gBFAGdJlaBNpDI/Es51SvWdyqX57RF+V 6n2Sh+mFyYOB/kAR0kVoo+Z9tQ8u5vWpH3neKNZ31y/WrwSOR1zDivWjiQP1ysR7gBFAGdJlaBPp fMrQbxn6L9M/iLiOlekH66NPrHeVWM8qYctB4IOw69hv46z/D/7/to7xe1Bcx8jbXzJ9B8a8Izz9 1BvCLf6yTHjprXNtPmdFyi9mHduLwOwaXMe61TAfYuhp73nS0t7zpKdt8hx2bfJ85FrqWeN62fOa a7pnpuspz7OuER7TNRIoBXqhfrsa+uH6UeK53zXUM9o1zDMSbYa5RnlKXGM9w+1nKWNhy3BX5Gc+ 93lGuBTU/cxstJtyhnZzPFNdxFxAtQug3bIztAt4lrssrLDb7UK7A2dot9tzwLXbc1Cg9B1GOwd8 TR+Fm8sOe5xpFlz2s7CP0Y57jUi+/cRzVdpRz7Vph4ADnuvS9nquBrpWW+dPZuE7HLCdc0S4+6nD WV1cHwGDs37tqpd1XsRrGofy7xs1d51u1ATIcsVnZbrOAdh/C0Adah/B5xVDs7yuY1ntpd9wfmD5 x0Eo//0LtvPzu0h++Caro+u7LMP1Lez/d9ZVri+zrnadzOpe7TlRWSNNa4q+Is2VNzXyul5rmON6 sGGTiD54AOXjGnqADKCB64GGDtcfgEh9Bxo6XTc3crl+1ygtYt/3NmrgGtfIDWS57oeP723UzFXW qGm18/kqU9Oyg+cT7rp+nulxPZKZ7jovs47rnMx/R9xPxWd+7YzL/MJZJ/OEMz7zuDMx85gzJfMT ecYSrv9WqD85M951MjPZ9VVmSsTz+hblpzOdgA40dH2bmY022dXOy8zAc2DsS1UMDER6TfDZRbjY GZixxjkgY7VAtUtHuwfO0C494wFnA8H4iM/F1rnbOQPuiyP6b43718617lbOde6Wzg3uc52bga3u 86XfDhgD6lDjAv8yorGcaJxR5szOGOkcnrHYOSxjkfPBjJURdT2csco5OWOt8+GM9c6HMjY6J2Zs cprgqnuPgW7cbwb3vuGuYQ/3k4627h6OdHeyo667MuK+N959MLWu+4PU+u73Ux3u3akN3HtTdfeB iM9qmrkTHIb7GoffPdkxyr0i4p53jHuVY7R7rWOke51jmPt1xxD3esdApKue1/vYU92aGnksb9Dr pi7WZ6XM0++JuC+dpw9Mma8Xp7yo90t5SS9KWa7fnbJCHxTxc8q1eO7yrl4n9Zh+U0R/fazflnpU vzO1Uu+TekD3p+6F/L5+a7VnT1NwPhXJkc/nEX1l8v36Jcmj9M8j7nlH6Z8m3YvPHMcBE/HZ5CT9 OHAi4p73Ub1d8gx9eXK5vj/inne2fij5Odwj/An4I+4NpuqHk6foFdX2vENxPn3P8BnlQD0D+/ff YY9ZEnFfWqwPxn60P/al/bE/7Y997GCgJOJnlGV6Wf0xujvpfnz+GGntGKcXwVf9k34HoO+koXo/ oK/9GSWWYfnMtR+vT+IPcxLvUd5COlLfRfqmxP76G4mD9Q141rQhsRTpUn1ropqfRgb7jNTHSP0j tD2G51XH0NexxH5I98MzKzUeOsI+mGE/W8rHnvxhpPl7i2frM9Rm6D8F4DzWFZwNuAD+r26CYZUh Kd+h5Re5TgXL+NtK3SDTZn6HivfdPL6/ravv6Yrf+GZdftzm50saG8xXzHL1veSLjbg46ufRyrD2 HA0lFegsZMnrVb+JRnxcT+RRN/UmkKUOfldqQavVxAWB9sbwx07lzZgx4/SRI0dOK/782pdfTul+ QV7va197rcd/6i4ZknGJ0e6jvn9LMn7Qy2czOM1qfTVFXiJwF0B7WUflNYFMm98E2H43CleCzwVY F+3M88Csw3IesElY1WG+kln/ZqTbSA3rj1pn6Oc3oP0NnPWeOIJy3I/aqn5Q1WyJP7SB/Ve1Ab5B 7g96w9mgzmsXzov6LRvqQG9d6Cco14nJhsOHD0dtA/XSBkxFQRvqQm8S9BOU68Zkw6FDh6K2gbpp A7YiQRuSoNcJ/QTlpJhsqKioiNoG6qYNbtsGJ/S6oZ+g7IzJhgMHDkRtA3XThizbBjf0ZkE/Qdkd kw379u2L2gbqpg05tg1Z0JsD/QTlrJhs2Lt3b9Q2UDdtaG7bkAO9zaGfoJwTkw179uyJ2gbqpg0c 69bYbA69LaGfoNw8Jht27doVtQ3UTRtybRtaQm8u9BOUW8Zkw86dO6O2gbppQ1vbhlzobQv9BOXc mGx45513oraBumlDe9uGttDbHvoJym1jsmHHjh1R20DdtOFS24b20Hsp9BOU28dkw7Zt26K2gbpp g2HbcCn0GtBPUL40Jhu2bt0atQ3UTRu62DYY0NsF+gnKRkw2bNmyJWobqJs2dLdt6AK93aGfoNwl Jhs2bdoUtQ3UTRuut23oDr3XQz9BuXtMNmzcuDFqG6ibNvSwbbgeentAP0H5+phs2LBhQ9Q2UDdt 6GXb0AN6e0E/QblHTDasX78+ahuomzb0tm3oBb29oZ+g3CsmGwKBQNQ2UDdt6Gvb0Bt6+0I/Qbl3 TDasXbs2ahuomzYU2zb0hd5i6Cco943JhtWrV0dtA3XThkG2DcXQOwj6CcrFMdmwatWqqG2gbtpQ YtswCHpLoJ+gPCgmG1auXBm1DdRNG8psG0qgtwz6CcolMdmwYsWKqG2gbtowxrahDHrHQD9BuSwm G5YtWxa1DdRNG8bZNoyB3nHQT1AeE5MNS5cujdoG6qYNE2wbxkHvBOgnKI+LyYYlS5ZEbQN104ZJ tg0ToHcS9BOUJ8Rkw6JFi6K2gbppw6O2DZOg91HoJyhPismGhQsXRm0DddOGqbYNj0LvVOgnKD8a kw0LFiyI2gbqpg3TbRumQu906CcoT43Jhvnz50dtA3XThmdsG6ZD7zPQT1CeHpMN8+bNi9oG6qYN s20bnoHe2dBPUH4mJhuef/75qG2gbtpAq637rNnQOw/6CcqzY7Jhzpw5UdtA3bSBEWTZMA96F0A/ QXleTDaUl5dHbQN104bFtg0LoHcx9BOUF8Rkw3PPPRe1DdRNGzi7W35YDL3LoJ+gvDgmG2bOnBm1 DdRNG16xbVgGvSuhn6C8LCYbftqzwZXQ+yr0E5RXRmXDuTiHFOAcPDNsFpTVM+EpSE8Eqv92XEJC w2BdPouFyOeMrnZGgvTFdKKh1THA7QBVx7qL1LTH14/Mq8P8EEC060E8fTbeYeCkkhoO5QOcg+0z xJZ5M9JtgA0ALjf8qmmrwIy74pRxyf0bEy0hE+N+0u+HtkSfvA60oSswGTAB9dsZBuSafBntb4nm or0X4LWg33n89aUbfKc33nFFvT79hfls/mz4nf6q6Qjn91tQuQWwA6BPPgF47Wh3dup+7UHHfvs6 MW5VPyg22Y6AeIVQFZl9/K98ffyhXN8/Dm/zkX+Ovv4rfDMLMc7dmuXrzUn7G21OUv79pfha+bjb Ex/9LH09Ez6mr98K8TX9/HL2L8/XnEMYz2ou+TnGNeeQd4HQuOY8UptxvQzXkr8xz/m6lfHD54qa 9qPPMzsrP/F3hk3ULwVw2L9l2xSJLngGUoj3PnrxXKpQ3gVfgncsdcEvDt+Nt7D1k/ewqfcG8H1t zClF7QH45Vsv2nrx8zKFnbTuOZ20wFPCZuErFr+Ht3wzf/QXVnpuXB7Txkzd4veaWXxdrrBWfpFw YFhni3t1FzZvwPuS2a75EGHty7HC/rnjrfzJDwl7R04VLu//R2Ft0Szhiul/EQ4Mfdkq7/U3YfOK 14X9rf4ubKS/K+z9bq9w+YkDVrrykLCWckTYbPmZlc4+KVyRgPcb8zzD/JpydO/bUPHBubAnoMfh dw3ADYDJkHPAIPv3lFnWGGgKXAOEHupz3CnIrIXrK78ZXA991QXI3DdgfpZ0Apg2h+ZTJlS+KksM 5tcPsqqnmP0SbEddlFnGQ/knFW7uirQJlAJV94vRjgcDbdsBOOzxQP+21vxf4z3VtX49e6Lvx6GA 13MKuOr1ZBmvJ20Idz0LUNYa4FHVH08ibxIQqz9oXzcAh+0P+r8I708ZrH0+UjPoE//ABOEd39cV rt2Y90PfE0EfzajBRyyjj2hXOB/xPCybf4hBZFXzl4m8UiBWfxlo2w7AYfuL1661Zkw75yz4huf1 bNA3z9XgG5b9lPgx0f/Z8EdLfDWjaSft42m1PD/SHx8CHEeVQC4AF9jzI8taBfPCxUoBymGfHFXH 00J0Vg7EGh+D0dYP4LDjg7b20Kx3I1tvWa76zlK+Ibkvfu+f7z7tD8l6V/IISHyPshf/tnWl5cup Dwmb7V6w0k/vsdKXfS0cSEjIo88DlzcQNp3NhI11vxXWpl1llRfdapW3H2CVJ462yodMtPL9k6z0 fY9b6ZJpwv6rsLaif+MirK3Uc90iK915qZW+81Xh8ivXCZttNgtrn70lXPHee8L+ze9b6Y8qhAPb jgmX/+WUsDkFc3Gtx04irsthXAteD867VWOHZYwdloeLncko+4nX0l5X1XrIea0uwDVP5VEOhapD VnXYRuWrugnBdqH5qj6K/ovzodYZa0etX0OOf64HvEbTariGLItm/P9v1tPAZXXEJ23a1BMu34A1 o9Z95Idv/hj0EdeHqnHOMvqIMRIuzunnaNZT7j3GArHOl9x7dARw2PMl94GttfM11631xTs7bkyO 6CXurVIAnJb8HyRlHhkA5YaAmufZN8+tF8B5nnH05xp8xDL6iPWvAUIPtc8uQCbtpB95KB1qrzoR fYwCYvVNPtp2AHDYvvEgYb3/nKuFWimK5F0xXC0G4G6ur+zdWD4Yq05fXMd+gLlxeSftwj2dzAex ZoC1VlgzwIEjyXnCOVkW18OawXp72lp8w2XCRvOrLU7qIaztu8ti9zBh/wjTKr8Dawfaey950iq/ 8ylhc8xzwv7CecLG5BeEvcsXCpe//bKVfuMVYe0fq4Qrdq0XDry2Rbh8/jvC5lTcr/E8avX+63P4 9xRwATCa/gfzEqj32bCsPcDrEC4uJqIstmtk3V+puVzN70wnAGTGGpllqh7nd8apyqOs0qxPWdVV jKxq8ToJeWOBWOO1G9p2BHDY8UrduYhE/5hDcrUqhuBuOsJVa4D6KQB93jAog844lseiAa/ZOHDV a8ay9iijLeGuWQHKaGe4sTwT5VOAWH1zB9oWADhs3/Ca9sVzlSLo9ff9RPxidP+nsPfibyw/OeKM 2vZXEfSOh0/or2ngqv5iGf1F+8L5qyfKlO0qpsg8qs6DLeD4hkCsvjsMe/YAOGzf0Xbukvm0agTu YKx3qA6Q51Y1PdHiEyyv/dbV0CdaBehnKP4DZIDMk8Px7zJTLzc7OPK0Dvstrrywk6RbDRE2O0yw eMEsi0cttsqzt1vsOGTxvpNW+bjvLU7D+6DQr/l1hrBx8nyLW3WweC7ezkW9X14pHNh4i8Uv9hE2 5w0X9nYcL6yd+5BwxbWThQPtnxQuz5kp7E0vFzZ7LRD2X7FU2Mhaa5XHbxTWPn1LuGLne8KBNfuF y+d9JOyd8bGVfvQzYS3pK2Fz47fCS3bHGbT78351hf3f1BPe8Y8kYaPSIVy783QB4uF9xABjl+/8 7gJmiKh5mmU+gHESLoafR9lZiiF7vuaY4LzDuZlzC9McV5SZzzTls/lcjX1TJ3XRDqWXaR5Vx6uJ vFIg1vFqoG07AIc9XnltWuPzsrSzEAs90fdCKGAsvFhDLLCMsUAbwsVCAcrC3RMkwGFfs188d7/A sNYnVNdaQW4BbshEhGfwG9B2JZWH+KMlEtYewbrX567tHs2L7wBxnhqijcTerRRzUgmYOSVVZqkR yCvGvDUc3A9t+Sxfq5ffSbvvxjzt9YnCZvHzVjppg8Xf7bLyZ/1LONA+Po/1A0PThM0rmgob6dj5 Id/4poOwtrWbcODZXhZP9Aub7UcJexPw1IB6L/yDle99RNh/1WPCxkXThb23/0lYy58tbP7mz8J+ 74vCFfteEg688aqwcSgg7E3eIKyd+rtwxb53hf1/2mOllx+00i9UWumZR4UDvz8hbHTGUwWe5yVf Cxc4NUPS8QnCeKGTxWF2kg1wrVKAOIDXmjKPDIAy89QY4thiPHZE5cPgG4E5kPuA2V7NTyzrDTAO wsXkTJTVdoxwLuC4JxKCzPmH84LKZzpU5v6SaZ4by8gqTVb1VX/sS9VhOfOZx3qhdZXMOizncS5A n6p7qJZwWjYQ69g7hr72ATjsuagBEoXyPK4Ef3/4bItjkDuJu2Vcjda01a3ytFmlWJE7CAc2dhM2 RyH+kW90L7HKHaZwxb8Q/8gPHMRTM3D5pqeEvaufsdKL8fQM+d6tuAMCa8sXCZvzlwr7p64SNsas F/YWbhEuz9kurNVifK6EDxoE43I4eDDSIDs+WTaQdYBrgNBD3f+WIDMaP/La8hqrOKIcChUXql5o XLAe44dH1dgwkVcKxBobBtq2A3DYsUEftNa8HXdF9LjlF8Yp63P8U+aRAVBmnrKXY6FnEPQ154IR 4MFgtldzAsvoc+ZdA4QeyucFyAy3TnWAolwgVn9wjfuUykP8cSESPbC78mmNvFxzOFr4NMELzw/F 3x+vS3wiwVWM+/ABsn7xWcQA/G+ztT8vxrrGd9pyZePI06YUXl4+bGae9mZCJ+EFBcLmwKlW2vGc xeYqi6/bYpWf/NjiLQl5bGfM1IW1e1pYfFOuxR3bCQdS8y0+dbWwufF2i/P6CRtpI4W9fx4vrG2b KFyxYrJwYNaTwsa0p4W9Y8uFtX7zhc1eC4X94xcLGwNfEfZOWyVc/uBaYXPxOmH/05uFjXVbhb2f bBcur7db2MRn0OKPhZVWetZRKz3tuHDFvV8IB4q+FS434gzW918aL7xjW4Kw8XqicLiZI7Y4viPO eqfTKMTGbMi/B4PsON4NeQLA2AkXx/NRdhbjSvbTXOsSAY4/zi1V5xXOLWruUbKab8hsw7aUQ8uV rMrI7Cc0TZntWZfzV6ge5il7VBtk2fOFWvv8KOwJxDqevWirU0HIeG6LRKl8xlSqqf/mGIk76NAx XdPo5ci2RvsA3Ctb66Q1znn3zVFfiD68GNXF+Cvj+gHs6rSXLi8nv5nZSdhxi8ULyixu/oiwufEp izsss7jeBqt8QaXFDi2P7QMHncLmSzkWP32exeN+LWzckGdxhyuFtYevFQ7c3lvYfLHQ4icHCRtH hglr+0zhCuxkRQ92smSj+2PC3ounC5f/aoaw6ZwjrMXPE644/qKwHyu5tHt7uXDgs9XC5bs2CHu3 bBLWXt4hbM7bKezfvlvYWHlQOLDziJXe9Imw96V/CmszvrHyP9AM6lmyHeMcXLK5nnDFmiTh8ldS hGt33JfG4X+SET+/B+ZAfgIM+tG4n4J0WyDcuF+Csv9C/P1orKuxx6Ggxp0ag2RC1VEy61ImRxrb LFNtyBzrSk9ofmgfoTawDtNV6yKr2nzwNfI+BWKdD1ai7UIAh73fwVwj14Njt/peTsbxtLXWOCZz HJM5jskcx5KP8Qs2B75ipbcdEQ50iM+T/KR0YWNfM2Ft0UXCgXGdrXSYnW1s69NMnNMu4AmA9w6z wFXj9Fnk8dzDxWl/lDFOw/ilWnypaxhuj4vuql1PU3TEfj0NtK95/xoo7n4W/Mo9bBM4kn7NqcGv LKNf6etwfi1AWbj9aznKngSqxjd/D6YU+bwm/N/yJDCPd2/Z41vjS8wvbvO9780Xv/Htui0+/9R3 p32/iq+X//bTCfl9WtfLb/ps/Xx/kHMnHvF9+5Cef/T7/b6iQ2n5XRbt8aV2S81X/Whx8fHxcfgz IV7TjTjTBR0JAPfeLcEpAM+tRRCYXS+HGDx+kDn+zwMaAqzPA10In4u/qp/0EPkyyImAB3AByRDS mlnP4Zl+MwfvcgF6QaYt6lD3BZxfdns17/im5zWd3LR/s1uRpp3qUPVoG8vfzm5+bqS+Ap7RLTI8 NzZP9qQ140nSto5B7gRuCCzByX0JNEKnPYDQ81HniWpmiL+uQDp4mLZMm7oCO4FNAK9/oqHVMSC3 A6p+tyPa7yOUom3/YPv/Rsz8HL7X8EuKIwPXhnG0GDF0CshCIHC/q2IH+3dTyagWVRy1REWOL44H xtRMYApQWzHFMdAGYEwmgHmo+WfPg9/7Lr69Tv6a43H5D39Zz553NEwrP4fYuAm25gLfhvi7JfzN 83gz5+act3Oe8t7rXSvzh/J7bVyDyejfBM50Dfa8M7cT54JQIGmPf4inuRbwHLzBfNblMX5Rpe/S OvH566/Z4/tq3Zf47svPw+e3wLYWAGP8E2Az4IDRtLsse503yfNqk9r09R3otwCwfB0X3xFyGyA0 Xu927PY91uYrX0rpLt8LTb7wXdhgr69A/9Kn8vH9ivGh6x+a/+T1D33Ioc4VbqhxvUhEqNyMMl7j hah0BFgOnAAYp4eyjjbZnlXUxOeZ24Sy6o9x+lPXn8no3wTOZpy2rnvC93iull/58Yc+7asT/I7W +J/D3KDidD38fACoAOoE4/TDxineTtmnG4f6Wsl0GeObgHiFUBWZsV51Xo4mTue8XuFrP/qk759H DvpuHPGZr8vcSt+y3BM+lV9TnIbYEnZvpmzHKZ4xBl9Dpb3AJqASSECbRtltmvzHs7jxyOwjjSmr /n5qDF6DvosAqJH5gesh91Wh6RuRPl++oY1KcuCzB/sIle3MHwnNkEoBuB/k+pgNuADGfB3DKkNS cwA6BRwugPL/AUsR14ds8AAA ------_=_NextPart_001_01C8D00D.200DC7A3 Content-Type: image/png; name="image004.png" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image004.png Content-Location: image004.png iVBORw0KGgoAAAANSUhEUgAAAhsAAAJXCAYAAAA6vZaqAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAHugSURBVHja 7b0JuFxXeabrdG7C6djGx5ZkC8eG0yHpKEDSSsig0KQjBtPiCdfIDEY02MjGgPAAB2NsObZBsbEF eBAx2HI8ybM8YAubQTaDBZggZoUhcQJJlIG07g1NCwLBaXL7VtdX2d/h19LaVbvOqWlXvfU871O7 1l7zWrX/b6+99loH/MEf/MEBAAAAAP2CSgAAAADEBsDA/xgHHLC8yQYAgHmwlusoYgOgitjYcfzx xzfOPPNMAICuaF4/9jaZ4VqK2ADoKDbe9773Nf7hH/4BAKArmteP3YgNxAZAJbFxzz33NL71rW8B AHQFYgOxAYDYAADEBmIDALEBAIgNxAbABIiNu+++u/H3f//3AABdgdhAbAAgNgAAsYHYABgNsXHX XXc1/u7v/g4AoCsQG4gNAMQGACA2EBsAoyM2/vZv/xYAoCsQG4gNAMQGACA2EBsA9RIbxfLEfWHJ kiWNb3zjG1zAARAbiA2AcRQbd955Z+Nv/uZvOjI7O9uiil8AGH8QG4gNAMQGACA2EBsAiA0AQGwg NgAmQGxs3bq1sXv37o688Y1vbFHFLwCMP4gNxAYAYgMAEBuIDQDEBgAgNhAbABMgNu64447GX//1 X3fEYqOK324466yzGjMzM/vxwAMPdB2XwnXyc8UVVzR+/dd/fS4dpV81fuXpv/7X/9rWz7XXXrtP flI6hV9I2aqg/MXyv+Y1r+l5mw6Kj3/8442vf/3r+7mrjufTf7rF6cR+0at2qgOIDcQGQK3Ehoxf L+LqdKH/7Gc/2/Kjb/2WoVLaEiDdGLhOBijmp1dGrxfxqK2Vp1iG448/vivBNUoo37l66dRGvUJ9 x2LDfRixgdgAgBKx8Vd/9VcdecMb3tCiit9uePOb39y6ULc7/7znPa+F7sJz7h/72Mdabr5Tt3sa l/zJz9e+9rU5N5Xf4fXtsIpfbjLGGzZsaOVR5/Xb7k7Lbpdffnkrfqet4/vvvz9bLoWJZbC7/Mc8 OO7oR25pOLkpfbkpr7l0dU5+otvOnTsbf/RHf9Q61rfjVZldJ86Hwzsdp28/ad2l7eS+prhjXmOe on+XIVc2t6XbJa1bucX2dD1W7V9lKO/277wI92Hlqdf/kVEFsYHYAKiV2NAFWt8RC4FoUH1xj0Y4 vdDbcMlwRKNn5G5BIMMhY+tzURzYwCluHeeMSkwrJwosfmK5XN8xvIVHLKPjSo1YFAISBz7vfNog 5gRcO/GjfCmMhJjQseKXf4eTu46dvoVY9BNFTdpO8qP6tsBUfHZ3X7B/+ZMff+fKJv+58rgOlQ8L KflNhVZZ/yrrq7GOYpkRG1xLERsANRYbwhd2GRlf3MuMQrzQ63zZ3awMmAyPziuMjWrOQMe02hkV u3cjNqIR87mYZxu36D+tKxvwtE5yIzvtxIbyaRERDXFaLzHfzoMNewyrcqSjDk4jbeNUMMWyWfDl ytZJbCg9HSvNdPSjXf9q11djvstEKGIDsQEAidi4/fbbG3/5l3/ZEYuNKn67wXe5uXPKmy7ep5xy ypzRef/73z/3nfqXXx/bXxpfWl6PDuT8i5hW9JP6ddoyhNEtl89cXn3n/dKXvjRbBvvPCbOvfvWr +9VJzEcsS1r+z3zmM600hdJP007rJebb6cuP2ijWs0dlFH/q36R5lX/FE/0orrKyOe12babwitP9 qEr/atdXY76dfq6dJgHEBmIDYCzEhs5FA2HjLcOoO1G5ydBGQ9xJbKQGUPEoPrlF/067TGwoLcfj +QQ2hMrTfMSG8+DwyldqxGJ+5C8a6k5iw8LK8TsN12cUOnarKjaiu8P6kU8UAR/96EdLxUZsV/+W /3ZiQ2UqExtu17L+UNa/yvpqKgadDmKDayliA6CD2Ljtttsa3/zmNztyxhlntKjitxu0m2zuFVG5 K2+eXyF0oZe7wuni7rvnyy67rOUmv45327ZtrfNl6Smc4/A5xRPjlZuOFVcaZ8yXBYzcLRA+8pGP ZMvlPKZ5dbliHmQIRfQvv857LHvMp3+X1XcMr/z6nPMe6yWtx5hvxSXkJ1enFk+uI5fF4XJ5zfkv K9vb3va2Vrqug3he/q+55pp94tPv6K9d/4rEMruOHEbppP0iV8ZxBLGB2ACojdgYFhYH8yUaoF7x la98pWVA/VvHZQZLfheSlsRQr/JtATTOhhUQG4gNAMTGwOmH2PCdvUc04ojJKIPYQGwAYgOgrdi4 9dZbG9/4xjc6YrFRxe8kcN999/U17n7G3w80UkK/mCwQG4gNAMQGACA2EBsAoyM2/uIv/qIjp59+ eosqftvx0EMPzR1/+tOfbt3BRzcYD9Suk1Re9+HYl3P9epz6OmIDsQEwkmLjrW99a+PSSy9tHb/k JS9pPP3pT5/jmGOOwUh3gYSa63IUedKTnjRRwkp9WMf69mMwu0XU79V2iA3EBsBEiY1bbrml8ed/ /ucdsdio4rcMXXz1/eCDD7aMUTyni/AFF1ywoPgniXvvvbfxpje9aWTzl7bvuLeF+7a+9Tu6RR55 5JGWsB6HciM2EBsAIyc2JCRsHHXBlTGKaX/5y1+eO37Xu941N9qhb/n3hVxudlecOlZcV199dcvP ySefPDdaIgGTy0v0o+OFpCmjEkdpoiHJ5cX+HV80SDEd5UduqjPFY3fH4zzIn/IR8y4xlxrDmKaO HafiUFkVJsbhdGJdRMEYjWcM53wrXpdHx86T6yR1j6NcZXURKStzDOe4qpS/SpoR9d2YflWxkatT xAZiA2DsxcbNN9/cePTRRzty2mmntajiN8dzn/vcxvve976531dddVXroquLvc69853vbLl/6lOf arnbn4y7zutYfh2HhUKMS3HYr3jxi1/cCh/zkfOzkDR1Tn7SNJWOjlP31L/j0PnZ2dk5d/nZvn17 y83xfOlLX5oLqzD2rziUHx2rPdM2TdPUsf2rPIpH2M1+4nnXXSyT0DnXierR9R3rTW7yp/zHune6 qf+yuojp5sosnJdYt1XKXyXNNP1YPvefmGbsUxGl6f5eZxAbiA2AkRMb8eIckYHShVfndbHPGTQb ipyRtjF1ePnxnaaFTGoco1EpM6JV07RQiIZdacotGpToPxoh5cVuEaVrIx3z6/JEsaF0XNZUXMW0 07Kl9aF4dKx47CcKMbmn/UUG2XWusPKfpuE6cXw27vITxUas51xdpG2WK7PyF8uQM/y58ldJM9c/ 0napIjZyfRCxgdgAQGz0WGzYqOUMovKTCoRuxIbuGn2xF+ndaXqhl/FbSJqp2LBwUT5SI+jRnTKx obAx7xoJqCI2YhpKOy1LFWOrcMLpRj8WGWXG02mozLl6c/qqa7mrnB61KRMbubrIpRvLbNEqN4uk bsRG1TQRG4gNxAZAl2LjpptuavzZn/1ZRyw2qvjNoYux0/rkJz85Z3T828PYPnfPPfe0zp100kmt czqWu+P7tV/7tTk/+tZvxa/vL37xiy13hTv//PP3yUf0I3T84Q9/eN5p6lt+lG+XU0P0IubFxtDh HKfKLDcbfLnFfNkwxXp0+vbvNHWsb/sxaZqxTI5f52Mc0Y/yrfMxHzG86sv5drgYPtZVzIfy6bBp nnJ1kfantMwxL+5Hau8q5a+SprCb21PH6mOO3+WMaabxKJ2q/7tRBrGB2AAYObGhC7MNgY2+Lti6 IKeGzOf8OCI1tL5g+yKub/vznIwy4xj9RIMx3zRtVBw2pikjlLrHvNqP41T9OC4bUp2PgikaROdV 4Z2OSI1bmmYsk+OP5bfhjfFEQZXikYWY75hGTD/69ShQ6r+sLtIypWVW/mIbqhyu307lr5pmGk+s r9hH0jLHuozCB7GB2ACYGLHxp3/6px059dRTW1TxW4YusgsJP4rcfffdY1muiIXIOJdxkHUp8TEO ZUFsIDYARlJsvPe972284x3vGDuxMc6G2BM5P/ShDyEWelSfX/jCFxAbiA2AyRIbW7ZsaXz961/v iMVGFb8AMP4gNhAbAIgNAEBsIDYAEBvz4fOf/3zjjW98YxadO++880b+Ij2MfCo9pTvffHYTXm2x 0PyqX1btm/PxP4j6Q2wgNgCgEBs33nhj42tf+1pHXv/617eo4reffO5zn2u84Q1vaKG5BM95znPm ft91112tyZrDzmMnhpHPF73oRY0PfvCD886nvvW7Sji1y0Lz6zbtl/9u6ab8kwJiA7EBMLZiIzUA 0cDYOD788MOtY32nxjMajNR4lBljh4vnJXr0O6aRxp8i/zqvOrcRT9PUecUd/cfzLlt0dxwxj2nY XDo5t+ieExtV6iyKDec39ef8pfHZLRUP9l/WplXFhv3HeFTf7fqM0kZsIDYQGwALEBs33HBD46tf /WpHLDaq+B0Uv/qrv9oyMP595513Np74xCe27uLXrl3bOv74xz8+51duQqMhdvvABz6wT3y5NBRG 6Si+K6+8spWO3H1OcTgvSluk8eic/Tis3BWn/agtFNZ+FLd+26/SjunYXd8e4dGxy6/vWFblO82r /HUqZwxfpc5cpksuuWSfMrutnDf9Vv6cBx3HtrN/16njUT7a+c+hfuA8xL7hMrXrMzond6cL/wZi A7EBMLFiIxo/GQm5/f7v//4+AsBGNbrr2EbPfPazn225R8Eg0nRk9GRYY75SwyRjpfiiaEjD6ljt YYOYGm+Fi4be7opL55xHC4zUj/KU5lX+q5TT4TvVWUwzllnfdo9pRQET69RtJPcoyFx3Zf7L+or8 u45ieXJt6XLGsuXaFLGB2EBsAHQhNr7yla90ZN26dS2q+B0UMgBnnHHG3O+tW7e23Pxb54wMVuTZ z352y4+OHZfuaNM0ZJjlV+flV3Gl6fhcJOYrpmOcvurfx47TeU79Kn/HHXfcPvlxOOUpFzb1E/12 U84YrlOd6fwDDzywTx3FOFxmj/DEvMW2dB6a/XS/+i3z366/6Hwso8Lk+ozjivHZfZT6/7BBbCA2 ABAbidh41ateNecuA2kjKePt4f40fhlMD6vH+HJiI9ZjzihFseEh/Rj+3HPPnctjmdjQt/yVCYn5 iA3FV6WcMVy7OotppgLL4kTurq+Ypxif4s/VtcOU+S/rKyqn8p0Kn6piQ2ERG4gNxAbAPMXG9ddf 3/iTP/mTjlhsVPE7KGQkTj/99Lnfd9xxR8vNv3VOfOxjH2u5v/vd757zo2P5Ufll/C6++OL94r// /vtb5xRG/hRORidNR3Hpt9x1rDBKM8YlIeGwOo7h9TuGcb59XiLD3zKajsNhnHYurPy4rpw/Hysu HVcpZ0yjXZ3FNBVHLLPLofNuC52PeXT55NfliO7yr7ja+ZfbZz7zmX3yZLEhv8q385/rM3KLfcZt 6vLDv4HYQGwATITYkAGJ+ZeBkZt/65zPy6DKkMhQpWW2scshg6Rwildx2JDFdCw4FLfFTVl+dV7p R0OdGryYb+dB34rXYkLnY15sXNOwOQOsvKaipFM5UwPers5ivC5z2i5RCEb/drfwie6q31Tg5Pz7 d1n9Kw7XU67PuJzuMzqvOksFDGIDsYHYAJgAsbFQbFR1xzusPPhuvWyUgDrrnnaCDxAbiA2AIYiN 6667rrFr166OvO51r2tRxW9dkFHS8Psw87B69erGiSeeSJ1B7UBsIDYAEBsAgNhAbACMhti49tpr G1/+8pc7YrFRxS8AjD+IDcQGQK3Exvr161uUnf/IRz7St7hTtm3b1nq0sXz58saznvWsRtX6iWHb +YllUfxKJ9IpfBmKqxdtofzpsY7Lv2nTprEzkm5fobKedtpprbZbaLxlbdCrtkFsIDYAEBsLQHlo l4+FXKw7xZ2ityze/va3N26//faWodXvquE//elPdxQ2sSwxLTNfoyeD2QuhoTypDMqLyi2DXFfB oTpROVJ3iwzXufyp3AsRte3aQHEjNhAbABMvNr70pS915LWvfW2LsvMXXXRR44orrmicc845rd+K VxdfEf3Jj9zkX34feeSROUHgeHQ+xqOLdYxH5/RbcZWlb9K4na/Un7jttttahii6yZ/Teeihh+bK pGPHqXByU1kcr/PjsubKomOFLavPsrw6Dwrrc45T4WI+0zjLyi50x5+GUR5OOOGE/cp/3333tdzc fo5b7iKmYz9ut9jnYj+RP7spDvt3WmX9KldmxSVhp7w7XqM2TsspN9VnbM+yMrvfxj6i3zHO2PZq 5075j2nWBcQGYgNg4GJDF1QZKxvnePG2AY/uMgJahtoXWV+YFYeNqIyFLuIOY6Ogc/qt8zbkMf2c YY5+LCpyRtePD3QuGjkZHYVXGVyO6N/G3+4xLZ9PyyI/NjTGRqwsrz72qENML+ZH4RRex3JXfTs+ H+fasEz8qPyK2+WXX9WP/OvY7a5jxe98u3z2Y8Gl79gfdM5lUV05Lbm7bGX9ql2Z3T/aiQ3VucsT 27OszKlYSNvAeXN+quYfsYHYABhbsfFHf/RHjS9+8YsdsdgoO68Lqo918Tz77LMbt956awv9Vjr6 1sU6htH5U089tYXC2G+MWxdifTsux3vhhRe2fqfpRxx36kdh7Z6icy984Qtb/p1n+ZXxsh+Xw/mJ +UvTevDBB+fcXRb7SedsqA7K8qr4Y/hc+WN+Yro6r3p13eXqy+3RqR5jHcUyOw6lG8OkfhRWdRnz KhSfyxrTcth2/SpXZqedlkXn071W3LYxrrIyxzTsVtYGqXun/NcJxAZiA2DoYiNnRFMD54tsvKhb cEQDEMVGaqB9rlux4XSj30996lMtopvyozRSw5OWIRUbURTEtFOxUWZkcnlVXqLgyYmb1HDF+knb JAq/XNhoZBWP7szTtHNiI617+cnlO20z+0/r2mUo61dlZW4nNsqEZoyrrMw+p/rTt/9Dndqgav4R G4gNAMRGBbGRXqR1QZURj+76nY5s6JwNoM/Hi7WHueOIQW4kYL5iw0Y1uilPcksNvY7Tu9KykQ37 W6jYSMsvt27ERhRSOWMrN9+l58RWLL9/VxUb0Y/COe+xn9hwl4mNsn7VL7FRVuY4opEre5rPMvey /CM2EBsAYyc2rrnmmsYXvvCFjrzmNa9pUXb+6KOPnju+99575y7or3zlK1vH0V1uK1eubIXZvn37 nHFRXmI4+VE4fevC/slPfrL1LWysdNFP04847tTPLbfcMuceUVrOg42J8q1zznssk74Vl+O0u9JS XM6n6zmWRX7SO12XuSyvCis/zoN+R/8xP05P337k4nI5XK78zncsv/Iby++2i2VO8+26lx+5Kz7n W/GpTuQe00rbLJahrF+VlTmte+M4cuWPcZWVOZY1xuOyx3yqXDn3KvkfdRAbiA2AgYuNeLEUuigr 7uhuoyU3X8h9URcOp/NpfPG3ji+//PJ9LvypfxPjTv3YPUX5lHHO1U2aNwuR9Hc0xjGfMR+OK6Vd XhW/8fyG6L8sPz5WvaV+cuXXXXeuTnNtE+OL51z3FiTyl+snaZyxzdL4y/pVu/yk7ex+WFb2KmXO +Y1+Ytt3m/+yvozYQGwATLzYqILv9HynXpc7uPlQNtKyUGS0JRg8ClS1/YZJOvoB4wFiA7EBUFls bN68ufH5z3++IxYbVfy2o5lu4/Wvf33jLW95y4LjGmVUxn7E++EPf7gVt6jadsPmE5/4xNi39ySC 2EBsAIys2AAAxAZiAwCxgdgAAMQGYgOgt2Ljc5/7XEdOOeWUFlX8AsD4g9hAbAAgNgAAsYHYABgN sXH11Vc3PvvZz3bEYqOKXwAYfxAbiA0AxAYAIDYQGwCjITauuuqqxs6dOzvy6le/ukUVvwAw/iA2 EBsAiA0AQGwgNgAQGwCA2EBsAEyA2Hjve9/b+MxnPtMRi40qfgFg/EFsIDYAEBsAgNhAbACMjtj4 4z/+446cfPLJLar4BYDxB7GB2ABAbAAAYgOxATAaYuM973lP49Of/nRHLDaq+AWA8QexgdgAGGmx ccMNN2TxuTpdcD/60Y+2GHS6uXqqkpetW7cOtb5y6ferDlVHw2ibUahnxAZiA2CkxMaVV17ZeOSR Rzpy0kkntajitxP/5b/8l8av/MqvNI466qgWOhZ33HFH63cv0hgUr33ta1sMOl3X0/vf//7GBRdc UCkv119/faueh1VXSl9tP4g6dJ+q2r97jdJWeevUl7sFsYHYABhpsRGNTGr8EBvdiQ0ZtKrpD1ts DLIOh92PEBuIDQAYcbGhu1+hY412yF137/LrUZH0DtZuDqvfvuPPGVz7cfwxnONS/l7+8pfPub/g BS8oLYOR/ziC0y4vOqc4ox8fOx79ttGKIwM2pq4nhbXRlj/F6zw5TBQbZfWZGsxYBtdVuzq3aEiN vX7H/Kf15nBV2nnjxo3ZNoz12uzbc2mpLh3Wbeg6Ur7Sdk37iOvf8bTrm04z/nb7IDYQGwATKzb+ 8A//sPGpT32qIxYbVfxW5TWveU3rohzddGG+7rrrWsdvetObWn62bdvWcn/ooYda7ueff37rIp76 /73f+72W/xjX7bffvk/8Ss9l1veaNWvmvqMfxam4FKfclLbiy5XBfmKaVfOiMqZ1EdNyXnSsb/vx eefTcQi5xbwqL0rH4dvVZ1lbtKtzl8H5VTlVn3ZXWP2O6cd2d11VbWcLDrdhrg+7/Iojtk+si5hW WR+JeYp15LpO8yw3iyGXP7bbOIHYQGwA1Fps+FgXaV3gbRji3a39Rf/xvP1EQ5j6j6gelB/fidqI R8GQM8g6L4Pm3zayVfIShUSa1kLFRjSwsR4dX1l9pvnL1V1a5zK4qRGW4HB4C5CYfozbdV+1nVXf HgFL6zTNq+ohtk9ZHtKwMQ8aJVH+VU6LS/lxnnPxxHZr1+8QG4gNgIkRG5/85Cc7snbt2hZV/FZF F+tf/uVf3sdNF2UfX3vtta3z8TuS+pef8847bx8/Dz74YGn8TkNhFFZ1cd99982lZcNpv7/zO7+T LcPs7Ozcbxkix9cpL07H8cS0nM/ox/UQzzufMQ65KR+OS/nQ7yr1mebPx66XXJ3fdtttc78ltlwf Ma1cezqMxUbVdo7hVK5cu9h/zI/DyH+ahzRsmgeVX+6qS5U31nUaj87HdivLf91BbCA2AMZKbKRG V8bDBib6912njmXYU0NowSCDEeNROBklG1XFaQNYRWzY3WH1XSUvVcSG4raxVB5zYsPpRAPofDiO Sy65pFJ9pm2hcE7bdRTrXG5OP5bfIkfpOP9l6fsxStV2dnl0rO92YkPnFaeFntu/ndiIfcR1mfqX H9dHWhblG7GB2ACAIDbe/e53Nz7xiU90xGKjit+qvPGNb2xdnKObLuI+vvXWW+fO68Ktc7qIxzDR v3jZy17W8iP3iy++OJuuzhn9vvfee+d+K+5TTjmllTfjcGleXQYZJoePaXbKi+JTGR1PTMt503nH EevL57dv3z6Xb8dhw+g8qTxV6zMiA+mRg051nit/lfZ0uVz2Ku2seGIbug7L0lXc7eqirI+4Dh2/ 68JiJFcW1UXatrk6GwcQG4gNgFqIDegPFhsLjUdig/oExAZiAwCxAVmx0Ys7acQGIDYQGwA9ERub Nm1q7NixoyOvetWrWlTxCwDjD2IDsQGA2AAAxAZiA2A0xMYVV1zRePjhhztisVHFLwCMP4gNxAYA YgNKeeYznzkScQBiA7EBMEFi4+Mf/3hHTjzxxBZV/I4zd999d2Pz5s2t7+guN+HfH/zgB1vfN998 85x7GlbnHNbHaTrRPfqPacV0Yr5y8StfT3va0/YLX1aOGLfdc3Hk0k/jS8uS+le8cnfZ0zxMet8b NRAbiA0AxEYfOPfcc1tG9tWvfnXr+6KLLmoZQbs9//nPb93xy6/9HH/88XPu+tbvn/3Zn2350Xm5 y6++dS6Xjr5T/45b7opX2N2GWunYv46VX7W3jh1nxHEKHcvN+Y95TOMoS9/uLrPjjP7lrvgURued B31HgeGwgNhAbADUUGxcfvnljY997GMdsdio4ndckWHUXbeO9b1+/fqWAb7wwgvn/Oi36vTkk09u GU25XX311a2w9iPDKTd9x7D2o+8PfOADrWN92z36v+mmm1q/9R3j1nm5p/GcccYZrTw5j2nZdF4C IP5WWH3bzXmOcZSl7/zZXWnn3FVXsT5y+dGx6xJGB8QGYgMAsdEnsdHJTUY1khrpKDZSo58zuqm7 vqOw0W9tFKZ8RNK8yV87sRHzG1H/kH+POqRioyz9VCA4/znhIP+5ckeRZZEHiA3EBgBiY6LEhgxn KgB0N64Rjypiw3f6uZGNVGzI2JaJjdRI289CxIZGKDxq4T6SG9koSz91V53kxFQsVxqP6zJ1B8QG YgOgZmLjsssua3z0ox/tyAknnNCiit9x5aUvfWnLAMow6lu/o+CQYZRxll8bbx3bkDqeaFz/83/+ z61jx63zntNgd/mJ4RxPdFc+Yr7k7rw4D86P/cey3XXXXXOPaYTCyk3f+u24HWeMoyx9uStNP1rJ 5Vdu8pPWkVDfVHqqV7u5DDB8EBuIDQDERp/w3IdorGVMLS5koG0oXbcPPPDAPv51LDcZV4+CpMY/ l47D+XdqhGXkywyzwjk/+ta5GJfYsmXLXDl0HP26bI4zjSOXvsstXEd2d5z2n9aRiYIJsYHYQGwA 1FRsXHrppY2PfOQjHbHYqOIXqiGxcdVVV41l2e68885W+e6///7W71WrVjXOOeecyuFvvPHGxumn n94KR18ZTRAbiA0AxEYNkCGVUR3X8jX7WOsxiTjppJO6Civ/Ckc/QWwgNgAQGwCA2OB6itgA6Cw2 HnrooY688pWvbFHFLwCMP4gNxAYAYgMAEBuIDQDEBgAgNhAbABMgNt71rnc1HnzwwY5YbFTxCwDj D2IDsQGA2AAAxAZiAwCxAQCIDcQGwASIjXe+852N7du3d+QVr3hFiyp+AWD8QWwgNgAQGwCA2EBs AIyG2HjHO97R+PCHP9wRi40qfgFg/EFsIDYAEBsAgNhAbAAgNgAAsYHYAJgQsfGhD32oI//tv/23 FlX8AsD4g9hAbAAgNgAAsYHYABgNsbFx48bGBz/4wY5YbFTxCwDjD2IDsQEwULHxohe9qHHkkUe2 eMpTntK44IILWu7vfve759wjJ5544lzY5z3vefuEVRi5y0/0N2jK0nfZhsVv//Zvz9VRFfdBpW90 Tn7SulL7Vom3H+2uuJX+m9/85p7EF/u3y4rYAMQGQBuxcckllzQ+8IEPdOTlL395i9T9zDPPbF1w /XvTpk2tC/vNN988d1wWp8Idd9xxc7+VF/tX2HXr1lXKWz844YQTWuTyPKw8iWuuuSbrLqGmOhtW +jk/ab9oF8b5v+eee1r0Ms/t+uB8iOWqUh/jCmIDsQEwMLEhQXDMMcfsJ0Ci8CgzSLlzMazdFL8u 8CJ3cdd5CQP7iWnYLYqaMnfVhd0dZ5qO8uzynn/++XP+c8JIbhZjQv6juwys3HL50fkYp8MobdeB 3Bwuio2YL9dnrs4czn5ifqN7Gk7pC9WP43G+5S43hVVduT38Hcsa8+xj5UFEf/brcsf+EPOlcPIn oRuFQbOfz/Wd2Fc7lcWiM/a9WK5cfPbrPLgu0vIiNhAbAIiNLsSGL+g2wtFAWWx4lMDozlXfuvh2 SlcGxBd/5TUVNr5zdbpRJMjdF3fF4Xg6uSt/ylu7kQ3lRX58J27hkI6O2I+Mj0d87J4aWudf+ZG/ WD82ovYb03c9p+7Ob5ovxe+yOV9pfsuEotOPacq/j4XzHcWA49I59zkLrhhvbkTJIsJxWoSpXDG8 6i5nzONoWVqn7cpiAZKGdblSN/fBtFyOI5YDsYHYAJgosXHxxRc3HnjggY5YbJSd37x5c+N1r3vd nPCQEbviiiuyYuPuu++eM2yd0pVBURwykIov50fnfazyKO40bYXX73buMT8yGDqfpqXy6VvhVN6Y rs8ZhY9+FMbxOu5cOJdH+VG9CudN38prjEPIoNld8fm8R2nScrh95MfppXHm2sfpp/Xl9onusVyx jVQelVthOpXL8anPOJ7Yl9zXHL5d/0jz3KksZXG6XDFcLF9suzSOtK3rDGIDsQEwMLEhY6qLfXTz nbMNey6+9AIfw6Z50kXb4iQXJqZhg1UmdNq5x7gdT5mh8ShOu/IofCyLBUo0qH40kiuPznnkxWmV GWWXIRUbqeCxX4/cWMzlxEbOMJYZaKffSWz4MYP8ewSgrFw5EVEmXnspNmJ/qCI2nM9cPSE2EBsA /DEKsXH//fd3ZM2aNS1Sd207L2MZ3fT7TW9605xhL4tTF2L582/7v+mmm/aJ/7zzzpv7nYsvuikO hVEcit/uKqfyVdVdBl7x5PKsbxnwWG4dy61d3SifEk5yd9z6HfOv+lixYsU+6cV82XjJX4y7zF3p xDqOfnWscjv9mC8R85GGtSGN6aTuCn/XXXft00ZpWe3X8cY8yC22fZp3xe08Rvey/pHm2SNaZWWJ baq0HI/LFcM5rrRO03zl6rSuIDYQGwADExs2tH511Y88onhI8QVXhlbHNqg6lxoXiwD7c9ydxEY0 ZsYX/U7uSktlKhMbzr/8OI6cEVH4mI7znhp1+3MZVS+xbqN4kB/n1+nLrZ17Wb58Pmfoywyj0xHx fBQbaf1EQeX09O1HWDFe50G4rxgL2FinFlKx/O36RwzrR09lZYntHdNyuWI4/Y9yftN8ITYQGwAT KTbe/va3N97//vd3xGKjnZ+rr766Ulw5tmzZMu+wnbjzzju7cu8VNpr9TGNS6XfbQWcQG4gNgKGI DUBsAGIDsQEAiI0B331zBw6IDcQGwMSLjYsuuqixbdu2jrzsZS9rUcUvAIw/iA3EBsBQxMbWrVtb LPQidtVVVw3tAjqoMuTOV0nb4S677LKRMTqDyEuv2mUU6mqY/RuxgdgAGIrYuPDCCxv33XdfRyw2 Uvcbbrih8cY3vrF1/IpXvKJFlfjEueee23jve9+7n/tv/dZvNS699NLK8fSSsjJ0Uy7lXWVo58dl 7Kb+5P+XfumXWsdPeMIThlI/Oeablxe+8IULbpf59rFh8NznPrfVfvMpxyiC2EBsAAxMbMgA+uLZ rUGQ32GJim6NWifxMF9i/VXxa7ExDvSrTke1j6ntRq2/IzYQGwADExv33ntvR44//vgWqbsMhu5s dXeuLeh1QZWbvp/znOe0/LznPe/Zz11uCqffOk7jfNe73tW4/vrr9wmnNNL0FYePlb4oC6c4o7t+ O5x+G/2OaSi80lE4/47xKL3oX/Har75V3lhPsYxp/TltuTt+EfMfy+24HY/T1aiBw7odcm2XphFR XmI8Oo7uzrfzEtsi/s6lozzpvPPWKb+xblz3LrP6T67N0z7mNGK4svjSdna9lvWhtP2jH/3HXN5c f68riA3EBsDAxIYurDYC+o6GwsZG7uvXr8+65y7WvojbqMlNxuSUU06pJDbKwvnCb3eFtZFyHMp/ KjZsMB0u+lfcPpcaG6fp9FUH0V3+0voTyqPzn/pNxYZxvuRHRjLmSWVK664sjdTAx/a0oSxrZ8Xn dJQH/W6XThRvnfIbxYbScxyKu12bu4/dfvvt+6TRKT73D4WLfTjXh8r6r/uC/ZSJE8QGYgNg7MVG 87vxvve9ryMWG6m7jaWOfQH3uWXLljWuvPLK1vEb3vCG1jnfPdq/wqdxKpzcFVZ+9Vt+r7vuuv38 Oq6Yflk4uxltPa50dOw4VB+xDEb5djlkDMvy4DpxnC5LGo/dy+rP+XB92a/jTdOU+znnnDMXTyyr RzzSMuXSiOd1TuWNv2XE03Z2XlTvsdxu+7J0nKcq+Y1pxrK7/sraPPYxuVkoyW+7+NJ+Ecua9iGX 02mk4dzWaV+oO4gNxAbAyIgNndfFXej4tttuqyw2YhrHHnvsfga2TGyUhYtGO9KN2ND51BD2WmzI wOu80rLxaic2FGcqClTuWMZoEC2acmm0ExtqQ4vGnNhIDWundKLY6JTfTmKjrM3dx5S23JQfxd0p vpzYsKBJ+0+7PhmFF2IDsQGA2FiA2PCdfpnYiHfd+o6GQHfKZWLDRkhuUaSkF/ZovJyHXLholD28 nQoCP0Ypy5ONlv0rnXSko1uxkdZfzL/TUzvlxIaFXDpiIX8qu/2k9VyWRurH+bUfjw6UiQ2LC6fX Lh3nsWp+24mDsjZ3H0vFg8pl/2XiJe0XfmSW60NpX7Ef9feyvoDYQGwATIzY2LBhQ+Oee+7pyEtf +tIWqfutt97a+M3f/M3Gs5/97MarX/3qFj4nN93RKQ35EdqmPrrrAnzGGWfsE6fP+9hhdeFO01dY xaHzOnb6ZeH02/6dxjvf+c45v2kZjPLtO9RYHqWT+pUfu8ey+Hd0z9Xftddeu0/8SlvuMV6d83eK 68VlVfg0j2VppGXO1WNaR04z97tdOo67Sn5jmjF+1Um7No99LJ7373bxxX4hYdKuD5XVbfST9oW6 g9hAbAAMTGzA+CKjnzP8AIgNxAZAV2LjbW97W+Puu+/uiMVGFb8wHlhsUBeQA7GB2ABAbAAAYgOx ATA6YuOuu+7qyEte8pIWVfwCwPiD2EBsAAxFbNx8880tuBADIDYQGwDQM7FxzTXXNE4//fTW8Zo1 a1pM8gV40ssPiA3EBgDsJzbe+ta3Nu68886OWGyk7pdccknLwOrYYqNKfOPKb/zGb0x0+WFyQGwg NgAGJjZkXJcuXdo47bTTWkJD6w/ITd/Petaz9vFnd/nNiZYYdtOmTS33F7zgBXNLQzs+pSN3+z35 5JPnjkX0Yzcd59Jx+fVb8cfy5Pzrd5l/oWMEByA2EBsAEMTGBRdc0Ni6dWtHXvziF7dI3WV8tfW8 jvUtA+xzMrz6lpv92P2KK67YJ55f/MVfbDgv+pY4kPGO8en4pJNO2icdpa/4tmzZMheP8xTDyl1p +nwM6/OKW8dnnXVW63ear82bN3f0L6FRpT4B6g5iA7EBMDSxEUVFNPARGWwb6lSYRCQWJDhiWgof 07FbTNN5imH1W2lGv9F/FCFRNChfMe/aeCsVLdE/YgMQG4gNABiw2LAhl+HXsfFIRJnYkB+NbkRR orzKmM9HbFi4pOnkRjxSsRHzbT+IDUBsIDYQGwAVxcb555/fuOOOOzpisZG6X3zxxY2VK1e2ji0C fE4GWeflZj833nhjy/3yyy/fJx4Z6VNPPbV1vHbt2tbvN7/5zS2/ChP9xHQUv/zk0pR/uV199dUt 0aBvnXc6jj+Gi/lJ86Xziqed/+ielhFgnEBsIDYABiY2JARkaCUmJBKEz8nNBlejFDLEFhG5NDyJ 1IY7Cg+PaNjN6Sh+C5mYpgWOwzpNCY6YjvMX8+rfMV/Oeyf/StdiKvUDgNhAbAAgNuYhNkaVdJQF ABAbiA2AIYqN22+/vSMvetGLWlTxOwocf/zxLeqSX4C6gdhAbABMvNgAAMQGYgMAsQEAiA3EBsAk iI3zzjuvcdttt3XEYqOKXwAYfxAbiA0AxAYAIDYQGwCjITZ+//d/v3Hrrbd25LjjjmtRxS8AjD+I DcQGAGIDABAbiA0AxAYAIDYQGwATIDbOPffcxi233NIRi40qfgFg/EFsIDYAEBsAgNhAbACMjti4 +eabO7J69eoWVfwCwPiD2EBsACA2AACxgdgAGA2xsX79+sZNN93UEYuNKn4BYPxBbCA2ABAbAIDY QGwAjIbYOOeccxpbtmzpyMqVKxuLFy9uLFu2DAA6MDMz06Ju+X71q19d6XogEBuIDYCei43LLrus MTs725B/AGiP/it1/L9ceumliA3EBsDwxAYAAGIDsQEwL7Fx9tlnN2688UYAgK5AbCA2ABAbAIDY QGwAjI7YuOGGGwAAugKxgdgAQGwAAGIDsQEwGmLjLW95S+P6668HAOgKxAZiAwCxAQCIDcQGAGID ABAbiA2ACRAbZ511VuO6664DAOgKxEaJ2Gh+ppYsOfy+ww5bvAsGy6JFix5u1v80nXH0xMbLXvay hgQHAEA3NK8fexAbebExc8ghh/zwgQ891IDB8vM//wvfb9b/SjrjyImNWQkOGAu+0OQrxd2mjMDe JjII/9zkO4X7o01+UPiNYb9ZnKceoRu26Caea2lGbCxevPj7//OfHmvAYFn+q7+6F7EB0HOxuLoQ EBIVu5psa7KhcF+e8T/d5LGM+xoZDuoUALGB2ACYHBExpf9Lp7vGwt/yLuJdWYiSdRn37dQ9AGID sQEwvqJiXZONxdC0HoE8Vhyv6HF6GvX4vL4T9xmJENoEALGB2ACor6iYLhEVe4vjTcX8GflZ2sd8 6DHLI3pskhE9j9FWAIgNxAZA/UTG0mKUwqJiYyE4Vg5jYl0xl+OrJfM5dvdT6AAgNgCxAdCd0dZj h1V17NOF8JkujlWGZcUx/08AxAZiA2AIhtmPP9Y32VyMTjxWvAGi49U1HGnZE37r1cW1tDUAYgOx AdB/Ixwnam4qhMTesPaEJlau7fWEzSGUc0V86wSxAYDYQGwADMYA7xqVORUDKKvKthmxAYDYQGwA 9O4uvtYjEX2ok01xjY3mZ2v6ZgoAIDYQGwD7G9ClxUjEhsJ47ipW1NxZvOrJcso/rqud8U2UYjSH /yUAYgOxAVD8f3PzKjxZc3tYpnsZ9VVah3uj+EJsACA2EBsAfzC3NsTu3LwK6qdS/U0XQmx5ukoo YgMAsYHYgEkwhMu95kOHEQ0Wm1qYWNtevE2zuZ3Y0KgQ81wAEBuIDairwUvnVews5lXoEcgq6qiv db8lPHpa10FsaPfXbdQbwIiKjXddtqnx93u+nT33hS9/tXH+W/+gxQMfeqhSmBSFk3/EBtTAuK0o 7qI3jut6FTVqi6mi/pcWE2eXJ+d3xrYoRjbYkA1gVMXGit9+RuPhT31mP/fb77yn8eQn//yc2JC/ 098w2zZMWfyKB7EBI2jQpoth+l1ht9K4sRhvgwyvbdZ4Ea+iTaaS8xKBM4nbXuoOoGZiQ+4SHP6t kQyLhqpiQyMj8vvKE9c2rrnuxn3OKXyMI41PYeO3zvs4+qkqehAbUGLUVqZGC0aiXba3W7SrRGzs ym3UBgAjLDY8mhEfn3QKk2KRYdFh9xf838e2RkmcxqPf2N36jmLC/iVw5F9+dWwBpLhFjAOxMbGG aXkxmXBDsT6F16vYSP3Usj2Xpq+6VhQbm1lVFKBmYkNIKPgxSBzpqCo24uMTHVtM6Ngixm6a1yHx 4GM/spFfzw+Ru8SFwsS4FVdOFCE2xsoAzYS1KjYUjzweLUTFjmLy5oa4GyjUtq3Vxls7+MmJjf3e WgGAGoiNVHjIwHsUolMY+9eohNCxxYTP+RFLKk7iSEUUFUpTYkPfcaSExyhjbXh2hLc/vFaF51Tw Wul4tvnOTrvSFmJjaWaEi0miAHUSGxYWOb9VxIYERpzzobgsHDyaITc/ComPXaKQqCI2FF9MC7Ex skZkRdj2XKMQW6gXyAiGPZ0m55YJzU6PXwBgiGLD8yeMHlt4LoSMv4y7/NjAl4XJCYtUgOhRSIw3 Th7VoxCFi5NJc2LDeVBcFh6IjZEQEZ43saFYI2FHWJrbq2huK87P8hopZPrS5oXMtUlfiQWAEREb ngeREw4y/vptkVAljEcacmtrKD4JCYkRh0vfUklFisWF34iJczMcR7+ExqSKjbCXx4oKfjcWEzLj vAnPnVjJ/Anoot95YujSBcTRenWZ+gQYMbExKligxDkcrLPRswv4ymRy5YawcJXZU8yNiPMjtnda khugh311vSeGFmugrJhHHKtZSRQAsVGKR1BY1Gs/gRBZH8SCWdohrnVBUGxJwsa4ERUw7NG0PV4n o3jMtnke8UyzuBcAYqN2PPVpT/teePuhqgCITFe4m2sk7E1GHXaE1S1j3OuZDAdjIjZWxjdJilG1 1fOMi8W9ABAb9eKoo476YZiTkGPjQsQGAMyNbEzH0Yn5CmnmbQBMoNjo9GhEczTSZciZswEw0cJj badFvSqMkmygLgEmSGx02oStm03dEBsAEyE2NGK4ps157fC6iroCqLnY0OulfjvEr57q9dL0NVO/ Gpu++mq/XinUr8vaj779amwUGzG+3Ou56WuyiA2AsRMaS4t1Wdrti7KefW8AxkBseEEviQYZegkG fXvbea2ToWMLBS/UFfdT8YJduZ1i4wqgdo/xxVVEFYcX7/IxYgNgbMXGbIV9UVqTo6kvgDEQGx5d kJGPj0LKliyPS41H96piI64I6t8a6dCcj2HO60BsAAxUbOzq9IikeIV7LfUFMGZiI+5DYnGQW+nT IyJRbHiCaBWxkeJRDC+Vni5ljtgAGCuhoYmduyv42zLf12IBoGZiI92PRKLCIxHRPTeyIX+p2EjD eY5HfGziRy2IDYDaC4s16Qqhxb45sxXC7uA/CTAhYsObpsmfHnPYjx536NjuFhse9fBKoanYiOHi pm/27/jSyaOIDYDaCY1l6R4o3eyLUmy2NkNdAtRcbGhEId1YLXesiaKeYxHD213f0X/0a/c0PomY ND75sSBhzgZA7cWGRibWJW6tnYIrht9ddbG8Qtgspd4BRlBsAGIDoE9CQ3v17Ezc9tkXpUIcj3WR 3vr57LECgNgAxAZAPYXG0pyoKATIti7i2N1lmnvZQwgAsYHYAJgMsbEjt4y4xEfVRx2aVKpN2uaR 7hraAACxgdgAGG+hoTkZO3oQz9puH4voNdn00Q0AIDYQGwDjJTRWFo9PlvYgro3d7uja7ZwQAMQG xh+xAVAvoTFTzJlY2aP4ts1nE7ZiZIWJogCIDcQGwJgJjaliTYwNPYzzUb3OOo9wnig6TdsAIDYQ GwDjIza2Vn3LpIs49yxwVGSWtgFAbCA2AMZDaGwoNlWb6nG8UwsIu7yYu8FrsACIDcQGQM2FxvJi lc+lmXMzw3wNtdjEjdENAMQGYgOg5mJjuuzNk2IOx/oh5m1pIYQY3QBAbCA2AMZQhGwehfUump9N gjYBQGwgNgDGS2jMdrOB2oBGN5bTNgCIDcQGwHgIjdXFa6fLRihPs4xuACA2EBsA4yE0VvRyUS8A QGwgNgAmS0gs73B+pnjVdO0C02EyJwBiA7EBMIFCQ5MsH21zfrpY7XNDD9LaPUqPYAAQG4DYAOiv yJgutmzfVjbZM6yzsbkH6Wm+xy7qHmAwYmP6Zw488P9tfjdgsPzkT/7kj7irAmhdh5YVoxWb2vhZ VTw6WdejNLf1Ki4A6CA2xuAipbucGRoUoLb/4bXFRM81bfzMFkJjRY/SnGF5cQDEBmIDYPxFhh6b bC9W/lzWxt/KYi+UmR6mvXHQr6dqFIWdYQGxgdgAgMH9b/1IZOMQrxvLBpymN5BDcABiA7EBAH38 vy4tNizb3atHIvPIw4p2b7sgOAAQG4gNgPr+V9d7NGOYxrZIf/2Q64HrFiA2EBsA0OP/6a5ifsay kvNLJ+maUUyK5doFiA3EBgD08H86nXGbKUYZ9vRi3YyK+VCau0ekTtYO83ESAGIDsQEwzsJjTTHK sbsQGzMDTFsGfssI1cWq8GiJ13ABsYHYAIB5/keXF+tkbCvW09gqIzukvGwatYW8ileAtxSLmjHK AYgNxAYAJP+/pcVd+Ybi90yxLkYUFzsLP6uGffdezB1ZPqJ1ySgHIDYQGwAQ/nczxd34nmK0YGlh LHcX+5tsGAVxkeR5SuJnxOvVoxx7WUodEBuIDYB+9eeVgdnCaJexqTDsZlWHuJcl/quwK+znc1qR p12FyFhfp/UiCkO+rSZ5XcYmjYDYQGwAdGvkVnZ6vbMYLYiGfnMHsbE+ESed4p9K/FdhdZHWo95t FSMIAIgNgOH2Rz9O2BDeuHisEA9ralKG5cW8AQuMTaM6z2HC+9oMu0YDYgOxAZNzwZ8thMXe4vGC 5yysrpMxKITS7kJkbEBgjHx7eZ2O3cUbPp4ngwABxAZiA8agzy0Njxb2FBP6Vo/DfhcYqtoKXj/u 2hbm2ewshO+W8Ohttng8RjsDYgOxASPc39YXIxi1mLsQ5mlsGNYOqzC0tl9RtP3aIDY2FwJka4Xw 28Lk4G7ZVSF+58vzg1hjBLGB2AAId5EjtwZCWN9iXXKHu7d4xMNjERi1PrsuzG3ypOi9hVh5tOjD fjTENR6xgdgAGLCoWF9M4Iyvpnp9i03hbpGhcqhzP18VhPOjYaL1JkZBEBuIDYDuRyNWFhfW9Z1G TYpn7lFQMFoBk/Sf8ejdLPWB2EBsjPeffXoeazWsrGoYi8mX841/RYX4ZzrE0W4hrdkK8a8tWRxr Z+a59p7EzwaWqe5bv11eZZ4CACA2JkZstDOIFcKuq7gy5O6M8XuswsJQ6+exCmVkaY/yn2N7pzdC 2ogB80CT97cRHEvn2XYM+w7/jngHdQGA2JgIsVFsr93pjnd3iSHcVsGYzlQcBeB5/v51t6yYoLaS +hi7tl1dl6XKoSftrUeNq6kLxEZtxYb3LAivbW1KZlLPdCkGuOMdjX40XfSlWepjLNtX/9ct1MXE tPeK4jHlBuoDsTGSYiOsS7AmzISOr2RZWGwMq0Su5G649v1oM8ZorNu3NbGWupioNl9avK21mfpA bIyi2FjtRW/CO96MPoz/RWlvp/kYUOs23sBd7kS2OyOWiI3Bi43iEcY0jQ9Jv9jEXS9iA8a27T0X azn1gdjom9gIG2XtKp7hrabxIbnzYVRj/Nt5I2Jjott/lgnCiI35dJxdJevxz726WUwIs8CoxT4W MJS+tIaL0ES0szYjW0tdTGz7TxX2YBX1gdjopuOsLhEbm4pzuwpW09BQwQitoy4QG8CNBSA2ch0n Hd34lyZfLB6rIDKgaj9iBVrEBkxGH5guRr9ZpRex0VXHSUc3/pEttKHLPqT5PHuoC8QGTEw/2MEj dcTGfDqORzf+d5PLaFTosv9ofZSd1AViAyamH2zksSliYz4dx6Mbf0mDwjz6j9ZQ2U5dIDZgYvrB LG8lDVFshCW468g/NbmopnlfPgZ/3qka9513FJu31TX/0wNu66U1rqvtRXvXMv/853vGhTX/z9fy Ff25C8hP//TjHvulp/7K3jqyaNGSf/mPv/jU79Yx74+bmvqXuguOgw859NonHHnUP9ex/o964swP Dj/iCT+sY96PftKTvz996KEPD7StD378Xz35F5Z9r471teTwpY8d/aSf+34d8754yRGPjdIKmHX+ z6v/1vU/r7zrP1hnsTFz6GGLvv/ZP/vvDRgs6kB1n6x08CHT91xw8Sbac8BcfdP7GtOHHrZrkG39 Mwce9O1tH/0c9T9gTjntzY1RGvrnPz8c9N/TfxCxAYgNQGwAYgMQG4gNxAYXHsQGYgOxwX8esTGW YuODn9zVeMVJr2/8p1/7zcbK5z6/celVN9WicZVXxAYXHsQGYgOxwX8esTHiYkNC4+gn/YfGWedf 3LjpngdbF0mJjjoIDuUbscGFB7GB2EBs8J9HbIy42Dj2xS9vrJtdv9+FUiMdFiM6L+7+8Kdbbju+ +M2Wnw3vfM+cu9CxREtVP8LnY/wKp2P5i+5CIkhuCofY4MKD2EBsIDb4zyM2aiA2ZLA1olE26uFR DiG/Mvzy79EQu0ucyF3+JQSq+NE5iR25RfEgMeF05cfu8iN3+Vc4xAYXHsQGYgOxwX8esVFzseER hzgKYXEgox/jkDCJYar4iSMWFie5dB2PhQaPUbjwIDYQG4gN/vOIjRqJjdSAR2GRTha1gMgJiVSg VPHj+SFKR6MeZWLDE0HTvDJBlAsPYgOxgdjgP4/YqIHYkFHXaEV006MLGXKd89wN+42PQhYqNtKJ qJ3ERip+GNngwoPYQGwgNvjPIzZqIDZsxC0uJDwkAvSIQ5M8dSyB4ZEHPQrpldhQWp6gqvQ9J6RM bOic4nRYxAYXHsQGYgOxwX8esVETsWFD7tdf03NyS93T+RY+lkARVf3EuOPbLj6fxmOxo+/ojtjg woPYQGwgNvjPIzZGXGwAYgMQG4DYAMQGDYrY4MKD2EBsIDb4zyM2EBuIDcQGIDYQG/znERuIDUBs AGIDEBuA2BgPsZG+VdLJHbHBhQexMXpiw2+iiSr7Ji3kLTG9eVa2yKDQOb+d1u+30RAb1a/z6hfu H1qjqd82JfYDxAZiY7+3ShAbiA3ERr3Ehhf3i8Y+rgbca7FRtshgTN+v1Lfzh9gYzH/eyxb4Ou8t LtT/+2lT0qUVEBs1Ehte3yKuuZG6e4EvrXFhf34FNS4M5t96ldabrqnzOUzc/E13SXa3Ik7TjH4G KVIQGzDpYsP7F6UCxMfxv+kRD++DZPd4XbBbXCzQiwgKi430mqJj78tkI+O4Fd6iKL2zjun16054 ksVGTnh6I820f9gWxPbySJbbx/0i9eO+ZZuSio1ok6JbP9sdsTFPfMfiuwUbf7ursdWpoijwxmi+ I3GnUwPH3VzdKRWXFwqLy5VbFbtTpWnq2H580UFsIDYQG4N5jOIF9/Tfi4Y8/n/9v/b/1f50LUiv AXYXMY54DUqNiUVIdE83boxxxGtYfBSE2Oi9zWj3H0j7h3fttrs36bRtiAs72o/7VNyBPBWdFjKK L/YPuQ/KXiA2uug4UQGqo5RtupYOe6ox9Wd2g6fLjqdxRCHi0Qof59L0/ikK1274FrGB2EBs9GeC qBf9s/CIF/52j1G8Q7MNk8PY+Kdx2G+3YqNs48ZePd5BbHQvNqJNiKPbsb3K2lnnY9j0BjbtB3YX 7p+DntOD2Oii48ShTXeM2Kh+Hpd7xhqf1Xn4s0xsuDOlYsMdLPc8zjvOesQDsYHYQGwM5jFKKvA9 WlFVbPgakRqFXBy+XixEbPjxLmJjMI9RUjePXqQjYW67qmIjzvuwcKkiNoRHSRAbI/wYJd5h5Ax/ HApN1aOfmbmTuOHTP74vVhYQ8ULjRzf2r04TR1zisCxio7cXnvhnbmdM6oDKUjY5GbFRndxGjTYi 6f/X//2c2EivAb4pSePIiYp43akqNmJc7g+Ijd6j63FsPz8uUbum831sU6qKjRg23TcrhovtHO0F YmPExYYazo8tyh6v+Hw6GSvO4UgvAj6XThD1xm9xck+apjp0THNQj1ImTWy4jvslNnyxGETblc3t GdQFaJweo3hE0a83xhFQ/3+FjUMqNvxf9jXA2ECk1wC7R7/x8UpqTMrEhg2Srzn9enth0l99jX3A owy5c26XVGzEa73b33M2jPtc7tVXt7OxTUJsjLDYGLVXiYbNJIqNMjGQGu50k710oz37ie66COii kY445Dbli2mkbn5s1y5fZZv3pRegKmnmNiKcJLFR1gfmS27EqR/EvuwdoxEb/33k+0dOQI5Sv0Js IDYQG30SG+kQeBz69l1HfMXMdyUeYnVY+0nfwS/zH+9WlAed86iYREMcio9lcH7Vpz2s7/lBFhs2 Ph6ujeWJadqPR9cmWWzUDfcn969+zfVCbPRHKNbtES5iY0jKFLFRT7HhlSKNBUQUCTr22wnxuWqc OBiH2m3gPTyau7BE/3Fisg1Eemfqx3nR3ZOaXRYPtTqOOGksvhYZ/cc00wWsuhndQGyMBulIGGKj HpQtCInYGBOxAYiNsrsJj2bEUQ6PMKTipN0z9DKxEUc7HD6d4BcFSRQxceTDAiKKhygSohhJ856m aQHl+Qrd3GkhNiYHxAYgNjKUPevOPVZJ7+QWoja9KmC3dx9+3t5uzgBio/9iI573++/piITaKrf+ QhWxEd+p9yhKNPzpY74oejzDPTerPRUP8RFNFDhxUmKc2R7/L/FNLMRG/0dV63J3i9joHWX/r1FZ mh6x0QW518LSP318KyWuBjif52i++83NQnc+crOORZzJnL4hM4j5JbyN8uN31uNdvg2wDb5XfY0r BLZ7OyA1LBYKMtDpqrRpX/Hr2OnS9V7hMhUbXlFQx/H1x+juVQzjXI9YPuUrvsKJ2Oi9gcktKV2X 5/aIjd5R9gbJqGy6h9jowvCnw8w5MZIuxFL2ilknbDji3Ykv7L4jTd/h9/vUFj3xXNnaH4iN3lx4 ytbZiJssxREIi1OPcHikQN9x1CD2p7hfTuyXcb6HDXq6VoaO7SfdWTJdfCqGtQDy2hCxLzrdsjRV DqfZzeZSiI3eXK8QGzxGQWzUUGzEBisTG3FmfjrE2e2fv2z3Pwsai5FoJJyWX1OM4eMrkoiN8bnw 1HnxsEkUG3FNjDhSFUch/T+3n7g/SnpNiiMb6foKuXV60sdlxqNVab4QG/3B65ekay7Z3aOFfpMr rsWSvpXm9nL/8Kii484tHtkuzbK1oBAbAxAb6Wz+dls5x0V81FEsBro1CmVbUcd44iRDpRs7oC8e nnjoToPYGC+xkRvtQGyMrtiIc1fiFvTR3aOQqTGJ+2V43ZWyVUb92mq6GWNZmvFNonR0DbHRH9Hp toxr2ET3dIVY94v45lhsd8cR+08cXY8LQsaR8JhmnEuWG41FbPRZbJQtC9spjIXHfMVG7u4it+S4 h+PT0Qx3GN/Z5PZaQWwwMx2xMdiRjdyIaTpyGm80fO2INz0WIHEib/p6s//v6byvXJq6RvjGZJDi dZLFRmzj+Cp6FJ25/VFi2+U28Ww3sTvtBwob/cd5h/ERKWJjxMRGbqJWXK++G7FR9qePCzLlFnjy 8/U0rbKLEmIDsYHYGI7YyN2VRsMTbzB8LUj/w1XERtwzJb4pl3uW72tL7lqG2Oiv2EgnWZft/Opz 6RYXVcSG988y3o8ltWfeXHRQ8z0QG20eo6SNZiXq9RTio4w4PJU2dNkralaYUdnGi4A7mgWH86jf HpZzWK+jUHbxyS0zjdhAbCA2+vMYxY8rvHpsavjjBl3+L/ua4v99HCbPvYEUh8zTNVdym23FBdz0 jdjov9hw20c7EdvK7rYP8XG4+0VspziK7v6TvqRgd4uMdDQlPkYZ5O6viI2SO5L0tdJ4J+JJWu4I dvdwVcTP29vtqeGJOrl1HHzh8bBXXFLYKjgN686VbtSUG+JFbCA2EBu9Fxu+aUh3fU0fl3oyX7pU ePSr/3M0LA4T5/LYPf7Xc/E4bLxuITb6KzbS+k43QbQ4TF9Xt984up1uwOk+lq5U7Amg7ldpmu6f ub6H2BiA2PC2v72uZC9dPQoX+fRNGsQGYgOx0XuxQRsjNqrM+5skEBt9NMZmlFb56+VkIMQGIDYQ G4iNPN7DiD6A2ADEBmIDsQGIDUBsIDYQG1x4EBuIDcQG/3nExhiLDT3+yC0dHSfaeFGUdBnnYaJ8 DGLSD2IDEBuA2ADExgKJq77F33Feh18j6nYyUL9fO1P8/RY/iA1AbABiAxAbPSAuzFJlq+7c1vNe BTBuzZ2Kk3Qb+XRtjvg7t618uo6GF+5BbHDhQWwgNhAb/OcRGyMuNuJysn5XOgqQuKKb17qQPy+a 4sV7orsutArnd6r9nrSFjARDbs38uDmb44u71Jo0b4gNLjyIDcQGYoP/PGJjhMVGHCGIK4V6K3c/ DokLbsUliuOcj7gSoMOlW8XHlebS5Y3t5lGMuPpbuuCX3fq5cA9iAxAbgNgAxEYPH6VE0WGRYdER H6c4jEVAuspnKjYUplmGuZ1dTTqa4bRTf97VMTdnpN+LyiA2ALEBiA1AbPRQbKTLxqaPLMrERtyl NTeykds0Le7Oly51mz4aidtHIza48CA2EBuIDf7ziI2aio3czngerSgz7FFs6PFGuh193GjJx/bj +R5R1MS8yI/8ei+WMmHBnA0uPIgNxAZig/88YqMmYiO3t4kultEtXWfDkz+9DbTQKEjq7jB+hTbu AGt/6TbzSivdmjhN36MiiA0uPIgNxAZig/88YqMGYqOOpI99EBtceBAbiA3EBv95xAZio2dohCM+ ikFscOFBbCA2EBv85xEbiI1agtgAxAYgNgCxAYgNLjyIDcQGYoP/PGIDsYHY4MKD2EBsIDb4zyM2 Rl5sTE39+/+lDl1Hjnn+C2uZb7F4yRGPjYPY+N3nrKpl/b/sxNc0jnvZCbXM++8d97KhiI01zTqr ZX2tPr5x4imn1zLvv/abzxg5sVHX/7z6gPpCHfOu/16txUYhONaqM9eUbzd5b03zvr7JVJ3FRvOz vMZ9Z2eTB2uc/5UDbuvVNa6rPU2uqXH+p0foPz9T43p8sPjf858fhtioubHbUffRARha39mtCyd1 MfbtPNVkb92FPfSkL2yTaKYuEBvz6Txbm6yhQaHLfrNSQpW6mIi2XtVkO3VBP6AfIDYW0oH0CGgL DQpd9BkNA+8apaFp6FtbTxdtPUN9THQ/WF+MajC6hdhY0MVkD50IKvaXFYXxWUZ9TITQ2M6w+UT3 gZXFHI2N2AjERi861KYmszQqdOgns8UcH4TG+Lf18sLIIDQmU2SuK9pf//cV1Atio1eda2nRsWZo WMj0jxXFRWcTdzdj39Z6RLaF0auJa/dlxc3E9mIy8GZEBmKj33cy0zQuhAvQtqJfrKROxrqtlxci Q28YraVOJuK/vaYQFWrzR4ubiVXUD2JjEB1wVdHpMCwYni1FX1hNnYx1O28qjM0uRMZYt/PaYt6F RigfK/7bW4vHJTPUE2JjGB1zadEhmRA0eRelVUXbY3jG1+jMFkZmT9HOsxibsWjbmWIy52yxeJX/ x43ie0vxRslKruuIjVHrvOsL9buei9FYt/NUcdfzaPG8diX1MhbturK4a/Xd7N7C6Gwqhs+XUk+1 Eokri5sBr4S5NREUu8O8qg2F/+XUH2KjTmp5YxhmXcdFauzadk9x18NkwHq137IgKDYUbbij+K82 iuPN4W52mnobiXZbUbTHyszy9duKdosiwiMTO4qbAftdg6BAbIyzut5cGKe9QUWv4264dne8Wwuj tB4jNPT2WBqMT84AbQkGaE8wQI8GQbGhGJ1ayShkz0RcjnVt9tzYkeGx0F5mZzi/LYljdUgLEQGT KTaSP+R0eD64ufjjNDJKPF4Mu2V1mz99BGPZub38qMTtsmYIeVhRsT27YVAbm72jyU1teKSo23b8 bcbwiO8k/h5J4n5H8T8TL+rSAI4LG0uMeTc8VlL/KY+2iaPdtSzXP5kbAYiNAYyCLPRiuK3iRWRv m+HGNZP8rnghCjcUoxhbur1bCqIyfV5cdif3aJuL+M4eGIwdiWGPhvkTGR4tyl7G9ysaoMc6xPO1 CmLjcz0qfzcGcFxY3wNhiuEHxAb0XOSsCpOodhbGYltxdz/2c06K+RibimH3DWVlLkY84gjB5uS5 /95g1LZXuJNb1mU+l7YZpSi7K91bYnTnMzrG/CMAQGxAz4zvVGF4thQGePsBY7jTbfG82Qszzca7 ueLc6mDI9xRGPD47Xter5/5B+K0t4t6UEQ972jy/5q4UAACxUWujvOqAH681MDsmImNb8dhgbSjj xjCf5tFg0Bd8Vx9GRdYFAbMz80hrS3F+FvEAAIDYmETRsbS4467lqqlF/r3S55sO+PHeBo3ie/1C y3XAjxcLWh9GJ/aGUZHNQcCwlwIAAGID2owM2HCO/F13EEnfavLQAT9eDXJBexsU8a4KIxWeGOkV ZWd5AwgAALEBCzPi6wrDOrITB5ufCwpxIaHx54UAWDrPuFYc8OPlq3eH+SwbeNwBAIDYgP4Z8xXF 3IOZEcvXCU2+2+QHTW48YB6L/hSTNuM8jp0H/Hj56pEqLwAAIDbGXXDMFAZ56Aa4+fmdJn9diIw3 dRk2fQtnVy/mcQAAAGIDeic4dg7rkUoxCvHZJv9Lc0m6zPe64nHIRK0vAgCA2IA6Co7lxQjH9ADT 1KqdtzT5diE2piuGWRdWzNy8kImiAACA2IDBCg6NCmwZUFp6E+SvmvylxENFMeRHJJsPYOdWAADE BtRWcGzv50hBMbdCEzW/2uSL7SZ/HvDjTdV2FnMw1vLWCAAAYgPqLzaWFo8opvsQ94pCNPxxMUox XeIv7neyhQW0AAAQGzB+gkPrUWzqcZyrijkh95U9NinmY3iV01kW1AIAQGzA+IqNqWLy5dIexSeh 8UCxAujakvRmc5uqAQAAYgPGV3D0ZHSjmGfxsUJsrMqcX12MZGxiJAMAALEBkyU2Fjy6UQiN24vH J6uScyvCdusz1DkAAFAJkyk45j26UYS9pRAUK5JzG4o3TFZSzwAAgNiYbLGhN1P2zCOcRy1uiXM0 igmgGsnYQP0CAABiAywQdnQzAlEICr3eemEcFSkW5dJoxmrqFQAAEBsQxcO6Lvcr0cjF+cXiYFOF 25pCaLDqJwAAIDZgP/FQ+VFKMU/jhmJkY7pw01smW3mdFQAAEBvQTkR0fJQSHpN8zhNCi1GOWeoQ AAAQG9BJbGzoNKmzEBY3eJ5G87OxyXrqDwAAEBtQRWxoBdDtbc5rVOPr3lOl23keAAAAiA3EhgTE 3jbnNarxYCEyVsbJoQAAAIgNqCo4duW2gy9GNf68OL+smLcxTZ0BAABiA7oVG5tykz2LUY2/bvI7 heCYob4AAACxAfMRG1orY2vippGMbxWCY2e6LDkAAABiA7oRG1qCfGfiprdUvlm8ebKVegIAAMQG LERs7DdJtPn5YpPvLHR3WAAAAMQGWFzssajQ3Iwm/7PJ51m4CwAAEBvQK7GxM6wOqqXJ9xZzNnjN FQAAEBvQE7GxWWtpFMdfKkY6NlE3AACA2IBeiY31xWRQbc72z03+B3M1AAAAsQG9FBtrm2xpsrrJ j/TKK/UCAACIDeil2FhZ7AB7cZN/1dob1AsAACA2oJdiY0UxSVSC4/9jYigAACA2oNdiY6ZYU0Nr a/wVdQIAAIgN6LXYmGryWJP/rbkb1AkAACA2oB+Co1HwXOoDAAAQG9ArgfHSJnc0ua3JvxRi43nF hNFp6ggAABAbsFCx8WgY0Uj5AXU0Pw4+8MB3tKlXAKgBjz/44C9wPUNsQG/ExvI2f7bnU0fzY/qQ g+9574a3Nb7zpS9ACeefdmrjXeecPZC0Hrj2mlZ6vY5X+a9ahr975JN9LWM3eYHO7PrAA42DDjzw 21zPEBvQO8HxzYzQ+BvqBrHRT+OvfvZzTzy68WcPbe/o//P33dtYsXx54+Hbbpm3sFFavS7H7z1r ZYsq/vohduaTF0BsIDZglEY3nkTdIDb6xStXv7Bl/EXOCEtURGFx+gmvbPXLzRddOHc+jhREvxIv afh2YsN+JWiiey4e+YnE83ZzOIdRnpV3lSE3umH/UXSlcaWCzPlVfE6rXV5y4ecr3BAbgNiAhQiO PUFoPEydIDb6iQy/jK/uxKMIkFG0CDEyqPr2SIiMZBQp+q1z+r79istb5zQK4vDtxIbTl38LArk7 HuMRgxiv3PRbpOeMDL78Oe+psJIQifm1mPLvGKdGg8rSsXual07h7R8QG4gNGJTY+I+F0Pj/qQ/E Rr/nFvjxie/6bQg94iGBIWSoPd/CgsJiJSc2hOctOG65lYkNiwaJAqXj+GWELTDkrnwpPzbUzl/O wPuc43b+ciM4Fl2pIIpxWYB5jkuuvsrERi58mkfmeSA2EBv1NNrLitdG68j3m7yvxvkfmSXWERvl 2BDK+MnQpiMHubvtqmLDIwlxtKKd2HD66chD2eOdNH+pgc+dKxMbyqvT9SiJR0PSuJyftBypQCnL i8N7lMXzO2LdA2IDsVEjfuIn/t2PDjziKXtryaJf+G5d8/5TBy7W6qfrERujjQ2sjWEc0tcdePpY RXfunUY24ghGNLKehNpObHg+g/zGtPWttJ1nz7foJDZiGp3ERjqyEed6lImFOCrUaWQjF97iKpa/ 32/JIDYAsdGfkY3Gr7/lSzBgjnzGa3VB34DYqMfE0JwAkTHUXIl45+1HBhYOMqC+87ehjiMYFgyK q8rIhkdA7N8G2hNSld8oIjqJDedd4XSs8jid3CML14dFQCexEONK56VUERuqOwupNI+A2EBsIDYA sTEWlK2tEd09kiE8N8F+hO7EZTT928een2B3H3s+Rm5kIfp3HHHyZozL801i/uNvG3iHi0ZcftLy pOfK4nXZHdbldToWGzFMu/Bl9QuIDcQGYgMQG1CDuSj9frvDb+Jo9ERiZhBpIjawa4gNxAYgNmCE HhF5nke/R4csMvwmDfWP2EBsIDYAsQEAiA3sI5WA2EBsIDYAALGB2EBsAGIDABAbiA1AbCA2EBsA iA1AbCA2EBuIDQBAbCA2EBv/xn/4vYsaP/s7pzWe+Nxzugr3a298pKswSiOl2zRjXIgNxAYAYgMQ GzUQGwcdtbyx+JdXt4z30t84oTF16BMb/+nUhyqFfdop97XCtvNz6C88a+5YcSuNXoiNGC9iA7EB gNgAxMaIio2nnHhbS2xEN4mBKADkR0SBYff4W98SKXK3WNHIh+K3X4mNGFcqXByvj3N5KEs/zadw ftL4EBsAgNhAbMAARzYkADTCkDPIEgoSH8KiRN8mihXFo9EGxSW3nz/uisYvrrl2Lv5OYiOG17HC y10jJ8KjLjE95yemK39+NKTfctd5/UZsAABiA7EBQxAbuvuXMZfxFn4sotGN+IhEvz1SYSGQig2d 17FEht3TxygpUYg4vNKyAIojLxYUqdhwfqJ/nbeAUrz2j9gAAMQGYgOGMEE0FR6ew5GbhBkfi0Sx kT6OsXFPxUa7kY342MTzOTxSkRM3aX5iejlhU5Y2YgMAEBuIDeiT2EhHL6JBT8WGRg88cpATG1Es xBGGhYiNdE6JH41UFRtpuRjZKEe7jWrzrV7tfxF3NY30a3+NbvJflrc0n4rPVM3HfMvX6/qvM5NW B4gNxMbEzNmQ4JAxtjGXsNAoh4+F31JpJzY0CiE3GXxPMtV5H+feRomPUVKx4fA6Vh48P6OK2FA6 LpfST0deEBs/RluIa2MvGTt96/dCL6DaUjxn1LWhVz+Mk3cnPf2EV2a3eK+SNxG3cS/bEr5TXY5C /feKuH38oKha/n7kzSITsYHYgD48RvEIhwy05lvEEQoLAs9/8NyNdJ0NGX+v1xEnYyo+uclvbp0N i4o4iiK/zofTEBIcqf+YH49+xHKlb9cgNvYn3TrcF3sZbxk/CwQdy5jndgD1TqQ6b0MgPyLuUuq4 lEZ6UXfcOqdw/u04406nUVDIfzQ8zr/82HjHfDhvzq++9Vv+tK26xUtaT7nyO7y+HWesjxiP3VSv Verf+XdZY/puG/tN6z9NL1efsU7cVqkf5S23w6z8us5dn86T/afxd+ovLqu/NdrjOpbY87lc3srq Nu1/sSzOl88rvdhm3dQ/YgOxgdgYEL2agJnOIdGIhMWEBFGv3ipBbHQebYiiQ8ZAF3ddkHXhT8PY YNqvLtASE/In/wqnc/qt8+lFWqMNNi7y47t8G5soABRe/mN4b4duIaDzNhLOi+Pz71x5HMZxGbtF /1HkeGQi+o31oTI4z2nd5eo/xq08qUxO3yM4MWyanvPTqT4VnyjzUzZKJL9p/Tp/HjlK4+/UX9wn 3IbRyCs+11+at051m/a/eE5xu+/p24/Nuq1/xAZiA7ExIPq1yJZGMxS3X29lufLBjWzEu1xdcNML dZnB9KOHaHxjWh5dSMWG7zDlJ2fM5Ed5S+OMd80yBn4EEkdOcvGlow5RbOSMSFr+mEYap7+dbvpY plP9x7gdRxpnTCet//R3mThwftQeOT/diA21j8VZbAfHX6W/pGVSXYg46mBhFIVhWd2266fOp+OV iLDY6Lb+ERuIDcQGIDY6IDERh8R95+i7N1/E24kNXfB1B+lRizia4MmPMQ5f6HN3oHqUkTNm0bCk xtl5tcGL+fddfs7Y2rikw+w2aCYdzdGxBZLOOa4yseE7d/lNH0vk6l9xx/zHkZ2cscvVv4xnzFtO bLl8SqtMbLid4ryVWL+Ox789WpHGX6W/xDJ5NM3HfkQSxYby1q5uc/1P/hSX+5JHq9xPFFe39Y/Y QGwgNgCxUXFSXnoH6uFtXZg9qlA2ic8XboePkzCju8P5GX80XvZnw+Gh8RiXjUdZ/qMQUfz67fBp fH6kE8N4/oHdTVn5nYYFmt39HdN1nLm3LXL177hdT7k47ZbWf5peWX3GOsv5cV3YqKcTNKOoiW2Y jlrkRtPK+ktZP3NcMb0o0srqNqbjPCqOODcm5tETgrupf8QGYgOx0eUcCa8WqscWXiyrrsSJo4iN /tKPt0xybx/0Mp2FxuXJhemozzjWv8RGL19JHXZ98eorYgOGJDYkNDTJU29u6HVRrwJaV8ERX5+t u9hofqZGXWwMglFdf2HQr0oCYgMQG7UVG141NLpJcMQVPL2MeBQgejvEr7faPb7S6tdYHTa+WiuB k75aa/9+jTamlfMvvzqOS5x7nQ2NzsT0aiw2NjTZ1mT5JIsNAMQGIDZqLjY6Leftxbm8kFdcX8OL Z3kzNR172XO7y783ZtN3btEwCYXoP7p75MUbvCms1wFxPArjV3AlViQ4ev0oZYhio1Eg0bGizmJj VEcCvB5HXVewrFKvVRcny40o5dbb6Ef992tUq138w+zXiA3EBmLjLfmt6C0U0vU15OZ1MBwmt+R4 XEU0ulucRP92k18fW8zk4nHYMXuMEsWG2dFkZSex4Zn4Zb9tXD3pMp6TYUovoPod306Yjx+/wVHl Ap3Lf/xO81+lzGXpxkWkfL6d+GgXp/PksJ3qNU3HfmK5op8q9ZpOpPVrpJ2MY6wvHce3TtJ8lvWn dm2Ypu16im0a6y7moazO2vVFn0vj79QncnXYrlyx/rsRrYgNxMZEiY102e8oAtIN0aLISMVGupS5 vnObqaUTUMvEifdI8dbzcYv73IZxXu+jX2LjsGXPa2QM/9D491NTXygTG3GVQ12s429P0NNrpvod 3w6Ir4bGhZC87oEXQvIKi3HiZic/fhXTr42mCy2V5T/GH19DdP79umgaxq8w2o8XmMqt1xFfCY0L TTl8NDIxjlycrk+vHeJzuXr1OiZxvQn5ifWa+qlar9FY+q2ZdnWQqz/Hr7p2unHF0LQ/xeXdO9V/ ut5H/O02iHlwPjvVR+yLXhMlxh/D5+qjrA7L6inWv+P2fw6xgdhAbAQ8cpAuY+7HIlEAxC3kq4iN GDaORkQR4t9lYiMVPMqD54oMUmyM0MjGliYz7UY2oiFJ14mIF/5oaB0uriXgpcXj64F+CyOG8SqL vtCWLdYUl5uOowi5/DsOr7egNLykeIzTr2amZdTF34ZbfuKy2C5nKjbiWhM2QjFfcQVTL6PteNKF x9I1GXL1mq7f0WkBrnRBsbRevTJmauhyC1alr/Tm+ki6pkRcsyJtn1S85Oo/1l2nxdbSlV1Np/qI 8ca1TnLx5/pEWR2265vzXVUUsYHYmCixYUPtlTolPDwvwuc8khDfUqkiNjyvw6/Vah6F0LHchDd6 KxMbjt9iJc7ZKBMbnvsxZmKjJTKqzNmIz9jTu1ivV1FFbHh1SV9MvepiTmzYj4et2xlFD0OX3T3G u1nH4XJ43QTH6fUTcmX0uggOZwOSppmKDQ+3e6Qm1mVcjyIaUD+qqCI2XK9VxEb0kwqGtF7jPifp YxORy29ObLj+2omNtH1SQ+tHGK7/tO7mKzY61Ufsi14vo53YSPtEWR2265s5scHIBmIDsVGC3+zI PVLxfAmJgtzW7RYm8bfFg4/L4kzDla2V4ddy4/noJ4bVcZqnGouNfURGFbHhxw0eZYi/043RcmLD d4/RmMWNyHIGL92srGwZag9Re/g7Xqxz+U/FkQWKRjmcnp/zxzD+7dGWeFda9hglPkJxeVKDk+Y9 jbOd2Ejr1el4WD5ngFM/7erV7ZRugBYfP5XVQa6PKL+5FTTb9ac0vlz9t1vZNd1YzXmIgq9TfcS+ 2E5s5OojrcN0cmlZ2b1YmPPmkaN28zcQG4iNiRQb/Vjvolfbu7OC6P70622Udvti9Iv5pFe3xaGG Ua91o1dtaqGS27hvPnH1600WxAZiA7HRo1U8e/0oA7HRf7ERl2QeFPN5LbMXy0UPuoyDrte60as2 jZNDh9E3ERuIDcQGIDYAYCRAbCA2EBuA2AAAxAZiA7ExKPzGiNe66MWeKembJIgNxAYAYgMQGxMq NrSwl18pja+VxrdS5jufox87syI2AACxgdiAmokNTfBMF/zysuQeofAaHX6NVWHkx0uYx0miPqdv u2ukxHF41ESvrdotXQAs9YvY4KINgNgAxEbNH6PIsHtxrlRoWIh4zxTvzupFveJeKl6cK+7g6hVJ 42Jf3njN4sWLf0mAOC75jSMuiA0AQGwAlVDzCaJe8MvCwyIi7lEid28Pn26Q5kW2LBbsJzd3w49q 4tLmTtOip9fbxyM2AACxgdiAIT5GSednxGXD434nHqnI7erq0QmPjHQjNqIf5SUVPYgNLtoAiA1A bNRYbOQ2afPjFH3H+Rj6nduzxKMb6b4nwvHERzZxszdvvObRjDh/o2y3WsQGACA2EBtQs8coMvR+ 7VXfqcGXQPAoR9lrrYojioroxxu/+bGMR0PilvIWFU7Lk0R5jILYAEBsAGJjTOZs5DZbG9SS57z6 itgAQGwAYmNCxAYriE6W2NCeEN4x08htFPckqbJ/hTbl6nXetddJWdq92FOjXfzd4rLre1D7tPQy /72MC7GB2ADEBmJjhEY2tFOpt1lPt/EeJdIt6nNoq/Jep6ut7cvO9WITsHbxz6ct3X793oHWcfcy /3ErecQGIDYQG4iNMXuMkl7kf+6JRzdeufqFLeMtY6Ltt2XA5JYaff2WuwVK/K2witu/HbZqGLkL pa88xVEL7/optEW4/Of8KLz9RAMv/8JGM5ZPdaGye1dR/Xb+5UdxKW6lF7cmT/PkcEZ+nK7jjvHb 3XmNbrHOY725vC5nmdhoV+YYzvHENsj5Vf04rlg/ubC59o35jf3QeSwLG4VVzJPjk59cO7g92/Vl xAZiA7EBiI0Big2PEMhNjyZsYH3RTg2YjnURF76A65yOFbeH820MYhj9tnGUkbABjmFyIxvRUEVj Gf04fhumKAqUB+dZv220la5He2Ld5NJLRw5UN/Jr/7l4/Fv1mYqNGL+Fks4pr7F95O560zn5Vb7b iY20zGpXi5o0fAxblhefT/Ofhs21r+pJx1GoOa60r6Rh0xG52B5OO63L6LesLyM2EBuIDUBsDFhs 5C7eNqLRn4xFagDi7zgy4N+5MDZgwne+DmNhMh+x4TtvGZf0nIya74ZleJ2e5gy0M6ZVxYZJ4/Fv H5fFL3c/2kofLbgO46hRWg+5xyixzLGO5a46KBMMubxUFRu59lUdO704ryRt91zYXF+rIjbSPOXq FbGB2EBsAGJjiGLDjylyRtsGI95t67f9p2KjLExMw8PsMb10GN2PEGS00jvcnKGJd7GK13fqcbSl 3Z27wistkRq5mCf7cfw5o+xytRMb8a4+LXsUNhYcncRGuzLH9DqNTsRHIbF9y8L6O7avvi1w4uOt snaPYauIjbRvRL/t+jJiA7GB2ADExgDf9IjD2z4nt7I7wdxdp+OIccd424WxIYvpee5Imm460pJO vnQ66bm0PPabltvf8Y44xpHWXeonjcfpet5HdE/LEfOf1nlZG8XvXLvmyuz428WZy4t+5/Kfc4vt m/vtcLl+lvNblo7dytqhU19GbCA2EBuA2JgQdEeaMy7DxKMHvXirJk4YBdbZAMQGYgOxgdgAAMQG YgOxAYgNAEBsIDYAsYHYGLjY8BsLvRr+7zZtzUfwXAn/Xmi8ca2OXhInHubK0a/4Yzqa8BnfzPDj ltw6G2WPZ6qmrfVB0vU/qj4C6rbsXvMit67GsClrW6/1gdhAbIw9P/ET/+5HBx7xlL215PBl361r 3n/qwMWPNcXG+nEQG5oQJ0Oj+Q/6LUMm8eG5EP5tA+fZ+17/wLP3HU/063kVjtvh5cevNjp+GZm4 dHbqz3HnjGL0q/AykjHN6Cc3OTTG699xPQ0d+60Exxvjc77b5TONN60br1+RTtaMfmyIo59omGP5 4noTsQyebJq2VSxbLu5Yj2mb+ne6DHquLtKwrpuYlvObtu1C+5/c7SdOaE3bO/pRvBZ4qd+47gpi A7Ex7iMby5qsrCn3NDmlxvmfGrfHKLq46k5NF1i/dhh/62IrQ+7XIb3uRHw10nd88fVWx2ND4YW8 /KqhL9pxTQn7i69SOn/xTYfUr41DfItAxkOkRk149VO/XuvfNmgWQl6IzG+IxPic73b5dN5sONO6 cR5SY5/WX+onjgjYyNrAxgXTXIZYn7GtXLa0bmJ7eLTDi7i5frzYl84537m6SMvjdMqWTE/b1unP t/+5LK6H2P6xPKkf/wfSNuQxCmIDRl8kLW2i0YFt1MfoiI10HY342wYmLlRVtsdGXII7Gk4bgLg8 tOOJi1uld+u5dSja3dmngsLGVO42iDkj53UyvPS118pIF6hK44vlKMun1/CwWFA4L7Nuw5sa3HaL TsWRKefdxjW3vHentsoZ+7j4mEcCOi2MlUvD6efKXCY2UmGYtu18+l8uTLv2TlelTdsQsYHYgNEX G5s036RgOXUyGmIjDl/HEQf/joYsd+GO+1REw+C7Qg9FpwZC317+2/NHcv5yRjz1mxv+j48e0qWn bfTSO27l3494UrGRxldFbMSh9yja4rmy1U9dfzmjHOPx3blHaRxnlbbKiY3cY5RUbMQl0l23ZW2W K3MUNq5TG/12bTuf/peGSZfET9s7jmzk2hCxgdiAeoxqWGwwujEiYsMXahuo+DvuGWGD4LtdGxzf 9dmvh7ijQfLGVn7m7mFy78fhi7jDRX9puulEPRuDdNKeV4PMTejzXiDOs3/nyunVNdP4nL92+Uzj zdWNjWa8449+YvyxbLkNwxzOK3B2aiuXLRUWET8SsXFO28piI21Lp58rc/oIr6wcadvOp/+lYTq1 d1wC38K7bFLoQkc7EBuIDejvqAajGyMmNuZLv7cqh9FsK088tQCj/yE2EBswiqMajG70SGzMrl07 9yhgWNz9nj8ceh5g8G115sknNV738jX0vwVw3SUXIzYQG9DnUQ1GNxbI1NTUGYdNT+8CgPry+IMP vpnrGWIDei88dugVUuoCAAAQG4DYAAAAxAYgNgAAABAbgNgAAADEBiA2AAAAsQGIDQAAAMQGIDYA AACxAYgNAABAbABiAwAAALEBiA0AAEBsAGIDAAAQG4DYAAAAQGwAYgMAABAbgNgAABjd694M9YDY AMQGAEA/r3u7m2xtspz6QGwAYgMAoB/XPQmNRoGugauoF8QGIDYAAHp53ZsNYsPsarKW+kFsAGID AKAX170VGbEhdjZZSh0hNgCxAQCw0OveVJPHEqGxWe7UD2IDEBsAAL269u0sRIZEx19otIN6QWwA YgMAoJfXvk1N9hSPVJYWczZ4hILYAMQGAEDPrn3Lo7goRMcOHqUgNgCxAQDQz+vhOs3doC4QG4DY AADo5zVRE0XXUReIDUBsAAD065o4VVwXmTCK2ADEBgBM2LVKq36uHlBaTBhFbABiAwAm8Fq1PSwv vmIA6TFhFLEBiA0AmLBr1aZkEa5tTZb1OU0mjCI2RoefOeSn7zlw+qd31ZGf/L/+3XenDvqpb9Q1 /wglgIkRG+tKlhjf0mS6j+kyYRSxMTJ/gsYZ1z+zlpy6+Rm1zftvHftEXWg20AcBJuI6uyojNPb2 e/O0YsLodm5sEBsjITau/JPVMGCev24ZYgNgcq6zM4nQ+Jt+P0YJaS8tljefoS0QG4gNxAYAjPe1 1punnV8Y/+UDTJsJo4gNxAZiAwAm4Fq7zW+iaFSjeD11aoDpr9UcEdoCsYHYQGwAwORce2f1lsqA 09RbMbPUP2IDsYHYAIDJuf4O9PV9JowiNhAbiA0AmLzr78BX+2TCKGIDsYHYAIDJuwav1nyOAafJ hFHEBmIDsQEAE3Yd3tLvNTcyaTJhFLGB2EBsAMAEXYc1l+LRQT/aYMIoYgOxgdgAgMm6FuvRxs4h iJyRnTCqpdybXIjYQGwAYgMAenc93jDo68KoThg96KCDzliyZMk/ykYtXrx4oJNoERuIDcQGAIzz 9XhqUNvQZ0ZVRmLCqPKyaNGiR9euXftPe/bsaSxdurRx7733No444oj/8fjHP/6liA3EBiA2AGDh 1+SBry5apDvUCaMauVi8ePGHnvrUp+7duXNnw59ly5Y1Hn300cbevXsbz3nOc75z+OGH3zeouqFD IjYQGwAwztdlbUm/eQjpDnzCqITDIYcc8o5FixZ9b+vWrY30s3LlysaOHTvmft9www0/aoqSvx3E 6A+dEbGB2ACAcb82a+LmqkEb/kFOGG1+1jSFxnfOO++8x5qfRu6zdu3axpYtW/Zx00jH8uXLv71k yZJjERuIDUBsAMD8r80DX100pNvXCaPa8VaTPo899tjvaV5Gu8/s7Gxj06ZN+7lLnDzjGc/4zhOe 8IRTERuIDUBsAMD8r88DX120SLcvE0aLeRm3PfnJT/5ufDTS7rNx48bG+vXrS8+/5CUvkeC4GLGB 2ADEBgDM/xo98NVFi3R7NmFUomV6enqD3ii56qqrftTo4qN5HGvWrOk0+vHdZtw3IDYQG4DYAIB5 GuphrC5apL3gCaOad6IJnWeeeeYP9EZJt5/du3c3ZmZmOvq79NJLf3jkkUfej9hAbABiAwDmd50e +OqiQejMa8KoXuFdsmTJzmc+85l7NaFzIR+ttdFpboc+11133T/3UnDQ+RAbiA0AmLRr9YZhXDO6 nTCqJcYPO+ywa4866qjvbd++vdGLz+rVqxvbtm2r5LeZh396whOecDViY8LFxvn3P7fxljtW9jWN t39sVSsNpRXd+50uYgMA+jzKMPDVRYu0l1eZNzI1NXXWoYceuvfyyy//10YPP3obRW+lVP0Uk0YX /JYKHa+GYkOG/+d+ddE+PPtVP9/zdH77uCftk8avPPsJc+eWPPEgxAYA1Pl6PZTVRSvka2VTZPz1 qaeeOq95GZ0+enNFi3tV/ei12BUrVnx7oeuF0OlqKDZk+E+4+On7uEkIvOD0p/RU0KSCQuLjpef+ Co9RAGBcrtlDXVY8ycvM4sWLH37605++d9euXY1+fSQepqenG2ULf+U+Ej1HH330Py5kYi0drmZi 44zrn9kSG+3EgUchhI79CEQCxecchx6HSETYze56fKL4lJ7TuPQzL9hvZEPhYnil4eN+jLYgNgCg x9ftbVqDY4jpTy9atOjKI488cm/VuRQL/aTLlld9k+WII474lvKL2JgAsaHRCxn33DkLAH17ToWN v8WDBYPd5S+OYEgkOOxr3r2i9Vvn5TeOpkRh49EO5c1iRekM6lELYgMAFnDdHsrqokXaa7T1+0UX XfRYNyMNg5634c/tt9/+o6VLlz6I2JgAsSHDHudO5MRGOvJh8aHvOAfD7tG/BEM6+VNCxaMiflQT 07J/nYuPchAbAFCTa/cqvZY6wPRaW79XWWK8Hx+lqfU25iNwjjnmmO/OZySIjlYzsZGbSxFHKlKx IaFgQeDvlJzYUHzpHJDoF7EBAGN2/d6sHWL7PYqS2/p9GJ9Vq1Y15vM6rYSKRmO6fZxCJ6uZ2PBE TSEh4XkccX6FjvUIRMeaN+G5E1EYeISkTGz4sYsfnei30mRkAwDG9Po9VTxOWdaPuNtt/T6MT5Wl y8s+2pr+8MMPvw+xMeZiI86P8HyKOJFTbp60Ged3SBR48qbdNVIS/UiEeEKp4owTR6OQ8CiKwtq/ wsa3Vcoe9yA2AGBEr+E93zRNjxwOO+ywPe22fh/GR3nRaqLzfb1Wq5nq8RNiY8zFRjtGaQ0MxAYA 1Ow63pPVRb31u+Y46E2OUfysXbu2sWXLlnmFVZkkoqoKMzoXYgOxAQCw77V853xXF53P1u/D+nS7 wFf60eqmWk4dsTGhYoO9UQAAFnQtn9HjlG7DaYnx+Wz9PszP8uXLG/NdREyPYjQPpcprw3QsxAZi AwBgYdf+VdPT0//QryXG+/nRQmLanK3foxt0FMQGYgMAYH7X/J5t/T7uoxt0GMQGYgMAoLtrfc+3 fh/30Q06DmIDsQEAUJGDDjroDC1q1eut38d9dIPOg9hAbAAAdL6+t7Z+X7t27T8NY4nxuo9u0IkQ G4gNAIDy6/pAtn4fhY9WFJ3vCqcSYAceeOD3EBuIDcQGAED163lrifFBbv0+7I8Ew7Jly/qyqiid CrGB2AAA2PdavqYpNL4zakuMD+KjFUW1suh8wx522GH3IDYQG4gNAIDya/hQt34flc98d4TViMhB Bx30T7klzOlgiA3EBgBM+rV7ZLZ+H5XHKTMzM435jOpIqGlkCLGB2EBsAAD82zV7anp6eoOWGB+V rd9H5bN58+bGunXrug6n+S2aUIvYQGwgNgCA63Wx9fuZZ55ZuyXGB/XRq7DdTo7VaMjU1NRj6aMU Oh1iA7EBAJN0nR75rd9H5SPhoF1hu320pNeEtS4JYgOxgdgAgEm7PreWGK/D1u+j9NH8jRUrVjS6 EWYXXHDBv05NTb0dsYHYQGwAwMSgrd8PPfTQveO2xPigPlrMTCMcVR835eZt0BERG4gNABjXa3Jt t34ftY9ehdUrsVU+quvHPe5xP0RsIDYQGwAwztfisdj6fdQ+ekOl6oJf2hFX7YDYQGwgNgBg3K7B 04sWLbpyZmbmO+Ow9fuoCg7todJpDY6mn+8322MtYgOxgdgAgLHBW79fdNFFE7fE+KA/WpNEr8W2 ezQlUTI9PX0zYgOxgdgAgHG47o711u+j+tHIUbtJozqvR1mIDcQGYgMAas2iRYvOfdrTnva9cd/6 fVQ/qvfly5dnX4vVOYlAxEafxMYZ1z8TBsxvHftExAbABPK4xz3u0o0bN2L1h/iR0NA6HOkcGbkf fPDB30Zs9IGfOeSn7zlw+qd3weBJV6sDgIm4wVt/9tlns3bGkD96fKXXYmdnZ/eZOKobcMQGAADU XWys1VsPmPvR+GzatKn1WMWvGx9yyCH/rB11ERsAAFBnsbFS+3Bg5kfnI6EhwSHhEdfaoMMCAEBd xcYyGTRM/Gh99ChFj1QOPvjgf2220fMQGwAAUGexsVRD9Zj30froTRSNOE1PT39eC60hNgAAoO6C A+s+Ih+tuaH1TvTKK1vMAwDA2CDDxjobw/9oR13trKuVXLOikM4KAAB15bDDDrtny5YtWPshfbS+ hubNNNvhWj8yQWwAAMBYweuvw/norRPtqqslyePurogNAAAYR7Gx/MlPfvJ3Mf+D+WhexplnnvmD 6enpf2jW/arK7URnBQCAOvO4xz3uh+12IOXTm89VV131oyOOOOJ/NIXGhq5FIR0VAADqzOLFix/e tm0baqBPnx07djQ0etSs59u8IihiAwAAJoqpqam3X3DBBeyR0uOPNlM75phjJDK0/9TyhbQRHRUA AGpN87PiqU996l7kQW8+WgH0vPPOe+ywww7b06zb1T1pIzoqAADUHW1nrjtxPgv7bN26tbFo0aLv HXLIIe9oCo2pnglCOikAANQdHqUs7LNz586GRocWL178ofnOy0BsAADAWMOmbPP77Nmzp3Hsscd+ b9GiRY/qcVTf2odOCgAA4wBLl1f/aF7GRRdd9NiSJUv+sSky1vRdDNJBAQBgHJiamjr/rLPOegwp 0f6j14SPPPLIvYsWLbqy3RLjiA0AAIDUoLHlfNuPt37XuiTNupoZaNvQQQEAYFxgga/9P+22fkds AAAAdD+6wV4p4dNp63fEBgAAAKMb8/pU3fodsQEAAMDoRlefbrd+R2wAAAAwulF5XsZ8tn5HbAAA ADC60fGzkK3fERsAAACMbpR+erH1O2IDAABgYaMbS3XHr0cM4/Tp5dbviA0AAIAFolc+tcbEOIiM fmz9jtgAAADoARoB0COHOn/6tfU7YgMAAKAXhu6AA2a0F4hGBur26ffW74gNAACAHjE1NXXWqaee +oO6iIxBbf2O2AAAAOghMtwaKRj1eRmD3PodsQEAANBLg3fAAUuPPvrov9XbHKP4GcbW74gNAACA 3guO5U972tP2jNLrsMPc+h2xAQAA0AeWLFly7DOe8YzvDFtkjMLW74gNAACAPrFo0aJz161b971h CY1R2fodsQEAANBHjjjiiBsuvfTSHw5SZIza1u+IDQAAgD6jeRLXXXfdP/dbZIzq1u+IDQAAgAFw 5JFH3n/22Wf3ZcboqG/9jtgAAAAYEEcdddS7TzzxxJ4Kjjps/Y7YAAAAGCBLlix50wte8IL/udBl zeu09TtiAwAAYMA8/vGPP+F3f/d3/5/5rMNRx63fERsAAABDQOtwHH300f9YdWnzOm/9jtgAAAAY lnE84IAZ7aVy7rnnfr+d0Kj71u+IDQAAgCFz+OGHX6Yt3tP9VMZl63fEBgAAwCgYygMOWHHEEUd8 64YbbvjRuG39jtgAAAAYHcExffjhh9934IEHfm+ctn5HbAAAAABiAwAAAACxAQAAAIgNAAAAQGwA AAAAzIv/A4Qxox0rNs/LAAAAAElFTkSuQmCC ------_=_NextPart_001_01C8D00D.200DC7A3-- From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: Best regards,Stefan AnderssonTribal Media AB Join the 3d web revolution : h= ttp://tribalnet.se/=20 > Date: Thu, 19 Jun 2008 20:16:06 +0200> From: olish at newworldgrid.com> To: = opensim-dev at lists.berlios.de> Subject: [Opensim-dev] A software to connect = its own region and TP in from locally...> > Hello !> > I started to develop= a software that creates a region automatically for> a given grid. Clicking= on "Create" creates automatically the region file> as the software gets au= tomatically the local IP + public IP + domain > name and you just have to f= ill the region name and its grid coordinates, > then when all regions are c= reated and configured, the user clicks "Start> Simulator" and the sim start= s up after the software configured its> firewall and forwarded its router p= orts correctly. So people can host> their region for free and at home.> > T= he aim of this software is offer people the ability to attach their own> re= gions on the grid they choose with the minimum manipulations possible,> and= without the need to rent a server or have another computer on the> LAN. Bu= t there's a but...> > I experimented this last week to TP into my locally h= osted regions> (viewer and opensim on the same computer) on OSGrid and my o= wn grid :> anybody outside the LAN can TP in, but anybody inside the LAN ca= n't> sadly, while I heard that some people could. I followed all instructio= ns> on the OSWiki here : http://opensimulator.org/wiki/Network_Settings . I= > run under Windows Vista, and there's no equivalent to iptables to route> = the traffic...> > It would be really great I think if people could host the= ir regions on > their own computer without such issues.> > Is this issue an= OpenSim related issue or may I use another software in> order to route cor= rectly the packets to the region from the local viewer> ? Any help would be= greatly appreciated. I would be happy to offer such> a tool to the OpenSim= community.> > Looking forward your reactions.> > Kind regards,> > Olish Ne= wman.> > _______________________________________________> Opensim-dev maili= ng list> Opensim-dev at lists.berlios.de> https://lists.berlios.de/mailman/lis= tinfo/opensim-dev= --_db30f500-2ec5-4860-a84b-2507af6b6e54_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Olish,
 
we are doing something similar to what you are describing with
 
http://tribalnet.se/
 
- there you can download an windows application that gives you the ability = to build locally, and either publish your local pc region or upload yo= ur build on our servers.
 
The issue you're seeing is known as the 'NAT bounce' or 'NAT loopback'=  issue - your router only translates and/or forwards traffic cros= sing the LAN-WAN border, which means that if you access your computer = with the _external_ IP from _within_ the LAN, the traffic isn't 'bounced' b= ack into the LAN, but is lost.
 
Normally, you would solve this by simply address the computer with your _in= ternal_ IP from the inside (typically, you have host file settings or an in= ternal dns that serves internal ip's within the LAN)
 
now, things are getting complicated with the Second Life viewer, as the vie= wer demands regions be addressed with _IP_, not host name, so the viewer ne= ver resolves anything, so host magic won't work.
 
so, on login and teleports, when the grid tells the viewer where to st= art, it would have to serve you your _internal_ IP - but your _externa= l_ ip to the rest of the world.
 
Which gets complex.

The solution is either to configuring routing/translation manually (which i= s complex for an end-user) or to get a router that supports it out of the b= ox.
 
From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: R>
Best regards,
Stefan Andersson
Tribal Media AB
 
Join = the 3d web revolution : http://tribalnet.se/
 




> Date: Thu, 19 Jun 2008 20:16:06 +0200
> From: olish at newworldgrid= .com
> To: opensim-dev at lists.berlios.de
> Subject: [Opensim-dev= ] A software to connect its own region and TP in from locally...
> > Hello !
>
> I started to develop a software that create= s a region automatically for
> a given grid. Clicking on "Create" cre= ates automatically the region file
> as the software gets automatical= ly the local IP + public IP + domain
> name and you just have to fil= l the region name and its grid coordinates,
> then when all regions = are created and configured, the user clicks "Start
> Simulator" and t= he sim starts up after the software configured its
> firewall and for= warded its router ports correctly. So people can host
> their region = for free and at home.
>
> The aim of this software is offer pe= ople the ability to attach their own
> regions on the grid they choos= e with the minimum manipulations possible,
> and without the need to = rent a server or have another computer on the
> LAN. But there's a bu= t...
>
> I experimented this last week to TP into my locally h= osted regions
> (viewer and opensim on the same computer) on OSGrid a= nd my own grid :
> anybody outside the LAN can TP in, but anybody ins= ide the LAN can't
> sadly, while I heard that some people could. I fo= llowed all instructions
> on the OSWiki here : http://opensimulator.o= rg/wiki/Network_Settings . I
> run under Windows Vista, and there's n= o equivalent to iptables to route
> the traffic...
>
> I= t would be really great I think if people could host their regions on
&= gt; their own computer without such issues.
>
> Is this issue = an OpenSim related issue or may I use another software in
> order to = route correctly the packets to the region from the local viewer
> ? A= ny help would be greatly appreciated. I would be happy to offer such
>= ; a tool to the OpenSim community.
>
> Looking forward your re= actions.
>
> Kind regards,
>
> Olish Newman.
&= gt;
> _______________________________________________
> Opensi= m-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lis= ts.berlios.de/mailman/listinfo/opensim-dev

= --_db30f500-2ec5-4860-a84b-2507af6b6e54_-- From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: in an unobfuscated form in at least one place where the garbage collection process can read it, or it risks deletion. This would apply to scripts which used offsite storage via email/http/XML-RPC as there would be no way for the process to know the references existed. On Mon, Jun 23, 2008 at 9:36 AM, Justin Clark-Casey < jjustincc at googlemail.com> wrote: > Dahlia Trimble wrote: > > Thanks for the great explantion Melanie. > > > > There was recently a discussion in sldev about asset garbage collection > > in Linden Lab's servers. Apparently they search for references for all > > assets in inventories, scripts, prim inventories, notecards, and > > probably a few places I cant think of offhand. If an asset is found to > > be unreferenced, the process will delete it. This was discussed as some > > people were talking about obfuscating scripts to prevent copying, and a > > linden was asking them not to do this as it could fool the asset garbage > > collector into thinking an asset was unreferenced if the only reference > > was in an obfuscated script. > > From this, it sounds like it isn't valid within the Second Life system > to take asset uuids as input to a script (or obfuscate them within the > script) and expect those assets to always exist. Is this correct? > > I always vaguely thought that asset reaping wasn't possible because of > the possibility of external input of uuids. But if Linden Labs doesn't > make this guarantee, then it must also be possible for OpenSim to do > some asset reaping. This would depend on the nature of the grid in > question (e.g. it would be easier to reap assets on a grid which only > allows its own region servers to connect). > > -- > justincc > Justin Clark-Casey > http://justincc.wordpress.com > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > ------=_Part_91_26316382.1214239826722 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
From how I understood the conversation in sldev, all asset UUIDs must exist in an unobfuscated form in at least one place where the garbage collection process can read it, or it risks deletion. This would apply to scripts which used offsite storage via email/http/XML-RPC as there would be no way for the process to know the references existed.
On Mon, Jun 23, 2008 at 9:36 AM, Justin Clark-Casey <jjustincc at googlemail.com> wrote:
Dahlia Trimble wrote:
> Thanks for the great explantion Melanie.
>
> There was recently a discussion in sldev about asset garbage collection
> in Linden Lab's servers. Apparently they search for references for all
> assets in inventories, scripts, prim inventories, notecards, and
> probably a few places I cant think of offhand. If an asset is found to
> be unreferenced, the process will delete it. This was discussed as some
> people were talking about obfuscating scripts to prevent copying, and a
> linden was asking them not to do this as it could fool the asset garbage
> collector into thinking an asset was unreferenced if the only reference
> was in an obfuscated script.

 From this, it sounds like it isn't valid within the Second Life system
to take asset uuids as input to a script (or obfuscate them within the
script) and expect those assets to always exist.  Is this correct?

I always vaguely thought that asset reaping wasn't possible because of
the possibility of external input of uuids.  But if Linden Labs doesn't
make this guarantee, then it must also be possible for OpenSim to do
some asset reaping.  This would depend on the nature of the grid in
question (e.g. it would be easier to reap assets on a grid which only
allows its own region servers to connect).

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

------=_Part_91_26316382.1214239826722-- From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: ting, physics) until we reach the inter-connectedness of users, avatars, wo= rlds and content that we call the 'metaverse'. Best regards,Stefan AnderssonTribal Media AB Join the 3d web revolution : h= ttp://tribalnet.se/=20 > Date: Fri, 27 Jun 2008 12:08:54 +0100> From: melanie at t-data.com> To: open= sim-dev at lists.berlios.de> Subject: Re: [Opensim-dev] Proposal to subdivide = the assets table> > Hi,> > Dr Scofield wrote:> > Stefan Andersson wrote:> >= > a) Provided the scenario allows pushing local prims across boundaries.> >= > b) The Prim can have a 'home asset server' which is the first region.> > = exactly.> > That is where the problem starts with home hosted regions. Home= DSL > is not suitable for asset serving. With hosted systems, it would be = > absolutely beautiful, truly spreading the load, but that darn home > DSL = makes it a pain.> > Also, that would lead to issues if that server goes dow= n. So, if > that were to be adopted, it would have to be combined with > pe= rsistent caching, so the resources needed are present on the > server curre= ntly hosting the object, as well as on the creation server.> > We should tr= y to avoid allowing grey prims by design. I agree they > will happen eventu= ally, but i believe they should not be a design > feature, we should do our= utmost to prevent them.> > Melanie> Melanie> > ___________________________= ____________________> Opensim-dev mailing list> Opensim-dev at lists.berlios.d= e> https://lists.berlios.de/mailman/listinfo/opensim-dev= --_0105e7e1-9539-40b5-beea-f51b03be7437_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes, I actually think we're (kind of) in total ag= reement. When I say 'base case' I don't mean 'the only thing the core shoul= d do', merely that I think of the application scenarios as being in differe= nt 'rings' where each ring contains various constellations of services.
=
We have gone in on something akin to the SL 'ring', and slowly, we are work= ing our ways outwards to something like a 'metaverse', but the metavarse wo= n't consist of one homogenous architecture.
 
Again, look at the web. The loose coupling that gives us 404's is also the = loose coupling that give us mash-ups.
 
The base scenario for me, something I think would be very useful from a bus= iness perspective, is the standalone prim serving content to anonymous avat= ars. It's like a campaign web page.
 
From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: ting, physics) until we reach the inter-connectedness of users, avatars, wo= rlds and content that we call the 'metaverse'.

Best regards,
Stefan Andersson
Tribal Media AB
 
Join = the 3d web revolution : http://tribalnet.se/
 




> Date: Fri, 27 Jun 2008 12:08:54 +0100
> From: melanie at t-data.com=
> To: opensim-dev at lists.berlios.de
> Subject: Re: [Opensim-dev= ] Proposal to subdivide the assets table
>
> Hi,
>
&= gt; Dr Scofield wrote:
> > Stefan Andersson wrote:
> >>= ; a) Provided the scenario allows pushing local prims across boundaries.> >> b) The Prim can have a 'home asset server' which is the firs= t region.
> > exactly.
>
> That is where the problem = starts with home hosted regions. Home DSL
> is not suitable for asse= t serving. With hosted systems, it would be
> absolutely beautiful, = truly spreading the load, but that darn home
> DSL makes it a pain.<= BR>>
> Also, that would lead to issues if that server goes down. = So, if
> that were to be adopted, it would have to be combined with =
> persistent caching, so the resources needed are present on the > server currently hosting the object, as well as on the creation serve= r.
>
> We should try to avoid allowing grey prims by design. I= agree they
> will happen eventually, but i believe they should not = be a design
> feature, we should do our utmost to prevent them.
&= gt;
> Melanie
> Melanie
>
> _____________________= __________________________
> Opensim-dev mailing list
> Opensim= -dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/ope= nsim-dev

= --_0105e7e1-9539-40b5-beea-f51b03be7437_-- From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: Charles ----- Original Message ---- From: krtaylor To: opensim-dev at lists.berlios.de Sent: Monday, June 30, 2008 1:41:10 PM Subject: [Opensim-dev] LSL test suite ideas I have been putting together a few ideas on how to include more tests for LSL. I am thinking of putting together a set of scripts that would systematically test all the script functionality that is currently implemented. I would start slow with a few functions and grow over time, hopefully with others contributions as well. I was thinking I would divide the functionality up into logical groups so that it wouldn't be too huge and would allow a developer to beat on a specific area if desired. I know we have used the Kan-Ed scripts in the past but as far as I can tell, the Kan-Ed scripts are no more - the Kansas Board of Regents closed down the URL for some reason. We could probably piece together most of it, but that is not really what I had in mind. The Kan-Ed scripts were good for showing a large set worked in world, but I am thinking more systematic coverage and reporting. The Kan-Ed scripts still required interpretation by someone in world as to whether they were working properly or not. I have had some irc discussions and I think the best approach for now is to have a set of scripts that are checked in and exist in inventory that can be run in world and would report the success or failure of the functions tested. Maybe this report could be pushed out to a webpage for on-line status of the current state of the LSL. This would be a supplemental help to me as I have been manually testing and updating the function list and status for several months now. Additionally, it would be nice for putting a load on the script engine for scalability and performance testing. There are a few helper os functions that may need to be implemented, but the core of what would be tested would be done via LSL. Comments? -- Kurt R Taylor (Kurt Stringer) Open Virtual Worlds Development http://opensimulator.org http://opensim.ibm.com International Business Machines, Corp. (512) 838-2496 T/L: 678 _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev --0-857153825-1214861126=:76701 Content-Type: text/html; charset=us-ascii
Dear Kr:

I think that is a capital idea. I see that we have some scripts in our library. If we had scripts similar to the notion that kan-ed originally used, that is about 10 scripts covering the range from very simple to complex, then we have a series of scripts we can use for testing.

From time to time, we can then encourage others to add to the test script library as we have additional functionality. The important thing is, I believe, that having such a standard set of scripts again allows is to guide our users to a common level of functionality.

Charles

----- Original Message ----
From: krtaylor <krtaylor at linux.vnet.ibm.com>
To: opensim-dev at lists.berlios.de
Sent: Monday, June 30, 2008 1:41:10 PM
Subject: [Opensim-dev] LSL test suite ideas


I have been putting together a few ideas on how to include more tests
for LSL. I am thinking of putting together a set of scripts that would
systematically test all the script functionality that is currently
implemented. I would start slow with a few functions and grow over time,
hopefully with others contributions as well. I was thinking I would
divide the functionality up into logical groups so that it wouldn't be
too huge and would allow a developer to beat on a specific area if desired.

I know we have used the Kan-Ed scripts in the past but as far as I can
tell, the Kan-Ed scripts are no more - the Kansas Board of Regents
closed down the URL for some reason. We could probably piece together
most of it, but that is not really what I had in mind. The Kan-Ed
scripts were good for showing a large set worked in world, but I am
thinking more systematic coverage and reporting. The Kan-Ed scripts
still required interpretation by someone in world as to whether they
were working properly or not.

I have had some irc discussions and I think the best approach for now is
to have a set of scripts that are checked in and exist in inventory that
can be run in world and would report the success or failure of the
functions tested. Maybe this report could be pushed out to a webpage for
on-line status of the current state of the LSL. This would be a
supplemental  help to me as I  have been manually testing and updating
the function list and status for several months now.  Additionally, it
would be nice for putting a load on the script engine for scalability
and performance testing. There are a few helper os functions that may
need to be implemented, but the core of what would be tested would be
done via LSL.

Comments?

--
Kurt R Taylor (Kurt Stringer)

Open Virtual Worlds Development
http://opensimulator.org  http://opensim.ibm.com
International Business Machines, Corp.
(512) 838-2496    T/L:  678


_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
--0-857153825-1214861126=:76701-- From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: seriously evaluate whether it is worth it. Creating new Packet classes is something that can be solved in managed code with an object pool that is aware of packet types. libomv had a huge success by using an object pool for incoming udp buffers and zero(en/de)coding buffers. The Packet class has already been re-factored in such a way that would allow object reuse. This is from my own personal testing, and more data on the topic would be greatly appreciated. Do you think it will be possible to empirically compare performance of funsl vs. the libomv wrapper? John -----Original Message----- From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Mike Mazur Sent: Thursday, August 14, 2008 2:39 PM To: opensim-dev at lists.berlios.de Subject: [Opensim-dev] Upcoming work on alternative client stack Hello, (Could it be? Are the mailing lists working again? I wanted to send this message last weekend.) Some of you may already know, I've started working on an alternative client stack. This alternative stack does not use libomv's Packet class to move packets around. The buffers which are written to by socket functions are passed around instead, with functions available for extracting or writing data to the buffers. These functions are provided by a package currently codenamed "funsl". Johan has written a compiler[1] which generates C# and C/C++ code from LL's message_template.msg file[2]. We're doing this because we believe the creation of a Packet object for each transferred packet impacts performance, particularly when GC events occur. As I'm working on this I found that libomv's Packet class is used outside the client stack, namely in OpenSim/Framework/ClientManager.cs and OpenSim/Framework/IClientAPI.cs (among other places). Since our client stack needs to implement these interfaces too, and needs to call ClientManager methods, those libomv Packet references get in the way. I would like to factor them out. Please allow me to give you an example, inspired by changeset r5785. ClientManager had a method, InPacket(), defined as below: public void InPacket(uint circuitCode, Packet packet) { IClientAPI client; bool tryGetRet =3D false; lock (m_clients) tryGetRet =3D m_clients.TryGetValue(circuitCode, out client); if (tryGetRet) { client.InPacket(packet); } } This method receives a circuit code and passes the packet to the IClientAPI instance associated with said circuit code. Why should the ClientManager have knowledge of Packet? It's not in the client stack, it only provides access to the clients. Therefore I changed the method as follows: public void InPacket(uint circuitCode, object packet) { IClientAPI client; bool tryGetRet =3D false; lock (m_clients) tryGetRet =3D m_clients.TryGetValue(circuitCode, out client); if (tryGetRet) { client.InPacket(packet); } } Instead of expecting a Packet object for the second argument, we expect any object. Naturally the signature of the InPacket() method in the IClientAPI interface has also changed. The cast from object to Packet (or byte[] in my case) is done in the class which implements IClientAPI, namely OpenSim/Region/ClientStack/LindenUDP/LLClientView.cs, where InPacket() has been changed as follows: - public virtual void InPacket(Packet NewPack) + public virtual void InPacket(object NewPack) { - m_PacketHandler.InPacket(NewPack); + // Cast NewPack to Packet. + m_PacketHandler.InPacket((Packet) NewPack); } InPacket() is the first method that has been changed so far, but others will need to follow (OutPacket(), SendSimStats(), ProcessInPacket(), etc). Please rest assured these changes don't break existing functionality, just factoring out some libomv Packet references which currently live outside the client stack. Any thoughts or concerns? Thank you, Mike [1] If you are interested in the source for the compiler, written in LISP, just ask ;) [2] http://svn.secondlife.com/trac/linden/browser/release/scripts/messages _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: seriously evaluate whether it is worth it. Creating new Packet classes
is something that can be solved in managed code with an object pool that
is aware of packet types. libomv had a huge success by using an object
pool for incoming udp buffers and zero(en/de)coding buffers. The Packet
class has already been re-factored in such a way that would allow object
reuse.

This is from my own personal testing, and more data on the topic would
be greatly appreciated. Do you think it will be possible to empirically
compare performance of funsl vs. the libomv wrapper?

John


-----Original Message-----
From: opensim-dev-bounces at lists.berlios.de
[mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Mike Mazur
Sent: Thursday, August 14, 2008 2:39 PM
To: opensim-dev at lists.berlios.de
Subject: [Opensim-dev] Upcoming work on alternative client stack

Hello,

(Could it be? Are the mailing lists working again? I wanted to send
this message last weekend.)

Some of you may already know, I've started working on an alternative
client stack. This alternative stack does not use libomv's Packet
class to move packets around. The buffers which are written to by
socket functions are passed around instead, with functions available
for extracting or writing data to the buffers.

These functions are provided by a package currently codenamed "funsl".
Johan has written a compiler[1] which generates C# and C/C++ code from
LL's message_template.msg file[2].

We're doing this because we believe the creation of a Packet object
for each transferred packet impacts performance, particularly when GC
events occur.

As I'm working on this I found that libomv's Packet class is used
outside the client stack, namely in OpenSim/Framework/ClientManager.cs
and OpenSim/Framework/IClientAPI.cs (among other places). Since our
client stack needs to implement these interfaces too, and needs to
call ClientManager methods, those libomv Packet references get in the
way. I would like to factor them out.

Please allow me to give you an example, inspired by changeset r5785.
ClientManager had a method, InPacket(), defined as below:

    public void InPacket(uint circuitCode, Packet packet)
    {
        IClientAPI client;
        bool tryGetRet = false;
        lock (m_clients)
            tryGetRet = m_clients.TryGetValue(circuitCode, out
client); if (tryGetRet)
        {
            client.InPacket(packet);
        }
    }

This method receives a circuit code and passes the packet to the
IClientAPI instance associated with said circuit code.

Why should the ClientManager have knowledge of Packet? It's not in the
client stack, it only provides access to the clients. Therefore I
changed the method as follows:

    public void InPacket(uint circuitCode, object packet)
    {
        IClientAPI client;
        bool tryGetRet = false;
        lock (m_clients)
            tryGetRet = m_clients.TryGetValue(circuitCode, out
client); if (tryGetRet)
        {
            client.InPacket(packet);
        }
    }

Instead of expecting a Packet object for the second argument, we
expect any object. Naturally the signature of the InPacket() method in
the IClientAPI interface has also changed. The cast from object to
Packet (or byte[] in my case) is done in the class which implements
IClientAPI, namely
OpenSim/Region/ClientStack/LindenUDP/LLClientView.cs, where InPacket()
has been changed as follows:

-        public virtual void InPacket(Packet NewPack)
+        public virtual void InPacket(object NewPack)
    {
-            m_PacketHandler.InPacket(NewPack);
+            // Cast NewPack to Packet.
+            m_PacketHandler.InPacket((Packet) NewPack);
    }

InPacket() is the first method that has been changed so far, but
others will need to follow (OutPacket(), SendSimStats(),
ProcessInPacket(), etc).

Please rest assured these changes don't break existing functionality,
just factoring out some libomv Packet references which currently live
outside the client stack.

Any thoughts or concerns?

Thank you,
Mike


[1] If you are interested in the source for the compiler, written in
LISP, just ask ;)
[2]
http://svn.secondlife.com/trac/linden/browser/release/scripts/messages
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

------=_Part_202769_7029875.1219103441814-- From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: We'll have to exchange some ideas.
It's too bad that the client is so attached to the one-mamma model. We need to constantly trick it on the server side.

--------------030102050901010402010203-- From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: We'll have to exchange some ideas. It's too bad that the client is so attached to the one-mamma model. We need to constantly trick it on the server side. --0-134747981-1225388983=:37208 Content-Type: text/html; charset=us-ascii

Dear Crista:

I have no problem supporting and committing patches to core from your efforts. Please move forward as you see appropriate.

Charles


----- Original Message ----
From: Cristina Videira Lopes <lopes at ics.uci.edu>
To: opensim-dev at lists.berlios.de
Sent: Thursday, October 30, 2008 9:19:28 AM
Subject: Re: [Opensim-dev] OSGrid <-> UCIGrid

Mircea Filipescu wrote:
Me too. I would be curious to ask two questions now, one of them related to that. First question is, how do you set that up on your own opensim so far? Is the inter-grid teleporting system in the core yet or just an experimental separate application? Will there be a way from opensim.ini to do that experimentally soon?
It's not in the core. It would be great if it makes it there :-) It will be really easy to merge.
Since the architecture of OpenSim is so good (I've said this many times before!), the extension I made is really modular and simple. The only weirdness is having to subclass OpenSim.cs, so that I can instantiate the hypergrid comms instead of the default comms.

My second question is something on longer term related to the technical part; I'm curious what will be done with the assets in this situation and with fetching them, and here I mean how one can sit on one grid and use assets and inventory from both that grid and another one. There are two problems here; First of them (smallest one) is the possibility of UUID conflicts. Lets say for example that someone uploads a texture on OSGrid and uses it in their inventory. Now they cross-grid TP to the LL grid, and in order for stuff to work correctly both the OSGrid asset server and LL grid asset server must be used. However, if the UUID of that texture he just uploaded on OSGrid is the same as the UUID of another texture / asset already on the LL grid, there will be a UUID conflict.
For this issue, I'm relying on probabilities & statistics! I hope the math delivers :-)
But I confess I feel a bit nervous about this too. I would feel a lot more comfortable if UUIDs would be suffixed with a domain name, or if they encoded domain names, so that ambiguity would be impossible, not just improbable.

Second problem as the devs have been discussing is that the SL client can only support one asset server at a time. So if you go into another grid like that normally you must have both the assets of the grid you come from and the ones of the grid you go to at the same time. So yeah I was curious if anything is intended or known about these problems so far... one way or another I guess they will be gotten through so yeah.
From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: We'll have to exchange some ideas.
It's too bad that the client is so attached to the one-mamma model. We need to constantly trick it on the server side.

--0-134747981-1225388983=:37208-- From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: ve concluded that we have a process that doesn't allow for rapid change unl= ess it's either =20 a) really easy=2C and shows immediate value for the percieved audience or b) has been labouriously discussed and dismissed=2C taken up again=2C re-ev= aluated=2C and then been dismissed again=2C just to be suddenly accepted be= cause some technology had matured enough=2C threshold reputation has been e= arned or a good tool was found. What I'm saying is that from what I can see our mindset is 'refactoring' ra= ther than 'rewriting'. Babysteps rather than big restructuring. Always thin= ing of the job that should be done in the light of the job that has been do= ne so far. =20 Good and Bad=2C it has worked well so far. Best regards=2CStefan AnderssonT= ribal Media AB Join the 3d web revolution : http://tribalnet.se/=20 Date: Sun=2C 7 Dec 2008 06:41:07 -0600From: james.stallings at gmail.comTo: op= ensim-dev at lists.berlios.deSubject: Re: [Opensim-dev] future rexviewer merge= rCommunication is a good thing Toni=2C and you have done a fair enough job = of it here.Clearly there are some cultural (think national=2C not corporate= ) differences here. You have laid out in bold relief many of the reasons be= hind the things that have frustrated me about the rexx project.One thing I = am always harping on with my employer is the notion of managing expectation= s. Typically I am talking in a sales context=2C but I'll say it here: manag= ement of expectations is everything! and of course=2C communication is key = to effective management of expectations.IMNSHO=2C this is the 'big fail' on= rexx's part - they were oft invited to drop in and discuss things on IRC o= r participate in the mailing lists. I dont think anyone really expected the= m to be there chatting in IRC everytime=2C but they could have been followi= ng and commenting on key work there and in the lists as well=2C and comment= ing about things that may have impacted their work=2C whether in a positive= or negative way. While it may seem we burn a lot of time in IRC goofing of= f=2C this is generally users or opensim devs that are finished with dev for= a time socializing. Nothing wrong with that=2C we are a community=2C and c= ommunities interact at many levels. No particular commitment to such trivia= lities is needful from the genuinely busy - opensim devs are all business w= hen working hard=2C and dont involve themselves very deeply in the lighter = side of the community (if at all) at such times. As a result of this mode o= f working=2C oportunities to avoid duplicated effort were missed=2C and dir= ections were taken that are not consonant with the general direction of the= broader community=2C leaving as much work to get re-integrated post-fork= =2C as it were=2C as perhaps was done to demonstrate a proof of concept in = the first place. Additionally=2C such communications as we did have were ty= pically in response to complaints about the cross platform issues=2C and we= were continually reassured the commitment was there=2C in spite of over a = year of work and still not a single line of rexx code that will run on any = of the alternate platforms. It simply appears as a result of this that ther= e is anything but a commitment to our cross-platform ideals. Worse=2C it se= ems to suggest that rexx's commitments are not to be trusted.Now=2C as I am= an equal opportunity offender=2C it is time for me to level my critical ey= e on the opensim team too. You see=2C they have contributed to this mess in= a subtle way=2C through a slavish adherence to an old toolchain: SVN *simp= ly does not do as good a job of supporting collaboration as modern tools li= ke Hg and GIT*. Hg is probably to be preferred over GIT as I believe Hg wor= ks cross-platform - but the key point is=2C these more modern repository ma= nagement toolchains would have offered rexx the flexibility to both do 'cle= an room' work outside and parallel to the broader community=2C and facilita= ted a much smoother integration of their clean-room work post-fork. Indeed= =2C these tools facillitate this asynch workflow so thoroughly that the ter= m 'fork' really loses most of it's meaning.Enough of hindsight. Time to mov= e forward=2C with lessons learned. Ryan seems very commited personally to c= orrecting such of these misteps as are perhaps of chief concern=3B I dont w= ant to be offensive and suggest he isnt sincere=2C because at this juncture= that is all I would be doing is offending=2C and that is honestly not my g= oal.It is clear from the 38 messages plus in this and related side threads = that rexx is getting the message about communication - and I will say it ag= ain just to reenforce the notion: to be a part of the community=2C one must= communicate with one's peers.I *wish* I could say that OpenSim's core dev = team is getting the message about the toolchains - this is something that h= obbles many innovators. Some have quietly adopted these newer toolchains fo= r themselves=2C but much of the benefits of this are lost because core stil= l sits in an SVN repo (yes=2C I am aware that Hg and GIT can work with SVN = repos=2C but to do things this way rather dilutes their strengths).Oh well= =2C one thing about us human beings is=2C we learn=2C grow=2C adapt. I dont= think anyone in this community of ours is less than intelligent (or less t= han human for that matter =3B) and I hold out hope that the OpenSim team wi= ll see how remaining bound to SVN is holding us back. Coming to this point in this discussion I am hopefull and optimistic that g= ood things are going to come out of this=2C in spite of the pain. C'mon=2C = Ryan=2C I cant *wait* another year to see this stuff =3B)CheersJamesOn Sun= =2C Dec 7=2C 2008 at 2:03 AM=2C Melanie wrote: Hello=2C Toni Alatalo wrote:> yep like i mentioned in the previous post they are ort= hogonal and> should be separate. was thinking of that earlier this week but= didn't> have time to bring up with the Rex people yet.That sounds good.Mel= anie _______________________________________________Opensim-dev mailing listOpen= sim-dev at lists.berlios.dehttps://lists.berlios.de/mailman/listinfo/opensim-d= ev-- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DThe windscours the earth for prayersThe= night obscures themhttp://osgrid.orghttp://del.icio.us/SPQRhttp://twitter.= com/jstallings2http://www.linkedin.com/pub/5/770/a49= --_3501f0de-0900-4628-9a60-f857ce1b7deb_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: ve concluded that we have a process =3Bthat doesn't =3Ballow for ra= pid change unless =3Bit's either
 =3B
a) really easy=2C and shows immediate value for the percieved audience
or
b) has been labouriously discussed and dismissed=2C taken up again=2C re-ev= aluated=2C and then been dismissed again=2C just to be suddenly accepted be= cause some technology had matured enough=2C threshold reputation has been e= arned =3Bor a good tool was found.

What I'm saying is that =3Bfrom what I can see our mindset is 'refactor= ing' rather than 'rewriting'. Babysteps rather than big restructuring. Alwa= ys thining of the job that should be done in the light of the job that has = been done so far.
 =3B
Good and Bad=2C it has worked well so far.
 =3B
Best regards=2CStefan Andersson
Tribal Media AB
 =3B
Join the =3B3d web= revolution : http://tribalnet.se/
=  =3B






Date: Sun=2C 7 Dec 2008 06:41:07 -0600
From: james.stallings at gmail.comTo: opensim-dev at lists.berlios.de
Subject: Re: [Opensim-dev] future rex= viewer merger

Communication is a good thing Toni=2C and you have don= e a fair enough job of it here.

Clearly there are some cultural (thi= nk national=2C not corporate) differences here. You have laid out in bold r= elief many of the reasons behind the things that have frustrated me about t= he rexx project.

One thing I am always harping on with my employer i= s the notion of managing expectations. Typically I am talking in a sales co= ntext=2C but I'll say it here: management of expectations is everything! an= d of course=2C communication is key to effective management of expectations= .

IMNSHO=2C this is the 'big fail' on rexx's part - they were oft in= vited to drop in and discuss things on IRC or participate in the mailing li= sts. I dont think anyone really expected them to be there chatting in IRC e= verytime=2C but they could have been following and commenting on key work t= here and in the lists as well=2C and commenting about things that may have = impacted their work=2C whether in a positive or negative way. While it may = seem we burn a lot of time in IRC goofing off=2C this is generally users or= opensim devs that are finished with dev for a time socializing. Nothing wr= ong with that=2C we are a community=2C and communities interact at many lev= els. No particular commitment to such trivialities is needful from the genu= inely busy - opensim devs are all business when working hard=2C and dont in= volve themselves very deeply in the lighter side of the community (if at al= l) at such times. As a result of this mode of working=2C oportunities to av= oid duplicated effort were missed=2C and directions were taken that are not= consonant with the general direction of the broader community=2C leaving a= s much work to get re-integrated post-fork=2C as it were=2C as perhaps was = done to demonstrate a proof of concept in the first place. Additionally=2C = such communications as we did have were typically in response to complaints= about the cross platform issues=2C and we were continually reassured the c= ommitment was there=2C in spite of over a year of work and still not a sing= le line of rexx code that will run on any of the alternate platforms. It si= mply appears as a result of this that there is anything but a commitment to= our cross-platform ideals. Worse=2C it seems to suggest that rexx's commit= ments are not to be trusted.

Now=2C as I am an equal opportunity off= ender=2C it is time for me to level my critical eye on the opensim team too= . You see=2C they have contributed to this mess in a subtle way=2C through = a slavish adherence to an old toolchain: SVN *simply does not do as good a = job of supporting collaboration as modern tools like Hg and GIT*. Hg is pro= bably to be preferred over GIT as I believe Hg works cross-platform - but t= he key point is=2C these more modern repository management toolchains would= have offered rexx the flexibility to both do 'clean room' work outside and= parallel to the broader community=2C and facilitated a much smoother integ= ration of their clean-room work post-fork. Indeed=2C these tools facillitat= e this asynch workflow so thoroughly that the term 'fork' really loses most= of it's meaning.

Enough of hindsight. Time to move forward=2C with = lessons learned. Ryan seems very commited personally to correcting such of = these misteps as are perhaps of chief concern=3B I dont want to be offensiv= e and suggest he isnt sincere=2C because at this juncture that is all I wou= ld be doing is offending=2C and that is honestly not my goal.

It is = clear from the 38 messages plus in this and related side threads that rexx = is getting the message about communication - and I will say it again just t= o reenforce the notion: to be a part of the community=2C one must communica= te with one's peers.

I *wish* I could say that OpenSim's core dev te= am is getting the message about the toolchains - this is something that hob= bles many innovators. Some have quietly adopted these newer toolchains for = themselves=2C but much of the benefits of this are lost because core still = sits in an SVN repo (yes=2C I am aware that Hg and GIT can work with SVN re= pos=2C but to do things this way rather dilutes their strengths).

Oh= well=2C one thing about us human beings is=2C we learn=2C grow=2C adapt. I= dont think anyone in this community of ours is less than intelligent (or l= ess than human for that matter =3B) and I hold out hope that the OpenSim te= am will see how remaining bound to SVN is holding us back.


Coming to this point in this discussion I a= m hopefull and optimistic that good things are going to come out of this=2C= in spite of the pain. C'mon=2C Ryan=2C I cant *wait* another year to see t= his stuff =3B)

Cheers
James




On Sun=2C Dec 7=2C= 2008 at 2:03 AM=2C Melanie <=3Bmelanie at t-data.com>=3B wrote:
Hello=2C

Toni Alatalo wrote:
>=3B yep like i mention= ed in the previous post they are orthogonal and
>=3B should be separat= e. was thinking of that earlier this week but didn't
>=3B have time to= bring up with the Rex people yet.

That sounds good.

Melanie
_______________________________________________
O= pensim-dev mailing list
= Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensi= m-dev



--
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The wind
scours the earth for prayers<= BR>The night obscures them

http://osg= rid.org
http://del.icio.us/SPQR<= /A>
http://twitter.com/jstall= ings2
http://www.l= inkedin.com/pub/5/770/a49
= --_3501f0de-0900-4628-9a60-f857ce1b7deb_-- From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: you will have an 'isolated' software team working on your viewer and none of this team will be contributing code to Opensim. I also assume that any contributors to your viewer will not be able to contribute to Opensim. If this is the case then they will also not be able to contribute to the Idealist viewer as the people working on this are opensim contributors. Please feel free to correct me if I am wrong. The beauty (for me anyway) of the IdealistViewer is that it is possible to be involved in contributing patches to both Opensim and IdealistViewer. I think that it is important to clarify this issue to prevent problems in the future. Chris Down From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: packets (and possibly some others=2C like IM?) where the viewer can only ac= cept IP. That is why it is implicitly resolved in some places. (Or rather= =2C that's the rationale for why those places need it) =20 The remoting issue=2C I don't know what that actually means=2C but remoting= should be resolved thru hostname as well. =20 It pains me to admit that I'm probably the source of all this confusion=2C = as I=2C way back then=2C did the DNS resolve as a quick fix to fix some net= working issues - but at that time I was not aware of the DnsEndPoint class. =20 So=2C really=2C the endpoint info should be stored in _DnsEndPoint_ not _IP= Endpoint_ all thru core. =20 and =20 Unless anybody knows of a reason not to=2C I suggest moving any IP resolvin= g into the LL client stack=2C as close to the actual needed conversion as p= ossible=2C and let core use hostnames=2C via DnsEndPoint=2C all over. Best regards=2CStefan AnderssonTribal Media AB Join the 3d web revolution := http://tribalnet.se/=20 Date: Thu=2C 11 Dec 2008 17:38:04 -0800From: lopes at ics.uci.eduTo: opensim-d= ev at lists.berlios.deSubject: Re: [Opensim-dev] external host nameThe thing i= s that this can potentially create a RegionInfo data structure with = nRegionInfo.ExternalHostName =3D regionData.IPADDR=3BThis is inconsiste= nt with certain queries on the Grid server=2C like "give me all my neighbor= s" which may send host names.So=2C back to the point: someone needs to deci= de what is it that RegionInfo.ExternalHostName is supposed to hold.Teravus= Ovares wrote:=20 RegionUpData is my fault=2C and spawned from compatibility issues with .NET remoting and Mono remoting with complex types. It is only used to notify a neighbor region that 'this region is up' Best Regards Teravus On 12/11/08=2C Cristina Videira Lopes wrote: =20 Things are very messy right now. You can search for "sim_ip"=2C for example= =2C which is used in chatting with the grid server=2C and where it is being converted to an IP address in about half of the cases. To compensate=2C and before I noticed this inconsistency=2C Homer introduce= d another field called "sim_host"=2C so not to mess with what was already the= re=2C that is supposed to carry the external host name=2C but this only works up = to the point in which RegionInfo data structures are created. At that point=2C= we need to decide what to place in m_externalHostName=2C sim_ip or sim_host. Which means changes in OGS1. I also noticed that there is yet another data structure called RegionUpData that uses IP addresses. So=2C messy. Someone should decide what this field is supposed to be=2C and= make it a rule. Charles Krinke wrote: Dear Diva: You have a very good point and I would support harmonizing to one notion even at the expense of breaking some things for a while. In fact=2C if someone can identify what some of those things are=2C or come= up with a couple of search strings or grep expressions=2C I would like to look= at the anomalies myself. +1 on external_host_name Charles ________________________________ From: Cristina Videira Lopes To: opensim-dev at lists.berlios.de Sent: Thursday=2C December 11=2C 2008 2:42:05 PM Subject: [Opensim-dev] external host name It turns out that a lot of problems with CAPs have to do with inconsistencies surrounding the URL of the seed cap. Specifically=2C in some cases we're producing URLs with hostnames=2C other times we're producing URLs with IP addresses=2C for example: http://ucigrid03.nacs.uci.edu:9000/CAPS/4cfc94fa-09be-409b-b136-cda2cdde000= 0/ vs. MailScanner has detected a possible fraud attempt from "128.200.71.43:9000" claiming to be MailScanner warning: numerical links are often malicious: MailScanner warning: numerical links are often malicious: http://128.200.71= .43:9000/CAPS/4cfc94fa-09be-409b-b136-cda2cdde0000/ The client is not smart enough to test if this is the same host=2C it assumes it isn't=2C so it decides someone's trying to game it. The inconsistencies are all over the code in OpenSim=2C and they pertain to the use of ExternalHostName in several data s! tructures. In some cases=2C an explicit conversion to IP addresses is made. We should converge to one single thing. And I believe that thing should be whatever it is given in external_host_name config. Is this right? However=2C I am a bit afraid this is going to break 17 different things... Crista _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ________________________________ _______________________________________________ Opensim-dev =20 mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev =20 _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev = --_c138cece-0090-4e59-bc4e-3ff653ac7430_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: leport =3Bpackets (and possibly some others=2C like IM?) =3Bwhere t= he viewer can only accept IP. That is why it is implicitly resolved in some= places. (Or rather=2C that's the rationale for why those places need it)  =3B
The remoting issue=2C I don't know what that actually means=2C but remoting= should be resolved thru hostname as well.
 =3B
It pains me to admit that I'm probably the source of all this confusion=2C = as I=2C way back then=2C did the DNS resolve as a quick fix to fix some net= working issues - but at that time I was not aware of the DnsEndPoint class.=
 =3B
So=2C really=2C the endpoint info should be =3Bstored in =3B_DnsEnd= Point_ not _IPEndpoint_ all thru core.
 =3B
and
 =3B
Unless anybody knows of a reason not to=2C I suggest moving any =3BIP r= esolving into the =3BLL client stack=2C as close to the actual needed c= onversion as possible=2C and let core =3Buse hostnames=2C via DnsEndPoi= nt=2C =3Ball over.

Best regards=2C
Stefan Andersson
Tribal Media AB
 =3B
J= oin the =3B3d web revolution : http://= tribalnet.se/
 =3B






Date: Thu=2C 11 Dec 2008 17:38:04 -0800
From: lopes at ics.uci.edu
To: o= pensim-dev at lists.berlios.de
Subject: Re: [Opensim-dev] external host nam= e

The thing is that this can potentially create a RegionInfo data st= ructure with
 =3B =3B =3B =3B =3B =3B =3B&n= bsp=3B =3B =3B nRegionInfo.ExternalHostName =3D regionData.IPADDR= =3B

This is inconsistent with certain queries on the Grid server=2C = like "give me all my neighbors" which may send host names.

So=2C bac= k to the point: someone needs to decide what is it that RegionInfo.External= HostName =3B is supposed to hold.

Teravus Ovares wrote: 
RegionUpData is my fault=2C and spawned from compatibility iss=
ues with
.NET remoting and Mono remoting with complex types.  It is only used
to notify a neighbor region that 'this region is up'

Best Regards

Teravus

On 12/11/08=2C Cristina Videira Lopes <=3Blopes at ics.uci.edu>=3B wrote:
  
Things are very messy right now. You can search for "sim_i=
p"=2C for example=2C
which is used in chatting with the grid server=2C and where it is being
converted to an IP address in about half of the cases.

To compensate=2C and before I noticed this inconsistency=2C Homer introduce=
d
another field called "sim_host"=2C so not to mess with what was already the=
re=2C
that is supposed to carry the external host name=2C but this only works up =
to
the point in which RegionInfo data structures are created. At that point=2C=
 we
need to decide what to place in m_externalHostName=2C sim_ip or sim_host.
Which means changes in OGS1.

I also noticed that there is yet another data structure called RegionUpData
that uses IP addresses.

So=2C messy. Someone should decide what this field is supposed to be=2C and=
 make
it a rule.

Charles Krinke wrote:

Dear Diva:

You have a very good point and I would support harmonizing to one notion
even at the expense of breaking some things for a while.

In fact=2C if someone can identify what some of those things are=2C or come=
 up
with a couple of search strings or grep expressions=2C I would like to look=
 at
the anomalies myself.

+1 on external_host_name

Charles

________________________________


From: Cristina Videira Lopes <=3Blopes at ics.uci.edu>=3B
To: opensim-dev at lists.berlios.de
Sent: Thursday=2C December 11=2C 2008 2:42:05 PM
Subject: [Opensim-dev] external host name

It turns out that a lot of problems with CAPs have to do with
inconsistencies surrounding the URL of the seed cap. Specifically=2C in
some cases we're producing URLs with hostnames=2C other times we're
producing URLs with IP addresses=2C for example:

http://ucigrid03.nacs.uci.e=
du:9000/CAPS/4cfc94fa-09be-409b-b136-cda2cdde0000/
vs.
MailScanner has detected a possible fraud attempt from "128.200.71.43:9000"
claiming to be MailScanner warning: numerical links are often malicious:
MailScanner war=
ning: numerical links are often malicious: http://128.200.71.43:=
9000/CAPS/4cfc94fa-09be-409b-b136-cda2cdde0000/

The client is not smart enough to test if this is the same host=2C it
assumes it isn't=2C so it decides someone's trying to game it.

The inconsistencies are all over the code in OpenSim=2C and they pertain
to the use of ExternalHostName in several data s! tructures. In some
cases=2C an explicit conversion to IP addresses is made.

We should converge to one single thing. And I believe that thing should
be whatever it is given in external_host_name config. Is this right?
However=2C I am a bit afraid this is going to break 17 different things...

Crista

_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-d=
ev
________________________________

    
_______________________________________________
Opensim-dev
  
mailing
list
    
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-d=
ev
  
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-d=
ev


    
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-d=
ev

= --_c138cece-0090-4e59-bc4e-3ff653ac7430_-- From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: packets (and possibly some others=2C like IM?) where the viewer can only ac= cept IP. That is why it is implicitly resolved in some places. (Or rather= =2C that's the rationale for why those places need it) The remoting issue= =2C I don't know what that actually means=2C but remoting should be resolve= d thru hostname as well. It pains me to admit that I'm probably the source = of all this confusion=2C as I=2C way back then=2C did the DNS resolve as a = quick fix to fix some networking issues - but at that time I was not aware = of the DnsEndPoint class. So=2C really=2C the endpoint info should be store= d in _DnsEndPoint_ not _IPEndpoint_ all thru core. and Unless anybody knows= of a reason not to=2C I suggest moving any IP resolving into the LL client= stack=2C as close to the actual needed conversion as possible=2C and let c= ore use hostnames=2C via DnsEndPoint=2C all over.Best regards=2CStefan Ande= rssonTribal Media AB Join the 3d web revolution : http://tribalnet.se/=20 Date: Thu=2C 11 Dec 2008 17:38:04 -0800From: lopes at ics.uci.eduTo: opensim-d= ev at lists.berlios.deSubject: Re: [Opensim-dev] external host nameThe thing i= s that this can potentially create a RegionInfo data structure with = nRegionInfo.ExternalHostName =3D regionData.IPADDR=3BThis is inconsiste= nt with certain queries on the Grid server=2C like "give me all my neighbor= s" which may send host names.So=2C back to the point: someone needs to deci= de what is it that RegionInfo.ExternalHostName is supposed to hold.Teravus= Ovares wrote:=20 RegionUpData is my fault=2C and spawned from compatibility issues with .NET remoting and Mono remoting with complex types. It is only used to notify a neighbor region that 'this region is up' Best Regards Teravus On 12/11/08=2C Cristina Videira Lopes wrote: =20 Things are very messy right now. You can search for "sim_ip"=2C for example= =2C which is used in chatting with the grid server=2C and where it is being converted to an IP address in about half of the cases. To compensate=2C and before I noticed this inconsistency=2C Homer introduce= d another field called "sim_host"=2C so not to mess with what was already the= re=2C that is supposed to carry the external host name=2C but this only works up = to the point in which RegionInfo data structures are created. At that point=2C= we need to decide what to place in m_externalHostName=2C sim_ip or sim_host. Which means changes in OGS1. I also noticed that there is yet another data structure called RegionUpData that uses IP addresses. So=2C messy. Someone should decide what this field is supposed to be=2C and= make it a rule. Charles Krinke wrote: Dear Diva: You have a very good point and I would support harmonizing to one notion even at the expense of breaking some things for a while. In fact=2C if someone can identify what some of those things are=2C or come= up with a couple of search strings or grep expressions=2C I would like to look= at the anomalies myself. +1 on external_host_name Charles ________________________________ From: Cristina Videira Lopes To: opensim-dev at lists.berlios.de Sent: Thursday=2C December 11=2C 2008 2:42:05 PM Subject: [Opensim-dev] external host name It turns out that a lot of problems with CAPs have to do with inconsistencies surrounding the URL of the seed cap. Specifically=2C in some cases we're producing URLs with hostnames=2C other times we're producing URLs with IP addresses=2C for example: http://ucigrid03.nacs.uci.edu:9000/CAPS/4cfc94fa-09be-409b-b136-cda2cdde000= 0/ vs. MailScanner has detected a possible fraud attempt from "128.200.71.43:9000" claiming to be MailScanner warning: numerical links are often malicious: MailScanner warning: numerical links are often malicious: http://128.200.71= .43:9000/CAPS/4cfc94fa-09be-409b-b136-cda2cdde0000/ The client is not smart enough to test if this is the same host=2C it assumes it isn't=2C so it decides someone's trying to game it. The inconsistencies are all over the code in OpenSim=2C and they pertain to the use of ExternalHostName in several data s! tructures. In some cases=2C an explicit conversion to IP addresses is made. We should converge to one single thing. And I believe that thing should be whatever it is given in external_host_name config. Is this right? However=2C I am a bit afraid this is going to break 17 different things... Crista _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ________________________________ _______________________________________________ Opensim-dev =20 mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev =20 _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev = --_93cdcf36-e58e-41c7-9d0c-28c44b8d43ea_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Augh. That's what you get for =3Bassuming stuff. It seems the DnsEndpoi= nt class is only available in .Net for Silverlight... that explains why I d= idn't know about it then. :D
 =3B
So=2C read that as 'should be stored in _something_like_ DnsEndpoint'.
<= BR> *sigh*

At any rate=2C moving the resolving into the very cases where IP adress is = mandatory is a good thing. The resolving is =3Bmulti-level cached anywa= y.

Best regards=2C
Stefan Andersson
Tribal Media AB
 =3B
<= BR>

From: stefan at tribalmedia.se
To: opensim-dev at lists.berlios.de
Date: Fr= i=2C 12 Dec 2008 11:04:27 +0100
Subject: Re: [Opensim-dev] external host= name

From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: leport =3Bpackets (and possibly some others=2C like IM?) =3Bwhere t= he viewer can only accept IP. That is why it is implicitly resolved in some= places. (Or rather=2C that's the rationale for why those places need it) =3B
The remoting issue=2C I don't know what that actually means= =2C but remoting should be resolved thru hostname as well.
 =3B
I= t pains me to admit that I'm probably the source of all this confusion=2C a= s I=2C way back then=2C did the DNS resolve as a quick fix to fix some netw= orking issues - but at that time I was not aware of the DnsEndPoint class.<= BR> =3B
So=2C really=2C the endpoint info should be =3Bstored in=  =3B_DnsEndPoint_ not _IPEndpoint_ all thru core.
 =3B
and =3B
Unless anybody knows of a reason not to=2C I suggest moving an= y =3BIP resolving into the =3BLL client stack=2C as close to the ac= tual needed conversion as possible=2C and let core =3Buse hostnames=2C = via DnsEndPoint=2C =3Ball over.

Best regards=2C
Stefan Anders= son
Tribal Media AB
 =3B
Join the =3B3d web revolution : <= A href=3D"http://tribalnet.se/">http://tribalnet.se/
 =3B







Date: Thu=2C 11 Dec 2008 17:38:04 -0800
From: lopes at ics.uci.edu
T= o: opensim-dev at lists.berlios.de
Subject: Re: [Opensim-dev] external host= name

The thing is that this can potentially create a RegionInfo dat= a structure with
 =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B nRegionInfo.ExternalHostName =3D regionData.IPA= DDR=3B

This is inconsistent with certain queries on the Grid server= =2C like "give me all my neighbors" which may send host names.

So=2C= back to the point: someone needs to decide what is it that RegionInfo.Exte= rnalHostName =3B is supposed to hold.

Teravus Ovares wrote:
= 
RegionUpData is my fault=2C and spawned from compatibility iss=
ues with
.NET remoting and Mono remoting with complex types.  It is only used
to notify a neighbor region that 'this region is up'

Best Regards

Teravus

On 12/11/08=2C Cristina Videira Lopes <=3Blopes at ics.uci.edu>=3B wrote=
:
  
Things are very messy right now. You can search for "sim_i=
p"=2C for example=2C
which is used in chatting with the grid server=2C and where it is being
converted to an IP address in about half of the cases.

To compensate=2C and before I noticed this inconsistency=2C Homer introduce=
d
another field called "sim_host"=2C so not to mess with what was already the=
re=2C
that is supposed to carry the external host name=2C but this only works up =
to
the point in which RegionInfo data structures are created. At that point=2C=
 we
need to decide what to place in m_externalHostName=2C sim_ip or sim_host.
Which means changes in OGS1.

I also noticed that there is yet another data structure called RegionUpData
that uses IP addresses.

So=2C messy. Someone should decide what this field is supposed to be=2C and=
 make
it a rule.

Charles Krinke wrote:

Dear Diva:

You have a very good point and I would support harmonizing to one notion
even at the expense of breaking some things for a while.

In fact=2C if someone can identify what some of those things are=2C or come=
 up
with a couple of search strings or grep expressions=2C I would like to look=
 at
the anomalies myself.

+1 on external_host_name

Charles

________________________________


From: Cristina Videira Lopes <=3Blopes at ics.uci.edu>=3B
To: opensim-dev at lists.berlios.de
Sent: Thursday=2C December 11=2C 2008 2:42:05 PM
Subject: [Opensim-dev] external host name

It turns out that a lot of problems with CAPs have to do with
inconsistencies surrounding the URL of the seed cap. Specifically=2C in
some cases we're producing URLs with hostnames=2C other times we're
producing URLs with IP addresses=2C for example:

http://ucigrid03.nacs.uc=
i.edu:9000/CAPS/4cfc94fa-09be-409b-b136-cda2cdde0000/
vs.
MailScanner has detected a possible fraud attempt from "128.200.71.43:9000"
claiming to be MailScanner warning: numerical links are often malicious:
MailScanner =
warning: numerical links are often malicious: http://128.200.71.=
43:9000/CAPS/4cfc94fa-09be-409b-b136-cda2cdde0000/

The client is not smart enough to test if this is the same host=2C it
assumes it isn't=2C so it decides someone's trying to game it.

The inconsistencies are all over the code in OpenSim=2C and they pertain
to the use of ExternalHostName in several data s! tructures. In some
cases=2C an explicit conversion to IP addresses is made.

We should converge to one single thing. And I believe that thing should
be whatever it is given in external_host_name config. Is this right?
However=2C I am a bit afraid this is going to break 17 different things...

Crista

_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensi=
m-dev
________________________________

    
_______________________________________________
Opensim-dev
  
mailing
list
    
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensi=
m-dev
  
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensi=
m-dev


    
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensi=
m-dev

= --_93cdcf36-e58e-41c7-9d0c-28c44b8d43ea_-- From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: d=2C=20 * for the people wanting to do public beta grade services based on OpenSi= m * for developers that want to code on modules without sudden mysterious b= reaks * and for the devs that want to debug without new parameters being introd= uced. =20 Now of course=2C vendor branches is one other way to do this=2C but what we= at Tribal realized=2C was that since we're coding in modules=2C all we use= d the vendor branch for was for stabilizing fixes. =20 And since that work would otherwise be duplicated in a number of dev teams= =2C it makes sense to share that work. =20 > A better approach to stability than stable branches is> to help create un= it tests for trunk.=20 =20 Which of course not only is a totally untestable assertion=2C but also has = to be weighted against a pragmatical timescale. =20 > This helps contain behavior=2C and> drives towards code correctness for p= arts of the tree.=20 =20 +1 to extended testing. =20 > I'd encourage people> spend time on enhancing automated testing instead o= f doing point in time> stable branches. I'd encourage people to do both=2C as I believe compairing the efforts woul= d be like compairing apples to pears. One is about testing the correctness = of the code in a point of time=2C the other is to provide an aggregate of e= xperience to facilitate a work process. =20 At heart=2C I'm an agile coder. I do believe that trunk should always be in= a shippable state=2C but to think that that means you should always ship t= runk=2C is to over-simplify. /Stefan = --_8c91159c-18de-4961-9531-c53f449079b8_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >=3B >=3B I can see some people being hesitant to commit to supporting = this
>=3B >=3B because they don't want to worry about committing to = two branches each
>=3B >=3B time they have a fix=2C or they don't wa= nt to maintain two slightly
>=3B >=3B different code bases.
 =3B
This would be 100% optional=2C and probably done by a small group of devote= es (like me and Darren=2C as in the case of the last stable) whose only hum= bly wish is to get a heads-up from peple whenever =3Ba good=2C clean bu= g fix has been committed.
 =3B
>=3B >=3B =3BBug reports could also become more of a hassle as
&= gt=3B >=3B some users will report bugs against the trunk=2C while others = against the
>=3B >=3B stable branch.

My concept will not work if we don't re-branch new stables reasonably often= - the heart of the concept is that 'stable' should not deviate from trunk = very far at all=2C just minor bug fixes and changes deemed 'harmless'.
 =3B
The reason=2C of course=2C is exactly that we should be reasonably certain = a bug exists in both branches.
 =3B
Apart from that=2C we have that same problem on every revision. The user ne= eds to tell us what revision (or trunk) the error is on.

>=3B >=3B Having said that=2C I can see a benefit for having a stab= le branch.
>=3B >=3B Ideally it would follow trunk pretty closely=2C= and when it becomes
>=3B >=3B challenging to apply patches to both = trees without too much massaging=2C
>=3B >=3B it's time to do final = stabilization on that final branch and release.

That was the general idea. Bu tI would say=2C given the agile nature of the= project=2C that we just _define_ that=2C "when bug fixes does not apply cl= eanly=2C it's an indication we should bump the number".

>=3B >=3B I would like to encourage you to give this a try.
 =3B
We already are. At the moment=2C I'm just waiting for people to tell me we = have a reasonably stable revision that I can branch again.
 =3B
>=3B =3B>=3B In the meantime=2C don't expect too much
>=3B >= =3B commitment from all the devs=2C and be prepared to take responsibility<= BR>>=3B >=3B for this stable branch. After some time=2C we can all look= back at how
>=3B >=3B things went and decide what to do in the futu= re.

This is basically what happened with 0.6.0-stable. Only thing we need is he= lp with finding the revisions=2C and to get tipped about good stabilizing&n= bsp=3Bfixes in trunk.

>=3B The problem with stable branches... is they aren't. If you add c= ode to
>=3B a branch=2C you have the potential to break it=2C especial= ly on a source
>=3B base as complex as OpenSim.

True as that may be=2C =3Bof course it depends on what type of code you= add=2C and how much.
 =3B
If we were talking doing serious work on a 'real' branch=2C I would be much= more inclined to agree=2C but the point of this is to keep it ligth=2C agi= le and to a minimum of deviation.

>=3B Personally=2C I'm going to stay focused on trunk=2C that's where= my time and
>=3B interest lies.
 =3B
Then do. I'm not trying to rally resources devoted into this=2C I'm merely = trying to work out a process that would work given the nature of the OpenSi= m project.
 =3B
From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: d=2C
 =3B * for the people wanting to do public beta grade services based on= OpenSim
 =3B * =3Bfor developers that want to code on modules without sudde= n mysterious breaks
 =3B * =3Band for the devs that want to debug without new parameter= s being introduced.
 =3B
Now of course=2C vendor branches is one other way to do this=2C but what we= at Tribal realized=2C was that since we're coding in modules=2C all we use= d the vendor branch for was for stabilizing fixes.
 =3B
And since that work would otherwise be duplicated in a number of dev teams= =2C it makes sense to share that work.
 =3B
>=3B =3BA better approach to stability than stable branches is
>= =3B to help create unit tests for trunk.
 =3B
Which of course not only is a totally untestable assertion=2C but also has = to be weighted against a pragmatical timescale.
 =3B
>=3B This helps contain behavior=2C and
>=3B drives towards code cor= rectness for parts of the tree.
 =3B
+1 to extended testing.
 =3B
>=3B I'd encourage people
>=3B spend time on enhancing automated tes= ting instead of doing point in time
>=3B stable branches.

I'd encourage people to do both=2C as =3BI believe compairing the effor= ts would be like =3Bcompairing apples to pears. One is about testing th= e correctness of the code in a point of time=2C the other is to provide an = aggregate of experience to facilitate =3Ba work process.
 =3B
At heart=2C I'm an agile coder. I do believe that trunk should always be in= a shippable state=2C but to think that that means you should always ship t= runk=2C is to over-simplify.

/Stefan
 =3B
= --_8c91159c-18de-4961-9531-c53f449079b8_-- From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: Charles ________________________________ From: Frank Nichols To: opensim-dev at 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 at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > ------------------------------------------------------------------------ > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev --0-81887043-1233637195=:75638 Content-Type: text/html; charset=us-ascii
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 <frank at thenichols.net>
To: opensim-dev at 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 <frank at thenichols.net
> <mailto:frank at thenichols.net>> 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 at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
>    https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> 

_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
--0-81887043-1233637195=:75638-- From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: the RegionInfo class tree=2C or be used in explicit serialization (as in=2C= filling in hashtables) =20 Thru SVN BLAME I can see that the serializable attribute was introduced wit= h the NHibernate patches. =20 From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: bernate=2C and is thus safe to work with in local changes. If you can find any other places using implicit serialization=2C please let= me know. =20 Again=2C =20 thank you. Stefan Andersson Tribal Media AB =20 > Date: Thu=2C 12 Feb 2009 11:07:13 +0000 > From: melanie at t-data.com > To: opensim-dev at lists.berlios.de > Subject: Re: [Opensim-dev] Refactoring the backend codepaths >=20 > Hi=2C >=20 > it is used in a remoting call=2C InformReginOfNeighbors or somesuch.=20 > That implicitly serializes it. That code may have been=20 > changed/removed since I looked at it=2C but that is why it is=20 > serializable. >=20 > Melanie >=20 > Stefan Andersson wrote: > > Esteemed colleagues=2C friends=2C lovers=3B > >=20 > >=20 > >=20 > > I have taken upon me to embark on an long and arduous journey=3B to try= to refactor the mess that is called 'LoginService' - and in the process pr= obably touch on quite a lot of the backend codepath messiness. > >=20 > >=20 > >=20 > > The general idea is to eliminate duplication by abstracting the archite= cture into 'service proxies'=2C 'service implementations'=2C 'model manager= s' and 'service interfaces'. > >=20 > >=20 > >=20 > > This will be done in babysteps=2C over a long time - my goal is to neve= r do any big restructuring=2C but merely work with my trusty refactoring to= ols=2C and as fast as time permits. > >=20 > >=20 > >=20 > > This said=2C the current tangliness may cause me to break something in = some code path=3B if so=2C I beg your forgiveness and support in rectifying= the situation. > >=20 > >=20 > >=20 > > Now=2C at this very moment=2C I have but one question upon my mind=3B p= ray answer it if you are among the wise - > >=20 > >=20 > >=20 > > why is "RegionProfileData" marked as "Serializable" - what is serializi= ng it? > >=20 > >=20 > > Thank you for your time=2C effort=2C support and understanding. > >=20 > >=20 > > Best regards=2C > > Stefan Andersson > > Tribal Media AB > >=20 > >=20 > >=20 > >=20 > > -----------------------------------------------------------------------= - > >=20 > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev --_d113603a-d6d4-4f3a-ac7f-668c53010489_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Melanie=2C
 =3B
Thank you to you and Belsepubi for your swift replies.
 =3B
From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: =3Buse the RegionInfo class tree=2C or be used in explicit serialization (a= s in=2C filling in hashtables)
 =3B
Thru SVN =3BBLAME I can s= ee that the serializable attribute was introduced with the NHibernate patch= es.
 =3B
From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: bernate=2C and is thus safe to work with in local changes.

If you can find any other places using implicit serialization=2C please let= me know.
 =3B
Again=2C
 =3B
thank you.
Stefan Andersson
Tribal Media AB



 =3B>=3B Date: Thu=2C 12 Feb 2009 11:07:13 +0000
>=3B From: melanie at t-= data.com
>=3B To: opensim-dev at lists.berlios.de
>=3B Subject: Re: = [Opensim-dev] Refactoring the backend codepaths
>=3B
>=3B Hi=2C<= BR>>=3B
>=3B it is used in a remoting call=2C InformReginOfNeighbor= s or somesuch.
>=3B That implicitly serializes it. That code may have= been
>=3B changed/removed since I looked at it=2C but that is why it= is
>=3B serializable.
>=3B
>=3B Melanie
>=3B
>= =3B Stefan Andersson wrote:
>=3B >=3B Esteemed colleagues=2C friends= =2C lovers=3B
>=3B >=3B
>=3B >=3B
>=3B >=3B
>= =3B >=3B I have taken upon me to embark on an long and arduous journey=3B= to try to refactor the mess that is called 'LoginService' - and in the pro= cess probably touch on quite a lot of the backend codepath messiness.
&g= t=3B >=3B
>=3B >=3B
>=3B >=3B
>=3B >=3B The gener= al idea is to eliminate duplication by abstracting the architecture into 's= ervice proxies'=2C 'service implementations'=2C 'model managers' and 'servi= ce interfaces'.
>=3B >=3B
>=3B >=3B
>=3B >=3B
&g= t=3B >=3B This will be done in babysteps=2C over a long time - my goal is= to never do any big restructuring=2C but merely work with my trusty refact= oring tools=2C and as fast as time permits.
>=3B >=3B
>=3B >= =3B
>=3B >=3B
>=3B >=3B This said=2C the current tangliness= may cause me to break something in some code path=3B if so=2C I beg your f= orgiveness and support in rectifying the situation.
>=3B >=3B
&g= t=3B >=3B
>=3B >=3B
>=3B >=3B Now=2C at this very moment= =2C I have but one question upon my mind=3B pray answer it if you are among= the wise -
>=3B >=3B
>=3B >=3B
>=3B >=3B
>=3B= >=3B why is "RegionProfileData" marked as "Serializable" - what is seria= lizing it?
>=3B >=3B
>=3B >=3B
>=3B >=3B Thank you f= or your time=2C effort=2C support and understanding.
>=3B >=3B
&= gt=3B >=3B
>=3B >=3B Best regards=2C
>=3B >=3B Stefan Ande= rsson
>=3B >=3B Tribal Media AB
>=3B >=3B
>=3B >=3B <= BR>>=3B >=3B
>=3B >=3B
>=3B >=3B ----------------------= --------------------------------------------------
>=3B >=3B
>= =3B >=3B _______________________________________________
>=3B >=3B= Opensim-dev mailing list
>=3B >=3B Opensim-dev at lists.berlios.de
= >=3B >=3B https://lists.berlios.de/mailman/listinfo/opensim-dev
>= =3B _______________________________________________
>=3B Opensim-dev m= ailing list
>=3B Opensim-dev at lists.berlios.de
>=3B https://lists.= berlios.de/mailman/listinfo/opensim-dev

= --_d113603a-d6d4-4f3a-ac7f-668c53010489_-- From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: database growth, and a reaping strategy would enforce that, so that = would be ok. If there'd be another strategy that would make reaping unnecessary, I'd = welcome that. To me one solution involving different data = responsibilities and quotas smells like such a solution. -- Dirk/Bart -----Urspr=FCngliche Nachricht----- Von: opensim-dev-bounces at lists.berlios.de = [mailto:opensim-dev-bounces at lists.berlios.de] Im Auftrag von Melanie Gesendet: Donnerstag, 19. Februar 2009 03:27 An: opensim-dev at lists.berlios.de Betreff: Re: [Opensim-dev] oddities with asset storage Hi, i proposed a reaping strategy that is both type and time based.=20 There was no direct response to it, but current development on new=20 de-duping cable beach plugins may go a long way to curb asset=20 proliferation and the reaper can be developed on that basis.=20 Refcounting may be feasible as a positive indication, e.g. to=20 indicate something is _definitely_ safe to delete, but a reaper will=20 still be required. Melanie Buckaroo Mu wrote: > Melanie wrote: >> This is something i have though about. However, it would not work in=20 >> OSGrid. Regions may go away, and they may go away permanently.=20 >> Anything in a prim inventory at that time is refcounted and would=20 >> not be released. Ever. >> =20 > In what what in particular would this be worse than the current=20 > situation? Yes, some assets would end up staying around forever.=20 > However, unlike the current scheme, some... would not. >> So, you'd need a ref list, to purge invalid refs. That is where the=20 >> inpracticability begins. A redf list for each and every asset,=20 >> listing either avatar UUID or region UUID? >> >> =20 > Eep, no - wasn't considering suggesting this. >> If assets are 51 mio, how long will the reflist table be? >> >> Melanie >> >> Buckaroo Mu wrote: >> =20 >>> Here's my L$0.02, for what it's worth - why not maintain a = 'reference=20 >>> count' in the asset entry? >>> >>> Resident A creates a prim, takes it into inventory. Asset is = created,=20 >>> inventory item pointing to asset is created, asset->useagecount++. = User=20 >>> gives away 15 copies of item, asset->usagecount+=3D15. Resident A = deletes=20 >>> original item, inventory item goes away, asset->usagecount--. >>> >>> Resident B rezzes item on sim. If item is no-copy, = asset->usagecount--.=20 >>> If it's copy, and Resident B (or Resident C) takes it back into=20 >>> inventory, asset->usagecount++ (they would have two copies of it).=20 >>> Resident B deletes both copies from inventory, asset->usagecount = -=3D2. >>> >>> If asset->usagecount =3D=3D 0, asset gets deleted. >>> >>> Tell me why this wouldn't work. I'm sure there's a simple reason, = but I=20 >>> can't think of it. All of this is assuming that the asset is no-mod = -=20 >>> any change to the asset creates a new UUID, correct? But if the = asset is=20 >>> rezzed, then taken back into inventory, it should have the same = UUID,=20 >>> thus adding one to the usage count. >>> >>> -Buckaroo >>> >>> Melanie wrote: >>> =20 >>>> All you described is design behavior. >>>> >>>> >>>> Prim items in world are not assets. They are stored exclusively in >>>> the prims tables of the region. >>>> >>>> Once taken, they become an asset. The name is totally meaningless, >>>> it reflects whatever was the name at creation. Nothing else. It >>>> never changes from there on. >>>> >>>> On deleting the inventory item, assets remain. There is no easy or >>>> practicable way to conclusively say that an asset is trash, because >>>> we don't know. >>>> >>>> In your test case, your (human) mind could know this for a fact, >>>> however, the silicon mind of the asset server can't. >>>> >>>> This is because you may have given the object to another user, or >>>> put a copy into a prim. >>>> >>>> These copies would refer to the same asset, that is what = "implictily >>>> shared" means. >>>> >>>> So, any asset may, at any time, have any number of links to it, = even >>>> zero. >>>> >>>> Like a website, you don't know who linked to it. If you remove it, >>>> you leave dead links. Assets are the same. Except, you get "Asset >>>> missing from database". >>>> >>>> So, assetas are NOT 1-to-1 with inventory items, and they _never_ >>>> get deleted. >>>> >>>> They have to be reaped, and there is a big discussion over how to >>>> best do that, running right now. >>>> >>>> Melanie >>>> >>>> >>>> Dirk Krause wrote: >>>> =20 >>>> =20 >>>>> Hi, >>>>> >>>>> I did a little test with a fresh OpenSim installation (yes, thanks = for >>>>> the installer!), >>>>> to get a grip on what I learned from Melanie yesterday. >>>>> >>>>> I wrote a little python script to help me monitor these tables: >>>>> inventoryStore/inventoryItems >>>>> assetStorage/assets >>>>> http://pastebin.com/mc9e6574 , be warned: ugly code. >>>>> >>>>> I started OpenSim and logged in a 'Test User' with the SL viewer. >>>>> >>>>> (Just to mention it - first time log in in as test users creates >>>>> 4 'blank' entries in assets.) >>>>> >>>>> The inventoryItems table was initially empty. >>>>> >>>>> Now I rezzed a cube and renamed it to 'p1'. >>>>> inventoryStore/inventoryItems was still empty. >>>>> To my surprise no new entry shows up in assetStorage/assets. >>>>> >>>>> Picking up the cube ('take') created an entry named 'p1' in the >>>>> inventory and in the asset table. >>>>> >>>>> Now I renamed the cube in Test Users inventory to 'p2'. >>>>> The name in inventoryStore/inventoryItems changes to 'p2'. >>>>> The entry in assetStorage/assets stays 'p1'. As mentioned on the = list >>>>> before, >>>>> the asset name is useless, since the user only sees the name in = the >>>>> inventory. >>>>> >>>>> Now I deleted 'p2' in my inventory - 'p2's parentfolderID changes = to >>>>> 'Trash'. >>>>> Now I emptied the trash - the inventory table is empty again, = which is >>>>> fine, >>>>> but here's the big one: >>>>> the assetStorage/assets still holds the reference to 'p1'. >>>>> >>>>> Just to make sure I shut down the simulator and opened it again, = and it >>>>> was still there. >>>>> >>>>> Now, doesn't that mean, that the database increases over time with = no >>>>> hope to find >>>>> these assets that actually should be gone? or is there some magic >>>>> purging that happens, >>>>> and that I missed? >>>>> >>>>> This would mean that any grid runs into a severe problem over = time. >>>>> >>>>> Best, >>>>> Dirk/Bart >>>>> _______________________________________________ >>>>> Opensim-dev mailing list >>>>> Opensim-dev at lists.berlios.de >>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>>> >>>>> >>>>> =20 >>>>> =20 >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> Opensim-dev at lists.berlios.de >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> >>>> >>>> =20 >>>> =20 >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> >>> =20 >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> >> =20 >=20 > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev >=20 >=20 _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: this out there for real, with a 2.0 tag, without first understanding if/how people detect phishing in this particular context. There have been enough studies in the past about how normal people handle security (or not) in practice, and the fallacies of designing systems assuming that people choose security over convenience.

But hey -- I have no interest in the success or failure of the corporations that are pushing for this.
I'll just stay here on my academic Ivory tower watching the phishing artists unwrap this wonderful present that is falling on their laps...
http://marcoslot.net/apps/openid/


And that's my last email about OpenID; case closed afaic, I'm too old and too cranky for these Web 2.0 experiments. I'd rather continue trying to solve the problem for real :-)

Crista

Aldon Hynes wrote: 
It is worth noting that Microsoft is now adopting OpenID as well.  A while
ago it went into testing,  The idea is that you can use Microsoft Live as
your OpenID provider.  I've tested it and it works fairly well.  In fact, I
think it works better than the Google implementation.  However, I still
prefer XRI based OpenID

=aldon.hynes
@ahynes1

-----Original Message-----
From: opensim-dev-bounces at lists.berlios.de
[mailto:opensim-dev-bounces at lists.berlios.de]On Behalf Of Ralf Haifisch
Sent: Monday, March 02, 2009 6:39 PM
To: opensim-dev at lists.berlios.de
Subject: Re: [Opensim-dev] OpenID


Crista,

this is a upcomming standard and common sense. If I do an audit based in ISO
27.001, this is a perfect thing and would get some applause if implementet,
generally speaking.


It is based on the established ideas from LPAD+Kerberos combining systems,
that use this triangle of user/workstation - auth-provider and
auth-subscriber in principle , as well.


Microsoft did try to run this with .Net Passport (uhm... maybe they even had
a name before that) and had a set of criteria you have to fulfill before
joining the system.  People did not like this "closed source big brother -
alike" system.


openID and SAML are major topics for those devs, that are into security
systems right now. Claim based systems and rights management are often based
on this.


It is all about a "secure stack".

- hopefully, you did write your operating system - why could it be trusted
otherwise ?
- what about the keyboard ?  easy going to implement what I need
- is there a "nuble" on your monitors video cord ? is this for antiference
reasons... hmmm..
- you print out strategic papers or sources on the big laserpinter in the
floor (sure, only you in the building)..  I did fetch interesting stuff
unencrypted from these devices
- you had this all new USB harddisc for backups that came with some new
drivers ?

Unless the whole stack from hardware to service is secure and trusts are
build and verified against each other.... what you see is the best that is
realistic achievable:


--> warn the user, if something is maybe wrong.


Its you, chooses the opened provider (I guess verisign is somewhat secure
for me)

It´s you who uses a service - and would have done even without opened.

Its you who gets a warning about possible fraud, you would not have been
getting without opened.


Instead of opened the usual user has 2000 passwords and requests new
passwords via clear text email over the web, regularly.


So - in total a regular user gets more security.  That’s the basic idea.


In some years we will use at least 2-factor authentification.  E.g. the
Netherlands did start giving out passports with a digital ID (certificate).
Cheap reader will spread.


There is a common sense that, "exo-technical means" will better serve
security needs in future. The more business driven standards like ISO 27.001
and 38.500 repect this. Technical means will fulfill a task assingned
exo-technical.


Let say - this is a new and upcoming system.
Its not worse than what we have.
It has many option got get better on a standard architecture.


It´s a little bit like the 3D web story...


Cheers,
Ralf


------------------------------

Message: 6
Date: Mon, 02 Mar 2009 14:44:46 -0800
From: Diva Canto <diva at metaverseink.com>
Subject: Re: [Opensim-dev] OpenID
To: opensim-dev at lists.berlios.de
Message-ID: <49AC615E.5010904 at metaverseink.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

OMG!
Sorry for insisting on this, but I tend to get obsessive when I'm trying
to figure things out :-)
I just tried login to some random Brazilian site using my OpenID-ed
Yahoo account. Indeed, it... works... i guess.
I seem to have been redirected to a yahoo openid login page, which,
after I entered my password, proceeded to warn me that "Warning: this
web site has not confirmed its identity with Yahoo! and might be
fraudulent....".

I have no idea/guarantees that this site that the Brazilian site
redirected me that looks like Yahoo, where I entered my password, and
that is warning me of danger, is, indeed, a legitimate Yahoo site. It
might not be. And I have no idea what that potentially fraudulent
Brazilian site might do with the info it gets from Yahoo (assuming this
is Yahoo and not a phishing scam).

Sorry, this defies all common sense...

I can see the *mechanism* of OpenID working among a group of
organizations that trust each other by exo-technical means (read
lawyers). But this mechanism in decentralized, world-wide open systems?!
That's insane!

Crista

Diva Canto wrote:
  
The more I read about OpenID the more concerns I have that it's unsafe
-- not just for OpenSim but in general. It seems that OpenID is a
wonderful opportunity for phishing sites to get access to people's
passwords directly.

The flaw is that it assumes that the initial site is trustworthy. That's
a huge assumption! Try to use your OSGrid OpenID-ed account in a future
version of DNCH... it will direct you to a page that will look like
OSGrid's login page, and then it will steal your password as you type it.

Is this serious?! Maybe I'm missing something fundamental...

<puzzled>
Crista

_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev


    




_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

--------------000200020906030200060404-- From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: understanding of how the assest server works. Also, I don't think I will play with that, but I was thinking of writing this info up in a blog post. Do you have a link to any additional information on your cryptogrid assest provider? Couple questions about the assest servers... Could I now run an assest server localy, and allow connections to other grids securing my assest here? Even if I could do this wouldn't it all still boil down to the CIL reaching an unsecure sim? I ask these questions because ealier someone mentioned trusted asset/inventory servers as possible furture solutions. I tried to find more info from past emails, but could not. Thanks again for everyone time answering my questions on this topic. I do appreciate it. I fully understand its impossible to protect data in any format 100% if its ever going to be used outside of a controlled enviroment. -----Original Message----- From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Frisby, Adam Sent: Thursday, March 19, 2009 8:05 PM To: opensim-dev at lists.berlios.de Subject: Re: [Opensim-dev] Couple questions on scripts The short answers here are: - The sims need unencrypted copies of scripts for operations (to compile them, etc). You can pass them the assemblies (compiled results), however CIL (our bytecode language) can be decompiled back to source form with remarkable accuracy (it's at the very least human readable). - So anyone who has a region that is running your scripts could potentially intercept them. - The grid & asset servers don't need unencrypted copies. If you are uploading onto an untrusted grid for use in a trusted subsection, there is the cryptogrid asset provider I wrote a while ago -- however this only works if you trust the region operators who you give the decryption key to. (and of course, you won't be able to use the asset without them having it). It definitely won't be as convenient since you need to provide the keys before rezzing the object, but it might be useful if you want to say run some private scripts on a region you self-host on OSGrid.org, and don't want the osgrid team getting a copy. Adam > -----Original Message----- > From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev- > bounces at lists.berlios.de] On Behalf Of Skidz Tweak > Sent: Thursday, 19 March 2009 12:43 PM > To: opensim-dev at lists.berlios.de > Subject: Re: [Opensim-dev] Couple questions on scripts > > That's very interesting. I like the idea of trusted asset/inventory > servers. > I will look through the past emails for more information on that > project > aspect. Thanks. > > -----Original Message----- > From: opensim-dev-bounces at lists.berlios.de > [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Melanie > Sent: Thursday, March 19, 2009 2:23 PM > To: opensim-dev at lists.berlios.de > Subject: Re: [Opensim-dev] Couple questions on scripts > > Hi, > > basically, to answer "yes" to your question #1, ALL of the following > must be true: > > - The grid must be owned and operated by a single entity > - Said entity must have a TOS, statement and/or track record of > respecting content creators' rights > - No outside regions can connect > - No outside persons can access the shell or database of the grid > > It would be up to you to determine whether you trust the operator of > the grid. Currently a few such grids exist. > > Generally, if a grid allows outside connections or Hypergridding, it > is not safe. > > However, hypergrid is moving towards a safe way to distribute > content from authenticating asset/inventory servers. Eventually this > may lead to signed binary assemblies being passed around the > simulators, with the region operators trusting the certificates. > However, this will likely not prevent retention of copies of the > goods, so the above points about trusting the operators still apply. > Even though your script source code can't be stolen in this future > scenario, permissions as we know them today could easily be > circumvented. > > Melanie > > > Skidz Tweak wrote: > > Hi all, I finally set up a openSim of my own, and its working great. > The > > development community in this project has done an outstanding job so > far > > (based on my own experiences). > > The setup process was easy, so easy I over complicated it by creating > the > > database tables and such myself prior to running it causing some > problems > :) > > > > I just had a couple questions: > > 1. Are scripts safe on other grids? I get a number of request to move > my > > tools into other grids. > > And what I mean by safe is, people can't steal them. > > 2. I am guessing the real answer to question number 1 is no, so... > Has > there > > been any effort in the direction of maybe a different way to > distribute > > items on the new grids? > > For example, I could imagine an install package for a sim, or > grid > > that could ensure purchase in an encrypted maner with a cert or > something. > > > > Just some thoughts and thx for your time. > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: "The 3D Internet Focus Area will look at ways in which 3D visualization and immersive environments such as Second Life are changing the way we communicate, share information, educate students and explore scientific problems. "'The Internet changed the way we share information and the 3D Internet will change the way we relate to each other in fundamental ways,' said John Hengeveld, a business strategy manager at Intel and chair of the 3D Internet Focus Area. 'These graphically rich 3D worlds require a host of HPC resources, and they could forever change education and how people come to understand scientific concepts.' "Submissions for most areas of the SC09 technical program will be accepted beginning March 16. Technical paper abstracts are due April 3 and final papers as well as submissions for tutorials, workshops and panels are due April 6." SC09 will be November 14-20, 2009 in Portland, Oregon, USA. http://sc09.supercomputing.org/ -Coyle [1] -- What's SC09? "SC09, sponsored by the ACM (the Association for Computing Machinery) and the IEEE Computer Society, offers a complete technical education program and exhibition to showcase the many ways high performance computing, networking, storage and analysis lead to advances in scientific discovery, research, education and commerce. This premier international conference includes a globally attended technical program, workshops, tutorials, an exhibit area, demonstrations and hands-on learning. From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: Key benefits * Faster and cheaper accommodation of existing systems. * Increased flexibility; easier to change as requirements change. * Standards-based. * Scales from point solutions to enterprise-wide deployment (distributed bus). * Predefined ready-for-use service types. * More configuration rather than integration coding. * No central rules engine, no central broker. * Incremental changes can be applied with zero down-time; enterprise becomes "refactorable". Key disadvantages * Enterprise Message Model is usually required, resulting in additional management overhead. May not be a simple task to achieve many disparate systems collaborating on message standards. * Requires ongoing management of message versions to ensure the intended benefit of loose coupling. Incorrect, insufficient, or incomplete management of message versions can result in tight coupling instead of the intended loose coupling. * It normally requires more hardware than simple point to point messaging. New skills needed to configure, manage, and operate an ESB. * Extra overhead and increased latency caused by messages traversing the extra ESB layer, especially as compared to point to point communications. The increased latency also results from additional XML processing, as the ESB normally uses XML as the communication language. * Some critics remark that ESB require a significant effort to implement, but produces no value unless SOA services are subsequently created for the ESB.[1] -------------------------------- Regards Teravus On 3/24/09, doug.lundin at gmail.com wrote: > All, > Suspect the notion of using an ESB with OpenSim would be seen as a feature request. But, am curious if anyone has thought about such an infrastructure approach and pros/cons for this project. How might it relate to the Grid? > Would be interested in hearing your thoughts. > Doug > Sent via BlackBerry by AT&T > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: any point that a uuid isn't the right thing for an asset, we can handle schema changes on MSSQL without too much hassle. MSSQL has a native unique identifier data type, so it was daft not to use it when we use uuids throughout the code - faster indexing and more efficient data storage. Migrating most of a database didn't take long, but the assets took a very long time to migrate since we have a >5Gb database of mostly assets at ReactionGrid now. -----Original Message----- From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Justin Clark-Casey Sent: 27 March 2009 14:59 To: opensim-dev at lists.berlios.de Subject: Re: [Opensim-dev] RFC: Ways of creating profiles for creators who will never log in Oh, now that is a most excellent idea, Stefan - one that I think is much better than copying and inserting profiles. And I even think it could be made to work with the current architecture. I think that it will need user ID fields in the database to be made much larger than the current char(36) limits for=20 UUIDS (I'd like to know how this affects MSSQL), so I would probably need to do that unless there are any comments. I shall seriously think about this and take this approach rather than the profile copying I was suggesting unless there=20 are any major pragmatic obstacles. Thanks! Stefan Andersson wrote: > Justin, > =20 > whilst you're at it, could you have a look at the feasabilty of just=20 > adding the url to the user profile on the user service on the=20 > originating grid? > =20 > We should try to move from guid/local to url/global in everything we do,=20 > even if in babysteps. > =20 > If we could let the user server serve a controlled subset of the user=20 > profile to the world, that could be used for preserving a link to the=20 > original creator. >=20 > So, instead of having creator=3D and then have to re-create that=20 > profile locally, we could have=20 > creator=3Dhttp://users.osgrid.org/users/justincc/ >=20 > Best regards, > Stefan Andersson > Tribal Media AB >=20 >=20 >=20 > =20 > > Date: Thu, 26 Mar 2009 21:00:16 +0000 > > From: jjustincc at googlemail.com > > To: opensim-dev at lists.berlios.de > > Subject: [Opensim-dev] RFC: Ways of creating profiles for creators=20 > who will never log in > > > > Hello, > > > > For Inventory Archives I plan to preserve item creator information. > When the archive is loaded I would like to recreate > > these profiles where possible/necessary (grid operators can choose=20 > not to allow this and that will be the default, I > > expect). > > > > However, unless an item creator has an account on the OpenSim to=20 > which the archive is loaded, they shouldn't be able to > > login to that instance. > > > > So far I've thought of 3 ways to create a profile without=20 > automatically allowing login. > > > > > > (1) Create a normal user account but set the password to something=20 > random. > > > > PROS > > * Doesn't require any changes to what we have today > > > > CONS > > * Creates user accounts which are never intended to be used for login > > * No way to distinguish archive created accounts from legitimate accounts > > ~~~~~ > > > > (2) Add a 'ProfileOnly' flag to the Users table > > > > PROS > > * Minimal changes to what we have today > > * Makes it clear that an entries has been created for its profile=20 > only, which can be used as a flag to disallow logins > > > > CONS > > * Creates user accounts where many details will be irrelevant unless=20 > item creators then get accounts on the instance. > > * Complicates administration tasks (e.g. create user). > > ~~~~~ > > > > (3) Separate the current 'users' table into 'userprofiles' and=20 > 'users' tables. > > > > 'userprofiles' will largely contain all the metadata about a user=20 > that you can see in the profile on the Linden Labs > > Second Life client today (name, about, interests, 1st life, etc.). > > > > 'users' will contain the data associated with a particular account=20 > (passwordHash, passwordSalt, homeRegion, > > homeLocationX, etc.) > > > > PROS > > * Makes it possible to create user profiles without creating user=20 > accounts. > > * Makes it possible to have somewhat separate profile and=20 > authentication plugins allow mix & match. However, the reuse > > of avatar name as the login identifier makes things a bit awkward. > > * Simplifies database understandability - the only people in the=20 > 'users' table are those with actual accounts, though on > > the other hand this does create 2 tables instead of 1. > > > > CONS > > * Short term adjustment pain for systems accessing OpenSim's=20 > databases directly > > * Complicates administration tasks (e.g. create user). > > ~~~~ > > > > I suspect that archiving isn't the only potential use for this=20 > functionality. For instance, the Hypergrid may also find > > it useful to preserve user information when a user rezzes an object > on a foreign system. > > > > Of the above approaches, I prefer (3) over (2) since it seems to me > to be the better long term approach even if there is > > some short term pain. I'm don't think that (1) is a good option. > > > > I've reproduced most of text at=20 > http://opensimulator.org/wiki/Creating_profiles_not_used_for_login for > reference. > > > > Comments? > > > > -- > > justincc > > Justin Clark-Casey > > http://justincc.wordpress.com > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev >=20 >=20 > ------------------------------------------------------------------------ >=20 > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev --=20 justincc Justin Clark-Casey http://justincc.wordpress.com _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev No virus found in this incoming message. Checked by AVG - www.avg.com=20 Version: 8.0.238 / Virus Database: 270.11.29/2023 - Release Date: 03/26/09 20:05:00 From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: 395 was about the most recent quite stable revision. If there is agreement = on that or another revision then I'll tag/branch it as a 0.6.5RC.
> <= br>> --- On Fri, 15/5/09, diva at metaverseink.com <= ;diva at metaverseink.com&= gt; wrote:
>
> From: diva at metaverseink.com <diva at metaverseink.com>
> Subject: [Open= sim-dev] WARNING: r9562 may break things
> To: "opensim-dev at lists.berlios.de" <opensim-dev at lists.berlios.de>
> Date: Friday, 15 May, 2009= , 6:23 AM
>
> Everyone --
> Just a warning to please sta= y away from head, starting in r9562, for the
> next couple of days u= nless you really really really want to help test
> things. We starte= d replacing the services to the new service model that
> was discussed here a few w= eeks ago, staring with the asset service. For
> starters, there are = new configuration variables in OpenSim.ini that you
> need to get ac= quainted with -- see the OpenSim.ini.example at the
> bottom. But un= less you really need to be in head, don't; please wait at
> least 24= hours.
>
> Melanie --
> The transplant is mostly done. = See commit message for the things that
> are borked. Also note, I ch= anged the config var you had called "Modules"
> to "ServiceConnector= s", you probably need to change your local .ini.
> Talk to you tomorr= ow.
> _______________________________________________
> Opensim= -dev mailing list
> Opensim-dev at lists.= berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> >
>
>       
>
> <= br>> -------------------------------------------------------------------= -----
>
> _______________________________________________
&= gt; Opensim-dev mailing list
> Opensim= -dev at 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

=0A=0A=0A=0A --0-1048744743-1242395963=:66058-- From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: 2009/5/25 Stefan Andersson > All, > > as of fifteen minutes ago, I just back-tagged 0.6.5-release, and > subsequently turned 0.6.5-rc1 into 0.6.5-post-fixes. > > This release is essentially based on trunk rev 9561, which has gotten som= e > good review - plus version number bumping and some aplied minor fixes. > > This is the last release to support Visual Studio 2005. > > I will now upgrade trunk to reflect our current version as 0.6.5. (we don= 't > up trunk until we know we have a proper release) > > Tomorrow, I will also put into place a little mechanism to be able to > specify "trunk", "rc1" or "release" in the version info. > > Happy 0.6.5 everybody! > > Best regards, > Stefan Andersson > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > --001636c5b91ecbef89046abb6e98 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=BFPerhaps a Happy Release Party? ;-D
=A0
From one of the suffered testers, =A1 thanks a lot for your great work= !

2009/5/25 Stefan Andersson <= ;stefan at tribalmedia.se>
All,
=A0
as of fifteen minutes ago, I just back-tagged 0.6.5-rel= ease, and subsequently turned 0.6.5-rc1 into 0.6.5-post-fixes.
=A0
Th= is release is essentially based on trunk rev 9561, which has gotten some go= od review - plus version number bumping and some=A0aplied minor=A0fixes. =A0
This is the last release to support Visual Studio 2005.

I wil= l now upgrade trunk to reflect our current version as 0.6.5. (we don't = up trunk until we know we have a proper release)
=A0
Tomorrow, I will= also put into place a little mechanism to be able to specify "trunk&q= uot;, "rc1" or "release" in the version info.
=A0
Happy 0.6.5 everybody!

Best regards,
Stefan Andersson
<= br>


_______________________________________________
Ope= nsim-dev mailing list
Op= ensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

<= /blockquote>

--001636c5b91ecbef89046abb6e98-- From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: objects in memory and increasing memory usage. This may be causing portions of memory to swap out where they may not have before. When retrieving the asset, it would need to swap it back in and it may have to do it in several steps in order to locate the asset. This may cause further delay as it may have to swap other memory out to make space. It would seem likely that a file based cache may perform better as the filename might provide a more direct route to the actual cache data. I suspect that the operating system may also allow searching directories for a filename fairly quickly - modern file systems are quite efficient these days. This is really just a guess... I suspect some benchmarking and profiling of several systems of different configurations may be necessary to determine what the bottleneck really is. On Tue, May 26, 2009 at 3:52 PM, wrote: > I noticed we have GlynnTucker.Cache.dll in the distribution, and this > wasn't being used. I have no idea what the story is, but since it's > there, I did one alternative cache module implementation using it, just > to see what happens. Since everything is modularized now, replacing the > asset cache implementation is as simple as editing your XXXCommon.ini > and changing the name: > > ;AssetCaching = "CoreAssetCache" > AssetCaching = "GlynnTuckerAssetCache" > > I would still urge that someone figures out what's wrong with > OpenSim/Framework/Cache.cs, which is the one used in CoreAssetCache. > > The GlynnTuckerAssetCache has been tried in the UCI Grid and in some > sims in OSGrid and at least it's not being an anti-cache. Let's wait a > few more days to see if it's being a real cache; if so we should see > declines on the traffic to the asset servers :-) > > Arthur Valadares wrote: > > If we ran a profiling with this cache maybe we could see where the > > bottle neck is, couldn't we? > > > > Mono has simple statistical profiler that shouldn't be too intruding: > > > > $ mono --profile=default:stat program.exe > > > > If anyone who saw this performance loss could test this, would be > > interesting to see where it's spending all this extra time. > > > > On Tue, 2009-05-26 at 10:57 -0700, diva at metaverseink.com wrote: > >> Just a quick note to inform everyone that word from osgrid folks > >> indicates that the asset cache is still borked and still a mystery. When > >> it is on, CPU usage spikes to unsustainable values (150% with 4 avies in > >> WP). > >> > >> If anyone cares to take a look at it / replace it with something else, > >> please do. > >> > >> OpenSim/Framework/Cache.cs > >> _______________________________________________ > >> Opensim-dev mailing list > >> Opensim-dev at lists.berlios.de > >> https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > --0016364ee01c638db7046ae1d243 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: objects in memory and increasing memory usage. This may be causing portions= of memory to swap out where they may not have before. When retrieving the = asset, it would need to swap it back in and it may have to do it in several= steps in order to locate the asset. This may cause further delay as it may= have to swap other memory out to make space. It would seem likely that a f= ile based cache may perform better as the filename might provide a more dir= ect route to the actual cache data. I suspect that the operating system may= also allow searching directories for a filename fairly quickly - modern fi= le systems are quite efficient these days.

This is really just a guess... I suspect some benchmarking a= nd profiling of several systems of different configurations may be necessar= y to determine what the bottleneck really is.

On Tue, May 26, 2009 at 3:52 PM, <diva at metaverseink.com> wrote:
I noticed we have GlynnTucker.Cache.dll in the distribution, and this
wasn't being used. I have no idea what the story is, but since it's=
there, I did one alternative cache module implementation using it, just
to see what happens. Since everything is modularized now, replacing the
asset cache implementation is as simple as editing your XXXCommon.ini
and changing the name:

;AssetCaching =3D "CoreAssetCache"
AssetCaching =3D "GlynnTuckerAssetCache"

I would still urge that someone figures out what's wrong with
OpenSim/Framework/Cache.cs, which is the one used in CoreAssetCache.

The GlynnTuckerAssetCache has been tried in the UCI Grid and in some
sims in OSGrid and at least it's not being an anti-cache. Let's wai= t a
few more days to see if it's being a real cache; if so we should see declines on the traffic to the asset servers :-)

Arthur Valadares wrote:
> If we ran a profiling with this cache maybe we could see where the
> bottle neck is, couldn't we?
>
> Mono has simple statistical profiler that shouldn't be too intrudi= ng:
>
> $ mono --profile=3Ddefault:stat program.exe
>
> If anyone who saw this performance loss could test this, would be
> interesting to see where it's spending all this extra time.
>
> On Tue, 2009-05-26 at 10:57 -0700, diva at metaverseink.com wrote:
>> Just a quick note to inform everyone that word from osgrid folks >> indicates that the asset cache is still borked and still a mystery= . When
>> it is on, CPU usage spikes to unsustainable values (150% with 4 av= ies in
>> WP).
>>
>> If anyone cares to take a look at it / replace it with something e= lse,
>> please do.
>>
>> OpenSim/Framework/Cache.cs
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensi= m-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
>> https://lists.berlios.de/mailman/listin= fo/opensim-dev
>
> ----------------------------------------------------------------= --------
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berl= ios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.d= e
https://lists.berlios.de/mailman/listinfo/opensim-dev

--0016364ee01c638db7046ae1d243-- From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: say you have good chances to get things done nicely here. Although I = don't agree on all your opinions (read: OpenID, OAuth), sometimes = someone has to implement things *when and *how she thinks it is right = without political constraints to make an impact. After all someone could think about paying you for your work. At least a = bit more than a hippo and a missing free t-shirt. -----Urspr=FCngliche Nachricht----- Von: opensim-dev-bounces at lists.berlios.de im Auftrag von Cristina = Videira Lopes Gesendet: Mi 03.06.2009 21:37 An: opensim-dev at lists.berlios.de Betreff: [Opensim-dev] OGPX and IETF-ing things [text] =20 Inifinity sent me a very nice private message, which, because it was =20 private, I'm not going to forward here. But the bottom line of his =20 nice message could use some public discussion. Essentially Infinity =20 is suggesting that we move towards getting the Hypergrid work into =20 the IETF, through this newly created OGPX working group. Personally, I think this is all premature. IETF-ing the Hypergrid is =20 premature for different reasons than IETF-ing OGP is premature. The =20 Hypergrid is not really ready for prime time until we have the =20 Hypergrid2 in place, with its security model to protect users from =20 malicious simulators. OGP is not ready for prime time because no one =20 has seen it yet, at least not any reasonably complete implementation =20 of it. The right thing to do, I think, is to first have implementations of =20 both OGP and the Hypergrid2 in OpenSim. Once that is in place, we can =20 all see the similarities and differences, and try to standardize the =20 similar pieces. Alternatively, we can try to work together towards =20 one single interop protocol, but honestly I think that's not going to =20 happen, simply because there is space for many (not just 2, but 3 or 4) What I suspect will happen is that OGP and the Hypergrid will have =20 several pieces that are very much in sync, with small details that =20 are different, and then they will have a few really important pieces =20 that are substantially different. Things like posting/retrieving =20 agents to/from regions, for example, we already converged to using =20 REST; inventory access, we already converged to using capability =20 URLs, etc. Small details such as the format of the data on the wire =20 are different, but that doesn't really matter as long as we agree =20 that the Content-type can be set to different things. The thing that will be substantially different is the issue of =20 authority: what component has authority to do what. In OGP regions =20 are still the ones doing agent transfers, therefore implying a trust =20 relation between interacting grids that must be established in some =20 non-technical manner (i.e. the receiving region trusts that the =20 sending region is not stealing the user's identity). In the =20 Hypergrid, agent transfers between non-trusting regions are done on =20 the client side, so that the identity of the user can always be =20 verified, there is no region in the middle acting on behalf of anyone. So, that's the main difference, as far as I understand OGP. The Hypergrid2 is in place through a proof-of-concept prototype =20 client (Grider) and a couple of small but horrible hacks in OpenSim. =20 OGP implementations don't exist yet, or they are not available to us =20 which is the same. I think there's a lot of work to do before we go =20 and propose any of this as standards. But I thought I'd bring this up for discussion. Maybe other people =20 aren't as strict on working implementations as I am. Crista _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ------_=_NextPart_001_01C9E488.83096C2A Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IjUUAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAMgAAAEFXOiBbT3BlbnNpbS1kZXZd IE9HUFggYW5kIElFVEYtaW5nIHRoaW5ncyBbdGV4dF0AnxABBYADAA4AAADZBwYAAwAWABIAHwAD ADMBASCAAwAOAAAA2QcGAAMAFgASADQAAwBIAQEJgAEAIQAAADEyODAzQjcyMzQyQzhCNEM5RDIz RjMyRUU0NjBFNjk4ABMHAQOQBgDwEAAAOQAAAAMAJgAAAAAAAwA2AAAAAABAADkAhWppdojkyQEe AD0AAQAAAAUAAABBVzogAAAAAAIBRwABAAAALwAAAGM9REU7YT0gO3A9Yml0bGFiO2w9SEVSTUVT LTA5MDYwMzIwMTg1MlotMjUyODYAAB4ASQABAAAALgAAAFtPcGVuc2ltLWRldl0gT0dQWCBhbmQg SUVURi1pbmcgdGhpbmdzIFt0ZXh0XQAAAEAATgAAwgjLguTJAR4AWgABAAAAJQAAAG9wZW5zaW0t ZGV2LWJvdW5jZXNAbGlzdHMuYmVybGlvcy5kZQAAAAACAVsAAQAAAGcAAAAAAAAAgSsfpL6jEBmd bgDdAQ9UAgAAAABvcGVuc2ltLWRldi1ib3VuY2VzQGxpc3RzLmJlcmxpb3MuZGUAU01UUABvcGVu c2ltLWRldi1ib3VuY2VzQGxpc3RzLmJlcmxpb3MuZGUAAAIBXAABAAAAKgAAAFNNVFA6T1BFTlNJ TS1ERVYtQk9VTkNFU0BMSVNUUy5CRVJMSU9TLkRFAAAAHgBdAAEAAAAXAAAAQ3Jpc3RpbmEgVmlk ZWlyYSBMb3BlcwAAAgFeAAEAAABGAAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAAQ3Jpc3RpbmEg VmlkZWlyYSBMb3BlcwBTTVRQAGxvcGVzQGljcy51Y2kuZWR1AAAAAgFfAAEAAAAXAAAAU01UUDpM T1BFU0BJQ1MuVUNJLkVEVQAAHgBmAAEAAAAFAAAAU01UUAAAAAAeAGcAAQAAACUAAABvcGVuc2lt LWRldi1ib3VuY2VzQGxpc3RzLmJlcmxpb3MuZGUAAAAAHgBoAAEAAAAFAAAAU01UUAAAAAAeAGkA AQAAABIAAABsb3Blc0BpY3MudWNpLmVkdQAAAB4AcAABAAAALgAAAFtPcGVuc2ltLWRldl0gT0dQ WCBhbmQgSUVURi1pbmcgdGhpbmdzIFt0ZXh0XQAAAAIBcQABAAAAGwAAAAHJ5IOTZoUSPUKWfEUA s00+TXvO/dAAATjA8wAeAHQAAQAAAB0AAABvcGVuc2ltLWRldkBsaXN0cy5iZXJsaW9zLmRlAAAA AB4AGgwBAAAADAAAAERpcmsgS3JhdXNlAB4AHQ4BAAAALgAAAFtPcGVuc2ltLWRldl0gT0dQWCBh bmQgSUVURi1pbmcgdGhpbmdzIFt0ZXh0XQAAAAIBCRABAAAAfwkAAHsJAAAXEQAATFpGdRvKF18D AAoAcmNwZzEyNeIyA0N0ZXgFQQEDAfdPCoACpAPjAgBjaArAc/BldDAgBxMCgA/zAFB/BFYIVQey EcUOUQMBEMcy9wYABsMRxTMERhDJEtsR09sI7wn3Oxi/DjA1EcIMYM5jAFALCQFkMzYRUAumJCBG A2EgeQhhIHQycgDQayAYwAWhZCCCdgSQeSB3ZWwDIHBkb2N1B4ACMAmAIOsLgB4gaAQAIADAAxAL gARnICEAc3QsIEmyJx7gc2EfMB3hIBDwUR8AIGdvBHAgEOFu8mMHkXRvIrARMCByISC7BCAfoG4i oAMAI1BsHzDSaASQZS4RYGwggAhgrGdoIaAkYicFQGEJwp4gAiAmkB9xHeNvcAuAFmkCIAQgKBjA YWQ6SCBPcAnwSUQhkE/UQXUggCkhkHMDcBEwfwdzKcIkghDwI3MHcAtQZbMf4iP2KnclMCcRbh7g tiolwAfgcyUwI/NrBCD+aQVAIKEFECXwBUAD8CWy/QVAcAbwLgAN4AdAIwAoEdseMQuAdCNzAMBr IqADkXMrUQDQdC4KogqECoBBnwGAEyEnMipmBaB1bB7g/y2TJpAG4C8SIgAhEiIyAhDrBcAd43cF sGslcQVAK4DzKvAmgSBiLgEEYBjAIHF3A5E28CCQcC9ALLM28G1PBAEhEgNQJtF0LS1QaVcAIDG7 McQtO0JVERBw+HJcJxDQISAhABDgIqD6TgDQaAUQEOA5oDtCMcQ+VgIgKKAnwAnwAJBtLVkBAHYt NHEjQkAhUnPsLmIEkCEAbz+wAQArQV0RYHUBgB5AITB2JwFDzwUQIXALgDbwVmkBADng3TbwTD4x ELAx00cHkAnwBQEAdCigTWkgMDMQLjA2LgHQMDkg4DIxOjM3MiU+DD9vvTHEQhEwGMABICigWyjC RT51XSiwR1BYLLNJsEVURi0hEiQFWw6yrl0xxArjCoBJAwBmJ+H+dB8wQ1E3MTEBHvQkwi8weQUQ dmEOsEzRBBAmoGW/IZAscDxRIZA/0C+gdREgfS3ydyrxS4VN1SGSHcBu/m8FQCLAShMjoDVxUAAe 0f0lNEIvESCAIqAG4AJAHbH7IQEm4WY4AVAnTYNOVTOV90+SKcIvMHUCYA3gH5AEAO8fwDjxAiAl cEUEEB/xBzHfJQFL8EwlS4UgoXMl4CPA/0GiSjJOEB9BN0EikSOQUoJPBCAjwVqVIqBIeSjQcv8J wEIQNfMgQSORS4VTcknCvyGQIIADYCXiIIMkkHclAf8FAChwIBJJMzYCIRIJwAhg+nAxu1AEkCnA QdBYwSGR/zP1IIMgoScyO8ArkE4QCHD/JWFJyVzaVLhk5zVjV4ABIP8lQSvBKGFjESNxN7JJx0kx +y4iZOlULWFLhWZrUYIoYf9YwihiHzA1ck3RTOEqAlZw/1iBAyBbMSJzU3Jr7hTgIFH/C1EjUE7B LtEt8SpBBZAIcf9MYQRiAyAjkTvAUZAFkAVA/0+RERA5QR2xS4UAwDxBKAD/T5Ah4AdwM8BOEAWw P7Bqdv9tJW4PT0dRgCbxcCcq4hEg+yyRLgF5ETAhkFsBNpRRgv8AcG2zYxICYGBRA3ArcU4h/ytX ThAoAVA2VHEuADG7a6L/LmQkAyOCH6BjhyGQIKFSIv854DbBInN9fAQgVHFLhVOxvyYAaoIswly7 cUMowlMHcP92kSNBWtRkQnF4M4EDkUuF/zLjOXItYT5xAxAKwC9xB5H/LMJohiNRewGFQh8hI5Eh cPMswQsRaXpv64o1LzAIkP8jUSVzBJF+AR8AY2KIlYxV/12TI5AjwSUxW6d+ZiSROQL/K4Bd0gSQ J8Bzox+wBvBPMX8vESXAJJAhcFjSY7dOECf/bQRRx3mnODAJ8CmhK1IfMP9PVpGSQGEqQTFxaCQD gR8wWihRgmpPkAVAMpSEM9Mm8AXANCkxylda8iYg/1owO7Bz8gPwH3GXpIHjWvL/hP9dRJ3UIpGN xj7ABJAvsf+OtFrUCsAioB8DdhAQ4CBC7HN5I0Bx5XN1UR+BETD/IOGelYkGN3Foh4v1LIJTcf8f MaB3NvBosAfgbWUrURhhvwBwLyGiBF43ooVaMGKMwv9YlWiHa4IkIyEAMPEvQFqD7i8YwB4wCJB2 IRKJBiPA7TBkL3STGMBnKAIhkDVy/Q7AYStiiHMHQHdkL+EfAR8jwDPhI6BPkK6pUkVT/FQ7IEEf AF3xHyEA0CNR/4vhsa+yuy+gCrA3EC9hWXdYVVJMi+ERMGMlcFP/pItaMKNhKvItYTVxZRFUYv9T co0AAZAm8lNyA/A3caWv/6azlKJa4x+gB5AmYm1lZRH/MqOtQQIgITAq8bVyJrOqau9TcghQIAEC MC1MYCjQiLP/P9BMgSPhgQFolyQEfy+Alf9a853Sw1Krf2jEnoOZUlow/1RTiQYpYQWwTFEooCxw WwH/fOIkgSvBKuLKJ4DkysNlcf+GcWqRsEW8qkGhH3FTcpTy/x+RIRKvUx4iAIBosYvhmRP/NXF9 VDTjNvAeMJryS4UYwPd2MX4iP9B0H1B6cpOSMYH/YYRCEJ6VdhA2wcNRWnF8kf8EACUwIDNWw1Tm AiDCsAWQPmgkwS+xA4EkkAXAKGn+LiVhU3IekUIwrpOwRNKk/56VjYpDYdqJbPUhcG1xZebfdDKW MUIRWIFMYCnNQ3AP/11RewHQbNQH2DPSwtqIZIHvpiIkgn44U3JjIQArsgCQ/wEAKaLbmN9GuyZ0 MoizB0D9UAB54mJQNh8BTBEJgNFFz2zk3Re8BDjQZGSTUdTl+9PjEPBsVIBUcXvxJIExu/5TgTGV 9evzC3GLOXsBdHH/CsEq8SYgPxAEgYzDSSLE/79wuofYXzc28HOxVHAt9gF/L+EjUAUxlAPCw0uF 5cUo9kddUQSQKThlM6ErcVRi+6R0lKRyBRACYCrCHmCH0/+Gl0uFaoODHSZEDsAhYXrE/wWxp5Oi snuzTgCKYfrisvP/UDZO48imIfAHgGVxY7clQf+WMTbwGFC7E5EFzMI/0NGz/1sxIsCI9yzRc7Gt sTEC58X/ZHIqQYzVxOxTMmOiJdKdAf0hwWJBgEokZIBh8Gg1V6j+TSIA6VGEsRMhKNAnwJNR/7y4 JmMHsjzhuxE30GFGgw6v8YOxMDG7QXNhMcpfEv//FA8U2vxVPkggyxXvRl95tUG/sHBzOi8vP34v 3yDS2REas0HAaEAvPjkxygJ9HmAAHgA1EAEAAAA8AAAAPDcyQzFDOUU1NzgwQTEzNEY4OTY1MzBE NDgwRjIyQkI3MDIxNDJCM0FAaGVybWVzLmJpdGxhYi5kZT4AHgA5EAEAAAAzAAAAPEQ4RThFMzE2 LTJCRjAtNENFNS1CRjVGLTE0OEE5MUJEQjY4MUBpY3MudWNpLmVkdT4AAB4ARxABAAAADwAAAG1l c3NhZ2UvcmZjODIyAAALAPIQAQAAAB8A8xABAAAAcAAAAEEAVwAlADMAQQAgAFsATwBwAGUAbgBz AGkAbQAtAGQAZQB2AF0AIABPAEcAUABYACAAYQBuAGQAIABJAEUAVABGAC0AaQBuAGcAIAB0AGgA aQBuAGcAcwAgAFsAdABlAHgAdABdAC4ARQBNAEwAAAALAPYQAAAAAEAABzATp2R2iOTJAUAACDDy eRyDiOTJAQMA3j+vbwAAAwDxPwcEAAAeAPg/AQAAAAwAAABEaXJrIEtyYXVzZQACAfk/AQAAAEcA AAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089QklUTEFCL09VPUJJVExBQi9DTj1SRUNJ UElFTlRTL0NOPURJUktLAAAeAPo/AQAAABUAAABTeXN0ZW0gQWRtaW5pc3RyYXRvcgAAAAACAfs/ AQAAAB4AAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAALgAAAAMA/T/kBAAAAwAZQAAAAAAD ABpAAAAAAAMAHUAAAAAAAwAeQAAAAAAeADBAAQAAAAYAAABESVJLSwAAAB4AMUABAAAABgAAAERJ UktLAAAAHgAyQAEAAAAlAAAAb3BlbnNpbS1kZXYtYm91bmNlc0BsaXN0cy5iZXJsaW9zLmRlAAAA AB4AM0ABAAAAEgAAAGxvcGVzQGljcy51Y2kuZWR1AAAAHgA4QAEAAAAGAAAARElSS0sAAAAeADlA AQAAAAIAAAAuAAAAAwB2QP////8LACkAAAAAAAsAIwAAAAAAAwAGEKBtVGgDAAcQowsAAAMAEBAA AAAAAwAREAAAAAAeAAgQAQAAAGUAAABGUk9NWU9VUlRSQUNLUkVDT1JEVkVSWVdFTExET0NVTUVO VEVESU5USElTTUFJTElOR0xJU1QsSURTQVlZT1VIQVZFR09PRENIQU5DRVNUT0dFVFRISU5HU0RP TkVOSUNFTFlIAAAAAAIBfwABAAAAPAAAADw3MkMxQzlFNTc4MEExMzRGODk2NTMwRDQ4MEYyMkJC NzAyMTQyQjNBQGhlcm1lcy5iaXRsYWIuZGU+APxM ------_=_NextPart_001_01C9E488.83096C2A-- From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: /// /// Inventory Item Types, eg Script, Notecard, Folder, etc /// public enum InventoryType : sbyte { /// Unknown Unknown = -1, /// Texture Texture = 0, /// Sound Sound = 1, /// Calling Card CallingCard = 2, /// Landmark Landmark = 3, /* /// Script //[Obsolete("See LSL")] Script = 4, /// Clothing //[Obsolete("See Wearable")] Clothing = 5, /// Object, both single and coalesced */ Object = 6, /// Notecard Notecard = 7, /// Category = 8, /// Folder Folder = 8, /// RootCategory = 9, /// an LSL Script LSL = 10, /* /// //[Obsolete("See LSL")] LSLBytecode = 11, /// //[Obsolete("See Texture")] TextureTGA = 12, /// //[Obsolete] Bodypart = 13, /// //[Obsolete] Trash = 14, */ /// Snapshot = 15, /* /// //[Obsolete] LostAndFound = 16, */ /// Attachment = 17, /// Wearable = 18, /// Animation = 19, /// Gesture = 20 } On Wed, 15 Jul 2009 22:56:07 -0400, "Frisby, Adam" wrote: > Does anyone know what the values of InventoryItems.InvType represent? It's > an integer and represents the type of inventory; but I cant seem to find > any documentation (either in code, or externally) about what the integers > correlate to. > > Adam > -- Jim !DSPAM:370,4a5e9ed719051028312470! From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: inventory to me - we did until recently have some lost assets after SI = sessions due to asset server crashing - previously the code would = attempt to store assets with descriptions bigger than database field = length. This seemed to happen mostly with SI uploaded items but also was = 100% reproducible if you had a sim with a long name and a parcel with a = long name and attempted to create a landmark - there are checks now to = stop this from happening that Justin kindly committed (and he was good = enough to add similar checks for MySQL) and we've not had a crash since = applying that patch over a week and a half ago. In terms of actual = inventory, no-one has reported loss of specific items. Sometimes slow to = load, but not loss. Is this something that has happened since 0.6.6 tag? Chris -----Original Message----- From: opensim-dev-bounces at lists.berlios.de = [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Melanie Sent: 27 July 2009 14:32 To: opensim-dev at lists.berlios.de Subject: Re: [Opensim-dev] Inventory loss Those MySQL issues listed below and others like it are corner cases=20 that OpenSim would never trigger. OpenSim is a very simplistic=20 database user, it doesn't even really use any relational features of=20 the database. So, I don't think that MySQL errors are something we need to concern=20 ourselves with at this point. Especially, your suggestion would not=20 help in those cases, as they are all about complete loss of rows.=20 That is unaffected by a "deleted" type flag. That is neither here nor there anyway, since such a "deleted" flag=20 would have to live under OpenSim.Data.XXXX. It has no business being in core at all. Melanie Colin B. Withers wrote: > Reason I wondered is simply the number of websites dedicated to = recovering from MYSQL database corruption, and offering tools for the = same. Google returns over 250,000 sites for 'mysql database corruption'. >=20 > MYSQL has had numerous bug fixes to fix database corruption, = introduced by differing versions of MYSQL, eg >=20 > Fixed in 4.0.18 > INSERT DELAYED ... SELECT ... could cause table corruption because = tables were not locked properly. This is now fixed by ignoring DELAYED = in this context. (Bug #1983)=20 >=20 > Fixed in 4.0.16 > Fixed bug in overrun check for BLOB values with compressed tables. = This was a bug introduced in 4.0.14. It caused MySQL to regard some = correct tables containing BLOB values as corrupted. (Bug #770, Bug = #1304, and maybe Bug #1295)=20 >=20 > Fixed in 4.0.15 > Fixed rare bug in MYISAM introduced in 4.0.3 where the index file = header was not updated directly after an UPDATE of split dynamic rows. = The symptom was that the table had a corrupted delete-link if mysqld was = shut down or the table was checked directly after the update. >=20 > Fixed in 4.0.14 > Comparison/sorting for latin1_de character set was rewritten. The old = algorithm could not handle cases like "s=E4" < "=DFa". See section = 5.6.1.1 German character set. In rare cases, it resulted in table = corruption. >=20 > and so on.. >=20 > My own experience with Opensim is that in the last 12 months there has = been three occasions where residents complained of stuff 'missing' (not = a single resident, but several at once) and a roll-back to the last = database backup cured the problems. >=20 > Rock >=20 > -----Original Message----- > From: opensim-dev-bounces at lists.berlios.de = [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Melanie > Sent: Monday, July 27, 2009 2:07 PM > To: opensim-dev at lists.berlios.de > Subject: Re: [Opensim-dev] Inventory loss >=20 > IMHO, inventory loss due to MySQL errors and/or corruption are below=20 > the radar. > Any losses would occur in OpenSim code, I believe. >=20 > Melanie >=20 > Colin B. Withers wrote: >> I wonder what proportion of inventory items that go astray are the = result of the success/failure of an operation, or are due to database = corruption issues. >>=20 >> Rock >>=20 >> -----Original Message----- >> From: opensim-dev-bounces at lists.berlios.de = [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Melanie >> Sent: Monday, July 27, 2009 12:30 PM >> To: opensim-dev at lists.berlios.de >> Subject: Re: [Opensim-dev] Inventory loss >>=20 >> There is a question here of why inventory loss occurs at all. At=20 >> what stage do we actually lose (as opposed to failing to bump the=20 >> folder serial) inventory items at all, and why? >>=20 >> While a "deleted" flag and an undelete function do make an admin's=20 >> life easier, I believe the real focus should be on the inventory=20 >> code. It will be redesigned anyway and once that happens, I think a=20 >> strong focus needs to be placed on data integrity preservation. >>=20 >> That would then mae the undelete functionality largely unnecessary.=20 >> Current inventory code often doesn't check for success of an=20 >> operation at all. That needs to be revisited. >>=20 >> Melanie >>=20 >> Thomas Grimshaw wrote: >>> Hey folks. >>>=20 >>> Been thinking a lot about inventory loss in OpenSim, something that = I=20 >>> think we should really do as much as possible to avoid. We've been=20 >>> experiencing numerous cases of lost inventory in K-Grid recently. >>>=20 >>> What i'd like to implement, is.. >>>=20 >>> When an item is removed from inventory (deleted, or rezzed if it's=20 >>> no-copy), it is not actually deleted by instead an "available" flag = is=20 >>> set in the inventory database. >>> All inventory queries will check for the flag and thus it will = appear as=20 >>> deleted to the user, but it can be restored easily by an admin if=20 >>> needed. A timestamp should also be set which indicates when the = item=20 >>> was made unavailable, so that routine cleanup can be performed on = items=20 >>> which were made unavailable a long time ago. >>>=20 >>> I wanted to get people's opinons of this before I implemented it in=20 >>> code. Can anyone think of any drawbacks or possible issues? Any = further=20 >>> room for improvement? >>>=20 >>> Cheers >>>=20 >>> Thomas Grimshaw >>> (RemedyTomm) >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>=20 >>>=20 >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >>=20 >>=20 > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev >=20 >=20 _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev No virus found in this incoming message. Checked by AVG - www.avg.com=20 Version: 8.5.392 / Virus Database: 270.13.29/2261 - Release Date: = 07/27/09 05:58:00 From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: t inventory to me - we did until recently have some lost assets after SI se= ssions due to asset server crashing - previously the code would attempt to = store assets with descriptions bigger than database field length. This seem= ed to happen mostly with SI uploaded items but also was 100% reproducible i= f you had a sim with a long name and a parcel with a long name and attempte= d to create a landmark - there are checks now to stop this from happening t= hat Justin kindly committed (and he was good enough to add similar checks f= or MySQL) and we've not had a crash since applying that patch over a we= ek and a half ago. In terms of actual inventory, no-one has reported loss o= f specific items. Sometimes slow to load, but not loss.

Is this something that has happened since 0.6.6 tag?

Chris

-----Original Message-----
From: opensim-dev-b= ounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Mel= anie
Sent: 27 July 2009 14:32
To: opensim-dev at lists.berli= os.de
Subject: Re: [Opensim-dev] Inventory loss

Those MySQL issues listed below and others like it are corner cases
that OpenSim would never trigger. OpenSim is a very simplistic
database user, it doesn't even really use any relational features of the database.
So, I don't think that MySQL errors are something we need to concern ourselves with at this point. Especially, your suggestion would not
help in those cases, as they are all about complete loss of rows.
That is unaffected by a "deleted" type flag.

That is neither here nor there anyway, since such a "deleted" fla= g
would have to live under OpenSim.Data.XXXX.

It has no business being in core at all.

Melanie


Colin B. Withers wrote:
> Reason I wondered is simply the number of websites dedicated to recove= ring from MYSQL database corruption, and offering tools for the same. Googl= e returns over 250,000 sites for 'mysql database corruption'.
>
> MYSQL has had numerous bug fixes to fix database corruption, introduce= d by differing versions of MYSQL, eg
>
> Fixed in 4.0.18
> INSERT DELAYED ... SELECT ... could cause table corruption because tab= les were not locked properly. This is now fixed by ignoring DELAYED in this= context. (Bug #1983)
>
> Fixed in 4.0.16
> Fixed bug in overrun check for BLOB values with compressed tables. Thi= s was a bug introduced in 4.0.14. It caused MySQL to regard some correct ta= bles containing BLOB values as corrupted. (Bug #770, Bug #1304, and maybe B= ug #1295)
>
> Fixed in 4.0.15
> Fixed rare bug in MYISAM introduced in 4.0.3 where the index file head= er was not updated directly after an UPDATE of split dynamic rows. The symp= tom was that the table had a corrupted delete-link if mysqld was shut down = or the table was checked directly after the update.
>
> Fixed in 4.0.14
> Comparison/sorting for latin1_de character set was rewritten. The old = algorithm could not handle cases like "s=E4" < "=DFa"= ;. See section 5.6.1.1 German character set. In rare cases, it resulted in = table corruption.
>
> and so on..
>
> My own experience with Opensim is that in the last 12 months there has= been three occasions where residents complained of stuff 'missing'= (not a single resident, but several at once) and a roll-back to the last d= atabase backup cured the problems.
>
> Rock
>
> -----Original Message-----
> From: opensim-= dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf O= f Melanie
> Sent: Monday, July 27, 2009 2:07 PM
> To: opensim-dev at lists.= berlios.de
> Subject: Re: [Opensim-dev] Inventory loss
>
> IMHO, inventory loss due to MySQL errors and/or corruption are below > the radar.
> Any losses would occur in OpenSim code, I believe.
>
> Melanie
>
> Colin B. Withers wrote:
>> I wonder what proportion of inventory items that go astray are the= result of the success/failure of an operation, or are due to database corr= uption issues.
>>
>> Rock
>>
>> -----Original Message-----
>> From: open= sim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Beha= lf Of Melanie
>> Sent: Monday, July 27, 2009 12:30 PM
>> To: opensim-dev at li= sts.berlios.de
>> Subject: Re: [Opensim-dev] Inventory loss
>>
>> There is a question here of why inventory loss occurs at all. At >> what stage do we actually lose (as opposed to failing to bump the<= br> >> folder serial) inventory items at all, and why?
>>
>> While a "deleted" flag and an undelete function do make = an admin's
>> life easier, I believe the real focus should be on the inventory >> code. It will be redesigned anyway and once that happens, I think = a
>> strong focus needs to be placed on data integrity preservation. >>
>> That would then mae the undelete functionality largely unnecessary= .
>> Current inventory code often doesn't check for success of an >> operation at all. That needs to be revisited.
>>
>> Melanie
>>
>> Thomas Grimshaw wrote:
>>> Hey folks.
>>>
>>> Been thinking a lot about inventory loss in OpenSim, something= that I
>>> think we should really do as much as possible to avoid. We'= ;ve been
>>> experiencing numerous cases of lost inventory in K-Grid recent= ly.
>>>
>>> What i'd like to implement, is..
>>>
>>> When an item is removed from inventory (deleted, or rezzed if = it's
>>> no-copy), it is not actually deleted by instead an "avail= able" flag is
>>> set in the inventory database.
>>> All inventory queries will check for the flag and thus it will= appear as
>>> deleted to the user, but it can be restored easily by an admin= if
>>> needed. =A0A timestamp should also be set which indicates when= the item
>>> was made unavailable, so that routine cleanup can be performed= on items
>>> which were made unavailable a long time ago.
>>>
>>> I wanted to get people's opinons of this before I implemen= ted it in
>>> code. Can anyone think of any drawbacks or possible issues? An= y further
>>> room for improvement?
>>>
>>> Cheers
>>>
>>> Thomas Grimshaw
>>> (RemedyTomm)
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at li= sts.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev=
>>>
>>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.= berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev=
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.= berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev=
>>
>>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berl= ios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berl= ios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>

_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.d= e
https://lists.berlios.de/mailman/listinfo/opensim-dev

No virus found in this incoming message.
Checked by AVG - www.avg.c= om
Version: 8.5.392 / Virus Database: 270.13.29/2261 - Release Date: 07/27/09 = 05:58:00
_________________________________________= ______
Opensim-dev mailing list
Opensim-dev at lists.berlios.d= e
https://lists.berlios.de/mailman/listinfo/opensim-dev



--
Michael Emo= ry Cerquoni - Nebadon Izumi @ http://osgrid.o= rg
--000e0cd47e38287f0e046fbd7b42-- From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: ventory to me - we did until recently have some lost assets after SI sessio= ns due to asset server crashing - previously the code would attempt to stor= e assets with descriptions bigger than database field length. This seemed t= o happen mostly with SI uploaded items but also was 100% reproducible if yo= u had a sim with a long name and a parcel with a long name and attempted to= create a landmark - there are checks now to stop this from happening that = Justin kindly committed (and he was good enough to add similar checks for M= ySQL) and we've not had a crash since applying that patch over a week and a= half ago. In terms of actual inventory, no-one has reported loss of specif= ic items. Sometimes slow to load, but not loss. Is this something that has happened since 0.6.6 tag? Chris -----Original Message----- From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Melanie Sent: 27 July 2009 14:32 To: opensim-dev at lists.berlios.de Subject: Re: [Opensim-dev] Inventory loss Those MySQL issues listed below and others like it are corner cases that OpenSim would never trigger. OpenSim is a very simplistic database user, it doesn't even really use any relational features of the database. So, I don't think that MySQL errors are something we need to concern ourselves with at this point. Especially, your suggestion would not help in those cases, as they are all about complete loss of rows. That is unaffected by a "deleted" type flag. That is neither here nor there anyway, since such a "deleted" flag would have to live under OpenSim.Data.XXXX. It has no business being in core at all. Melanie Colin B. Withers wrote: > Reason I wondered is simply the number of websites dedicated to recoverin= g from MYSQL database corruption, and offering tools for the same. Google r= eturns over 250,000 sites for 'mysql database corruption'. > > MYSQL has had numerous bug fixes to fix database corruption, introduced b= y differing versions of MYSQL, eg > > Fixed in 4.0.18 > INSERT DELAYED ... SELECT ... could cause table corruption because tables= were not locked properly. This is now fixed by ignoring DELAYED in this co= ntext. (Bug #1983) > > Fixed in 4.0.16 > Fixed bug in overrun check for BLOB values with compressed tables. This w= as a bug introduced in 4.0.14. It caused MySQL to regard some correct table= s containing BLOB values as corrupted. (Bug #770, Bug #1304, and maybe Bug = #1295) > > Fixed in 4.0.15 > Fixed rare bug in MYISAM introduced in 4.0.3 where the index file header = was not updated directly after an UPDATE of split dynamic rows. The symptom= was that the table had a corrupted delete-link if mysqld was shut down or = the table was checked directly after the update. > > Fixed in 4.0.14 > Comparison/sorting for latin1_de character set was rewritten. The old alg= orithm could not handle cases like "s=E4" < "=DFa". See section 5.6.1.1 Ger= man character set. In rare cases, it resulted in table corruption. > > and so on.. > > My own experience with Opensim is that in the last 12 months there has be= en three occasions where residents complained of stuff 'missing' (not a sin= gle resident, but several at once) and a roll-back to the last database bac= kup cured the problems. > > Rock > > -----Original Message----- > From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Melanie > Sent: Monday, July 27, 2009 2:07 PM > To: opensim-dev at lists.berlios.de > Subject: Re: [Opensim-dev] Inventory loss > > IMHO, inventory loss due to MySQL errors and/or corruption are below > the radar. > Any losses would occur in OpenSim code, I believe. > > Melanie > > Colin B. Withers wrote: >> I wonder what proportion of inventory items that go astray are the resul= t of the success/failure of an operation, or are due to database corruption= issues. >> >> Rock >> >> -----Original Message----- >> From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Melanie >> Sent: Monday, July 27, 2009 12:30 PM >> To: opensim-dev at lists.berlios.de >> Subject: Re: [Opensim-dev] Inventory loss >> >> There is a question here of why inventory loss occurs at all. At >> what stage do we actually lose (as opposed to failing to bump the >> folder serial) inventory items at all, and why? >> >> While a "deleted" flag and an undelete function do make an admin's >> life easier, I believe the real focus should be on the inventory >> code. It will be redesigned anyway and once that happens, I think a >> strong focus needs to be placed on data integrity preservation. >> >> That would then mae the undelete functionality largely unnecessary. >> Current inventory code often doesn't check for success of an >> operation at all. That needs to be revisited. >> >> Melanie >> >> Thomas Grimshaw wrote: >>> Hey folks. >>> >>> Been thinking a lot about inventory loss in OpenSim, something that I >>> think we should really do as much as possible to avoid. We've been >>> experiencing numerous cases of lost inventory in K-Grid recently. >>> >>> What i'd like to implement, is.. >>> >>> When an item is removed from inventory (deleted, or rezzed if it's >>> no-copy), it is not actually deleted by instead an "available" flag is >>> set in the inventory database. >>> All inventory queries will check for the flag and thus it will appear a= s >>> deleted to the user, but it can be restored easily by an admin if >>> needed. A timestamp should also be set which indicates when the item >>> was made unavailable, so that routine cleanup can be performed on items >>> which were made unavailable a long time ago. >>> >>> I wanted to get people's opinons of this before I implemented it in >>> code. Can anyone think of any drawbacks or possible issues? Any further >>> room for improvement? >>> >>> Cheers >>> >>> Thomas Grimshaw >>> (RemedyTomm) >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.392 / Virus Database: 270.13.29/2261 - Release Date: 07/27/09 = 05:58:00 _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- Michael Emory Cerquoni - Nebadon Izumi @ http://osgrid.org --_000_63FAD4F222230A4EA79DE9E8BE664735340F0360winxbeus19excha_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

It’s worth also noting the clientside inventory skelet= on can get corrupted – clearing cache will often restore supposedly missing inve= ntory.

 

Adam

 

From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Nebadon I= zumi
Sent: Monday, 27 July 2009 10:39 PM
To: opensim-dev at lists.berlios.de
Subject: Re: [Opensim-dev] Inventory loss

 

I don't recall OSgrid r= eally getting many complaints about it either, infact i do not recall any, I am n= ot saying its never occured, but its so minimal its not something i ever remem= ber occuring, even when our whole asset table corrupted, we were able to get 10= 0% recovery, i think we lost 1 asset. We run on MySQL, but run fragstore for b= lob storage, any grids still storing blobs inside the database is going to be i= n major trouble if they don't switch, storing blobs inside of any of the currently available database systems OpenSim's core is really a terrible id= ea and should not be done for anything that is considered a production level t= ype grid.

Neb

On Mon, Jul 27, 2009 at 6:39 AM, Chris Hart <Chris at codetorque.co.uk> wrote= :

From MSSQL side of the grid fence, I haven't had anyon= e complain of lost inventory to me - we did until recently have some lost ass= ets after SI sessions due to asset server crashing - previously the code would attempt to store assets with descriptions bigger than database field length= . This seemed to happen mostly with SI uploaded items but also was 100% reproducible if you had a sim with a long name and a parcel with a long nam= e and attempted to create a landmark - there are checks now to stop this from happening that Justin kindly committed (and he was good enough to add simil= ar checks for MySQL) and we've not had a crash since applying that patch over = a week and a half ago. In terms of actual inventory, no-one has reported loss= of specific items. Sometimes slow to load, but not loss.

Is this something that has happened since 0.6.6 tag?

Chris


-----Original Message-----
From: opensim-dev-b= ounces at lists.berlios.de [mailto:opensim-dev= -bounces at lists.berlios.de] On Behalf Of Melanie

Sent: 27 July 2009 14:3= 2
To: opensim-dev at lists.berli= os.de
Subject: Re: [Opensim-dev] Inventory loss

Those MySQL issues listed below and others like it are corner cases
that OpenSim would never trigger. OpenSim is a very simplistic
database user, it doesn't even really use any relational features of
the database.
So, I don't think that MySQL errors are something we need to concern
ourselves with at this point. Especially, your suggestion would not
help in those cases, as they are all about complete loss of rows.
That is unaffected by a "deleted" type flag.

That is neither here nor there anyway, since such a "deleted" fla= g
would have to live under OpenSim.Data.XXXX.

It has no business being in core at all.

Melanie


Colin B. Withers wrote:
> Reason I wondered is simply the number of websites dedicated to recove= ring from MYSQL database corruption, and offering tools for the same. Google ret= urns over 250,000 sites for 'mysql database corruption'.
>
> MYSQL has had numerous bug fixes to fix database corruption, introduce= d by differing versions of MYSQL, eg
>
> Fixed in 4.0.18
> INSERT DELAYED ... SELECT ... could cause table corruption because tab= les were not locked properly. This is now fixed by ignoring DELAYED in this context. (Bug #1983)
>
> Fixed in 4.0.16
> Fixed bug in overrun check for BLOB values with compressed tables. Thi= s was a bug introduced in 4.0.14. It caused MySQL to regard some correct tabl= es containing BLOB values as corrupted. (Bug #770, Bug #1304, and maybe Bug #1= 295)
>
> Fixed in 4.0.15
> Fixed rare bug in MYISAM introduced in 4.0.3 where the index file head= er was not updated directly after an UPDATE of split dynamic rows. The symptom= was that the table had a corrupted delete-link if mysqld was shut down or the t= able was checked directly after the update.
>
> Fixed in 4.0.14
> Comparison/sorting for latin1_de character set was rewritten. The old algorithm could not handle cases like "s=E4" < "=DFa"= ;. See section 5.6.1.1 German character set. In rare cases, it resulted in table corruption.
>
> and so on..
>
> My own experience with Opensim is that in the last 12 months there has been three occasions where residents complained of stuff 'missing' (not a single resident, but several at once) and a roll-back to the last database backup cured the problems.
>
> Rock
>
> -----Original Message-----
> From: opensim-= dev-bounces at lists.berlios.de [mailto:opensim-dev= -bounces at lists.berlios.de] On Behalf Of Melanie
> Sent: Monday, July 27, 2009 2:07 PM
> To: opensim-dev at lists.= berlios.de
> Subject: Re: [Opensim-dev] Inventory loss
>
> IMHO, inventory loss due to MySQL errors and/or corruption are below > the radar.
> Any losses would occur in OpenSim code, I believe.
>
> Melanie
>
> Colin B. Withers wrote:
>> I wonder what proportion of inventory items that go astray are the result of the success/failure of an operation, or are due to database corruption issues.
>>
>> Rock
>>
>> -----Original Message-----
>> From: open= sim-dev-bounces at lists.berlios.de [mailto:opensim-dev= -bounces at lists.berlios.de] On Behalf Of Melanie
>> Sent: Monday, July 27, 2009 12:30 PM
>> To: opensim-dev at li= sts.berlios.de
>> Subject: Re: [Opensim-dev] Inventory loss
>>
>> There is a question here of why inventory loss occurs at all. At >> what stage do we actually lose (as opposed to failing to bump the<= br> >> folder serial) inventory items at all, and why?
>>
>> While a "deleted" flag and an undelete function do make = an admin's
>> life easier, I believe the real focus should be on the inventory >> code. It will be redesigned anyway and once that happens, I think = a
>> strong focus needs to be placed on data integrity preservation. >>
>> That would then mae the undelete functionality largely unnecessary= .
>> Current inventory code often doesn't check for success of an
>> operation at all. That needs to be revisited.
>>
>> Melanie
>>
>> Thomas Grimshaw wrote:
>>> Hey folks.
>>>
>>> Been thinking a lot about inventory loss in OpenSim, something that I
>>> think we should really do as much as possible to avoid. We've = been
>>> experiencing numerous cases of lost inventory in K-Grid recent= ly.
>>>
>>> What i'd like to implement, is..
>>>
>>> When an item is removed from inventory (deleted, or rezzed if = it's
>>> no-copy), it is not actually deleted by instead an "available" flag is
>>> set in the inventory database.
>>> All inventory queries will check for the flag and thus it will appear as
>>> deleted to the user, but it can be restored easily by an admin= if
>>> needed.  A timestamp should also be set which indicates w= hen the item
>>> was made unavailable, so that routine cleanup can be performed= on items
>>> which were made unavailable a long time ago.
>>>
>>> I wanted to get people's opinons of this before I implemented = it in
>>> code. Can anyone think of any drawbacks or possible issues? An= y further
>>> room for improvement?
>>>
>>> Cheers
>>>
>>> Thomas Grimshaw
>>> (RemedyTomm)
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at li= sts.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev=
>>>
>>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.= berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev=
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.= berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev=
>>
>>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berl= ios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev=
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berl= ios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev=
>
>

_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.d= e
https://lists.berlios.de/mailman/listinfo/opensim-dev

No virus found in this incoming message.
Checked by AVG - www.avg.c= om
Version: 8.5.392 / Virus Database: 270.13.29/2261 - Release Date: 07/27/09 05:58:00

_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.d= e
https://lists.berlios.de/mailman/listinfo/opensim-dev




--
Michael Emory Cerquoni - Nebadon Izumi @ http= ://osgrid.org

--_000_63FAD4F222230A4EA79DE9E8BE664735340F0360winxbeus19excha_-- From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: undreds of threads severely limits scaling the number of concurrent clients= . UDP packets all come in on a single port and are put into incoming queues= for each client view. The client view UPD threads (1 per client) then dequ= eue that packet and make the appropriate calls into scene. When the scene h= as updates, it puts them into the outbound queue for every client view and = finally the client view thread comes around and sends the packets out to cl= ients. Inbound processing on the scene happens on the individual client vie= w thread, but often this work is small and most of the time is spent switch= ing threads in and out.=20 I tested a change where I eliminated the outbound queue and had the main th= read call directly into the send packet routing. As the number of active ag= ents increases, outbound traffic grows exponentially compared to inbound. T= his change alone allowed me to scale the number of active viewers on a sing= le region using TestClient up to more than 200. I also tried eliminating th= e inbound queues and instead making the calls to scene directly. This behav= ior, as Tom pointed out, causes a single client to stop up the entire packe= t processing thread when a complex operation comes along.=20 I think that it would be ideal, as I believe Mojito described, if there wer= e a small number of threads handling outbound client packet sending and the= y blocked on their packet queue to get work. For inbound traffic, simple op= erations should be called directly on the scene and the more complex operat= ions put into a queue for a set of slower processing threads. Having 300 th= reads (1 per client) is too many, but 1 was not enough. We could certainly = start with 1 thread for outbound UDP for all clients and grow as the number= of clients grows. Something on the order of 1 outbound thread per 50 clien= ts and 1 inbound thread per 5 or 10 clients would be about ideal in my esti= mation.=20 Dan lake Software Engineer Visual Applications Research Intel Labs -----Original Message----- From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at list= s.berlios.de] On Behalf Of Mojito Sorbet Sent: Friday, July 31, 2009 9:05 AM To: opensim-dev at lists.berlios.de Subject: Re: [Opensim-dev] Threads, threads, threads and more threads If it was me starting from scratch (and I do have experience building fast servers that handle hundreds of simultaneous client connections in limited resources), I would have one thread per blocking resource, driven by work queues. What the viewer might see as a single operation turns into a "workflow" along a series of these queues, each thread doing its part like an assembly line. The only thing that blocks is a hardware interface. So for example, there only needs to be one listening thread per UDP port, not one per viewer. A network interface can only deliver one packet at a time. The sending IP address on the packet keys you to the correct user context to match it up with. A disk interface on the other hand works better with multiple requests outstanding at once, so that the kernel seek optimization has something to work on; you would have perhaps 5 threads to round-robin handle disk I/O. The per-user context is where you keep track of the state of all the things that the viewer is doing at once, rather than spreading this information all over the call stacks of threads. As soon as the processing of an input packet needs to do something that might block, the request is put on the input queue of another thread that handles the blocking operation. It takes a bit to get used to programming like this, but I can report that the performance results are quite amazing regarding scalability. It also reduces the need for locks, since it is mostly just the work queues that are touched by more than one thread. _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: Albert -------------------------------------------------------------------- 2009/9/4 Andr=E9 Filipe > Hello, > I wonder if someone can access the Sciencesim (Sciencesim.com) with > Hypergrid. I would ask for someone to test if can connect. I use this > feature a lot and I can not stay without it. > > Best Regards > > Andr=E9 Filipe > Federal University of ABC > Sao Paulo - Brazil > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > --00151744805e8a69480472c4f669 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: --------------------------------------------------------------

2009/9/4 Andr=E9 Filipe <andrefilipemb at gmail.com><= br>
= Hello,

=A0I wonder if someone can access the Sciencesim=A0(Sciencesim= .com)=A0with Hypergrid.=A0=A0I would ask for someone to test if can connect= . I use this feature a lot and I can not stay without it.=A0

Best Regards

<= div style=3D"margin-bottom: 0.2em;"> Andr=E9 Filipe
Federal University= of ABC
Sao Paulo - Brazil
<= /div>


_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.d= e
https://lists.berlios.de/mailman/listinfo/opensim-dev


--00151744805e8a69480472c4f669-- From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: far", instead, go to others grids (condensationland.com:9000, jamland.de:9300), works well. From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: , but we have an other, 213.172.38.61:900, with 0.6.6.3 version and from 0.6.= 6 vefsions and 0.6.3 versions, we can acces. Strange. A. 2009/9/4 > The viewer cannot jump longer that 4096 regions in either direction. > You can use the UCI Gateways that I set up for this purpose: > > ucigrid04.nacs.uci.edu:9003 (@3000,3000) > ucigrid04.nacs.uci.edu:9007 (@7000,7000) > > I think ScienceSim is located in the 10000's. > If you're in the lows, get yourself to ucigrid04.nacs.uci.edu:9007, and > try this on the map: peak.sciencesim.com:9001 > Not sure if that's still valid. > > > Gustavo Alberto Navarro Bilbao wrote: > > >From our server always says "too far" > > > > Albert > > > > -------------------------------------------------------------------- > > > > 2009/9/4 Andr=E9 Filipe > > > > > > Hello, > > > > I wonder if someone can access the Sciencesim (Sciencesim.com) wit= h > > Hypergrid. I would ask for someone to test if can connect. I use > > this feature a lot and I can not stay without it. > > > > Best Regards > > > > Andr=E9 Filipe > > Federal University of ABC > > Sao Paulo - Brazil > > > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > > > > > -----------------------------------------------------------------------= - > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > --00151747b69085ed260472c64465 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In our case, we have some services in our grid. 213.172.38.61:9300 (0.6.6 .10108 i v 5) is in 6000/6000 coor= denates, 213.172.39.61:9700 (0.6.= 6=A0=A0 .239a1 i v 5) is in OSGrid in 9997/10004 coordenates.
From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: to far", instead, go to others grids (condensationland.com:9000,=A0 jamland.de:9300), works well.

From outside our serveer, if we try to acces to our services, is imposs= ible, but we have an other, 213.172.38= .61:900, with 0.6.6.3 version and from 0.6.6 vefsions and 0.6.3 version= s, we can acces.

Strange.

A.

2009/9/4 <diva at metaverseink.co= m>
The viewer cannot jump longer that 4096 regions in either direction.
You can use the UCI Gateways that I set up for this purpose:

ucigrid04.= nacs.uci.edu:9003 =A0(@3000,3000)
ucigrid04.= nacs.uci.edu:9007 =A0(@7000,7000)

I think ScienceSim is located in the 10000's.
If you're in the lows, get yourself to ucigrid04.nacs.uci.edu:9007, and
try this on the map: peak.sciencesim.com:9001
Not sure if that's still valid.


Gustavo Alberto Navarro Bilbao wrote:
> =A0>From our server always says "too far"
>
> Albert
>
> -------------------------------------------------------------------- >
> 2009/9/4 Andr=E9 Filipe <andrefilipemb at gmail.com
> <mailto:andrefilip= emb at gmail.com>>
>
> =A0 =A0 Hello,
>
> =A0 =A0 =A0I wonder if someone can access the Sciencesim (Sciencesim.c= om) with
> =A0 =A0 Hypergrid. =A0I would ask for someone to test if can connect. = I use
> =A0 =A0 this feature a lot and I can not stay without it.
>
> =A0 =A0 Best Regards
>
> =A0 =A0 Andr=E9 Filipe
> =A0 =A0 Federal University of ABC
> =A0 =A0 Sao Paulo - Brazil
>
>
> =A0 =A0 _______________________________________________
> =A0 =A0 Opensim-dev mailing list
> =A0 =A0 Opensim-= dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
> =A0 =A0 https://lists.berlios.de/mailman/li= stinfo/opensim-dev
>
>
>
> ----------------------------------------------------------------= --------
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berl= ios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.d= e
https://lists.berlios.de/mailman/listinfo/opensim-dev

--00151747b69085ed260472c64465-- From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: correct? http://www.adamfrisby.com/blog/category/technical/idealist/ Adam, what is the status of Xenki? Is Xenki development now being abandoned? (now that "Rei" viewer is OpenSource?) With all these various OpenSource Viewers/Browsers out there, would it be possible to work on some form of cross-platform compatibility or "standardization" between the various viewers and the various server platforms (OpenSim Core, OpenSim + ModRex, and 3Di?) Mark On Wed, Sep 30, 2009 at 1:11 PM, Frisby, Adam wrote= : > TribalServer fell into disrepair I believe, but MW & LBSA donated their > unique features into a Forge project at least 6 months ago. (look for > =91Tribal=92 in the projects list). > > > > 3Di is just OpenSim + a support contract + some extra modules for the 3D > models and analytics. I believe 3Di runs fairly close to OpenSim releases= , > and they do donate code back to core which indicates they would have to b= e. > > > > RealXtend was probably the only really =91fork fork=92 where the goal was= to do > some things differently; but that got merged back last November, and now = you > can run ModRex with OpenSim-trunk. (although sometimes compatibility issu= es > with the module do appear on new features, eg megaregions) > > > > So, I don=92t think there are any major forks anymore =96 3Di would be it= if > anything, and they aren=92t that much of one. > > > > Adam > > > > *From:* opensim-dev-bounces at lists.berlios.de [mailto: > opensim-dev-bounces at lists.berlios.de] *On Behalf Of *Mark Malewski > *Sent:* Wednesday, 30 September 2009 11:05 AM > *To:* diva at metaverseink.com; Opensim-dev at lists.berlios.de > > *Subject:* Re: [Opensim-dev] [realXtend] Re: 3Di Viewer "Rei" goes open > source (BSD licensed in-browser viewer) > > > > Diva, > > > > There are/were quite a few forks floating around out there. > > *> What opensim forks are you talking about? I don't know of any, so * > > *> please point me to one.* > > > > http://3di-opensim.com/en/ > > > > You've never heard of 3Di OpenSim Enterprise? > > > > > http://virtualeconomicforum.com/content-library/blogging/about/3di_to_sel= l_opensim_server_software/ > > > > I can think of maybe 4 forks just off the top of my head. I believe > "Tribal Media Server" (or Tribal Net) and "3Di Server" and RealXtend/ModR= ex > were all forks based on the original OpenSim core? > > > > I understand that RealXtend came back from being a separate fork, and > RealXtend has now integrated their work back into OpenSim as a module > (ModRex). I believe Adam Frisby helped with converting RealXtend into a > "ModRex" module, but what about "3Di Server" and "Tribal Media Server"? = Are > those not separate OpenSim-based forks? > > > > I understand that each of these OpenSim-based Server "forks" uses differe= nt > technologies (realXtend/ModRex supports Ogre3D, and 3Di Server supports > Irrlicht, etc.) I'm not quite sure what Tribal Media Server is (but it > seems to have been OpenSim-based fork as well that seemed to have a nice > Admin Control panel). > > > > I believe "Tribal Server" or "Tribal Net" was the name of Tribal Media's > Server. I believe it was a fork off of the original OpenSim core as well= . > > > > > http://www.ugotrade.com/2008/05/14/tribal-media-changing-the-game-with-op= ensim/ > > > > I believe Tribal Media's Server (Tribal Server) had a really nice Admin > Control Panel, and an easy way to get Tribal Sim servers online. > > > > As for 3Di server, I believe it supports "Irrlicht" 3D rendering engine. > (ModRex/RealXtend support Ogre3d rendering engine). > > > > I don't know all the exact specifics as to each of the various different > server forks, but I know much of RealXtend's work has been integrated bac= k > into OpenSim (as a ModRex module), but 3Di and Tribal Media servers (as f= ar > as I know) are not OpenSource, and have not had their work put back into > OpenSim. > > > > I don't know all the specifics as to the exact differences between all th= e > various server forks, but it would be nice to create a wiki page, showing= a > nice comparison chart between Tribal Media Server, 3Di Enterprise Server, > ModRex, and the native OpenSim Core. > > > > Just so people can see what features each of the various servers (such as > 3Di Enterprise Server, or Tribal Media Server, or ModRex) has. They all > seem to be OpenSim-based. I understand RealXtend is now "ModRex" (as an > OpenSim module) but it used to be an OpenSim fork. > > > > It would just be nice to know what features are in 3Di Enterprise Server, > and Tribal Media Server. (and maybe see a nice comparison chart on the w= iki > page showing each of the features between each of the various OpenSim-bas= ed > servers). > > > > Ultimately, I'd really love to see some of the work from 3Di and Tribal > Media contributed back (as OpenSource) to the OpenSim Community (as open > source modules for the OpenSim core), just as RealXtend has done (with > ModRex). > > > > Mark > > > > > > On Wed, Sep 30, 2009 at 12:02 PM, wrote: > > What opensim forks are you talking about? I don't know of any, so please > point me to one. > > > > Mark Malewski wrote: > > */ > > > Adam, > > > > > /**/=85 then if we can get someone to adjust the full viewer, we=92d= have > /* > > */> somewhat of a standard on our hands./* > > > > See, now that's what I'm talking about! Me "likey" the idea of > > standards! ;-) > > > > I'd really like to see some form standardization, so that viewers can > > work on each of the various platforms. In a perfect world, I'd really > > like to see some of these technologies that 3Di and Tribal Media > > are/were working on, slowly come back to the OpenSim Community as > > OpenSource Modules (similar to the RealXtend/ModRex module). > > > > That way we just have ONE single OpenSim core distribution, and then > > have various modules (like "ModRex" or a "3Di" module, or a > > "Tribal_Media" module) that can be installed on top of OpenSim core? > > > > This would seem to make MUCH more sense, instead of all the various > > forks out there. I really do like the idea of "standardization", and > > would really like to see Modules created instead of completely differen= t > > OpenSim "forks". > > > > Then it would be great to see the Viewers designed so that all the > > various viewers will work with all the different platform modules > > (ModRex, 3Di, Tribal Media Server, etc.) > > > > Mark > > > > > > On Wed, Sep 30, 2009 at 11:07 AM, Frisby, Adam > > > wrote: > > > > It works with vanilla but from my understanding not ModRex; the > > meshes are handled as Irrlicht meshes if I understand correctly. > > Synchronising these mesh standards (in both rex & 3diov) might be a > > good idea methinks. > > > > > > > > =85 then if we can get someone to adjust the full viewer, we=92d ha= ve > > somewhat of a standard on our hands. > > > > > > > > Adam > > > > > > > > *From:* opensim-dev-bounces at lists.berlios.de > > > > [mailto:opensim-dev-bounces at lists.berlios.de > > ] *On Behalf Of *Mark > > Malewski > > *Sent:* Wednesday, 30 September 2009 9:02 AM > > *To:* realxtend at googlegroups.com > > > ; Opensim-dev at lists.berlios.de > > > > > *Subject:* Re: [Opensim-dev] [realXtend] Re: 3Di Viewer "Rei" goes > > open source (BSD licensed in-browser viewer) > > > > > > > > Nlin, > > > > > > > > Does the "Rei" Viewer work with the OpenSim + ModRex (RealXtend) as > > well? > > > > Could you please explain the differences between a plain vanilla > > OpenSim Server, a OpenSim + ModRex (realXtend) server, and a 3di > server? > > > > > > > > > > > > Thank-you for all that you do, > > > > > > > > Mark > > > > > > > > > > > > On Wed, Sep 30, 2009 at 8:36 AM, Anu Mishra > > > wrote: > > > > Nlin > > > > > > > > Do you know if this viewer works with Realxtend server as well? > > > > > > > > Anu > > > > > > > > On 9/30/09, *Mark Malewski* > > > wrote: > > > > RealXtend, > > > > > > > > > > Have any of the RealXtend core developer's had a chance to look > > at this OpenSource "Rei" viewer yet? > > > > > > > > > > It seems to be an OpenSource web-based viewer. It looks pretty > > cool. Would this OpenSource contribution help RealXtend's > > Viewer project in any way? Could this viewer be easily modifie= d > > to work with BOTH the stock OpenSim AND also work with RealXten= d > > & ModRex? > > > > > > > > > > Mark > > > > > > > > On Wed, Sep 30, 2009 at 2:07 AM, Mark Malewski > > > > > wrote: > > > > Nlin, > > > > > > > > > > Thank-you very much for the post, that seems like an excellent > > contribution to the OpenSim Community! > > > > > > > > > > I'm wondering what type of effect this might have on RealXtend'= s > > project development of a new viewer? > > > > > > > > > > Will this "Rei" viewer work with the latest stock OpenSim serve= r? > > > > > > > > > > Mark > > > > > > > > On Tue, Sep 29, 2009 at 8:24 PM, nlin > > > wrote: > > > > > > Hello, > > > > Today 3Di's in-browser viewer source code has been opened > > up, as the project 3Di Viewer "Rei". The license is BSD. > > Please have a look if you are interested! > > > > > Project home page: http://3di-rei.org > > > Press release: http://3di.jp/en/news/2009093001.html > > > > We're very interested in further development of this open > > source viewer with the community. Thanks to the > > IdealistViewer developers, as portions of Rei use source > > code from an early version of IdealistViewer. Rei uses no > > code from GPL-licensed viewers. > > > > The Rei source code is in git at github, with the main > > repository at: http://github.com/3di/3di-viewer-rei > > > > Thanks, > > -nlin > > > > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ > > > > > > http://groups.google.com/group/realxtend > > http://www.realxtend.org > > -~----------~----~----~----~------~----~------~--~--- > > > > > > > > > > _______________________________________________ > > Opensim-dev mailing list > > > Opensim-dev at lists.berlios.de > > > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > > > > > > -----------------------------------------------------------------------= - > > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > --001485f794ccd7a9630474d00e1a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Adam, thank-you for the response. =A0You seem to know quite well wh= at all the various groups are working on. =A0;-)


> So, I don=92t = think there are any major forks anymore=A0=96=A0

> 3D= i=A0would be it if anything, and they aren=92t that much of one.

=

Ok, this is good to know. =A0It wa= s hard keeping track of everything that was going on out there, and I still= wasn't exactly sure what 3Di was working on (or if it was getting cont= ributed back to OpenSim Core, or as a separate OpenSim module). =A0I did kn= ow they were working on an "OpenViewer" (which I'm guessing h= as been renamed to "Rei" viewer?) =A0I'm still not quite sure= as to all the specifics of 3Di Server's features.

It would just be nice to get everything integrated back into= core (or as OpenSim modules).

>TribalServer fell into disre= pair I believe, but MW & LBSA

> donated = their unique features into a Forge project at least 6 >months ago. (look= for =91Tribal=92 in the projects list).

I'll need to lo= ok around. =A0It really would be nice to try and get as many of these great= things/features updated and integrated into Core (or as OpenSim modules) I= 'm still not quite sure what features 3Di's Enterprise server has.<= /div>

Do we have any contacts over at 3Di that we can t= alk to? =A0Do they have any plans to "OpenSource" their work (and= modules)?

It would be good to have some form of &= quot;standardization" among the various groups, so that the Viewers/Br= owsers (Hippo, Naali, and Rei) will at least be cross-platform and support = OpenSim Core, RealXtend/ModRex, and 3Di.

From what I understand, the "Rei" Viewer is b= ased on the Idealist Viewer, correct?


Adam, what is the status of Xenki? =A0Is Xenki developm= ent now being abandoned? (now that "Rei" viewer is OpenSource?) = =A0

With all these various OpenSource Viewers/Brow= sers out there, would it be possible to work on some form of cross-platform= compatibility or "standardization" between the various viewers a= nd the various server platforms (OpenSim Core, OpenSim + ModRex, and 3Di?)<= /div>

=A0=A0 =A0 =A0 =A0 =A0 =A0Mark


On Wed, Sep 30, 2009 at 1:11 PM, Frisby, Ad= am <adam at deep= think.com.au> wrote:

TribalServer fell into di= srepair I believe, but MW & LBSA donated their unique features into a Forge project at least 6 months ago. (= look for =91Tribal=92 in the projects list).

=A0

3Di is just OpenSim + a s= upport contract + some extra modules for the 3D models and analytics. I believe 3Di runs fairly close to OpenSim releases, and they do donate code back to core which indicates they would h= ave to be.

=A0

RealXtend was probably th= e only really =91fork fork=92 where the goal was to do some things differently; but that got merged back last November, = and now you can run ModRex with OpenSim-trunk. (although sometimes compatibilit= y issues with the module do appear on new features, eg megaregions)

=A0

So, I don=92t think there= are any major forks anymore =96 3Di would be it if anything, and they aren=92t that much of one.

=A0

Adam

=A0

From: opensim-dev-bounces at lists.berlio= s.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Mark M= alewski
Sent: Wednesday, 30 September 2009 11:05 AM
To: diva@= metaverseink.com; Opensim-dev at lists.berlios.de


Subject: Re: [Opensim-dev] [realXtend] Re: 3Di Viewer "Rei"= ; goes open source (BSD licensed in-browser viewer)

=A0

Diva,

=A0

There are/were quite a few forks floating around out there.

>=A0What opensim forks are you talking about? I don't know of any, so=A0

> please=A0point me to one.

=A0

=A0

You've never heard of 3Di OpenSim Enterprise?

=A0

=A0

I can think of maybe 4 forks just off the top of my head. =A0I believe "Tribal Media Server" (or Tribal Net) and "3Di Server" and RealXtend/ModRex were all forks based on the original Open= Sim core?

=A0

I understand that RealXtend came back from being a separate fork, and RealXtend has now integrated their work back into OpenSim as a mo= dule (ModRex). =A0I believe Adam Frisby helped with converting RealXtend into a "ModRex" module, but what about "3Di Server" and "Tribal Media Server"? =A0Are those not separate OpenSim-based forks?=A0

=A0

I understand that each of these OpenSim-based Server "forks" uses different technologies (realXtend/ModRex supports Ogre3D, and 3Di Server supports Irrlicht, etc.) =A0I'm not quite sure w= hat Tribal Media Server is (but it seems to have been OpenSim-based fork as wel= l that seemed to have a nice Admin Control panel).

=A0

I believe "Tribal Server" or "Tribal Net" was the name of Tribal Media's Server. =A0I believe it was a = fork off of the original OpenSim core as well.

=A0

I believe Tribal Media's Server (Tribal Server) had a really nice Admin Control Panel, and an easy way to get Tribal Sim servers online.=

=A0

As for 3Di server, I believe it supports "Irrlicht" 3D rendering engine. =A0(ModRex/RealXtend support Ogre3d rendering engine).

=A0

I don't know all the exact specifics as to each of the various different server forks, but I know much of RealXtend's work has= been integrated back into OpenSim (as a ModRex module), but 3Di and Tribal Media servers (as far as I know) are not OpenSource, and have not had their work = put back into OpenSim.

=A0

I don't know all the specifics as to the exact differences between all the various server forks, but it would be nice to create a wiki page, showing a nice comparison chart between Tribal Media Server, 3Di Enterprise Server, ModRex, and the native OpenSim Core.

=A0

Just so people can see what features each of the various servers (such as 3Di Enterprise Server, or Tribal Media Server, or ModRex) = has. =A0They all seem to be OpenSim-based. =A0I understand RealXtend is now "ModRex" (as an OpenSim module) but it used to be an OpenSim fork= .

=A0

It would just be nice to know what features are in 3Di Enterprise Server, and Tribal Media Server. =A0(and maybe see a nice comparison chart on the wiki page showing each of the features between each= of the various OpenSim-based servers).

=A0

Ultimately, I'd really love to see some of the work from 3Di and Tribal Media contributed back (as OpenSource) to the OpenSim Community = (as open source modules for the OpenSim core), just as RealXtend has done (with ModRex).

=A0

=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 Mark

=A0

=A0

On Wed, Sep 30, 2009 at 12:02 PM, <diva at metaverseink.com> wrote:

What opensim forks are you talking about? I don't know of any, so please
point me to one.



Mark Malewski wrote:
> */

> Adam,
>
> =A0> /**/=85 then if we can get someone to adjust the full viewer, we=92d have /*
> */> somewhat of a standard on our hands./*
>
> See, now that's what I'm talking about! =A0Me "likey"= ; the idea of
> standards! =A0;-)
>
> I'd really like to see some form standardization, so that viewers = can
> work on each of the various platforms. =A0In a perfect world, I'd really
> like to see some of these technologies that 3Di and Tribal Media
> are/were working on, slowly come back to the OpenSim Community as
> OpenSource Modules (similar to the RealXtend/ModRex module).
>
> That way we just have ONE single OpenSim core distribution, and then > have various modules (like "ModRex" or a "3Di" mod= ule, or a
> "Tribal_Media" module) that can be installed on top of OpenS= im core?
>
> This would seem to make MUCH more sense, instead of all the various > forks out there. =A0I really do like the idea of "standardization", and
> would really like to see Modules created instead of completely differe= nt
> OpenSim "forks".
>
> Then it would be great to see the Viewers designed so that all the
> various viewers will work with all the different platform modules
> (ModRex, 3Di, Tribal Media Server, etc.)
>
> =A0 =A0 =A0 =A0 =A0 =A0 Mark
>
>
> On Wed, Sep 30, 2009 at 11:07 AM, Frisby, Adam <adam at deepthink.com.au

> <mailto:adam at deepthink.com.au>> wrote:
>
> =A0 =A0 It works with vanilla but from my understanding not ModRex; the
> =A0 =A0 meshes are handled as Irrlicht meshes if I understand correctly.
> =A0 =A0 Synchronising these mesh standards (in both rex & 3diov) might be a
> =A0 =A0 good idea methinks.
>
>
>
> =A0 =A0 =85 then if we can get someone to adjust the full viewer, we= =92d have
> =A0 =A0 somewhat of a standard on our hands.
>
>
>
> =A0 =A0 Adam
>
>
>
> =A0 =A0 *From:* opensim-dev-bounces at lists.berlios.de
> =A0 =A0 <mailto:opensim-dev-bounces at lists.berlios.de>
> =A0 =A0 [mailto:opensim-dev-bounces at lists.berlios.de
> =A0 =A0 <mailto:opensim-dev-bounces at lists.berlios.de>] *On Behalf Of *Mark
> =A0 =A0 Malewski
> =A0 =A0 *Sent:* Wednesday, 30 September 2009 9:02 AM
> =A0 =A0 *To:* realxtend at googlegroups.com

> =A0 =A0 <mailto:realxtend at googlegroups.com>; Opensim-dev at lists.berlios.de=
> =A0 =A0 <mailto:Opensim-dev at lists.berlios.de>

> =A0 =A0 *Subject:* Re: [Opensim-dev] [realXtend] Re: 3Di Viewer "Rei" goes
> =A0 =A0 open source (BSD licensed in-browser viewer)
>
>
>
> =A0 =A0 Nlin,
>
>
>
> =A0 =A0 Does the "Rei" Viewer work with the OpenSim + ModRex (RealXtend) as
> =A0 =A0 well?
>
> =A0 =A0 Could you please explain the differences between a plain vanilla
> =A0 =A0 OpenSim Server, a OpenSim + ModRex (realXtend) server, and a 3di server?
>
>
>
>
>
> =A0 =A0 =A0 =A0 =A0 Thank-you for all that you do,
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Mark
>
>
>
>
>
> =A0 =A0 On Wed, Sep 30, 2009 at 8:36 AM, Anu Mishra <anuranjanm at gmail.com

> =A0 =A0 <mailto:anuranjanm at gmail.com>> wrote:
>
> =A0 =A0 Nlin
>
>
>
> =A0 =A0 Do you know if this viewer works with Realxtend server as well?
>
>
>
> =A0 =A0 Anu
>
>
>
> =A0 =A0 On 9/30/09, *Mark Malewski* <mark.malewski at gmail.com

> =A0 =A0 <mailto:mark.malewski at gmail.com>> wrote:
>
> =A0 =A0 =A0 =A0 RealXtend,
>
>
>
>
> =A0 =A0 =A0 =A0 Have any of the RealXtend core developer's had a chance to look
> =A0 =A0 =A0 =A0 at this OpenSource "Rei" viewer yet?
>
>
>
>
> =A0 =A0 =A0 =A0 It seems to be an OpenSource web-based viewer. =A0It looks pretty
> =A0 =A0 =A0 =A0 cool. =A0Would this OpenSource contribution help RealXtend's
> =A0 =A0 =A0 =A0 Viewer project in any way? =A0Could this viewer be easily modified
> =A0 =A0 =A0 =A0 to work with BOTH the stock OpenSim AND also work with RealXtend
> =A0 =A0 =A0 =A0 & ModRex?
>
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Mark
>
>
>
> =A0 =A0 =A0 =A0 On Wed, Sep 30, 2009 at 2:07 AM, Mark Malewski

> =A0 =A0 =A0 =A0 <mark.malewski at gmail.com <mailto:mark.malewski at gmail.com>> wrote:
>
> =A0 =A0 =A0 =A0 Nlin,
>
>
>
>
> =A0 =A0 =A0 =A0 Thank-you very much for the post, that seems like an excellent
> =A0 =A0 =A0 =A0 contribution to the OpenSim Community!
>
>
>
>
> =A0 =A0 =A0 =A0 I'm wondering what type of effect this might have on RealXtend's
> =A0 =A0 =A0 =A0 project development of a new viewer?
>
>
>
>
> =A0 =A0 =A0 =A0 Will this "Rei" viewer work with the latest stock OpenSim server?
>
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Mark
>
>
>
> =A0 =A0 =A0 =A0 On Tue, Sep 29, 2009 at 8:24 PM, nlin <nlin.message at gmail.com<= /p>

> =A0 =A0 =A0 =A0 <mailto:nlin.message at gmail.com>> wrote:
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 Hello,
>
> =A0 =A0 =A0 =A0 =A0 =A0 Today 3Di's in-browser viewer source code has been opened
> =A0 =A0 =A0 =A0 =A0 =A0 up, as the project 3Di Viewer "Rei". The license is BSD.
> =A0 =A0 =A0 =A0 =A0 =A0 Please have a look if you are interested!
>

> =A0 =A0 =A0 =A0 =A0 =A0 Project home page: http://3di-rei.org <http://3di-rei.org= />

> =A0 =A0 =A0 =A0 =A0 =A0 Press release: http://3di.jp/en/news/2009093001.html
>
> =A0 =A0 =A0 =A0 =A0 =A0 We're very interested in further development of this open
> =A0 =A0 =A0 =A0 =A0 =A0 source viewer with the community. Thanks to the
> =A0 =A0 =A0 =A0 =A0 =A0 IdealistViewer developers, as portions of Rei use source
> =A0 =A0 =A0 =A0 =A0 =A0 code from an early version of IdealistViewer. Rei uses no
> =A0 =A0 =A0 =A0 =A0 =A0 code from GPL-licensed viewers.
>
> =A0 =A0 =A0 =A0 =A0 =A0 The Rei source code is in git at github, with the main
> =A0 =A0 =A0 =A0 =A0 =A0 repository at: http://github.com/3di/3di-viewer-rei
>
> =A0 =A0 =A0 =A0 =A0 =A0 Thanks,
> =A0 =A0 =A0 =A0 =A0 =A0 -nlin
>
>
>
>
>
>
>
> =A0 =A0 =A0 =A0 --~--~---------~--~----~------------~-------~--~----~<= br> >
>
> =A0 =A0 =A0 =A0 http://groups.google.com/group/realxtend
> =A0 =A0 =A0 =A0 http://www.realxtend.org
> =A0 =A0 =A0 =A0 -~----------~----~----~----~------~----~------~--~---<= br> >
>
>
>
> =A0 =A0 _______________________________________________
> =A0 =A0 Opensim-dev mailing list

> =A0 =A0 Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>

> ------------------------------------------------------------------------

>
> _______________________________________________
> Opensim-dev mailing list
> Open= sim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-d= ev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

=A0


_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.d= e
https://lists.berlios.de/mailman/listinfo/opensim-dev


--001485f794ccd7a9630474d00e1a-- From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: to include hooks and mechanisms for expanding/enhancing the system with new capabilities WITHOUT having to make major changes to the system infrastructure. OpenSim doesn't seem to be "extensible". OpenSim seems to be "broken". There is a big difference. Maybe your definition of "extensible" means that it requires a rocket scientist just to get the trunk to even compile (or even work), and takes hours and hours of debugging code, just to get a module to even work. That isn't my idea of "extensible". I understand over the past few months, the server infrastructure (and architecture) has been changing quite a bit. It's hard to even tell if ModRex (or any other modules) even work with the current OpenSim trunk (or latest build) at this point. The average layperson doesn't want to spend hours and hours trying to compile from source, or debugging code, or searching for plugins/modules that may (or may not) exist, and even worse many of them may not be updated, or may not even work with the current OpenSim as "core" evolves. Often times many of these modules are not updated, and most have no clue how to even build from source, and for this reason it might be good to just have VERY simple "turn-key" distributions available for download. (Stable releases) Similar to how RealXtend has done in the past. I supposed I could sit down and begin working on creating a fully configured VMWare image of OpenSim with various modules installed and configured, that people could easily download, and be up and running in a few minutes (without having to hunt for various modules, or applications), or sifting through outdated wiki pages trying to figure out how to even get started or even get up and running, but to be honest most people just want something VERY easy to use, VERY easy to setup, and would love a nice GUI interface (like WixTD, etc.) that they can use to administer the server, add users, etc. Most laypeople don't want to hire a software engineer, or a programmer, just to get OpenSim to compile, or even get a module working, or just to get OpenSim running on a machine. If I want to use a plugin with Firefox, I've NEVER had to compile or debug code. If I want to enable a PHP module, I've NEVER had to debug any code. Most modules are included in the default distro, and modules can easily be turned on and off, by simply "enabling" them in the default ini (configuration) file. In my opinion, you may be confusing "extensible system" as an excuse as to why nothing should work properly. In my opinion, EVERY single working module that exists for OpenSim should be included in the default distro (in the modules directory), and these modules should ALL be disabled by default, but can be easily enabled by simply uncommenting out ONE single line in the default.ini configuration file. Include EVERY single working module with the default OpenSim distro, so users have a list of default working modules that are regularly updated so that they actually work (and are not broken), so that when a stable release comes out, a user can just enable or disable whatever modules they wish to use (by uncommenting out a line or two in the default .ini configuration file) and those modules are in the modules directory, and can easily be enabled by just uncommenting out a single line in the default ini configuration file. The problem is, it seems like a herd of cats are headed in all opposite directions, and people really just want something that actually works. Diva, is that honestly too much to ask? There are Applications and there are Operating Systems. What do you call OpenSim? Is it an Application or an Operating System? (or is it neither?) When I say "works", I'm talking about someone can download OpenSim, and be up and running (designing things from within the OpenSim Application platform such as creating 3D content, in-world). Not sitting down and downloading source code, or attempting to figure out how to learn C# or C++ or how to write a module, just to get simple things running. The thing that made RealXtend so popular was that it was easy to use, and they had distros that were already setup and ready to use (even with a nice "beneath the sea" demo world as part of the distro). Keep in mind that most of the people interested in OpenSim as a 3D development platform are laypeople, and are graphics designers (and Second Life users) that are NOT Computer Science majors, and are not engineers, and really don't know ANY programming languages (some may know a bit of Java, or HTML, or LSL), but most don't even know C++ or C# nor would they have any idea how to even compile or build from source. They just want to use OpenSim to design 3D content, and create their own virtual world. Do you expect a web developer to know C? or C++? or C#? Try thinking of OpenSim as a "3D Web Server" for users (similar to Apache). Yes, Apache is extensible, and many modules can be written for Apache, but most of the common modules are already tested and included with the Apache distro. Modules are tested, and included with all the latest releases, and users can easily comment (or uncomment) out a single line in the default configuration file, and have the included modules working. So I believe the key to making OpenSim widely adopted as a "usable" platform for 3D developers, would be to make OpenSim easy to use (so that ANYONE can get up and running in less than 10 minutes). I believe every single tested module should be included with the default distro's. So that users can easily enable/disable whatever modules they want, and users know that the modules included with each distro have been tested, and are working modules. At this point in time, does ANYONE actually know what works, and what doesn't work? Do we actually have a working distro, with working modules (that have been tested to work) with an actual OpenSim release? Since 0.7 release is supposed to be coming out soon (in a week?) is there any way that we can stop development, and begin testing all the OpenSim modules, and add all the OpenSim modules (that have been tested and are working) to an OpenSim 0.7 release candidate? RealXtend does a very good job of doing this (with their old distros), but now that ModRex is integrated with OpenSim core, we're back to the drawing board again. If someone wants to enable ModRex, they should just be able to uncomment out a line in the default .ini file, and all the features of ModRex should work. If someone wants to enable currency, they should just be able to just uncomment out a line in the default .ini file, and now the currency module should be enabled. Why not make things SIMPLE and EASY to use? If someone wants to write a module (and wants it included with the OpenSim distro) then it needs to be tested, and once it has been tested (and confirmed to work) then it can be included with the OpenSim distro. This way at least we know what modules work (and are tested). OpenSim has evolved so quickly, that I'm not quite sure what modules even exist (or even work) at this point, and I have a few old distro's running, but I was too scared to even upgrade because everyone said that "OpenSim is currently broken" (due to all the latest changes) and people really just really want a WORKING distro (with working modules). I'm still running OpenSim 0.62 and ReX Server 0.4 on my local machines simply because it has been months where things have been completely broken (as OpenSim trunk would not even compile) and OpenSim has been making some backend changes and I'm still not even sure that ModRex/RealXtend even works since it has migrated over to OpenSim? I think your definition of "extensibility" and "extensible systems architecture" is different from mine. I believe in having something that ACTUALLY WORKS (out of the box), and extensibility means that new capabilities could EASILY be added without having to make changes to the system infrastructure. Your definition of "extensibility" seems to mean, nothing works, everything is broken, and you need to hire a software engineer just to get a few basic modules up and running. In my opinion, "extensibility" means that all the various modules would come by default with the default OpenSim distro, and they could easily be turned on (enabled) or turned off (disabled) by simply uncommenting a line in the default.ini file. Similar to PHP distro, or Apache server, or various other platforms. Either OpenSim is an Application or it's an Operating System. Since it doesn't run on bare metal, I certainly would NOT call it an Operating System, therefore I would consider it a software Application. I would consider OpenSim a 3D development platform. In my opinion, I would consider OpenSim a Server platform (software application) and you need both the OpenSim Server (platform) and a compatible Viewer to make OpenSim work. The problem is that OpenSim has evolved so much (and so quickly) that much of the Wiki documentation is outdated, no one is quite sure what even works at this point, and what doesn't work at this point. There is no list of recently "tested" modules (that are known to work with the current build/latest distro). Most "noobs" just really want a distro that they can easily download (maybe in a VMWare format) so they can just fire up a pre-configured image, and be up and running in minutes (instead of days or weeks). I'm willing to help test, and I'm willing to help with documentation, and I'm willing to even create "distros" that are easy to use (and that are tested and working) but it seems like nobody is working together. What if we just STOPPED developing, for just ONE week, and worked together on creating an actual distro? Just a working (and well tested) distro, that is thoroughly tested, that is STABLE, and that has all the OpenSim modules working with it? Then release it as a OpenSim 0.7 release. That's all I ask. Then after OpenSim 0.7 release candidate comes out (and it well tested, and all the modules from the OpenSim GForge are tested to work and be compatible with the 0.7 release, and then we wrap everything up, and release it as a working distro! Just halt development for 1 week, and just focus on bug fixes, and getting the modules to all work so we can just have a nice OpenSim 0.7 release candidate, with lots of working modules (that are all tested) and are included in the default distro. People can still choose what modules they wish to enable, but at least include all the known working modules with the default distro (or create a "vanilla" distro, and a "full distro" with the OpenSim 0.7 Release). That way one has the working modules, and the other doesn't have the working modules. But this way at least we can have an actual TESTED release candidate, that has all the working OpenSim modules (with updated documentation). I'm willing to help with documentation, and testing, but I just want to see an actual release candidate (with working modules) come out. On Wed, Sep 30, 2009 at 2:03 PM, wrote: > Mark Malewski wrote: > > It would just be nice to get everything integrated back into core (or as > > OpenSim modules). > > This would be terrible. We're going in the opposite direction, which is > to have a minimal core and let people do their own extensions as they > wish, hopefully replacing the heck out of the reference implementations. > > I think you, and maybe others here, may need to understand better this > concept of extensible systems. That's at the very core of OpenSim from > the beginning, even before I started contributing -- OpenSim is not an > application, it's a platform with which to build applications. > > Some extenders of OpenSim may want to get together and try to make their > extensions work with each other. That's great and desirable. But let's > not prevent innovative ideas from emerging by throwing a massive > feature-full application out there as "OpenSim". > > Diva / Crista > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > --001485f1ecf4de0dba0474d34838 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Diva,

>> It wou= ld just be nice to get everything integrated back into core (or as
>&= gt; OpenSim modules).
>
>This would be terrible= .=A0

Diva, please explain WHY would having a working OpenSim= distro be terrible? =A0Having something that actually "works" is= terrible? =A0In my opinion, just the opposite is true.

You can spend your whole life developing things (that no one actually = uses, and that don't actually work or do much of anything, and that no = one will ever use) or you can make a WORKING product that is usable, and th= at is EASY to use, and that people will use.

You seem to prefer the latter. =A0

=

> I think you, and maybe others here, may need to u= nderstand better this
>concept of extensible systems. That's at t= he very core of OpenSim from
>the beginning, even before I started contributing -- OpenSim is not an<= br>>application, it's a platform with which to build applications.
I think you need to sit down and understand the concept = of "working product". =A0You also need to stop confusing "ex= tensible system" with "not working" product.

PHP, and Apache are what I would c= onsider "extensible systems". =A0PHP is easily downloaded, and it= works (out of the box). =A0Yet it comes with many different modules (as pa= rt of the default distro) and those modules have all been thoroughly tested= , and can easily be enabled by simply uncommenting out the module name in t= he default.ini file.

From an engineering standpoint, extensibility m= eans the system is designed to include hooks and mechanisms for expanding/e= nhancing the system with new capabilities WITHOUT having to make major chan= ges to the system infrastructure.=A0

OpenSim doesn't seem to be "extensible". = =A0OpenSim seems to be "broken". =A0There is a big difference. = =A0Maybe your definition of "extensible" means that it requires a= rocket scientist just to get the trunk to even compile (or even work), and= takes hours and hours of debugging code, just to get a module to even work= . =A0That isn't my idea of "extensible".

I understand over the past few months, the server infra= structure (and architecture) has been changing quite a bit. =A0It's har= d to even tell if ModRex (or any other modules) even work with the current = OpenSim trunk (or latest build) at this point. =A0

The average layperson doesn't want to spend hours a= nd hours trying to compile from source, or debugging code, or searching for= plugins/modules that may (or may not) exist, and even worse many of them m= ay not be updated, or may not even work with the current OpenSim as "c= ore" evolves. =A0Often times many of these modules are not updated, an= d most have no clue how to even build from source, and for this reason it m= ight be good to just have VERY simple "turn-key" distributions av= ailable for download. (Stable releases)

Similar to how RealXtend has done in the past. =A0

I supposed I could sit down and begin working on creat= ing a fully configured VMWare image =A0of OpenSim with various modules inst= alled and configured, that people could easily download, and be up and runn= ing in a few minutes (without having to hunt for various modules, or applic= ations), or sifting through outdated wiki pages trying to figure out how to= even get started or even get up and running, but to be honest most people = just want something VERY easy to use, VERY easy to setup, and would love a = nice GUI interface (like WixTD, etc.) that they can use to administer the s= erver, add users, etc.

Most laypeople don't want to hire a software engine= er, or a programmer, just to get OpenSim to compile, or even get a module w= orking, or just to get OpenSim running on a machine. =A0

If I want to use a plugin with Firefox, I've NEVER had to compile = or debug code. =A0If I want to enable a PHP module, I've NEVER had to d= ebug any code. =A0Most modules are included in the default distro, and modu= les can easily be turned on and off, by simply "enabling" them in= the default ini (configuration) file.

In my opinion, you may be confusing "extensible sy= stem" as an excuse as to why nothing should work properly.
<= br>
In my opinion, EVERY single working module that exists for Op= enSim should be included in the default distro (in the modules directory), = and these modules should ALL be disabled by default, but can be easily enab= led by simply uncommenting out ONE single line in the default.ini configura= tion file.

Include EVERY single working module with the default Op= enSim distro, so users have a list of default working modules that are regu= larly updated so that they actually work (and are not broken), so that when= a stable release comes out, a user can just enable or disable whatever mod= ules they wish to use (by uncommenting out a line or two in the default .in= i configuration file) and those modules are in the modules directory, and c= an easily be enabled by just uncommenting out a single line in the default = ini configuration file.

The problem is, it seems like a herd of cats are headed= in all opposite directions, and people really just want something that act= ually works. =A0Diva, is that honestly too much to ask?

There are Applications and there are Operating Systems. =A0What do you= call OpenSim? =A0Is it an Application or an Operating System? =A0(or is it= neither?)

When I say "works", I'm t= alking about someone can download OpenSim, and be up and running (designing= things from within the OpenSim Application platform such as creating 3D co= ntent, in-world). =A0Not sitting down and downloading source code, or attem= pting to figure out how to learn C# or C++ or how to write a module, just t= o get simple things running.

The thing that made RealXtend so popular was that it wa= s easy to use, and they had distros that were already setup and ready to us= e (even with a nice "beneath the sea" demo world as part of the d= istro).

Keep in mind that most of the people interested in Open= Sim as a 3D development platform are laypeople, and are graphics designers = (and Second Life users) that are NOT Computer Science majors, and are not e= ngineers, and really don't know ANY programming languages (some may kno= w a bit of Java, or HTML, or LSL), but most don't even know=A0C++ or C#= =A0nor would they have any idea how to even compile or build from source. = =A0They just want to use OpenSim to design 3D content, and create their own= virtual world.

Do you expect a web developer to know C? or C++? or C#?=

Try thinking of OpenSim as a "3D Web Server&= quot; for users (similar to Apache). =A0Yes, Apache is extensible, and many= modules can be written for Apache, but most of the common modules are alre= ady tested and included with the Apache distro. =A0Modules are tested, and = included with all the latest releases, and users can easily comment (or unc= omment) out a single line in the default configuration file, and have the i= ncluded modules working.

So I believe the key to making OpenSim widely adopted a= s a "usable" platform for 3D developers, would be to make OpenSim= easy to use (so that ANYONE can get up and running in less than 10 minutes= ). =A0I believe every single tested module should be included with the defa= ult distro's. =A0So that users can easily enable/disable whatever modul= es they want, and users know that the modules included with each distro hav= e been tested, and are working modules.

At this point in time, does ANYONE actually know what w= orks, and what doesn't work? =A0Do we actually have a working distro, w= ith working modules (that have been tested to work) with an actual OpenSim = release?

Since 0.7 release is supposed to be coming out soon (in= a week?) is there any way that we can stop development, and begin testing = all the OpenSim modules, and add all the OpenSim modules (that have been te= sted and are working) to an OpenSim 0.7 release candidate?

RealXtend does a very good job of doing this (with thei= r old distros), but now that ModRex is integrated with OpenSim core, we'= ;re back to the drawing board again.=A0

If someone= wants to enable ModRex, they should just be able to uncomment out a line i= n the default .ini file, and all the features of ModRex should work. =A0If = someone wants to enable currency, they should just be able to just uncommen= t out a line in the default .ini file, and now the currency module should b= e enabled. =A0

Why not make things SIMPLE and EASY to use?
<= br>
If someone wants to write a module (and wants it included wit= h the OpenSim distro) then it needs to be tested, and once it has been test= ed (and confirmed to work) then it can be included with the OpenSim distro.= =A0This way at least we know what modules work (and are tested).

OpenSim has evolved so quickly, that I'm not quite = sure what modules even exist (or even work) at this point, and=A0I have a f= ew old distro's running, but I was too scared to even upgrade because e= veryone said that "OpenSim is currently broken" (due to all the l= atest changes) and people really just really want a WORKING distro (with wo= rking modules).

I'm still running OpenSim 0.62 and ReX Server 0.4 o= n my local machines simply because it has been months where things have bee= n completely broken (as OpenSim trunk would not even compile) and OpenSim h= as been making some backend changes and I'm still not even sure that Mo= dRex/RealXtend even works since it has migrated over to OpenSim? =A0

I think your definition of "extensibility" an= d "extensible systems architecture" is different from mine. =A0I = believe in having something that ACTUALLY WORKS (out of the box), and exten= sibility means that new capabilities could EASILY be added without having t= o make changes to the system infrastructure.

Your definition of "extensibility" seems to m= ean, nothing works, everything is broken, and you need to hire a software e= ngineer just to get a few basic modules up and running.

In my opinion, "extensibility" means that all the various mo= dules would come by default with the default OpenSim distro, and they could= easily be turned on (enabled) or turned off (disabled) by simply uncomment= ing a line in the default.ini file. =A0Similar to PHP distro, or Apache ser= ver, or various other platforms.

Either OpenSim is an Application or it's an Operati= ng System. =A0Since it doesn't run on bare metal, I certainly would NOT= call it an Operating System, therefore I would consider it a software Appl= ication. =A0I would consider OpenSim a 3D development platform.

In my opinion, I would consider OpenSim a Server platfo= rm (software application) and you need both the OpenSim Server (platform) a= nd a compatible Viewer to make OpenSim work.

The p= roblem is that OpenSim has evolved so much (and so quickly) that much of th= e Wiki documentation is outdated, no one is quite sure what even works at t= his point, and what doesn't work at this point. There is no list of rec= ently "tested" modules (that are known to work with the current b= uild/latest distro).=A0

Most "noobs" just really want a distro that t= hey can easily download (maybe in a VMWare format) so they can just fire up= a pre-configured image, and be up and running in minutes (instead of days = or weeks).

I'm willing to help test, and I'm willing to he= lp with documentation, and I'm willing to even create "distros&quo= t; that are easy to use (and that are tested and working) but it seems like= nobody is working together.

What if we just STOPPED developing, for just ONE week, = and worked together on creating an actual distro? =A0Just a working (and we= ll tested) distro, that is thoroughly tested, that is STABLE, and that has = all the OpenSim modules working with it?

Then release it as a OpenSim 0.7 release.
That's all I ask. =A0Then after OpenSim 0.7 release candida= te comes out (and it well tested, and all the modules from the OpenSim GFor= ge are tested to work and be compatible with the 0.7 release, and then we w= rap everything up, and release it as a working distro!

Just halt development for 1 week, and just focus on bug= fixes, and getting the modules to all work so we can just have a nice Open= Sim 0.7 release candidate, with lots of working modules (that are all teste= d) and are included in the default distro. =A0

People can still choose what modules they wish to enabl= e, but at least include all the known working modules with the default dist= ro (or create a "vanilla" distro, and a "full distro" w= ith the OpenSim 0.7 Release). =A0That way one has the working modules, and = the other doesn't have the working modules.

But this way at least we can have an actual TESTED rele= ase candidate, that has all the working OpenSim modules (with updated docum= entation).

I'm willing to help with documentat= ion, and testing, but I just want to see an actual release candidate (with = working modules) come out.



On Wed, S= ep 30, 2009 at 2:03 PM, <diva at metaverseink.com> wrote:
Mark Malewski wrote:
> It would just be nice to get everything integrated back into core (or = as
> OpenSim modules).

This would be terrible. We're going in the opposite direction, wh= ich is
to have a minimal core and let people do their own extensions as they
wish, hopefully replacing the heck out of the reference implementations.
I think you, and maybe others here, may need to understand better this
concept of extensible systems. That's at the very core of OpenSim from<= br> the beginning, even before I started contributing -- OpenSim is not an
application, it's a platform with which to build applications.

Some extenders of OpenSim may want to get together and try to make their extensions work with each other. That's great and desirable. But let= 9;s
not prevent innovative ideas from emerging by throwing a massive
feature-full application out there as "OpenSim".

Diva / Crista
_________________________________________= ______
Opensim-dev mailing list
Opensim-dev at lists.berlios.d= e
https://lists.berlios.de/mailman/listinfo/opensim-dev

--001485f1ecf4de0dba0474d34838-- From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: to include hooks and mechanisms for expanding/enhancing the system with new= capabilities WITHOUT having to make major changes to the system infrastruc= ture. OpenSim doesn't seem to be "extensible". OpenSim seems to be "broken". Th= ere is a big difference. Maybe your definition of "extensible" means that = it requires a rocket scientist just to get the trunk to even compile (or ev= en work), and takes hours and hours of debugging code, just to get a module= to even work. That isn't my idea of "extensible". I understand over the past few months, the server infrastructure (and archi= tecture) has been changing quite a bit. It's hard to even tell if ModRex (= or any other modules) even work with the current OpenSim trunk (or latest b= uild) at this point. The average layperson doesn't want to spend hours and hours trying to compi= le from source, or debugging code, or searching for plugins/modules that ma= y (or may not) exist, and even worse many of them may not be updated, or ma= y not even work with the current OpenSim as "core" evolves. Often times ma= ny of these modules are not updated, and most have no clue how to even buil= d from source, and for this reason it might be good to just have VERY simpl= e "turn-key" distributions available for download. (Stable releases) Similar to how RealXtend has done in the past. I supposed I could sit down and begin working on creating a fully configure= d VMWare image of OpenSim with various modules installed and configured, t= hat people could easily download, and be up and running in a few minutes (w= ithout having to hunt for various modules, or applications), or sifting thr= ough outdated wiki pages trying to figure out how to even get started or ev= en get up and running, but to be honest most people just want something VER= Y easy to use, VERY easy to setup, and would love a nice GUI interface (lik= e WixTD, etc.) that they can use to administer the server, add users, etc. Most laypeople don't want to hire a software engineer, or a programmer, jus= t to get OpenSim to compile, or even get a module working, or just to get O= penSim running on a machine. If I want to use a plugin with Firefox, I've NEVER had to compile or debug = code. If I want to enable a PHP module, I've NEVER had to debug any code. = Most modules are included in the default distro, and modules can easily be= turned on and off, by simply "enabling" them in the default ini (configura= tion) file. In my opinion, you may be confusing "extensible system" as an excuse as to = why nothing should work properly. In my opinion, EVERY single working module that exists for OpenSim should b= e included in the default distro (in the modules directory), and these modu= les should ALL be disabled by default, but can be easily enabled by simply = uncommenting out ONE single line in the default.ini configuration file. Include EVERY single working module with the default OpenSim distro, so use= rs have a list of default working modules that are regularly updated so tha= t they actually work (and are not broken), so that when a stable release co= mes out, a user can just enable or disable whatever modules they wish to us= e (by uncommenting out a line or two in the default .ini configuration file= ) and those modules are in the modules directory, and can easily be enabled= by just uncommenting out a single line in the default ini configuration fi= le. The problem is, it seems like a herd of cats are headed in all opposite dir= ections, and people really just want something that actually works. Diva, = is that honestly too much to ask? There are Applications and there are Operating Systems. What do you call O= penSim? Is it an Application or an Operating System? (or is it neither?) When I say "works", I'm talking about someone can download OpenSim, and be = up and running (designing things from within the OpenSim Application platfo= rm such as creating 3D content, in-world). Not sitting down and downloadin= g source code, or attempting to figure out how to learn C# or C++ or how to= write a module, just to get simple things running. The thing that made RealXtend so popular was that it was easy to use, and t= hey had distros that were already setup and ready to use (even with a nice = "beneath the sea" demo world as part of the distro). Keep in mind that most of the people interested in OpenSim as a 3D developm= ent platform are laypeople, and are graphics designers (and Second Life use= rs) that are NOT Computer Science majors, and are not engineers, and really= don't know ANY programming languages (some may know a bit of Java, or HTML= , or LSL), but most don't even know C++ or C# nor would they have any idea = how to even compile or build from source. They just want to use OpenSim to= design 3D content, and create their own virtual world. Do you expect a web developer to know C? or C++? or C#? Try thinking of OpenSim as a "3D Web Server" for users (similar to Apache).= Yes, Apache is extensible, and many modules can be written for Apache, bu= t most of the common modules are already tested and included with the Apach= e distro. Modules are tested, and included with all the latest releases, a= nd users can easily comment (or uncomment) out a single line in the default= configuration file, and have the included modules working. So I believe the key to making OpenSim widely adopted as a "usable" platfor= m for 3D developers, would be to make OpenSim easy to use (so that ANYONE c= an get up and running in less than 10 minutes). I believe every single tes= ted module should be included with the default distro's. So that users can= easily enable/disable whatever modules they want, and users know that the = modules included with each distro have been tested, and are working modules= . At this point in time, does ANYONE actually know what works, and what doesn= 't work? Do we actually have a working distro, with working modules (that = have been tested to work) with an actual OpenSim release? Since 0.7 release is supposed to be coming out soon (in a week?) is there a= ny way that we can stop development, and begin testing all the OpenSim modu= les, and add all the OpenSim modules (that have been tested and are working= ) to an OpenSim 0.7 release candidate? RealXtend does a very good job of doing this (with their old distros), but = now that ModRex is integrated with OpenSim core, we're back to the drawing = board again. If someone wants to enable ModRex, they should just be able to uncomment ou= t a line in the default .ini file, and all the features of ModRex should wo= rk. If someone wants to enable currency, they should just be able to just = uncomment out a line in the default .ini file, and now the currency module = should be enabled. Why not make things SIMPLE and EASY to use? If someone wants to write a module (and wants it included with the OpenSim = distro) then it needs to be tested, and once it has been tested (and confir= med to work) then it can be included with the OpenSim distro. This way at = least we know what modules work (and are tested). OpenSim has evolved so quickly, that I'm not quite sure what modules even e= xist (or even work) at this point, and I have a few old distro's running, b= ut I was too scared to even upgrade because everyone said that "OpenSim is = currently broken" (due to all the latest changes) and people really just re= ally want a WORKING distro (with working modules). I'm still running OpenSim 0.62 and ReX Server 0.4 on my local machines simp= ly because it has been months where things have been completely broken (as = OpenSim trunk would not even compile) and OpenSim has been making some back= end changes and I'm still not even sure that ModRex/RealXtend even works si= nce it has migrated over to OpenSim? I think your definition of "extensibility" and "extensible systems architec= ture" is different from mine. I believe in having something that ACTUALLY = WORKS (out of the box), and extensibility means that new capabilities could= EASILY be added without having to make changes to the system infrastructur= e. Your definition of "extensibility" seems to mean, nothing works, everything= is broken, and you need to hire a software engineer just to get a few basi= c modules up and running. In my opinion, "extensibility" means that all the various modules would com= e by default with the default OpenSim distro, and they could easily be turn= ed on (enabled) or turned off (disabled) by simply uncommenting a line in t= he default.ini file. Similar to PHP distro, or Apache server, or various o= ther platforms. Either OpenSim is an Application or it's an Operating System. Since it doe= sn't run on bare metal, I certainly would NOT call it an Operating System, = therefore I would consider it a software Application. I would consider Ope= nSim a 3D development platform. In my opinion, I would consider OpenSim a Server platform (software applica= tion) and you need both the OpenSim Server (platform) and a compatible View= er to make OpenSim work. The problem is that OpenSim has evolved so much (and so quickly) that much = of the Wiki documentation is outdated, no one is quite sure what even works= at this point, and what doesn't work at this point. There is no list of re= cently "tested" modules (that are known to work with the current build/late= st distro). Most "noobs" just really want a distro that they can easily download (maybe= in a VMWare format) so they can just fire up a pre-configured image, and b= e up and running in minutes (instead of days or weeks). I'm willing to help test, and I'm willing to help with documentation, and I= 'm willing to even create "distros" that are easy to use (and that are test= ed and working) but it seems like nobody is working together. What if we just STOPPED developing, for just ONE week, and worked together = on creating an actual distro? Just a working (and well tested) distro, tha= t is thoroughly tested, that is STABLE, and that has all the OpenSim module= s working with it? Then release it as a OpenSim 0.7 release. That's all I ask. Then after OpenSim 0.7 release candidate comes out (and = it well tested, and all the modules from the OpenSim GForge are tested to w= ork and be compatible with the 0.7 release, and then we wrap everything up,= and release it as a working distro! Just halt development for 1 week, and just focus on bug fixes, and getting = the modules to all work so we can just have a nice OpenSim 0.7 release cand= idate, with lots of working modules (that are all tested) and are included = in the default distro. People can still choose what modules they wish to enable, but at least incl= ude all the known working modules with the default distro (or create a "van= illa" distro, and a "full distro" with the OpenSim 0.7 Release). That way = one has the working modules, and the other doesn't have the working modules= . But this way at least we can have an actual TESTED release candidate, that = has all the working OpenSim modules (with updated documentation). I'm willing to help with documentation, and testing, but I just want to see= an actual release candidate (with working modules) come out. On Wed, Sep 30, 2009 at 2:03 PM, > wrote: Mark Malewski wrote: > It would just be nice to get everything integrated back into core (or as > OpenSim modules). This would be terrible. We're going in the opposite direction, which is to have a minimal core and let people do their own extensions as they wish, hopefully replacing the heck out of the reference implementations. I think you, and maybe others here, may need to understand better this concept of extensible systems. That's at the very core of OpenSim from the beginning, even before I started contributing -- OpenSim is not an application, it's a platform with which to build applications. Some extenders of OpenSim may want to get together and try to make their extensions work with each other. That's great and desirable. But let's not prevent innovative ideas from emerging by throwing a massive feature-full application out there as "OpenSim". Diva / Crista _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev --_000_63FAD4F222230A4EA79DE9E8BE6647354D38EE74winxbeus19excha_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

tl; dr.

 

Adam

 

From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Mark Male= wski
Sent: Wednesday, 30 September 2009 3:45 PM
To: diva at metaverseink.com; opensim-dev at lists.berlios.de
Subject: [Opensim-dev] OpenSim 0.7 Release Candidate with ALL workin= g OpenSim Modules

 

Diva,

 

>> It would just be nice to get everything integrated back into core (or as
>> OpenSim modules).
>

>This would be terrible. 

 

Diva, please explain WHY would having a working OpenSi= m distro be terrible?  Having something that actually "works" = is terrible?  In my opinion, just the opposite is true.

 

You can spend your whole life developing things (that = no one actually uses, and that don't actually work or do much of anything, and tha= t no one will ever use) or you can make a WORKING product that is usable, and th= at is EASY to use, and that people will use.

 

You seem to prefer the latter.  

 

 

> I think you,= and maybe others here, may need to understand better this
>concept of extensible systems. That's at the very core of OpenSim from<= br> >the beginning, even before I started contributing -- OpenSim is not an<= br> >application, it's a platform with which to build applications.<= o:p>

I think you need to sit down and understand the concep= t of "working product".  You also need to stop confusing "extensible system" with "not working" product.

 

PHP, and Apache are what I would consider "extensible systems".  = PHP is easily downloaded, and it works (out of the box).  Yet it comes wit= h many different modules (as part of the default distro) and those modules ha= ve all been thoroughly tested, and can easily be enabled by simply uncommentin= g out the module name in the default.ini file.

 

From an engineering standpoint, extensibility means the system is designed to include hooks and mechanisms for expanding/enhancing the system with new capabilities WITHOUT having to make major changes to the system infrastructure. 

 

OpenSim doesn't seem to be "extensible".  OpenSim seems to be "broken".  There is a big differen= ce.  Maybe your definition of "extensible" means that it require= s a rocket scientist just to get the trunk to even compile (or even work), and takes hours and hours of debugging code, just to get a module to even work.  That isn't my idea of "extensible".

 

I understand over the past few months, the server infrastructure (and architecture) has been changing quite a bit.  It's hard to even tell if ModRex (or any other modules) even work with the curre= nt OpenSim trunk (or latest build) at this point.  

 

The average layperson doesn't want to spend hours and = hours trying to compile from source, or debugging code, or searching for plugins/modules that may (or may not) exist, and even worse many of them ma= y not be updated, or may not even work with the current OpenSim as "core" evolves.  Often times many of these modules are not updated, and most have no clue how to even build from source, and for this reason it might be good to just have VERY simple "turn-key" distributions available for download. (Stable releases)

 

Similar to how RealXtend has done in the past.  <= o:p>

 

I supposed I could sit down and begin working on creat= ing a fully configured VMWare image  of OpenSim with various modules install= ed and configured, that people could easily download, and be up and running in= a few minutes (without having to hunt for various modules, or applications), = or sifting through outdated wiki pages trying to figure out how to even get started or even get up and running, but to be honest most people just want something VERY easy to use, VERY easy to setup, and would love a nice GUI i= nterface (like WixTD, etc.) that they can use to administer the server, add users, e= tc.

 

Most laypeople don't want to hire a software engineer,= or a programmer, just to get OpenSim to compile, or even get a module working, o= r just to get OpenSim running on a machine.  

 

If I want to use a plugin with Firefox, I've NEVER had= to compile or debug code.  If I want to enable a PHP module, I've NEVER h= ad to debug any code.  Most modules are included in the default distro, a= nd modules can easily be turned on and off, by simply "enabling" the= m in the default ini (configuration) file.

 

In my opinion, you may be confusing "extensible system" as an excuse as to why nothing should work properly.

 

In my opinion, EVERY single working module that exists= for OpenSim should be included in the default distro (in the modules directory)= , and these modules should ALL be disabled by default, but can be easily enab= led by simply uncommenting out ONE single line in the default.ini configuration file.

 

Include EVERY single working module with the default O= penSim distro, so users have a list of default working modules that are regularly updated so that they actually work (and are not broken), so that when a sta= ble release comes out, a user can just enable or disable whatever modules they = wish to use (by uncommenting out a line or two in the default .ini configuration file) and those modules are in the modules directory, and can easily be ena= bled by just uncommenting out a single line in the default ini configuration fil= e.

 

The problem is, it seems like a herd of cats are heade= d in all opposite directions, and people really just want something that actuall= y works.  Diva, is that honestly too much to ask?

 

There are Applications and there are Operating Systems= .  What do you call OpenSim?  Is it an Application or an Operating System?  (or is it neither?)

 

When I say "works", I'm talking about someon= e can download OpenSim, and be up and running (designing things from within the OpenSim Application platform such as creating 3D content, in-world).  = Not sitting down and downloading source code, or attempting to figure out how t= o learn C# or C++ or how to write a module, just to get simple things running= .

 

The thing that made RealXtend so popular was that it w= as easy to use, and they had distros that were already setup and ready to use (even with a nice "beneath the sea" demo world as part of the distro).

 

Keep in mind that most of the people interested in Ope= nSim as a 3D development platform are laypeople, and are graphics designers (and= Second Life users) that are NOT Computer Science majors, and are not engineers, an= d really don't know ANY programming languages (some may know a bit of Java, o= r HTML, or LSL), but most don't even know C++ or C# nor would they = have any idea how to even compile or build from source.  They just want to = use OpenSim to design 3D content, and create their own virtual world.

 

Do you expect a web developer to know C? or C++? or C#= ?

 

Try thinking of OpenSim as a "3D Web Server"= for users (similar to Apache).  Yes, Apache is extensible, and many module= s can be written for Apache, but most of the common modules are already teste= d and included with the Apache distro.  Modules are tested, and included with all the latest releases, and users can easily comment (or uncomment) o= ut a single line in the default configuration file, and have the included module= s working.

 

So I believe the key to making OpenSim widely adopted = as a "usable" platform for 3D developers, would be to make OpenSim eas= y to use (so that ANYONE can get up and running in less than 10 minutes).  = I believe every single tested module should be included with the default distro's.  So that users can easily enable/disable whatever modules th= ey want, and users know that the modules included with each distro have been tested, and are working modules.

 

At this point in time, does ANYONE actually know what = works, and what doesn't work?  Do we actually have a working distro, with wor= king modules (that have been tested to work) with an actual OpenSim release?

 

Since 0.7 release is supposed to be coming out soon (i= n a week?) is there any way that we can stop development, and begin testing all= the OpenSim modules, and add all the OpenSim modules (that have been tested and= are working) to an OpenSim 0.7 release candidate?

 

RealXtend does a very good job of doing this (with the= ir old distros), but now that ModRex is integrated with OpenSim core, we're back t= o the drawing board again. 

 

If someone wants to enable ModRex, they should just be= able to uncomment out a line in the default .ini file, and all the features of ModRex should work.  If someone wants to enable currency, they should = just be able to just uncomment out a line in the default .ini file, and now the currency module should be enabled.  

 

Why not make things SIMPLE and EASY to use?=

 

If someone wants to write a module (and wants it inclu= ded with the OpenSim distro) then it needs to be tested, and once it has been tested (and confirmed to work) then it can be included with the OpenSim dis= tro.  This way at least we know what modules work (and are tested).

 

OpenSim has evolved so quickly, that I'm not quite sur= e what modules even exist (or even work) at this point, and I have a few old distro's running, but I was too scared to even upgrade because everyone sai= d that "OpenSim is currently broken" (due to all the latest changes= ) and people really just really want a WORKING distro (with working modules).=

 

I'm still running OpenSim 0.62 and ReX Server 0.4 on m= y local machines simply because it has been months where things have been completely broken (as OpenSim trunk would not even compile) and OpenSim has been making some backend changes and I'm still not even sure that ModRex/RealXtend even works since it has migrated over to OpenSim?  

 

I think your definition of "extensibility" a= nd "extensible systems architecture" is different from mine.  I believe in having something that ACTUALLY WORKS (out of the box), and extensibility means that new capabilities could EASILY be added without hav= ing to make changes to the system infrastructure.

 

Your definition of "extensibility" seems to = mean, nothing works, everything is broken, and you need to hire a software engine= er just to get a few basic modules up and running.

 

In my opinion, "extensibility" means that al= l the various modules would come by default with the default OpenSim distro, and = they could easily be turned on (enabled) or turned off (disabled) by simply uncommenting a line in the default.ini file.  Similar to PHP distro, o= r Apache server, or various other platforms.

 

Either OpenSim is an Application or it's an Operating System.  Since it doesn't run on bare metal, I certainly would NOT cal= l it an Operating System, therefore I would consider it a software Application.  I would consider OpenSim a 3D development platform.

 

In my opinion, I would consider OpenSim a Server platf= orm (software application) and you need both the OpenSim Server (platform) and = a compatible Viewer to make OpenSim work.

 

The problem is that OpenSim has evolved so much (and s= o quickly) that much of the Wiki documentation is outdated, no one is quite s= ure what even works at this point, and what doesn't work at this point. There i= s no list of recently "tested" modules (that are known to work with th= e current build/latest distro). 

 

Most "noobs" just really want a distro that = they can easily download (maybe in a VMWare format) so they can just fire up a pre-configured image, and be up and running in minutes (instead of days or weeks).

 

I'm willing to help test, and I'm willing to help with documentation, and I'm willing to even create "distros" that are = easy to use (and that are tested and working) but it seems like nobody is workin= g together.

 

What if we just STOPPED developing, for just ONE week,= and worked together on creating an actual distro?  Just a working (and wel= l tested) distro, that is thoroughly tested, that is STABLE, and that has all= the OpenSim modules working with it?

 

Then release it as a OpenSim 0.7 release.

 

That's all I ask.  Then after OpenSim 0.7 release candidate comes out (and it well tested, and all the modules from the OpenS= im GForge are tested to work and be compatible with the 0.7 release, and then = we wrap everything up, and release it as a working distro!

 

Just halt development for 1 week, and just focus on bu= g fixes, and getting the modules to all work so we can just have a nice OpenS= im 0.7 release candidate, with lots of working modules (that are all tested) a= nd are included in the default distro.  

 

People can still choose what modules they wish to enab= le, but at least include all the known working modules with the default distro = (or create a "vanilla" distro, and a "full distro" with the OpenSim 0.7 Release).  That way one has the working modules, and the o= ther doesn't have the working modules.

 

But this way at least we can have an actual TESTED rel= ease candidate, that has all the working OpenSim modules (with updated documentation).

 

I'm willing to help with documentation, and testing, b= ut I just want to see an actual release candidate (with working modules) come ou= t.

 

 

 

On Wed, Sep 30, 2009 at 2:03 PM, <diva at metaverseink.com> wrote:<= o:p>

Mark Malewski wrote: > It would just be nice to get everything integrated back into core (or = as
> OpenSim modules).

This would be terrible. We're going in the opposite direction, which is
to have a minimal core and let people do their own extensions as they
wish, hopefully replacing the heck out of the reference implementations.
I think you, and maybe others here, may need to understand better this
concept of extensible systems. That's at the very core of OpenSim from
the beginning, even before I started contributing -- OpenSim is not an
application, it's a platform with which to build applications.

Some extenders of OpenSim may want to get together and try to make their extensions work with each other. That's great and desirable. But let's
not prevent innovative ideas from emerging by throwing a massive
feature-full application out there as "OpenSim".

Diva / Crista

_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.d= e
https://lists.berlios.de/mailman/listinfo/opensim-dev

 

--_000_63FAD4F222230A4EA79DE9E8BE6647354D38EE74winxbeus19excha_-- From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: mocracy.html#electorate "The voting system itself should be used to choose new committers, both ful= l and partial. But here is one of the rare instances where secrecy is appro= priate. You can't have votes about potential committers posted to a public = mailing list, because the candidate's feelings (and reputation) could be hu= rt. Instead, the usual way is that an existing committer posts to a private= mailing list consisting only of the other committers, proposing that someo= ne be granted commit access. The other committers speak their minds freely,= knowing the discussion is private. Often there will be no disagreement, an= d therefore no vote necessary. After waiting a few days to make sure every = committer has had a chance to respond, the proposer mails the candidate and= offers him commit access. If there is disagreement, discussion ensues as f= or any other question, possibly resulting in a vote. For this process to be= open and frank, the mere fact that the discussion is taking place at all s= hould be secret. If the person under consideration knew it was going on, an= d then were never offered commit access, he could conclude that he had lost= the vote, and would likely feel hurt. Of course, if someone explicitly ask= s for commit access, then there is no choice but to consider the proposal a= nd explicitly accept or reject him. If the latter, then it should be done a= s politely as possible, with a clear explanation: "We liked your patches, b= ut haven't seen enough of them yet," or "We appreciate all your patches, bu= t they required considerable adjustments before they could be applied, so w= e don't feel comfortable giving you commit access yet. We hope that this wi= ll change over time, though." Remember, what you're saying could come as a = blow, depending on the person's level of confidence. Try to see it from the= ir point of view as you write the mail." --- I personally suggest reading that whole chapter (#4) for reasons why a lot = of projects have a committers mailing list (and yes it is a standard practi= ce.) Adam > -----Original Message----- > From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev- > bounces at lists.berlios.de] On Behalf Of Ryan McDougall > Sent: Monday, 19 October 2009 9:33 PM > To: opensim-dev at lists.berlios.de > Subject: [Opensim-dev] The notion of "core" >=20 > On Tue, Oct 20, 2009 at 2:49 AM, Frisby, Adam > wrote: > > Ter pretty much summed it up - both it and the irc channel are fairly > low-volume, and the 'topic' is restricted to only 'personal' or 'meta' > matters; such as discussion of approval of commit rights. > > > > It's pretty standard practice across open source projects with more > than 5 committers for the committers to have a mailing list for these > purposes, since realtime chats aren't practical across timezones. > > > > Adam > > >=20 > I am not sure I'd agree just how standard a process it is. >=20 > The one's I've been involved with or otherwise have some detailed > knowledge of, have never had them; including such big names as GNOME, > Fedora, and Linux. For example the GNOME foundation list is not only > world-readable, but anyone can join: > http://mail.gnome.org/mailman/listinfo/foundation-list . Actual > foundation members are voted by the community at large. >=20 > Basically the way they are able to operate is, they don't distribute > commit access according to monolithic vote of knighted members; they > have a system of maintainership, and each maintainer gives access > rights to his module/repo as she sees fit, in a web of trust. >=20 > One of the complaints one sometimes hears is how monolithic the > project is (even if the code-base is modular). Maybe the move to git, > and the maturation of the code allows more distribution and > specialization of responsibility? >=20 > My concerns with core mailing list are: >=20 > 1. It's "secret", ie. not world readable. I can understand limiting > membership to voting partners to avoid bikeshedding, but I can't > understand secrecy of any kind in an open source project. >=20 > 2. Decisions made there (aside from commit rights) affect other > people, and they not only have no voice to represent themselves, they > don't even get to know what is being said about them. That doesn't > seem fair somehow. >=20 > The knowledge that someone can read what you write makes you think > harder about what you say. Maybe a private list makes the problem of > disagreement within core worse rather than better? I haven't the > faintest idea who this snowcrash guy is, but when I was a topic of > discussion on -core, I remember not liking it at all. >=20 > As for the issue of timezones, I understand that completely! Which is > why I wish you guys used ML more frequently! :) >=20 > My intention is not to bike-shed, but to be productive. Either opensim > core is open to this point of view or it's not, and we move on from > there. >=20 > Cheers, and much love! > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: "The voting system itself should be used to choose new committers, both full and partial. But here is one of the rare instances where secrecy is appropriate. You can't have votes about potential committers posted to a public mailing list, because the candidate's feelings (and reputation) could be hurt. Instead, the usual way is that an existing committer posts to a private mailing list consisting only of the other committers, proposing that someone be granted commit access. The other committers speak their minds freely, knowing the discussion is private. Often there will be no disagreement, and therefore no vote necessary. After waiting a few days to make sure every committer has had a chance to respond, the proposer mails the candidate and offers him commit access. If there is disagreement, discussion ensues as for any other question, possibly resulting in a vote. For this process to be open and frank, the mere fact that the discussion is taking place at all should be secret . If the person under consideration knew it was going on, and then were never offered commit access, he could conclude that he had lost the vote, and would likely feel hurt. Of course, if someone explicitly asks for commit access, then there is no choice but to consider the proposal and explicitly accept or reject him. If the latter, then it should be done as politely as possible, with a clear explanation: "We liked your patches, but haven't seen enough of them yet," or "We appreciate all your patches, but they required considerable adjustments before they could be applied, so we don't feel comfortable giving you commit access yet. We hope that this will change over time, though." Remember, what you're saying could come as a blow, depending on the person's level of confidence. Try to see it from their point of view as you write the mail." --- I personally suggest reading that whole chapter (#4) for reasons why a lot of projects have a committers mailing list (and yes it is a standard practice.) Adam > -----Original Message----- > From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev- > bounces at lists.berlios.de] On Behalf Of Ryan McDougall > Sent: Monday, 19 October 2009 9:33 PM > To: opensim-dev at lists.berlios.de > Subject: [Opensim-dev] The notion of "core" > > On Tue, Oct 20, 2009 at 2:49 AM, Frisby, Adam > wrote: > > Ter pretty much summed it up - both it and the irc channel are fairly > low-volume, and the 'topic' is restricted to only 'personal' or 'meta' > matters; such as discussion of approval of commit rights. > > > > It's pretty standard practice across open source projects with more > than 5 committers for the committers to have a mailing list for these > purposes, since realtime chats aren't practical across timezones. > > > > Adam > > > > I am not sure I'd agree just how standard a process it is. > > The one's I've been involved with or otherwise have some detailed > knowledge of, have never had them; including such big names as GNOME, > Fedora, and Linux. For example the GNOME foundation list is not only > world-readable, but anyone can join: > http://mail.gnome.org/mailman/listinfo/foundation-list . Actual > foundation members are voted by the community at large. > > Basically the way they are able to operate is, they don't distribute > commit access according to monolithic vote of knighted members; they > have a system of maintainership, and each maintainer gives access > rights to his module/repo as she sees fit, in a web of trust. > > One of the complaints one sometimes hears is how monolithic the > project is (even if the code-base is modular). Maybe the move to git, > and the maturation of the code allows more distribution and > specialization of responsibility? > > My concerns with core mailing list are: > > 1. It's "secret", ie. not world readable. I can understand limiting > membership to voting partners to avoid bikeshedding, but I can't > understand secrecy of any kind in an open source project. > > 2. Decisions made there (aside from commit rights) affect other > people, and they not only have no voice to represent themselves, they > don't even get to know what is being said about them. That doesn't > seem fair somehow. > > The knowledge that someone can read what you write makes you think > harder about what you say. Maybe a private list makes the problem of > disagreement within core worse rather than better? I haven't the > faintest idea who this snowcrash guy is, but when I was a topic of > discussion on -core, I remember not liking it at all. > > As for the issue of timezones, I understand that completely! Which is > why I wish you guys used ML more frequently! :) > > My intention is not to bike-shed, but to be productive. Either opensim > core is open to this point of view or it's not, and we move on from > there. > > Cheers, and much love! > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: evolution of virtual worlds. It is no surprise that most Opensim developers wish to go beyond that first step, learning from past mistakes and finding better models for the future. I mentioned earlier our work at the IETF on new VW protocols, in which LL are a leading party --- see https://www.ietf.org/mailman/listinfo/ogpx , the mailing list of the VWRAP working group. What may surprise you is that even Lindens know that the current SL is not a good model for the future, which is why the protocols being discussed go far beyond their legacy ones. Indeed, Lindens will be facing a huge rewrite if this work bears fruit. When even Lindens don't wish their future to be constrained by the current SL design because they know its many problems, this really highlights how bad it would be for the Opensim team to do so. :-) I hope that one or more of these issues resonates with you, and makes it a bit clearer why Opensim really cannot afford to align itself with SL. There is no future in looking backwards. Morgaine. ======================================= On Mon, Nov 23, 2009 at 1:06 PM, Len Brown wrote: > Rock, > > I sympathize with you on many levels. I've also had my doubts > regarding the future of OpenSim, but I have also maintained some degree of > faith that things will pull through in the end. > > For me the shock came when I was abruptly informed that "OpenSim is > not Second Life, is not intended to be like Second Life, nor ever will." I > still haven't the foggiest idea what this developer had smoked for them to > so strongly assert that incredibly false statement. > > For me, the enjoyment of OpenSim has come from my intense devotion to > building and skinning. In fact, for the last few months I've been working > on a full region that has many hundreds of skins, clothes, hair, furniture, > etc, etc, that I'd like to package up as an OAR and give out freely, since > repeatedly I've been told that instead of giving money to help further > OpenSim I'd do more proactively by giving content. So I plan to do just > that and give my money to other open source initiatives that matter to me. > > I have a passion for writing, and have thought many times that one of > the greatest powers OpenSim would gain is having simple, straightforward, > step-by-step instructions on how to download, compile, install, administer > and overall just plain operate the core applications. What kills me is that > everyone who does a search for OpenSim inevitably hits the > opensimulator.org site and that is where the massive roadblock presents > itself. It's useless for most and irrelevant to the few who consider > themselves OpenSim experts. > > Heck, even now on the configuration page it still displays info for > 0.6.6 including (months old) known bugs in setting up region xml files. If > there was appointed a volunteer whose sole job was to keep information on > opensimulator.org relevant that one task would resolve a mountain of > negativity right there. I sit here in front of my computers a good 10 to 12 > hours a day. > > I would sincerely love to contribute to the OpenSim project, > especially in documentation support. But the thing holding me back is > communication. If I cannot get a straight answer on who to GIVE money to in > order to help, then I stand little chance of getting clear, straight answers > from developers when asking about issues I need to consider and incorporate > in documentation. > > If communication is a hurdle we can all overcome, with a genuine and > heart-felt effort to relay information, motives, and plans with one another, > then I'd sincerely appreciate having the opportunity to personally > contribute. I'm not a programmer today, but have a degree in programming > fro the 90's (so much has changed my degree is practically useless in that > regard). But I do know how to explain things and relay information in > simple terms. But only if my own questions will be answered with more than > "look it up or figure it out yourself" as my answer. > > If any of you would appreciate my help, feel free to let me know at > any time and I'll do what I can. > > - Len W. Brown > lenwbrown at gmail.com > > > On Mon, Nov 23, 2009 at 6:23 AM, Colin B. Withers < > Colin.Withers at eumetsat.int> wrote: > >> Hi guys, >> >> I have decided to leave the Opensim project. You will probably not even >> notice if I leave, as not being a programmer my only inputs were the writing >> of the step-by-step tutorials ( >> http://chapter-and-metaverse.blogspot.com/ ), the drafts of the OpenSim >> User Manual on the Forge, and helping out in the IRC channels, for >> newcomers. >> >> You may find my reasons for leaving Opensim interesting though (and please >> do not construe any of my reasons as an attack on anyone). >> >> 1. The Platform >> I raised this several times in the past in IRC, and made posts on my blog >> about the product lifecycle of the platform ( >> http://rock-vacirca.blogspot.com/2009/02/direction-of-virtual-worlds.html). I believe that the platforms underpinning both Second Life and Opensim >> are quite long in the tooth now, and I questioned how much product lifecycle >> there was left, particularly given that Opensim is now nearing 3 years of >> development, is still in Alpha, and if the current release of 0.6.7 is any >> indicator, then still only around two thirds into the development cycle. >> With the (inevitable) coming of much superior platforms, such as Blue Mars >> and (as a virtual world); Unity, for browser-based Virtual Wolrds; and now >> UDK (for creating sandboxes, standalones, and open grids), then I fear that >> Opensim has missed the boat as far as the remaining lifecycle of the >> platform is concerned. When you show people what is possible with these >> engines (for example this avatar editor for the forthcom >> ing APB (using the Unreal Engine): >> http://www.youtube.com/watch?v=icR3LtEMvZI or this city: >> http://www.youtube.com/watch?v=hmLzNbPXMDg (using the CryEngine), then >> neither SL not Opensim stands comparison. >> >> 2. Lack of Support for Currency in Opensim >> I felt the impact of this when I first made the switch from SL to Opensim. >> I had a thriving RP sim in SL (over 50 people, mainly female) and they all >> agreed to follow me over to my Opensim and the OSGrid. However, within a >> month they had all left, citing the same reason, the lack of places to shop, >> to buy the quality stuff they wanted (skins, hair, clothes etc), as a >> quality appearance, and the fun of shopping is what all the females placed >> high on their requirements from a Virtual World. They drifted back to Second >> Life, and the guys followed them. I have always believed that the lack of >> support for currency in the core was a mistake, but that is just my opinion. >> >> 3. Marketing >> I have also raised this issue several times, and blogged about it. It is >> far from clear just who an eventually released Opensim is actually aimed at. >> I think that any company that is interested in a firewalled corporate >> solution to collaboration and prototyping will already be looking at the >> Enterprise solution that is currently available from Second Life; that any >> indie group that is thinking of running a themed grid will need an economy >> to stay viable; and any individual who is looking for a private sandbox >> solution for their SL work will need full compatibility (which is not the >> case with the OS version of LSL diverging from the SL LSL). So, just who is >> the platform aimed at? I was also very disappointed in the view of one of >> the core devs who said that 'marketing is a null concept for us'. >> >> I am currently designing and creating cities for Blue Mars, and involved >> in a team for proving the UDK as a platform for the design and creation of >> Virtual Worlds (as opposed to purely games), and with so much documentation >> available for these mature engines (particularly for the UDK, Blue Mars lags >> behind somewhat in that department, but have hired extra staff to put that >> right), I am achieving the productivity I want, building the worlds that I >> want, with stable crash-free platforms. >> >> However, I do wish the Opensim team the very best in their endeavours, and >> I sincerely hope their goals are eventually achieved. >> >> If anyone would like to take over the Opensim Tutorials pages at >> http://chapter-and-metaverse.blogspot.com/ and >> http://chapter-and-metaverse2.blogspot.com/ (they will need some updating >> following several changes) then I am more than willing to pass the posts >> over, and of course the Opensim User Manual is there in the Forge for anyone >> to develop further. >> >> Best Regards and Good Luck >> >> Rock >> >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > --0016e6d7eefa4147ee047911d695 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Nov 23, 2009 at 1:06 PM, Len Brown <lenwbrown at gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 2= 04, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
For me the shock came when I was abruptly informed that "OpenSim is not Se= cond Life, is not intended to be like Second Life, nor ever will."=A0 I= still haven't the foggiest idea what this developer had smoked for them to so strongly assert that incredibly false statement.


= Len, let me give you an alternative perspective on that quote to help you s= ee the reasons for it.=A0 I'm not on the Opensim team, but after five y= ears in SL, two years in AWG, and a year of working on future VW protocols = in our IETF group, I have some background to know why Opensim needs to dist= ance itself from SL:

  • SL's statically tiled resource architecture is badly non= -scalable, because most resource usage in VWs cannot be statically mapp= ed (demand moves around).=A0 The inability to assign resources dynamically = in SL results in huge overload in busy places and gross wastage in idle are= as.=A0 It also limits the number of participants in events and the bandwidt= h of their interaction, as well as the size and complexity of everything in= a region.=A0 This architecture is fundamental to SL, yet it is a recipe fo= r failure.=A0 As long as Opensim adheres to the SL model, Opensim will be s= imilarly non-scalable.

  • The LSL scripting language is linguistically weak, semanti= cally obscure, and lacking in the glue that could allow components to coope= rate effectively.=A0 As a result, individual scripts are quite underpowered= and inefficient, and multi-script constructions do not scale well in compl= exity because the overheads of cooperation are so large.=A0 That's a ba= d restriction on progress which Opensim needs to leave behind.

  • LSL scripts are not scalable in power or size, and this wi= ll continue to be true even after SL allows C# and other CLR languages to b= e used.=A0 There is no possibility of using more CPU power for scripting th= an is available in one single simulator in SL.=A0 That is not a good founda= tion upon which to build an ambitious future of clever components.

  • SL's simulation environment is non-portable, having ev= olved over time into a plethora of special cases that will not be accuratel= y replicable anywhere else.=A0 In effect this means that there will never b= e effective interop with SL's scripted objects.=A0 It would not be a us= eful goal to seek compatibility with what could realistically be described = as an "ill-defined mess".

  • SL's object and type systems are non-extensible= , so compatibility with SL means living in the past, and worse, living in a= past defined entirely by one slow-moving company.=A0 Tying the capabilitie= s of Opensim to that millstone would be a disaster --- it would ensure the = death of Opensim versus any extensible alternative that may appear.=A0 Deve= loping new extensible forms of world data beyond SL's original set is a= must for Opensim's survival as a modern VW platform.

  • SL's viewer has deep knowledge of SL semantics be= cause the client and server were designed for each other rather than design= ed as endpoints of a standard protocol.=A0 This has the very bad consequenc= e that future VW viewers would need to know about SL specifics in order to = interoperate with SL, which is a poor approach that doesn't scale to me= taverse-wide diversity.=A0 Opensim needs to leave world-specific kludges be= hind if it has ambitions to underpin a highly diverse metaverse of worlds, = and this means leaving the SL viewer behind.

  • SL's constructed objects are non-hierarchical, = which means that creators cannot use objects created by others as subcompon= ents.=A0 This restriction completely blocks the hierarchical engineering pr= ocess that is the basis of progress in RL.=A0 In SL you always have to buil= d from "raw materials", so it is not possible to ride on the shou= lders of giants, nor harness a huge pyramid of people skills.=A0 Even Phili= p and Cory Linden admitted that this was a mistake -- see=A0 https://wiki.secon= dlife.com/wiki/Prim_and_Object_Hierarchy .=A0 We don't want to live= with their mistake.

  • SL is based on highly centralized concepts of id= entity, storage and control, which come together to create either a wal= led garden or a prison planet, depending on one's perspective.=A0 Whate= ver one's worldview, the end result is badly non-scalable in those thre= e areas.=A0 SL suffers hugely from that non-scalability despite the relativ= ely small size of the service at this early stage.=A0 Opensim needs decentr= alized / distributed mechanisms for identity, storage and control if= it is to scale for Internet-wide adoption.

  • From a futurist angle, Second Life has very narrow horizon= s and barely pays lip service to the virtual aspect of "= virtual worlds".=A0 Nobody could claim that a Flatland of square land = tiles all featuring the same Earth-like look and physics pushes the envelop= e of the imagination.=A0 To boldly go where Lindens did not go before (topo= logically and geographically or spatially) will be one of the most apprecia= ted developments in Opensim.=A0 SL's obsession with RL is an unwanted c= onstraint in VWs, and we need to go beyond it.


That is not the full list of problems with SL, but hopefu= lly it serves to illustrate some of the concerns that VW developers have to= consider in the light of the SL legacy.=A0 While Linden Lab deserves much = applause for their vision and for their work in creating Second Life, many = years have now passed, and lessons have been learned.=A0 Compatibility with= SL must not be the end goal of Opensim because of issues like those highli= ghted above.

From a longer perspective, SL represents only the first step in the evo= lution of virtual worlds.=A0 It is no surprise that most Opensim developers= wish to go beyond that first step, learning from past mistakes and finding= better models for the future.

I mentioned earlier our work at the IETF on new VW protocols, in which = LL are a leading party --- see=A0 https://www.ietf.org/mailman/listinfo/ogpx , the mailing = list of the VWRAP working group.=A0 What may surprise you is that even Lind= ens know that the current SL is not a good model for the future, which is w= hy the protocols being discussed go far beyond their legacy ones.=A0 Indeed= , Lindens will be facing a huge rewrite if this work bears fruit.=A0 When e= ven Lindens don't wish their future to be constrained by the current SL= design because they know its many problems, this really highlights how bad= it would be for the Opensim team to do so. :-)

I hope that one or more of these issues resonates with you, and makes i= t a bit clearer why Opensim really cannot afford to align itself with SL.= =A0 There is no future in looking backwards.


Morgaine.





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Mon, Nov 23, 2009 at 1:06 PM, Len Brown <lenwbrown at gmail.com>= ; wrote:
Rock,

=A0= =A0=A0=A0 I sympathize with you on many levels.=A0 I've also had my dou= bts regarding the future of OpenSim, but I have also maintained some degree= of faith that things will pull through in the end.

=A0=A0=A0=A0 For me the shock came when I was abruptly informed that &q= uot;OpenSim is not Second Life, is not intended to be like Second Life, nor= ever will."=A0 I still haven't the foggiest idea what this develo= per had smoked for them to so strongly assert that incredibly false stateme= nt.

=A0=A0=A0=A0 For me, the enjoyment of OpenSim has come from my intense = devotion to building and skinning.=A0 In fact, for the last few months I= 9;ve been working on a full region that has many hundreds of skins, clothes= , hair, furniture, etc, etc, that I'd like to package up as an OAR and = give out freely, since repeatedly I've been told that instead of giving= money to help further OpenSim I'd do more proactively by giving conten= t.=A0 So I plan to do just that and give my money to other open source init= iatives that matter to me.

=A0=A0=A0=A0 I have a passion for writing, and have thought many times = that one of the greatest powers OpenSim would gain is having simple, straig= htforward, step-by-step instructions on how to download, compile, install, = administer and overall just plain operate the core applications.=A0 What ki= lls me is that everyone who does a search for OpenSim inevitably hits the <= a href=3D"http://opensimulator.org" target=3D"_blank">opensimulator.org= site and that is where the massive roadblock presents itself.=A0 It's = useless for most and irrelevant to the few who consider themselves OpenSim = experts.

=A0=A0=A0=A0 Heck, even now on the configuration page it still displays= info for 0.6.6 including (months old) known bugs in setting up region xml = files.=A0 If there was appointed a volunteer whose sole job was to keep inf= ormation on opensimu= lator.org relevant that one task would resolve a mountain of negativity= right there.=A0 I sit here in front of my computers a good 10 to 12 hours = a day.

=A0=A0=A0=A0 I would sincerely love to contribute to the OpenSim projec= t, especially in documentation support.=A0 But the thing holding me back is= communication.=A0 If I cannot get a straight answer on who to GIVE money t= o in order to help, then I stand little chance of getting clear, straight a= nswers from developers when asking about issues I need to consider and inco= rporate in documentation.

=A0=A0=A0=A0 If communication is a hurdle we can all overcome, with a g= enuine and heart-felt effort to relay information, motives, and plans with = one another, then I'd sincerely appreciate having the opportunity to pe= rsonally contribute.=A0 I'm not a programmer today, but have a degree i= n programming fro the 90's (so much has changed my degree is practicall= y useless in that regard).=A0 But I do know how to explain things and relay= information in simple terms.=A0 But only if my own questions will be answe= red with more than "look it up or figure it out yourself" as my a= nswer.

=A0=A0=A0=A0 If any of you would appreciate my help, feel free to let m= e know at any time and I'll do what I can.

- Len W. Brown
=A0= =A0=A0=A0 lenwbrow= n at gmail.com


On Mon, Nov 23, 2009 at 6:23 AM, Colin B. Withers <Colin.Withers@= eumetsat.int> wrote:
Hi guys,

I have decided to leave the Opensim project. You will probably not even not= ice if I leave, as not being a programmer my only inputs were the writing o= f the step-by-step tutorials ( http://chapter-and-metaverse.blogspot.com/= ), the drafts of the OpenSim User Manual on the Forge, and helping out in = the IRC channels, for newcomers.

You may find my reasons for leaving Opensim interesting though (and please = do not construe any of my reasons as an attack on anyone).

1. The Platform
I raised this several times in the past in IRC, and made posts on my blog a= bout the product lifecycle of the platform ( h= ttp://rock-vacirca.blogspot.com/2009/02/direction-of-virtual-worlds.html ). I believe that the platforms underpinning both Second Life and Opensim= are quite long in the tooth now, and I questioned how much product lifecyc= le there was left, particularly given that Opensim is now nearing 3 years o= f development, is still in Alpha, and if the current release of 0.6.7 is an= y indicator, then still only around two thirds into the development cycle. = With the (inevitable) coming of much superior platforms, such as Blue Mars = and (as a virtual world); Unity, for browser-based Virtual Wolrds; and now = UDK (for creating sandboxes, standalones, and open grids), then I fear that= Opensim has missed the boat as far as the remaining lifecycle of the platf= orm is concerned. When you show people what is possible with these engines = (for example this avatar editor for the forthcom
=A0ing APB (using the Unreal Engine): http://www.youtube.com/watch?v=3DicR3= LtEMvZI or this city: http://www.youtube.com/watch?v=3DhmLzNbPXMDg = (using the CryEngine), then neither SL not Opensim stands comparison.

2. Lack of Support for Currency in Opensim
I felt the impact of this when I first made the switch from SL to Opensim. = I had a thriving RP sim in SL (over 50 people, mainly female) and they all = agreed to follow me over to my Opensim and the OSGrid. However, within a mo= nth they had all left, citing the same reason, the lack of places to shop, = to buy the quality stuff they wanted (skins, hair, clothes etc), as a quali= ty appearance, and the fun of shopping is what all the females placed high = on their requirements from a Virtual World. They drifted back to Second Lif= e, and the guys followed them. I have always believed that the lack of supp= ort for currency in the core was a mistake, but that is just my opinion.
3. Marketing
I have also raised this issue several times, and blogged about it. It is fa= r from clear just who an eventually released Opensim is actually aimed at. = I think that any company that is interested in a firewalled corporate solut= ion to collaboration and prototyping will already be looking at the Enterpr= ise solution that is currently available from Second Life; that any indie g= roup that is thinking of running a themed grid will need an economy to stay= viable; and any individual who is looking for a private sandbox solution f= or their SL work will need full compatibility (which is not the case with t= he OS version of LSL diverging from the SL LSL). So, just who is the platfo= rm aimed at? I was also very disappointed in the view of one of the core de= vs who said that 'marketing is a null concept for us'.

I am currently designing and creating cities for Blue Mars, and involved in= a team for proving the UDK as a platform for the design and creation of Vi= rtual Worlds (as opposed to purely games), and with so much documentation a= vailable for these mature engines (particularly for the UDK, Blue Mars lags= behind somewhat in that department, but have hired extra staff to put that= right), I am achieving the productivity I want, building the worlds that I= want, with stable crash-free platforms.

However, I do wish the Opensim team the very best in their endeavours, and = I sincerely hope their goals are eventually achieved.

If anyone would like to take over the Opensim Tutorials pages at http://chapt= er-and-metaverse.blogspot.com/ and http://chapter-and-metaverse2.blogspo= t.com/ (they will need some updating following several changes) then I = am more than willing to pass the posts over, and of course the Opensim User= Manual is there in the Forge for anyone to develop further.

Best Regards and Good Luck

Rock


_______________________________________________
Opensim-dev mailing list
Opensim-d= ev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev


_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.d= e
https://lists.berlios.de/mailman/listinfo/opensim-dev


--0016e6d7eefa4147ee047911d695-- From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: evolution of virtual worlds. It is no surprise that most Opensim developers wish to go beyond that first step, learning from past mistakes and finding better models for the future. I mentioned earlier our work at the IETF on new VW protocols, in which LL are a leading party --- see https://www.ietf.org/mailman/listinfo/ogpx , the mailing list of the VWRAP working group. What may surprise you is that even Lindens know that the current SL is not a good model for the future, which is why the protocols being discussed go far beyond their legacy ones. Indeed, Lindens will be facing a huge rewrite if this work bears fruit. When even Lindens don't wish their future to be constrained by the current SL design because they know its many problems, this really highlights how bad it would be for the Opensim team to do so. :-) I hope that one or more of these issues resonates with you, and makes it a bit clearer why Opensim really cannot afford to align itself with SL. There is no future in looking backwards. Morgaine. ======================================= On Mon, Nov 23, 2009 at 1:06 PM, Len Brown wrote: Rock, I sympathize with you on many levels. I've also had my doubts regarding the future of OpenSim, but I have also maintained some degree of faith that things will pull through in the end. For me the shock came when I was abruptly informed that "OpenSim is not Second Life, is not intended to be like Second Life, nor ever will." I still haven't the foggiest idea what this developer had smoked for them to so strongly assert that incredibly false statement. For me, the enjoyment of OpenSim has come from my intense devotion to building and skinning. In fact, for the last few months I've been working on a full region that has many hundreds of skins, clothes, hair, furniture, etc, etc, that I'd like to package up as an OAR and give out freely, since repeatedly I've been told that instead of giving money to help further OpenSim I'd do more proactively by giving content. So I plan to do just that and give my money to other open source initiatives that matter to me. I have a passion for writing, and have thought many times that one of the greatest powers OpenSim would gain is having simple, straightforward, step-by-step instructions on how to download, compile, install, administer and overall just plain operate the core applications. What kills me is that everyone who does a search for OpenSim inevitably hits the opensimulator.org site and that is where the massive roadblock presents itself. It's useless for most and irrelevant to the few who consider themselves OpenSim experts. Heck, even now on the configuration page it still displays info for 0.6.6 including (months old) known bugs in setting up region xml files. If there was appointed a volunteer whose sole job was to keep information on opensimulator.org relevant that one task would resolve a mountain of negativity right there. I sit here in front of my computers a good 10 to 12 hours a day. I would sincerely love to contribute to the OpenSim project, especially in documentation support. But the thing holding me back is communication. If I cannot get a straight answer on who to GIVE money to in order to help, then I stand little chance of getting clear, straight answers from developers when asking about issues I need to consider and incorporate in documentation. If communication is a hurdle we can all overcome, with a genuine and heart-felt effort to relay information, motives, and plans with one another, then I'd sincerely appreciate having the opportunity to personally contribute. I'm not a programmer today, but have a degree in programming fro the 90's (so much has changed my degree is practically useless in that regard). But I do know how to explain things and relay information in simple terms. But only if my own questions will be answered with more than "look it up or figure it out yourself" as my answer. If any of you would appreciate my help, feel free to let me know at any time and I'll do what I can. - Len W. Brown lenwbrown at gmail.com On Mon, Nov 23, 2009 at 6:23 AM, Colin B. Withers wrote: Hi guys, I have decided to leave the Opensim project. You will probably not even notice if I leave, as not being a programmer my only inputs were the writing of the step-by-step tutorials ( http://chapter-and-metaverse.blogspot.com/ ), the drafts of the OpenSim User Manual on the Forge, and helping out in the IRC channels, for newcomers. You may find my reasons for leaving Opensim interesting though (and please do not construe any of my reasons as an attack on anyone). 1. The Platform I raised this several times in the past in IRC, and made posts on my blog about the product lifecycle of the platform ( http://rock-vacirca.blogspot.com/2009/02/direction-of-virtual-worlds.html ). I believe that the platforms underpinning both Second Life and Opensim are quite long in the tooth now, and I questioned how much product lifecycle there was left, particularly given that Opensim is now nearing 3 years of development, is still in Alpha, and if the current release of 0.6.7 is any indicator, then still only around two thirds into the development cycle. With the (inevitable) coming of much superior platforms, such as Blue Mars and (as a virtual world); Unity, for browser-based Virtual Wolrds; and now UDK (for creating sandboxes, standalones, and open grids), then I fear that Opensim has missed the boat as far as the remaining lifecycle of the platform is concerned. When you show people what is possible with these engines (for example this avatar editor for the forthcom ing APB (using the Unreal Engine): http://www.youtube.com/watch?v=icR3LtEMvZI or this city: http://www.youtube.com/watch?v=hmLzNbPXMDg (using the CryEngine), then neither SL not Opensim stands comparison. 2. Lack of Support for Currency in Opensim I felt the impact of this when I first made the switch from SL to Opensim. I had a thriving RP sim in SL (over 50 people, mainly female) and they all agreed to follow me over to my Opensim and the OSGrid. However, within a month they had all left, citing the same reason, the lack of places to shop, to buy the quality stuff they wanted (skins, hair, clothes etc), as a quality appearance, and the fun of shopping is what all the females placed high on their requirements from a Virtual World. They drifted back to Second Life, and the guys followed them. I have always believed that the lack of support for currency in the core was a mistake, but that is just my opinion. 3. Marketing I have also raised this issue several times, and blogged about it. It is far from clear just who an eventually released Opensim is actually aimed at. I think that any company that is interested in a firewalled corporate solution to collaboration and prototyping will already be looking at the Enterprise solution that is currently available from Second Life; that any indie group that is thinking of running a themed grid will need an economy to stay viable; and any individual who is looking for a private sandbox solution for their SL work will need full compatibility (which is not the case with the OS version of LSL diverging from the SL LSL). So, just who is the platform aimed at? I was also very disappointed in the view of one of the core devs who said that 'marketing is a null concept for us'. I am currently designing and creating cities for Blue Mars, and involved in a team for proving the UDK as a platform for the design and creation of Virtual Worlds (as opposed to purely games), and with so much documentation available for these mature engines (particularly for the UDK, Blue Mars lags behind somewhat in that department, but have hired extra staff to put that right), I am achieving the productivity I want, building the worlds that I want, with stable crash-free platforms. However, I do wish the Opensim team the very best in their endeavours, and I sincerely hope their goals are eventually achieved. If anyone would like to take over the Opensim Tutorials pages at http://chapter-and-metaverse.blogspot.com/ and http://chapter-and-metaverse2.blogspot.com/ (they will need some updating following several changes) then I am more than willing to pass the posts over, and of course the Opensim User Manual is there in the Forge for anyone to develop further. Best Regards and Good Luck Rock _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.709 / Virus Database: 270.14.78/2521 - Release Date: 11/23/09 14:45:00 ------=_NextPart_000_002A_01CA6C68.7723E480 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

What she said! Thank you Morgaine for clarifying this for = all of us.  In my opinion this discussion was appropriate here to = understand roadmap and documentation efforts.  Thanks for caring to let the rest of = the community hear about your very smart opinions.  More talk like this will = bring the community together wherever it occurs.

 

From:= opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of = Morgaine
Sent: Monday, November 23, 2009 6:04 PM
To: opensim-dev at lists.berlios.de
Subject: Re: [Opensim-dev] Leaving Project

 

On Mon, Nov 23, 2009 at 1:06 PM, Len Brown <lenwbrown at gmail.com> = wrote:

 

For me the shock came when I was abruptly informed = that "OpenSim is not Second Life, is not intended to be like Second Life, nor ever will."  I still haven't the foggiest idea what this = developer had smoked for them to so strongly assert that incredibly false = statement.



Len, let me give you an alternative perspective on that quote to help = you see the reasons for it.  I'm not on the Opensim team, but after five = years in SL, two years in AWG, and a year of working on future VW protocols in = our IETF group, I have some background to know why Opensim needs to distance = itself from SL:

  • SL's statically tiled resource = architecture is badly non-scalable, because most resource usage in VWs = cannot be statically mapped (demand moves around).  The inability to = assign resources dynamically in SL results in huge overload in busy places = and gross wastage in idle areas.  It also limits the number of participants in events and the bandwidth of their interaction, as = well as the size and complexity of everything in a region.  This = architecture is fundamental to SL, yet it is a recipe for failure.  As long = as Opensim adheres to the SL model, Opensim will be similarly = non-scalable.

 

  • The LSL scripting language is = linguistically weak, semantically obscure, and lacking in the glue that could = allow components to cooperate effectively.  As a result, individual = scripts are quite underpowered and inefficient, and multi-script = constructions do not scale well in complexity because the overheads of cooperation = are so large.  That's a bad restriction on progress which Opensim = needs to leave behind.

 

  • LSL scripts are not scalable in power or = size, and this will continue to be true even after SL allows C# and other = CLR languages to be used.  There is no possibility of using more = CPU power for scripting than is available in one single simulator in = SL.  That is not a good foundation upon which to build an ambitious = future of clever components.

 

  • SL's simulation environment is = non-portable, having evolved over time into a plethora of special cases that will = not be accurately replicable anywhere else.  In effect this means = that there will never be effective interop with SL's scripted objects.  = It would not be a useful goal to seek compatibility with what could = realistically be described as an "ill-defined mess".

 

  • SL's object and type systems are = non-extensible, so compatibility with SL means living in the past, and worse, = living in a past defined entirely by one slow-moving company.  Tying the capabilities of Opensim to that millstone would be a disaster --- = it would ensure the death of Opensim versus any extensible alternative that = may appear.  Developing new extensible forms of world data beyond = SL's original set is a must for Opensim's survival as a modern VW = platform.

 

  • SL's viewer has deep knowledge of SL = semantics because the client and server were designed for each other rather = than designed as endpoints of a standard protocol.  This has the = very bad consequence that future VW viewers would need to know about SL = specifics in order to interoperate with SL, which is a poor approach that = doesn't scale to metaverse-wide diversity.  Opensim needs to leave world-specific kludges behind if it has ambitions to underpin a = highly diverse metaverse of worlds, and this means leaving the SL viewer = behind.

 

  • SL's constructed objects are = non-hierarchical, which means that creators cannot use objects created by others as subcomponents.  This restriction completely blocks the = hierarchical engineering process that is the basis of progress in RL.  In = SL you always have to build from "raw materials", so it is not = possible to ride on the shoulders of giants, nor harness a huge pyramid of = people skills.  Even Philip and Cory Linden admitted that this was a = mistake -- see  https= ://wiki.secondlife.com/wiki/Prim_and_Object_Hierarchy .  We don't want to live with their mistake.

 

  • SL is based on highly centralized = concepts of identity, storage and control, which come together to = create either a walled garden or a prison planet, depending on one's perspective.  Whatever one's worldview, the end result is = badly non-scalable in those three areas.  SL suffers hugely from = that non-scalability despite the relatively small size of the service at = this early stage.  Opensim needs decentralized / distributed = mechanisms for identity, storage and control if it is to scale for = Internet-wide adoption.

 

  • From a futurist angle, Second Life has = very narrow horizons and barely pays lip service to the = virtual aspect of "virtual worlds".  Nobody could claim that = a Flatland of square land tiles all featuring the same Earth-like = look and physics pushes the envelope of the imagination.  To boldly go = where Lindens did not go before (topologically and geographically or = spatially) will be one of the most appreciated developments in Opensim.  = SL's obsession with RL is an unwanted constraint in VWs, and we need to = go beyond it.



That is not the full list of problems with SL, but hopefully it serves = to illustrate some of the concerns that VW developers have to consider in = the light of the SL legacy.  While Linden Lab deserves much applause = for their vision and for their work in creating Second Life, many years have now = passed, and lessons have been learned.  Compatibility with SL must not be = the end goal of Opensim because of issues like those highlighted above.

From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: evolution of virtual worlds.  It is no surprise that most Opensim developers = wish to go beyond that first step, learning from past mistakes and finding = better models for the future.

I mentioned earlier our work at the IETF on new VW protocols, in which = LL are a leading party --- see  https://www.ietf.org/= mailman/listinfo/ogpx , the mailing list of the VWRAP working group.  What may surprise = you is that even Lindens know that the current SL is not a good model for the = future, which is why the protocols being discussed go far beyond their legacy ones.  Indeed, Lindens will be facing a huge rewrite if this work = bears fruit.  When even Lindens don't wish their future to be constrained = by the current SL design because they know its many problems, this really = highlights how bad it would be for the Opensim team to do so. :-)

I hope that one or more of these issues resonates with you, and makes it = a bit clearer why Opensim really cannot afford to align itself with SL.  = There is no future in looking backwards.


Morgaine.






=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Mon, Nov 23, 2009 at 1:06 PM, Len Brown <lenwbrown at gmail.com> = wrote:

Rock,

     I sympathize with you on many levels.  = I've also had my doubts regarding the future of OpenSim, but I have also = maintained some degree of faith that things will pull through in the end.

     For me the shock came when I was abruptly = informed that "OpenSim is not Second Life, is not intended to be like Second = Life, nor ever will."  I still haven't the foggiest idea what this developer had smoked for them to so strongly assert that incredibly = false statement.

     For me, the enjoyment of OpenSim has come from = my intense devotion to building and skinning.  In fact, for the last = few months I've been working on a full region that has many hundreds of = skins, clothes, hair, furniture, etc, etc, that I'd like to package up as an = OAR and give out freely, since repeatedly I've been told that instead of giving = money to help further OpenSim I'd do more proactively by giving content.  = So I plan to do just that and give my money to other open source initiatives = that matter to me.

     I have a passion for writing, and have thought = many times that one of the greatest powers OpenSim would gain is having = simple, straightforward, step-by-step instructions on how to download, compile, install, administer and overall just plain operate the core = applications.  What kills me is that everyone who does a search for OpenSim inevitably = hits the opensimulator.org site and that is where the massive roadblock presents itself.  It's useless for most and irrelevant to the few who consider themselves = OpenSim experts.

     Heck, even now on the configuration page it = still displays info for 0.6.6 including (months old) known bugs in setting up = region xml files.  If there was appointed a volunteer whose sole job was = to keep information on opensimulator.org relevant that one task would resolve a mountain of negativity right there.  I sit here in front of my computers a good 10 to 12 hours a = day.

     I would sincerely love to contribute to the = OpenSim project, especially in documentation support.  But the thing = holding me back is communication.  If I cannot get a straight answer on who to = GIVE money to in order to help, then I stand little chance of getting clear, straight answers from developers when asking about issues I need to = consider and incorporate in documentation.

     If communication is a hurdle we can all = overcome, with a genuine and heart-felt effort to relay information, motives, and plans = with one another, then I'd sincerely appreciate having the opportunity to = personally contribute.  I'm not a programmer today, but have a degree in = programming fro the 90's (so much has changed my degree is practically useless in = that regard).  But I do know how to explain things and relay information = in simple terms.  But only if my own questions will be answered with = more than "look it up or figure it out yourself" as my answer.

     If any of you would appreciate my help, feel = free to let me know at any time and I'll do what I can.

- Len W. Brown
     lenwbrown at gmail.com

 

On Mon, Nov 23, 2009 at 6:23 AM, Colin B. Withers = <Colin.Withers at eumetsat.int> wrote:

Hi guys,

I have decided to leave the Opensim project. You will probably not even = notice if I leave, as not being a programmer my only inputs were the writing of = the step-by-step tutorials ( http://chapter-and-metaverse.blogspot.com/ ), the = drafts of the OpenSim User Manual on the Forge, and helping out in the IRC = channels, for newcomers.

You may find my reasons for leaving Opensim interesting though (and = please do not construe any of my reasons as an attack on anyone).

1. The Platform
I raised this several times in the past in IRC, and made posts on my = blog about the product lifecycle of the platform ( http://rock-vacirca.blogspot.com/2009/02/direction-of-v= irtual-worlds.html ). I believe that the platforms underpinning both Second Life and = Opensim are quite long in the tooth now, and I questioned how much product lifecycle = there was left, particularly given that Opensim is now nearing 3 years of development, is still in Alpha, and if the current release of 0.6.7 is = any indicator, then still only around two thirds into the development cycle. = With the (inevitable) coming of much superior platforms, such as Blue Mars = and (as a virtual world); Unity, for browser-based Virtual Wolrds; and now UDK = (for creating sandboxes, standalones, and open grids), then I fear that = Opensim has missed the boat as far as the remaining lifecycle of the platform is = concerned. When you show people what is possible with these engines (for example = this avatar editor for the forthcom
 ing APB (using the Unreal Engine): http://www.youtube.com/watch?v=3DicR3LtEMvZI or this city: http://www.youtube.com/watch?v=3DhmLzNbPXMDg = (using the CryEngine), then neither SL not Opensim stands comparison.

2. Lack of Support for Currency in Opensim
I felt the impact of this when I first made the switch from SL to = Opensim. I had a thriving RP sim in SL (over 50 people, mainly female) and they all = agreed to follow me over to my Opensim and the OSGrid. However, within a month = they had all left, citing the same reason, the lack of places to shop, to buy = the quality stuff they wanted (skins, hair, clothes etc), as a quality = appearance, and the fun of shopping is what all the females placed high on their requirements from a Virtual World. They drifted back to Second Life, and = the guys followed them. I have always believed that the lack of support for currency in the core was a mistake, but that is just my opinion.

3. Marketing
I have also raised this issue several times, and blogged about it. It is = far from clear just who an eventually released Opensim is actually aimed at. = I think that any company that is interested in a firewalled corporate = solution to collaboration and prototyping will already be looking at the Enterprise solution that is currently available from Second Life; that any indie = group that is thinking of running a themed grid will need an economy to stay = viable; and any individual who is looking for a private sandbox solution for = their SL work will need full compatibility (which is not the case with the OS = version of LSL diverging from the SL LSL). So, just who is the platform aimed at? I = was also very disappointed in the view of one of the core devs who said that 'marketing is a null concept for us'.

I am currently designing and creating cities for Blue Mars, and involved = in a team for proving the UDK as a platform for the design and creation of = Virtual Worlds (as opposed to purely games), and with so much documentation = available for these mature engines (particularly for the UDK, Blue Mars lags = behind somewhat in that department, but have hired extra staff to put that = right), I am achieving the productivity I want, building the worlds that I want, = with stable crash-free platforms.

However, I do wish the Opensim team the very best in their endeavours, = and I sincerely hope their goals are eventually achieved.

If anyone would like to take over the Opensim Tutorials pages at http://chapter-and-metaverse.blogspot.com/ and http://chapter-and-metaverse2.blogspot.com/ (they will need some updating following several changes) then I am more = than willing to pass the posts over, and of course the Opensim User Manual is = there in the Forge for anyone to develop further.

Best Regards and Good Luck

Rock


_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

 


_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de=
https://lists.berlios.de/mailman/listinfo/opensim-dev

 

No = virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.709 / Virus Database: 270.14.78/2521 - Release Date: = 11/23/09 14:45:00

------=_NextPart_000_002A_01CA6C68.7723E480-- From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: on of virtual worlds.=A0 It is no surprise that most Opensim developers wish t= o go beyond that first step, learning from past mistakes and finding better models for the future.

I mentioned earlier our work at the IETF on new VW protocols, in which LL a= re a leading party --- see=A0 https://www.ietf.org/mailman/listinfo/ogpx , the mailing list of the VWRAP working group.=A0 What may surprise you is that even Lindens know that the current SL is not a good model for the futu= re, which is why the protocols being discussed go far beyond their legacy ones.=A0 Indeed, Lindens will be facing a huge rewrite if this work bears fruit.=A0 When even Lindens don't wish their future to be constrained b= y the current SL design because they know its many problems, this really highligh= ts how bad it would be for the Opensim team to do so. :-)

I hope that one or more of these issues resonates with you, and makes it a = bit clearer why Opensim really cannot afford to align itself with SL.=A0 There is no future in looking backwards.


Morgaine.






=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Mon, Nov 23, 2009 at 1:06 PM, Len Brown <lenwbrown at gmail.com= > wrote:

Rock,

=A0=A0=A0=A0 I sympathize with you on many levels.=A0 I've also had my doubts regarding the future of OpenSim, but I have also maintained s= ome degree of faith that things will pull through in the end.

=A0=A0=A0=A0 For me the shock came when I was abruptly informed that "OpenSim is not Second Life, is not intended to be like Second Li= fe, nor ever will."=A0 I still haven't the foggiest idea what this developer had smoked for them to so strongly assert that incredibly false statement.

=A0=A0=A0=A0 For me, the enjoyment of OpenSim has come from my intense devotion to building and skinning.=A0 In fact, for the last few months I've been working on a full region that has many hundreds of ski= ns, clothes, hair, furniture, etc, etc, that I'd like to package up as an O= AR and give out freely, since repeatedly I've been told that instead of giving= money to help further OpenSim I'd do more proactively by giving content.=A0 S= o I plan to do just that and give my money to other open source initiatives tha= t matter to me.

=A0=A0=A0=A0 I have a passion for writing, and have thought many times that one of the greatest powers OpenSim would gain is having simple, straightforward, step-by-step instructions on how to download, compile, install, administer and overall just plain operate the core applications.= =A0 What kills me is that everyone who does a search for OpenSim inevitably hit= s the opensimulator.or= g site and that is where the massive roadblock presents itself.=A0 It's useless for most and irrelevant to the few who consider themselves OpenSim experts.

=A0=A0=A0=A0 Heck, even now on the configuration page it still displays info for 0.6.6 including (months old) known bugs in setting up reg= ion xml files.=A0 If there was appointed a volunteer whose sole job was to keep information on opens= imulator.org relevant that one task would resolve a mountain of negativity right there.=A0 I sit here in front of my computers a good 10 to 12 hours a day.<= br>
=A0=A0=A0=A0 I would sincerely love to contribute to the OpenSim project, especially in documentation support.=A0 But the thing holding me back is communication.=A0 If I cannot get a straight answer on who to GIVE money to in order to help, then I stand little chance of getting clear, straight answers from developers when asking about issues I need to conside= r and incorporate in documentation.

=A0=A0=A0=A0 If communication is a hurdle we can all overcome, with a genuine and heart-felt effort to relay information, motives, and plans wi= th one another, then I'd sincerely appreciate having the opportunity to pe= rsonally contribute.=A0 I'm not a programmer today, but have a degree in program= ming fro the 90's (so much has changed my degree is practically useless in t= hat regard).=A0 But I do know how to explain things and relay information in simple terms.=A0 But only if my own questions will be answered with more than "look it up or figure it out yourself" as my answer.

=A0=A0=A0=A0 If any of you would appreciate my help, feel free to let me know at any time and I'll do what I can.

- Len W. Brown
=A0=A0=A0=A0 lenwb= rown at gmail.com

=A0

On Mon, Nov 23, 2009 at 6:23 AM, Colin B. Withers &l= t;Colin.Wit= hers at eumetsat.int> wrote:

Hi guys,

I have decided to leave the Opensim project. You will probably not even not= ice if I leave, as not being a programmer my only inputs were the writing of th= e step-by-step tutorials ( http://chapter-and-metaverse.blogspot.com/ ), th= e drafts of the OpenSim User Manual on the Forge, and helping out in the IRC channels, = for newcomers.

You may find my reasons for leaving Opensim interesting though (and please = do not construe any of my reasons as an attack on anyone).

1. The Platform
I raised this several times in the past in IRC, and made posts on my blog a= bout the product lifecycle of the platform ( http:/= /rock-vacirca.blogspot.com/2009/02/direction-of-virtual-worlds.html ). I believe that the platforms underpinning both Second Life and Opensim a= re quite long in the tooth now, and I questioned how much product lifecycle th= ere was left, particularly given that Opensim is now nearing 3 years of development, is still in Alpha, and if the current release of 0.6.7 is any indicator, then still only around two thirds into the development cycle. Wi= th the (inevitable) coming of much superior platforms, such as Blue Mars and (= as a virtual world); Unity, for browser-based Virtual Wolrds; and now UDK (for creating sandboxes, standalones, and open grids), then I fear that Opensim = has missed the boat as far as the remaining lifecycle of the platform is concer= ned. When you show people what is possible with these engines (for example this avatar editor for the forthcom
=A0ing APB (using the Unreal Engine): http://www.youtube.com/watch?v=3DicR3= LtEMvZI or this city: http://www.youtube.com/watch?v=3DhmLzNbPXMDg (using the CryEngine), then neither SL not Opensim stands comparison.

2. Lack of Support for Currency in Opensim
I felt the impact of this when I first made the switch from SL to Opensim. = I had a thriving RP sim in SL (over 50 people, mainly female) and they all ag= reed to follow me over to my Opensim and the OSGrid. However, within a month the= y had all left, citing the same reason, the lack of places to shop, to buy th= e quality stuff they wanted (skins, hair, clothes etc), as a quality appearan= ce, and the fun of shopping is what all the females placed high on their requirements from a Virtual World. They drifted back to Second Life, and th= e guys followed them. I have always believed that the lack of support for currency in the core was a mistake, but that is just my opinion.

3. Marketing
I have also raised this issue several times, and blogged about it. It is fa= r from clear just who an eventually released Opensim is actually aimed at. I think that any company that is interested in a firewalled corporate solutio= n to collaboration and prototyping will already be looking at the Enterprise solution that is currently available from Second Life; that any indie group that is thinking of running a themed grid will need an economy to stay viab= le; and any individual who is looking for a private sandbox solution for their = SL work will need full compatibility (which is not the case with the OS versio= n of LSL diverging from the SL LSL). So, just who is the platform aimed at? I wa= s also very disappointed in the view of one of the core devs who said that 'marketing is a null concept for us'.

I am currently designing and creating cities for Blue Mars, and involved in= a team for proving the UDK as a platform for the design and creation of Virtu= al Worlds (as opposed to purely games), and with so much documentation availab= le for these mature engines (particularly for the UDK, Blue Mars lags behind somewhat in that department, but have hired extra staff to put that right),= I am achieving the productivity I want, building the worlds that I want, with stable crash-free platforms.

However, I do wish the Opensim team the very best in their endeavours, and = I sincerely hope their goals are eventually achieved.

If anyone would like to take over the Opensim Tutorials pages at http://chapt= er-and-metaverse.blogspot.com/ and http://chapter-and-metaverse2.blogspot.com/ (they will need some updating following several changes) then I am more tha= n willing to pass the posts over, and of course the Opensim User Manual is th= ere in the Forge for anyone to develop further.

Best Regards and Good Luck

Rock


_______________________________________________
Opensim-dev mailing list
Opensim-d= ev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

=A0


_______________________________________________
Opensim-dev mailing list
Opensim-d= ev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

=A0

No virus found in this incoming message.


Checked by AVG - www.avg.c= om
Version: 9.0.709 / Virus Database: 270.14.78/2521 - Release Date: 11/23/09 14:45:00


_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.d= e
https://lists.berlios.de/mailman/listinfo/opensim-dev




--
=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
http://osgrid.org
http://del.icio.us/SPQR
http://twitter.com/jstallings2
http://www.linkedin.com/p= ub/5/770/a49
--0016364ed520fa4d130479123119-- From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: evolution of virtual worlds. It is no surprise that most Opensim developers wish to go beyond that first step, learning from past mistakes and finding better models for the future. I mentioned earlier our work at the IETF on new VW protocols, in which LL are a leading party --- see https://www.ietf.org/mailman/listinfo/ogpx , the mailing list of the VWRAP working group. What may surprise you is that even Lindens know that the current SL is not a good model for the future, which is why the protocols being discussed go far beyond their legacy ones. Indeed, Lindens will be facing a huge rewrite if this work bears fruit. When even Lindens don't wish their future to be constrained by the current SL design because they know its many problems, this really highlights how bad it would be for the Opensim team to do so. :-) I hope that one or more of these issues resonates with you, and makes it a bit clearer why Opensim really cannot afford to align itself with SL. There is no future in looking backwards. Morgaine. ======================================= On Mon, Nov 23, 2009 at 1:06 PM, Len Brown wrote: Rock, I sympathize with you on many levels. I've also had my doubts regarding the future of OpenSim, but I have also maintained some degree of faith that things will pull through in the end. For me the shock came when I was abruptly informed that "OpenSim is not Second Life, is not intended to be like Second Life, nor ever will." I still haven't the foggiest idea what this developer had smoked for them to so strongly assert that incredibly false statement. For me, the enjoyment of OpenSim has come from my intense devotion to building and skinning. In fact, for the last few months I've been working on a full region that has many hundreds of skins, clothes, hair, furniture, etc, etc, that I'd like to package up as an OAR and give out freely, since repeatedly I've been told that instead of giving money to help further OpenSim I'd do more proactively by giving content. So I plan to do just that and give my money to other open source initiatives that matter to me. I have a passion for writing, and have thought many times that one of the greatest powers OpenSim would gain is having simple, straightforward, step-by-step instructions on how to download, compile, install, administer and overall just plain operate the core applications. What kills me is that everyone who does a search for OpenSim inevitably hits the opensimulator.org site and that is where the massive roadblock presents itself. It's useless for most and irrelevant to the few who consider themselves OpenSim experts. Heck, even now on the configuration page it still displays info for 0.6.6 including (months old) known bugs in setting up region xml files. If there was appointed a volunteer whose sole job was to keep information on opensimulator.org relevant that one task would resolve a mountain of negativity right there. I sit here in front of my computers a good 10 to 12 hours a day. I would sincerely love to contribute to the OpenSim project, especially in documentation support. But the thing holding me back is communication. If I cannot get a straight answer on who to GIVE money to in order to help, then I stand little chance of getting clear, straight answers from developers when asking about issues I need to consider and incorporate in documentation. If communication is a hurdle we can all overcome, with a genuine and heart-felt effort to relay information, motives, and plans with one another, then I'd sincerely appreciate having the opportunity to personally contribute. I'm not a programmer today, but have a degree in programming fro the 90's (so much has changed my degree is practically useless in that regard). But I do know how to explain things and relay information in simple terms. But only if my own questions will be answered with more than "look it up or figure it out yourself" as my answer. If any of you would appreciate my help, feel free to let me know at any time and I'll do what I can. - Len W. Brown lenwbrown at gmail.com On Mon, Nov 23, 2009 at 6:23 AM, Colin B. Withers wrote: Hi guys, I have decided to leave the Opensim project. You will probably not even notice if I leave, as not being a programmer my only inputs were the writing of the step-by-step tutorials ( http://chapter-and-metaverse.blogspot.com/ ), the drafts of the OpenSim User Manual on the Forge, and helping out in the IRC channels, for newcomers. You may find my reasons for leaving Opensim interesting though (and please do not construe any of my reasons as an attack on anyone). 1. The Platform I raised this several times in the past in IRC, and made posts on my blog about the product lifecycle of the platform ( http://rock-vacirca.blogspot.com/2009/02/direction-of-virtual-worlds.html ). I believe that the platforms underpinning both Second Life and Opensim are quite long in the tooth now, and I questioned how much product lifecycle there was left, particularly given that Opensim is now nearing 3 years of development, is still in Alpha, and if the current release of 0.6.7 is any indicator, then still only around two thirds into the development cycle. With the (inevitable) coming of much superior platforms, such as Blue Mars and (as a virtual world); Unity, for browser-based Virtual Wolrds; and now UDK (for creating sandboxes, standalones, and open grids), then I fear that Opensim has missed the boat as far as the remaining lifecycle of the platform is concerned. When you show people what is possible with these engines (for example this avatar editor for the forthcom ing APB (using the Unreal Engine): http://www.youtube.com/watch?v=icR3LtEMvZI or this city: http://www.youtube.com/watch?v=hmLzNbPXMDg (using the CryEngine), then neither SL not Opensim stands comparison. 2. Lack of Support for Currency in Opensim I felt the impact of this when I first made the switch from SL to Opensim. I had a thriving RP sim in SL (over 50 people, mainly female) and they all agreed to follow me over to my Opensim and the OSGrid. However, within a month they had all left, citing the same reason, the lack of places to shop, to buy the quality stuff they wanted (skins, hair, clothes etc), as a quality appearance, and the fun of shopping is what all the females placed high on their requirements from a Virtual World. They drifted back to Second Life, and the guys followed them. I have always believed that the lack of support for currency in the core was a mistake, but that is just my opinion. 3. Marketing I have also raised this issue several times, and blogged about it. It is far from clear just who an eventually released Opensim is actually aimed at. I think that any company that is interested in a firewalled corporate solution to collaboration and prototyping will already be looking at the Enterprise solution that is currently available from Second Life; that any indie group that is thinking of running a themed grid will need an economy to stay viable; and any individual who is looking for a private sandbox solution for their SL work will need full compatibility (which is not the case with the OS version of LSL diverging from the SL LSL). So, just who is the platform aimed at? I was also very disappointed in the view of one of the core devs who said that 'marketing is a null concept for us'. I am currently designing and creating cities for Blue Mars, and involved in a team for proving the UDK as a platform for the design and creation of Virtual Worlds (as opposed to purely games), and with so much documentation available for these mature engines (particularly for the UDK, Blue Mars lags behind somewhat in that department, but have hired extra staff to put that right), I am achieving the productivity I want, building the worlds that I want, with stable crash-free platforms. However, I do wish the Opensim team the very best in their endeavours, and I sincerely hope their goals are eventually achieved. If anyone would like to take over the Opensim Tutorials pages at http://chapter-and-metaverse.blogspot.com/ and http://chapter-and-metaverse2.blogspot.com/ (they will need some updating following several changes) then I am more than willing to pass the posts over, and of course the Opensim User Manual is there in the Forge for anyone to develop further. Best Regards and Good Luck Rock _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ------=_NextPart_000_00B7_01CA6CF5.12D3D3E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Very interesting debate you have going on = here…

 

Just to summarise, it seems to me that while the project = roadmap so far has been to implement copy of Second Life the general feeling is = that we are now pretty much there and it is time to go after even greater things = and we need to decide a product road map on our own from here. Hope I am = summarising all this correctly from all emails flying around?

 

There are as many business models in the mix as there are companies involved. While my company makes money from utilising OpenSim = as an engine for private virtual worlds and business applications we develop = for our customers, there are people elsewhere whose main interest is to create = global public access grids to compete with other virtual worlds such as Second = Life. I think it is important that the focus remains considering OpenSim as an = engine and this way everyone’s business models can be satisfied = (hopefully).

 

Just quickly about the debate around the compatibility = between Second Life and OpenSim. Which ever way this all goes, long term virtual = worlds will definitely need a standard ways to communicate. It is important = that different platforms can talk with each other if we aim for a 3D = internet. Traditional internet would not have taken off the same way if there would have been = only 1 web server vendor to use (does not matter would it been Apache or MS IIS). = So lets make sure that our product roadmap does listen / follow what other = platforms are doing.

 

And finally, I sense from some of the discussions an anti = SL/LL tone the same way there has been an anti Microsoft tone in so many Open = Source projects in the past. So many good Open Source projects have been wasted = away in the past because they concentrated fighting the “big = evil” instead of writing code that was great and made sense. There is = absolutely no point diverting OpenSim from Second Life for just sake of it, because we = feel now that OpenSim is great enough product and we can do it all ourselves. = However, if we find that keeping the compatibility is going to stop us realising = some great things in the future then that is a different matter, but even = then each case should be considered carefully.

 

Regards,

 

Olli

 

From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of = Impalah Shenzhou
Sent: 24 November 2009 09:42
To: opensim-dev at lists.berlios.de
Subject: Re: [Opensim-dev] Leaving Project

 

Hi:

Morgaine, I agree with you except:

  • SL is based on highly centralized = concepts of identity, storage and control, which come = together to create either a walled garden or a prison planet, depending on = one's perspective.  Whatever one's worldview, the end result is = badly non-scalable in those three areas.  SL suffers hugely from = that non-scalability despite the relatively small size of the service at = this early stage.  Opensim needs decentralized / distributed = mechanisms for identity, storage and control if it is to = scale for Internet-wide adoption.


How can I trust anyone who hasn't been authorized through a well known = trusting system? Well, if you mean systems like OpenID, forget my comments. If = not, can you explain that?

About the topic...

Except with the lack of huge, updated and good documentation, and having = into account that there are no money incomes (no business angels out of = here)... it's a miracle for the project to be still alive :-)

No complaints about opensim, no opinions about Blue Mars and the = rest...


2009/11/24 Morgaine <morgaine.dinova at googlemail= .com>

On Mon, Nov 23, 2009 at 1:06 PM, Len Brown <lenwbrown at gmail.com> wrote:

 

For me the shock came when I was abruptly informed = that "OpenSim is not Second Life, is not intended to be like Second Life, nor ever will."  I still haven't the foggiest idea what this = developer had smoked for them to so strongly assert that incredibly false = statement.

 

Len, let me give you = an alternative perspective on that quote to help you see the reasons for = it.  I'm not on the Opensim team, but after five years in SL, two years in = AWG, and a year of working on future VW protocols in our IETF group, I have some background to know why Opensim needs to distance itself from = SL:

  • SL's statically tiled resource = architecture is badly non-scalable, because most resource usage in VWs = cannot be statically mapped (demand moves around).  The inability to = assign resources dynamically in SL results in huge overload in busy places = and gross wastage in idle areas.  It also limits the number of participants in events and the bandwidth of their interaction, as = well as the size and complexity of everything in a region.  This = architecture is fundamental to SL, yet it is a recipe for failure.  As long = as Opensim adheres to the SL model, Opensim will be similarly = non-scalable.

 

  • The LSL scripting language is = linguistically weak, semantically obscure, and lacking in the glue that could = allow components to cooperate effectively.  As a result, individual = scripts are quite underpowered and inefficient, and multi-script = constructions do not scale well in complexity because the overheads of cooperation = are so large.  That's a bad restriction on progress which Opensim = needs to leave behind.

 

  • LSL scripts are not scalable in power or = size, and this will continue to be true even after SL allows C# and other = CLR languages to be used.  There is no possibility of using more = CPU power for scripting than is available in one single simulator in = SL.  That is not a good foundation upon which to build an ambitious = future of clever components.

 

  • SL's simulation environment is = non-portable, having evolved over time into a plethora of special cases that will = not be accurately replicable anywhere else.  In effect this means = that there will never be effective interop with SL's scripted objects.  = It would not be a useful goal to seek compatibility with what could = realistically be described as an "ill-defined mess".

 

  • SL's object and type systems are = non-extensible, so compatibility with SL means living in the past, and worse, = living in a past defined entirely by one slow-moving company.  Tying the capabilities of Opensim to that millstone would be a disaster --- = it would ensure the death of Opensim versus any extensible alternative that = may appear.  Developing new extensible forms of world data beyond = SL's original set is a must for Opensim's survival as a modern VW = platform.

 

  • SL's viewer has deep knowledge of SL = semantics because the client and server were designed for each other rather = than designed as endpoints of a standard protocol.  This has the = very bad consequence that future VW viewers would need to know about SL = specifics in order to interoperate with SL, which is a poor approach that = doesn't scale to metaverse-wide diversity.  Opensim needs to leave world-specific kludges behind if it has ambitions to underpin a = highly diverse metaverse of worlds, and this means leaving the SL viewer = behind.

 

  • SL's constructed objects are = non-hierarchical, which means that creators cannot use objects created by others as subcomponents.  This restriction completely blocks the = hierarchical engineering process that is the basis of progress in RL.  In = SL you always have to build from "raw materials", so it is not = possible to ride on the shoulders of giants, nor harness a huge pyramid of = people skills.  Even Philip and Cory Linden admitted that this was a = mistake -- see  https://wiki.secondlife.com/wiki/Prim_and_Object_Hierar= chy .  We don't want to live with their mistake.

 

  • SL is based on highly centralized = concepts of identity, storage and control, which come together to = create either a walled garden or a prison planet, depending on one's perspective.  Whatever one's worldview, the end result is = badly non-scalable in those three areas.  SL suffers hugely from = that non-scalability despite the relatively small size of the service at = this early stage.  Opensim needs decentralized / distributed = mechanisms for identity, storage and control if it is to scale for Internet-wide adoption.

 

  • From a futurist angle, Second Life has = very narrow horizons and barely pays lip service to the = virtual aspect of "virtual worlds".  Nobody could claim that = a Flatland of square land tiles all featuring the same Earth-like = look and physics pushes the envelope of the imagination.  To boldly go = where Lindens did not go before (topologically and geographically or = spatially) will be one of the most appreciated developments in Opensim.  = SL's obsession with RL is an unwanted constraint in VWs, and we need to = go beyond it.



That is not the full list of problems with SL, but hopefully it serves = to illustrate some of the concerns that VW developers have to consider in = the light of the SL legacy.  While Linden Lab deserves much applause = for their vision and for their work in creating Second Life, many years have now = passed, and lessons have been learned.  Compatibility with SL must not be = the end goal of Opensim because of issues like those highlighted above.

From bogus@does.not.exist.com Sat Apr 19 01:31:08 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 01:31:08 -0000 Subject: No subject Message-ID: evolution of virtual worlds.  It is no surprise that most Opensim developers = wish to go beyond that first step, learning from past mistakes and finding = better models for the future.

I mentioned earlier our work at the IETF on new VW protocols, in which = LL are a leading party --- see  https://www.ietf.org/mailman/listinfo/ogpx , the = mailing list of the VWRAP working group.  What may surprise you is that = even Lindens know that the current SL is not a good model for the future, = which is why the protocols being discussed go far beyond their legacy ones.  Indeed, Lindens will be facing a huge rewrite if this work bears = fruit.  When even Lindens don't wish their future to be constrained by the = current SL design because they know its many problems, this really highlights how = bad it would be for the Opensim team to do so. :-)

I hope that one or more of these issues resonates with you, and makes it = a bit clearer why Opensim really cannot afford to align itself with SL.  = There is no future in looking backwards.


Morgaine.






=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

On Mon, Nov 23, 2009 at 1:06 PM, Len Brown <lenwbrown at gmail.com> wrote:

Rock,

     I sympathize with you on many levels.  = I've also had my doubts regarding the future of OpenSim, but I have also = maintained some degree of faith that things will pull through in the end.

     For me the shock came when I was abruptly = informed that "OpenSim is not Second Life, is not intended to be like Second = Life, nor ever will."  I still haven't the foggiest idea what this developer had smoked for them to so strongly assert that incredibly = false statement.

     For me, the enjoyment of OpenSim has come from = my intense devotion to building and skinning.  In fact, for the last = few months I've been working on a full region that has many hundreds of = skins, clothes, hair, furniture, etc, etc, that I'd like to package up as an = OAR and give out freely, since repeatedly I've been told that instead of giving = money to help further OpenSim I'd do more proactively by giving content.  = So I plan to do just that and give my money to other open source initiatives = that matter to me.

     I have a passion for writing, and have thought = many times that one of the greatest powers OpenSim would gain is having = simple, straightforward, step-by-step instructions on how to download, compile, install, administer and overall just plain operate the core = applications.  What kills me is that everyone who does a search for OpenSim inevitably = hits the opensimulator.org site and that is where the massive roadblock presents itself.  It's useless for most and irrelevant to the few who consider themselves = OpenSim experts.

     Heck, even now on the configuration page it = still displays info for 0.6.6 including (months old) known bugs in setting up = region xml files.  If there was appointed a volunteer whose sole job was = to keep information on opensimulator.org relevant that one task would resolve a mountain of negativity right there.  I sit here in front of my computers a good 10 to 12 hours a = day.

     I would sincerely love to contribute to the = OpenSim project, especially in documentation support.  But the thing = holding me back is communication.  If I cannot get a straight answer on who to = GIVE money to in order to help, then I stand little chance of getting clear, straight answers from developers when asking about issues I need to = consider and incorporate in documentation.

     If communication is a hurdle we can all = overcome, with a genuine and heart-felt effort to relay information, motives, and plans = with one another, then I'd sincerely appreciate having the opportunity to = personally contribute.  I'm not a programmer today, but have a degree in = programming fro the 90's (so much has changed my degree is practically useless in = that regard).  But I do know how to explain things and relay information = in simple terms.  But only if my own questions will be answered with = more than "look it up or figure it out yourself" as my answer.

     If any of you would appreciate my help, feel = free to let me know at any time and I'll do what I can.

- Len W. Brown
     lenwbrown at gmail.com

 

On Mon, Nov 23, 2009 at 6:23 AM, Colin B. Withers = <Colin.Withers at eumetsat.int> wrote:

Hi guys,

I have decided to leave the Opensim project. You will probably not even = notice if I leave, as not being a programmer my only inputs were the writing of = the step-by-step tutorials ( http://chapter-and-metaverse.blogspot.com/ ), the = drafts of the OpenSim User Manual on the Forge, and helping out in the IRC = channels, for newcomers.

You may find my reasons for leaving Opensim interesting though (and = please do not construe any of my reasons as an attack on anyone).

1. The Platform
I raised this several times in the past in IRC, and made posts on my = blog about the product lifecycle of the platform ( http://rock-vacirca.blogspot.com/2009/02/direction-of-v= irtual-worlds.html ). I believe that the platforms underpinning both Second Life and = Opensim are quite long in the tooth now, and I questioned how much product lifecycle = there was left, particularly given that Opensim is now nearing 3 years of development, is still in Alpha, and if the current release of 0.6.7 is = any indicator, then still only around two thirds into the development cycle. = With the (inevitable) coming of much superior platforms, such as Blue Mars = and (as a virtual world); Unity, for browser-based Virtual Wolrds; and now UDK = (for creating sandboxes, standalones, and open grids), then I fear that = Opensim has missed the boat as far as the remaining lifecycle of the platform is = concerned. When you show people what is possible with these engines (for example = this avatar editor for the forthcom
 ing APB (using the Unreal Engine): http://www.youtube.com/watch?v=3DicR3LtEMvZI or this city: http://www.youtube.com/watch?v=3DhmLzNbPXMDg = (using the CryEngine), then neither SL not Opensim stands comparison.

2. Lack of Support for Currency in Opensim
I felt the impact of this when I first made the switch from SL to = Opensim. I had a thriving RP sim in SL (over 50 people, mainly female) and they all = agreed to follow me over to my Opensim and the OSGrid. However, within a month = they had all left, citing the same reason, the lack of places to shop, to buy = the quality stuff they wanted (skins, hair, clothes etc), as a quality appearance, = and the fun of shopping is what all the females placed high on their = requirements from a Virtual World. They drifted back to Second Life, and the guys followed = them. I have always believed that the lack of support for currency in the core = was a mistake, but that is just my opinion.

3. Marketing
I have also raised this issue several times, and blogged about it. It is = far from clear just who an eventually released Opensim is actually aimed at. = I think that any company that is interested in a firewalled corporate = solution to collaboration and prototyping will already be looking at the Enterprise solution that is currently available from Second Life; that any indie = group that is thinking of running a themed grid will need an economy to stay = viable; and any individual who is looking for a private sandbox solution for = their SL work will need full compatibility (which is not the case with the OS = version of LSL diverging from the SL LSL). So, just who is the platform aimed at? I = was also very disappointed in the view of one of the core devs who said that 'marketing is a null concept for us'.

I am currently designing and creating cities for Blue Mars, and involved = in a team for proving the UDK as a platform for the design and creation of = Virtual Worlds (as opposed to purely games), and with so much documentation = available for these mature engines (particularly for the UDK, Blue Mars lags = behind somewhat in that department, but have hired extra staff to put that = right), I am achieving the productivity I want, building the worlds that I want, = with stable crash-free platforms.

However, I do wish the Opensim team the very best in their endeavours, = and I sincerely hope their goals are eventually achieved.

If anyone would like to take over the Opensim Tutorials pages at http://chapter-and-metaverse.blogspot.com/ and http://chapter-and-metaverse2.blogspot.com/ (they will need some updating following several changes) then I am more = than willing to pass the posts over, and of course the Opensim User Manual is = there in the Forge for anyone to develop further.

Best Regards and Good Luck

Rock


_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

 


_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

 


_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de=
https://lists.berlios.de/mailman/listinfo/opensim-dev

 

------=_NextPart_000_00B7_01CA6CF5.12D3D3E0-- From jjustincc at googlemail.com Tue Apr 1 00:03:12 2014 From: jjustincc at googlemail.com (Justin Clark-Casey) Date: Tue, 01 Apr 2014 01:03:12 +0100 Subject: [Opensim-dev] Optimize pushing assets to other grids In-Reply-To: <53399CF4.9090609@t-data.com> References: <1396190871524-7579093.post@n2.nabble.com> <5338312A.4070302@metaverseink.com> <1396266948910-7579100.post@n2.nabble.com> <5339995A.4010208@t-data.com> <53399CF4.9090609@t-data.com> Message-ID: <533A0240.7010103@googlemail.com> I originally put in the MajorInterfaceVersion back in 2008 but I now think that's a very bad way to handle updates in a distributed system with no central control. Instead, just like the web, the protocol should be designed with extensbility in mind so that the system can evolve without massive disruption [1], allowing old and new components to co-exist. I think that one more planned bump of MajorInterfaceVersion would be acceptable to introduce extensibility but continual bumps are going to do damage to the system and people's confidence in the system. Not only does it affect the Hypergrid idea, but also in a large grid it makes it very difficult, if not impossible, to experiment with newer updates if they are not protocol compatible. I'll also note that the version number has not been bumped since October 2010. Unsurprisingly, nobody has wanted to inflict (or be blamed) for that pain so everybody has been at pains not to introduce incompatible updates (or only incompatible in minor ways). But really this compatibility should be achieved with a planned mechanism rather than the ad hoc measures that have always been used, and where one day luck runs out. [1] https://www.ics.uci.edu/~fielding/pubs/dissertation/net_app_arch.htm#sec_2_2 On 31/03/14 17:51, Melanie wrote: > There is no implicit versioning in the actual request protocol. That > would have been impossible to maintain in the long run. Instead, > there is a "protocol version". We can bump it when there are > incompatible changes on any protocol and it invalidates all of them. > So a sim version 7 will refuse to connect to a server version 6 and > vice versa. This gives us both control and simplicity. > > Melanie > > On 31/03/2014 18:45, Jim Williams wrote: >> Seems reasonable to me...A design approach I would have taken. >> >> One question. Is there some sort of versioning built into the protocol? >> One verb yes, but the dictionary numbers the definitions..... >> >> >> On Mon, Mar 31, 2014 at 12:35 PM, Melanie wrote: >> >>> This isn't designed as RPC, it's designed as REST. One URL/VERB >>> combination for each function. >>> We wanted to get away from the RPC concept. Let's not take backwards >>> steps here. >>> >>> Melanie >>> >>> On 31/03/2014 15:15, Oren Hurvitz wrote: >>>> This isn't overloading: it's an RPC endpoint that accepts many methods. >>> You >>>> wouldn't create a separate endpoint for each method, would you? >>>> >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>> http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579104.html >>>> Sent from the opensim-dev mailing list archive at Nabble.com. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> Opensim-dev at lists.berlios.de >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >> >> >> >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > . > -- Justin Clark-Casey (justincc) OSVW Consulting http://justincc.org http://twitter.com/justincc From orenh at kitely.com Tue Apr 1 13:00:30 2014 From: orenh at kitely.com (Oren Hurvitz) Date: Tue, 1 Apr 2014 06:00:30 -0700 (PDT) Subject: [Opensim-dev] REST handlers use partial string matching Message-ID: <1396357230099-7579119.post@n2.nabble.com> I tried to add a REST handler at the endpoint "/assets_exist". It turns out that I can't do that, because REST handlers are searched using partial string matches, so servers that don't implement the new handler will mistakenly choose the "/assets" endpoint instead. For now, I solved the problem by using a different endpoint: "/get_assets_exist". For the future, I think that this should be changed so that only full string matches work. Otherwise each time a new handler is added it will have to find an endpoint name that isn't a prefix of any current endpoint -- a difficult and error-prone task. Before I do that, does anyone know of endpoints that rely on the current behavior (partial string matches)? -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119.html Sent from the opensim-dev mailing list archive at Nabble.com. From melanie at t-data.com Tue Apr 1 17:55:14 2014 From: melanie at t-data.com (Melanie) Date: Tue, 01 Apr 2014 19:55:14 +0200 Subject: [Opensim-dev] REST handlers use partial string matching In-Reply-To: <1396357230099-7579119.post@n2.nabble.com> References: <1396357230099-7579119.post@n2.nabble.com> Message-ID: <533AFD82.9010603@t-data.com> The REST URLs need to use partial matching, however, current semantics are broken. Without partial matching, URLS like /assets/782911..... would not work. the issue here is that it should match whole URL parts, not partial URL parts. Matching partial words as it does now seems like someone was cutting corners, it's not by design. /assets/ should match /assets/9887234...... but not /assets_exist. The slash is the differentiator and partial compares of URL string prefixes should be done by full-string matches of slash/delimited parts, not prefix matching of the entire URL. Melanie On 01/04/2014 15:00, Oren Hurvitz wrote: > I tried to add a REST handler at the endpoint "/assets_exist". It turns out > that I can't do that, because REST handlers are searched using partial > string matches, so servers that don't implement the new handler will > mistakenly choose the "/assets" endpoint instead. > > For now, I solved the problem by using a different endpoint: > "/get_assets_exist". > > For the future, I think that this should be changed so that only full string > matches work. Otherwise each time a new handler is added it will have to > find an endpoint name that isn't a prefix of any current endpoint -- a > difficult and error-prone task. Before I do that, does anyone know of > endpoints that rely on the current behavior (partial string matches)? > > > > -- > View this message in context: http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119.html > Sent from the opensim-dev mailing list archive at Nabble.com. > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > From jjustincc at googlemail.com Tue Apr 1 17:59:57 2014 From: jjustincc at googlemail.com (Justin Clark-Casey) Date: Tue, 01 Apr 2014 18:59:57 +0100 Subject: [Opensim-dev] REST handlers use partial string matching In-Reply-To: <1396357230099-7579119.post@n2.nabble.com> References: <1396357230099-7579119.post@n2.nabble.com> Message-ID: <533AFE9D.1020406@googlemail.com> Hi Oren. I believe the expected way to retrieve metadata (and effectively an existence check) for a resource in REST would be to send a HEAD request [1] to the url, rather than to have a separate endpoint. I think changing the handling to exact matching is fine - I can't think why partial matching is done currently and I can't see how it makes sense in an HTTP context. As far as I know nothing makes use of partial matching. [1] http://books.google.co.uk/books?id=XUaErakHsoAC&pg=PA98&lpg=PA98&dq=restful+web+services+%22OPTIONS+method+lets%22&source=bl&ots=5jkmCnpNmy&sig=mXt_bcmXcZhoU6hFFm0L5j14IvE&hl=en&sa=X&ei=Hf06U--1E7GM7Aad2YHwAw&ved=0CDMQ6AEwAA#v=onepage&q=restful%20web%20services%20%22OPTIONS%20method%20lets%22&f=false On 01/04/14 14:00, Oren Hurvitz wrote: > I tried to add a REST handler at the endpoint "/assets_exist". It turns out > that I can't do that, because REST handlers are searched using partial > string matches, so servers that don't implement the new handler will > mistakenly choose the "/assets" endpoint instead. > > For now, I solved the problem by using a different endpoint: > "/get_assets_exist". > > For the future, I think that this should be changed so that only full string > matches work. Otherwise each time a new handler is added it will have to > find an endpoint name that isn't a prefix of any current endpoint -- a > difficult and error-prone task. Before I do that, does anyone know of > endpoints that rely on the current behavior (partial string matches)? > > > > -- > View this message in context: http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119.html > Sent from the opensim-dev mailing list archive at Nabble.com. > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- Justin Clark-Casey (justincc) OSVW Consulting http://justincc.org http://twitter.com/justincc From jjustincc at googlemail.com Tue Apr 1 18:03:55 2014 From: jjustincc at googlemail.com (Justin Clark-Casey) Date: Tue, 01 Apr 2014 19:03:55 +0100 Subject: [Opensim-dev] REST handlers use partial string matching In-Reply-To: <533AFD82.9010603@t-data.com> References: <1396357230099-7579119.post@n2.nabble.com> <533AFD82.9010603@t-data.com> Message-ID: <533AFF8B.6050607@googlemail.com> In what context is such partial matching required? It is not a requirement of REST, as far as I know. On 01/04/14 18:55, Melanie wrote: > The REST URLs need to use partial matching, however, current > semantics are broken. > > Without partial matching, URLS like /assets/782911..... would not > work. the issue here is that it should match whole URL parts, not > partial URL parts. Matching partial words as it does now seems like > someone was cutting corners, it's not by design. > > /assets/ should match /assets/9887234...... but not /assets_exist. > The slash is the differentiator and partial compares of URL string > prefixes should be done by full-string matches of slash/delimited > parts, not prefix matching of the entire URL. > > Melanie > > On 01/04/2014 15:00, Oren Hurvitz wrote: >> I tried to add a REST handler at the endpoint "/assets_exist". It turns out >> that I can't do that, because REST handlers are searched using partial >> string matches, so servers that don't implement the new handler will >> mistakenly choose the "/assets" endpoint instead. >> >> For now, I solved the problem by using a different endpoint: >> "/get_assets_exist". >> >> For the future, I think that this should be changed so that only full string >> matches work. Otherwise each time a new handler is added it will have to >> find an endpoint name that isn't a prefix of any current endpoint -- a >> difficult and error-prone task. Before I do that, does anyone know of >> endpoints that rely on the current behavior (partial string matches)? >> >> >> >> -- >> View this message in context: http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119.html >> Sent from the opensim-dev mailing list archive at Nabble.com. >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- Justin Clark-Casey (justincc) OSVW Consulting http://justincc.org http://twitter.com/justincc From melanie at t-data.com Tue Apr 1 19:00:30 2014 From: melanie at t-data.com (Melanie) Date: Tue, 01 Apr 2014 21:00:30 +0200 Subject: [Opensim-dev] REST handlers use partial string matching In-Reply-To: <533AFF8B.6050607@googlemail.com> References: <1396357230099-7579119.post@n2.nabble.com> <533AFD82.9010603@t-data.com> <533AFF8B.6050607@googlemail.com> Message-ID: <533B0CCE.5000308@t-data.com> It is required because it's the basis of "extra path info". It's not part of REST, but rather part of HTTP. Requesting /asset/456392f6-c0b3-a346-6465-8218cbe7abe84592 which is not a registered URL, will invoke /asset/ which is. The ID passed as part of the URL is then given to that handler as the extra path info. You have the same thing in apache. Basically, any URL longer than and starting with a registered URL will invoke that registered URL with extra path info. The fallacy in our server is that the matching isn't by path parts, but character-wise. Melanie On 01/04/2014 20:03, Justin Clark-Casey wrote: > In what context is such partial matching required? It is not a requirement of REST, as far as I know. > > On 01/04/14 18:55, Melanie wrote: >> The REST URLs need to use partial matching, however, current >> semantics are broken. >> >> Without partial matching, URLS like /assets/782911..... would not >> work. the issue here is that it should match whole URL parts, not >> partial URL parts. Matching partial words as it does now seems like >> someone was cutting corners, it's not by design. >> >> /assets/ should match /assets/9887234...... but not /assets_exist. >> The slash is the differentiator and partial compares of URL string >> prefixes should be done by full-string matches of slash/delimited >> parts, not prefix matching of the entire URL. >> >> Melanie >> >> On 01/04/2014 15:00, Oren Hurvitz wrote: >>> I tried to add a REST handler at the endpoint "/assets_exist". It turns out >>> that I can't do that, because REST handlers are searched using partial >>> string matches, so servers that don't implement the new handler will >>> mistakenly choose the "/assets" endpoint instead. >>> >>> For now, I solved the problem by using a different endpoint: >>> "/get_assets_exist". >>> >>> For the future, I think that this should be changed so that only full string >>> matches work. Otherwise each time a new handler is added it will have to >>> find an endpoint name that isn't a prefix of any current endpoint -- a >>> difficult and error-prone task. Before I do that, does anyone know of >>> endpoints that rely on the current behavior (partial string matches)? >>> >>> >>> >>> -- >>> View this message in context: http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119.html >>> Sent from the opensim-dev mailing list archive at Nabble.com. >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > From cmickeyb at gmail.com Tue Apr 1 19:08:02 2014 From: cmickeyb at gmail.com (Mic Bowman) Date: Tue, 1 Apr 2014 12:08:02 -0700 Subject: [Opensim-dev] REST handlers use partial string matching In-Reply-To: <533B0CCE.5000308@t-data.com> References: <1396357230099-7579119.post@n2.nabble.com> <533AFD82.9010603@t-data.com> <533AFF8B.6050607@googlemail.com> <533B0CCE.5000308@t-data.com> Message-ID: so what you're saying is just make sure the '/' is part of the match? to terminate the match? i think the problem is that /asset matches /asset_test which is not what is expected. so all registered partial matches should include the trailing '/' to disambiguate... or am i missing the point? On Tue, Apr 1, 2014 at 12:00 PM, Melanie wrote: > It is required because it's the basis of "extra path info". It's not > part of REST, but rather part of HTTP. > > Requesting > > /asset/456392f6-c0b3-a346-6465-8218cbe7abe84592 > > which is not a registered URL, will invoke > > /asset/ > > which is. The ID passed as part of the URL is then given to that > handler as the extra path info. You have the same thing in apache. > > Basically, any URL longer than and starting with a registered URL > will invoke that registered URL with extra path info. > The fallacy in our server is that the matching isn't by path parts, > but character-wise. > > Melanie > > On 01/04/2014 20:03, Justin Clark-Casey wrote: > > In what context is such partial matching required? It is not a > requirement of REST, as far as I know. > > > > On 01/04/14 18:55, Melanie wrote: > >> The REST URLs need to use partial matching, however, current > >> semantics are broken. > >> > >> Without partial matching, URLS like /assets/782911..... would not > >> work. the issue here is that it should match whole URL parts, not > >> partial URL parts. Matching partial words as it does now seems like > >> someone was cutting corners, it's not by design. > >> > >> /assets/ should match /assets/9887234...... but not /assets_exist. > >> The slash is the differentiator and partial compares of URL string > >> prefixes should be done by full-string matches of slash/delimited > >> parts, not prefix matching of the entire URL. > >> > >> Melanie > >> > >> On 01/04/2014 15:00, Oren Hurvitz wrote: > >>> I tried to add a REST handler at the endpoint "/assets_exist". It > turns out > >>> that I can't do that, because REST handlers are searched using partial > >>> string matches, so servers that don't implement the new handler will > >>> mistakenly choose the "/assets" endpoint instead. > >>> > >>> For now, I solved the problem by using a different endpoint: > >>> "/get_assets_exist". > >>> > >>> For the future, I think that this should be changed so that only full > string > >>> matches work. Otherwise each time a new handler is added it will have > to > >>> find an endpoint name that isn't a prefix of any current endpoint -- a > >>> difficult and error-prone task. Before I do that, does anyone know of > >>> endpoints that rely on the current behavior (partial string matches)? > >>> > >>> > >>> > >>> -- > >>> View this message in context: > http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119.html > >>> Sent from the opensim-dev mailing list archive at Nabble.com. > >>> _______________________________________________ > >>> Opensim-dev mailing list > >>> Opensim-dev at lists.berlios.de > >>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> > >>> > >> _______________________________________________ > >> Opensim-dev mailing list > >> Opensim-dev at lists.berlios.de > >> https://lists.berlios.de/mailman/listinfo/opensim-dev > >> > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jjustincc at googlemail.com Tue Apr 1 19:30:40 2014 From: jjustincc at googlemail.com (Justin Clark-Casey) Date: Tue, 01 Apr 2014 20:30:40 +0100 Subject: [Opensim-dev] REST handlers use partial string matching In-Reply-To: <533B0CCE.5000308@t-data.com> References: <1396357230099-7579119.post@n2.nabble.com> <533AFD82.9010603@t-data.com> <533AFF8B.6050607@googlemail.com> <533B0CCE.5000308@t-data.com> Message-ID: <533B13E0.9040107@googlemail.com> Ah okay, I see what you mean. Yes, the asset/ part matches the asset handler and then it is in charge of interpreting the subsequent 456392f6-c0b3-a346-6465-8218cbe7abe84592 section of the path. When you said 782911... below I thought that you were talking about UUID fragments as used by git to identify commits, where "782911" would normally be enough to identify an asset like "782911f6-c0b3-a346-6465-8218cbe7abe84592" so you could say something like GET http://myserver.com/asset/782911. But that was a misinterpretation. On 01/04/14 20:00, Melanie wrote: > It is required because it's the basis of "extra path info". It's not > part of REST, but rather part of HTTP. > > Requesting > > /asset/456392f6-c0b3-a346-6465-8218cbe7abe84592 > > which is not a registered URL, will invoke > > /asset/ > > which is. The ID passed as part of the URL is then given to that > handler as the extra path info. You have the same thing in apache. > > Basically, any URL longer than and starting with a registered URL > will invoke that registered URL with extra path info. > The fallacy in our server is that the matching isn't by path parts, > but character-wise. > > Melanie > > On 01/04/2014 20:03, Justin Clark-Casey wrote: >> In what context is such partial matching required? It is not a requirement of REST, as far as I know. >> >> On 01/04/14 18:55, Melanie wrote: >>> The REST URLs need to use partial matching, however, current >>> semantics are broken. >>> >>> Without partial matching, URLS like /assets/782911..... would not >>> work. the issue here is that it should match whole URL parts, not >>> partial URL parts. Matching partial words as it does now seems like >>> someone was cutting corners, it's not by design. >>> >>> /assets/ should match /assets/9887234...... but not /assets_exist. >>> The slash is the differentiator and partial compares of URL string >>> prefixes should be done by full-string matches of slash/delimited >>> parts, not prefix matching of the entire URL. >>> >>> Melanie >>> >>> On 01/04/2014 15:00, Oren Hurvitz wrote: >>>> I tried to add a REST handler at the endpoint "/assets_exist". It turns out >>>> that I can't do that, because REST handlers are searched using partial >>>> string matches, so servers that don't implement the new handler will >>>> mistakenly choose the "/assets" endpoint instead. >>>> >>>> For now, I solved the problem by using a different endpoint: >>>> "/get_assets_exist". >>>> >>>> For the future, I think that this should be changed so that only full string >>>> matches work. Otherwise each time a new handler is added it will have to >>>> find an endpoint name that isn't a prefix of any current endpoint -- a >>>> difficult and error-prone task. Before I do that, does anyone know of >>>> endpoints that rely on the current behavior (partial string matches)? >>>> >>>> >>>> >>>> -- >>>> View this message in context: http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119.html >>>> Sent from the opensim-dev mailing list archive at Nabble.com. >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> Opensim-dev at lists.berlios.de >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> >>>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >> > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > . > -- Justin Clark-Casey (justincc) OSVW Consulting http://justincc.org http://twitter.com/justincc From sphere1952 at gmail.com Tue Apr 1 19:47:21 2014 From: sphere1952 at gmail.com (Jim Williams) Date: Tue, 1 Apr 2014 15:47:21 -0400 Subject: [Opensim-dev] REST handlers use partial string matching In-Reply-To: References: <1396357230099-7579119.post@n2.nabble.com> <533AFD82.9010603@t-data.com> <533AFF8B.6050607@googlemail.com> <533B0CCE.5000308@t-data.com> Message-ID: I think the correct way to look at this is that any URI "..../handler/..." should be passed to the correct "handler" handler; which should then pass the rest of the path on to any sub-handlers as appropriate. You shouldn't be looking at the parts of a path element unless it is the leaf (follows the last slash). The URI began life as a directory tree, and you would not match part of the directory thinking it was a file. Any valid semantic URI parser will interpret elements of a URI strictly in context, and never assume anything about elements except within the context of the element to its immediate left. It would be ok for /asset and /asset_test to be treated as a match, but never ok for /asset/ and /asset_test or /asset_test/ to match. One is matching a directory to a file, and the other is matching two different directories. On Tue, Apr 1, 2014 at 3:08 PM, Mic Bowman wrote: > so what you're saying is just make sure the '/' is part of the match? to > terminate the match? i think the problem is that /asset matches /asset_test > which is not what is expected. so all registered partial matches should > include the trailing '/' to disambiguate... or am i missing the point? > > > > On Tue, Apr 1, 2014 at 12:00 PM, Melanie wrote: > >> It is required because it's the basis of "extra path info". It's not >> part of REST, but rather part of HTTP. >> >> Requesting >> >> /asset/456392f6-c0b3-a346-6465-8218cbe7abe84592 >> >> which is not a registered URL, will invoke >> >> /asset/ >> >> which is. The ID passed as part of the URL is then given to that >> handler as the extra path info. You have the same thing in apache. >> >> Basically, any URL longer than and starting with a registered URL >> will invoke that registered URL with extra path info. >> The fallacy in our server is that the matching isn't by path parts, >> but character-wise. >> >> Melanie >> >> On 01/04/2014 20:03, Justin Clark-Casey wrote: >> > In what context is such partial matching required? It is not a >> requirement of REST, as far as I know. >> > >> > On 01/04/14 18:55, Melanie wrote: >> >> The REST URLs need to use partial matching, however, current >> >> semantics are broken. >> >> >> >> Without partial matching, URLS like /assets/782911..... would not >> >> work. the issue here is that it should match whole URL parts, not >> >> partial URL parts. Matching partial words as it does now seems like >> >> someone was cutting corners, it's not by design. >> >> >> >> /assets/ should match /assets/9887234...... but not /assets_exist. >> >> The slash is the differentiator and partial compares of URL string >> >> prefixes should be done by full-string matches of slash/delimited >> >> parts, not prefix matching of the entire URL. >> >> >> >> Melanie >> >> >> >> On 01/04/2014 15:00, Oren Hurvitz wrote: >> >>> I tried to add a REST handler at the endpoint "/assets_exist". It >> turns out >> >>> that I can't do that, because REST handlers are searched using partial >> >>> string matches, so servers that don't implement the new handler will >> >>> mistakenly choose the "/assets" endpoint instead. >> >>> >> >>> For now, I solved the problem by using a different endpoint: >> >>> "/get_assets_exist". >> >>> >> >>> For the future, I think that this should be changed so that only full >> string >> >>> matches work. Otherwise each time a new handler is added it will have >> to >> >>> find an endpoint name that isn't a prefix of any current endpoint -- a >> >>> difficult and error-prone task. Before I do that, does anyone know of >> >>> endpoints that rely on the current behavior (partial string matches)? >> >>> >> >>> >> >>> >> >>> -- >> >>> View this message in context: >> http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119.html >> >>> Sent from the opensim-dev mailing list archive at Nabble.com. >> >>> _______________________________________________ >> >>> Opensim-dev mailing list >> >>> Opensim-dev at lists.berlios.de >> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >>> >> >>> >> >> _______________________________________________ >> >> Opensim-dev mailing list >> >> Opensim-dev at lists.berlios.de >> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> >> > >> > >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- No essence. No permanence. No perfection. Only action. -------------- next part -------------- An HTML attachment was scrubbed... URL: From orenh at kitely.com Tue Apr 1 19:49:49 2014 From: orenh at kitely.com (Oren Hurvitz) Date: Tue, 1 Apr 2014 12:49:49 -0700 (PDT) Subject: [Opensim-dev] REST handlers use partial string matching In-Reply-To: <533AFE9D.1020406@googlemail.com> References: <1396357230099-7579119.post@n2.nabble.com> <533AFE9D.1020406@googlemail.com> Message-ID: <1396381789745-7579127.post@n2.nabble.com> Re: why use POST instead of HEAD: because this lets me check the existence of many assets at once with a single HTTP request. The main use of the AssetsExist call is with HGAssetGatherer, which knows the full list of assets that it wants to send, so it's able to check all of them at once. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119p7579127.html Sent from the opensim-dev mailing list archive at Nabble.com. From cmickeyb at gmail.com Tue Apr 1 19:52:43 2014 From: cmickeyb at gmail.com (Mic Bowman) Date: Tue, 1 Apr 2014 12:52:43 -0700 Subject: [Opensim-dev] REST handlers use partial string matching In-Reply-To: <1396381789745-7579127.post@n2.nabble.com> References: <1396357230099-7579119.post@n2.nabble.com> <533AFE9D.1020406@googlemail.com> <1396381789745-7579127.post@n2.nabble.com> Message-ID: Do you really save much with a single request vs a keep alive on the connection? HTTP connection overhead is likely much smaller than the database operations... do you have a feel for how much we'll save with the multiplexed call? --mic On Tue, Apr 1, 2014 at 12:49 PM, Oren Hurvitz wrote: > Re: why use POST instead of HEAD: because this lets me check the existence > of > many assets at once with a single HTTP request. The main use of the > AssetsExist call is with HGAssetGatherer, which knows the full list of > assets that it wants to send, so it's able to check all of them at once. > > > > -- > View this message in context: > http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119p7579127.html > Sent from the opensim-dev mailing list archive at Nabble.com. > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From melanie at t-data.com Tue Apr 1 19:56:18 2014 From: melanie at t-data.com (Melanie) Date: Tue, 01 Apr 2014 21:56:18 +0200 Subject: [Opensim-dev] REST handlers use partial string matching In-Reply-To: References: <1396357230099-7579119.post@n2.nabble.com> <533AFD82.9010603@t-data.com> <533AFF8B.6050607@googlemail.com> <533B0CCE.5000308@t-data.com> Message-ID: <533B19E2.7030002@t-data.com> The proper method is to break up the local portion of the URL into words using "/" as the separator, then matching that list of words against similar lists created from the registered URLs, usually stored as a tree. There are two ways to match, "shortest match" and "more specific". The algorithm used by apache is "shortest match", meaning that as soon as a word list is fully matched against the request's words, it's considered a match and the handler is invoked. Everything past the matched portion becomes extra path info. Melanie On 01/04/2014 21:08, Mic Bowman wrote: > so what you're saying is just make sure the '/' is part of the match? to > terminate the match? i think the problem is that /asset matches /asset_test > which is not what is expected. so all registered partial matches should > include the trailing '/' to disambiguate... or am i missing the point? > > > > On Tue, Apr 1, 2014 at 12:00 PM, Melanie wrote: > >> It is required because it's the basis of "extra path info". It's not >> part of REST, but rather part of HTTP. >> >> Requesting >> >> /asset/456392f6-c0b3-a346-6465-8218cbe7abe84592 >> >> which is not a registered URL, will invoke >> >> /asset/ >> >> which is. The ID passed as part of the URL is then given to that >> handler as the extra path info. You have the same thing in apache. >> >> Basically, any URL longer than and starting with a registered URL >> will invoke that registered URL with extra path info. >> The fallacy in our server is that the matching isn't by path parts, >> but character-wise. >> >> Melanie >> >> On 01/04/2014 20:03, Justin Clark-Casey wrote: >> > In what context is such partial matching required? It is not a >> requirement of REST, as far as I know. >> > >> > On 01/04/14 18:55, Melanie wrote: >> >> The REST URLs need to use partial matching, however, current >> >> semantics are broken. >> >> >> >> Without partial matching, URLS like /assets/782911..... would not >> >> work. the issue here is that it should match whole URL parts, not >> >> partial URL parts. Matching partial words as it does now seems like >> >> someone was cutting corners, it's not by design. >> >> >> >> /assets/ should match /assets/9887234...... but not /assets_exist. >> >> The slash is the differentiator and partial compares of URL string >> >> prefixes should be done by full-string matches of slash/delimited >> >> parts, not prefix matching of the entire URL. >> >> >> >> Melanie >> >> >> >> On 01/04/2014 15:00, Oren Hurvitz wrote: >> >>> I tried to add a REST handler at the endpoint "/assets_exist". It >> turns out >> >>> that I can't do that, because REST handlers are searched using partial >> >>> string matches, so servers that don't implement the new handler will >> >>> mistakenly choose the "/assets" endpoint instead. >> >>> >> >>> For now, I solved the problem by using a different endpoint: >> >>> "/get_assets_exist". >> >>> >> >>> For the future, I think that this should be changed so that only full >> string >> >>> matches work. Otherwise each time a new handler is added it will have >> to >> >>> find an endpoint name that isn't a prefix of any current endpoint -- a >> >>> difficult and error-prone task. Before I do that, does anyone know of >> >>> endpoints that rely on the current behavior (partial string matches)? >> >>> >> >>> >> >>> >> >>> -- >> >>> View this message in context: >> http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119.html >> >>> Sent from the opensim-dev mailing list archive at Nabble.com. >> >>> _______________________________________________ >> >>> Opensim-dev mailing list >> >>> Opensim-dev at lists.berlios.de >> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >>> >> >>> >> >> _______________________________________________ >> >> Opensim-dev mailing list >> >> Opensim-dev at lists.berlios.de >> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> >> > >> > >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev From dahliatrimble at gmail.com Tue Apr 1 19:56:44 2014 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Tue, 1 Apr 2014 12:56:44 -0700 Subject: [Opensim-dev] REST handlers use partial string matching In-Reply-To: References: <1396357230099-7579119.post@n2.nabble.com> <533AFE9D.1020406@googlemail.com> <1396381789745-7579127.post@n2.nabble.com> Message-ID: Not sure about this particular application but keeping a connection open can eliminate the need to instantiate a connection whenever a request is made; a process that can make several round trips to multiple endpoints. On Tue, Apr 1, 2014 at 12:52 PM, Mic Bowman wrote: > Do you really save much with a single request vs a keep alive on the > connection? HTTP connection overhead is likely much smaller than the > database operations... do you have a feel for how much we'll save with the > multiplexed call? > > --mic > > > > On Tue, Apr 1, 2014 at 12:49 PM, Oren Hurvitz wrote: > >> Re: why use POST instead of HEAD: because this lets me check the >> existence of >> many assets at once with a single HTTP request. The main use of the >> AssetsExist call is with HGAssetGatherer, which knows the full list of >> assets that it wants to send, so it's able to check all of them at once. >> >> >> >> -- >> View this message in context: >> http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119p7579127.html >> Sent from the opensim-dev mailing list archive at Nabble.com. >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From melanie at t-data.com Tue Apr 1 19:59:01 2014 From: melanie at t-data.com (Melanie) Date: Tue, 01 Apr 2014 21:59:01 +0200 Subject: [Opensim-dev] REST handlers use partial string matching In-Reply-To: References: <1396357230099-7579119.post@n2.nabble.com> <533AFD82.9010603@t-data.com> <533AFF8B.6050607@googlemail.com> <533B0CCE.5000308@t-data.com> Message-ID: <533B1A85.7070207@t-data.com> Well, with URLs, it's not known which part (word) of the url local part is a directory and which is a file/script. http://www.example.com/dir/file.php/extra/info is legal. At the time of parsing, it is not intrinsically knowable that file.php is a script. Therefore, you can't look at just the last element, but need to match wordwise left to right. Melanie On 01/04/2014 21:47, Jim Williams wrote: > I think the correct way to look at this is that any URI "..../handler/..." > should be passed to the correct "handler" handler; which should then pass > the rest of the path on to any sub-handlers as appropriate. You shouldn't > be looking at the parts of a path element unless it is the leaf (follows > the last slash). The URI began life as a directory tree, and you would not > match part of the directory thinking it was a file. Any valid semantic URI > parser will interpret elements of a URI strictly in context, and never > assume anything about elements except within the context of the element to > its immediate left. > > It would be ok for /asset and /asset_test to be treated as a match, but > never ok for /asset/ and /asset_test or /asset_test/ to match. One is > matching a directory to a file, and the other is matching two different > directories. > > > > On Tue, Apr 1, 2014 at 3:08 PM, Mic Bowman wrote: > >> so what you're saying is just make sure the '/' is part of the match? to >> terminate the match? i think the problem is that /asset matches /asset_test >> which is not what is expected. so all registered partial matches should >> include the trailing '/' to disambiguate... or am i missing the point? >> >> >> >> On Tue, Apr 1, 2014 at 12:00 PM, Melanie wrote: >> >>> It is required because it's the basis of "extra path info". It's not >>> part of REST, but rather part of HTTP. >>> >>> Requesting >>> >>> /asset/456392f6-c0b3-a346-6465-8218cbe7abe84592 >>> >>> which is not a registered URL, will invoke >>> >>> /asset/ >>> >>> which is. The ID passed as part of the URL is then given to that >>> handler as the extra path info. You have the same thing in apache. >>> >>> Basically, any URL longer than and starting with a registered URL >>> will invoke that registered URL with extra path info. >>> The fallacy in our server is that the matching isn't by path parts, >>> but character-wise. >>> >>> Melanie >>> >>> On 01/04/2014 20:03, Justin Clark-Casey wrote: >>> > In what context is such partial matching required? It is not a >>> requirement of REST, as far as I know. >>> > >>> > On 01/04/14 18:55, Melanie wrote: >>> >> The REST URLs need to use partial matching, however, current >>> >> semantics are broken. >>> >> >>> >> Without partial matching, URLS like /assets/782911..... would not >>> >> work. the issue here is that it should match whole URL parts, not >>> >> partial URL parts. Matching partial words as it does now seems like >>> >> someone was cutting corners, it's not by design. >>> >> >>> >> /assets/ should match /assets/9887234...... but not /assets_exist. >>> >> The slash is the differentiator and partial compares of URL string >>> >> prefixes should be done by full-string matches of slash/delimited >>> >> parts, not prefix matching of the entire URL. >>> >> >>> >> Melanie >>> >> >>> >> On 01/04/2014 15:00, Oren Hurvitz wrote: >>> >>> I tried to add a REST handler at the endpoint "/assets_exist". It >>> turns out >>> >>> that I can't do that, because REST handlers are searched using partial >>> >>> string matches, so servers that don't implement the new handler will >>> >>> mistakenly choose the "/assets" endpoint instead. >>> >>> >>> >>> For now, I solved the problem by using a different endpoint: >>> >>> "/get_assets_exist". >>> >>> >>> >>> For the future, I think that this should be changed so that only full >>> string >>> >>> matches work. Otherwise each time a new handler is added it will have >>> to >>> >>> find an endpoint name that isn't a prefix of any current endpoint -- a >>> >>> difficult and error-prone task. Before I do that, does anyone know of >>> >>> endpoints that rely on the current behavior (partial string matches)? >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> View this message in context: >>> http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119.html >>> >>> Sent from the opensim-dev mailing list archive at Nabble.com. >>> >>> _______________________________________________ >>> >>> Opensim-dev mailing list >>> >>> Opensim-dev at lists.berlios.de >>> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> >>> >>> >>> >> _______________________________________________ >>> >> Opensim-dev mailing list >>> >> Opensim-dev at lists.berlios.de >>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >>> > >>> > >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev From sphere1952 at gmail.com Tue Apr 1 19:59:57 2014 From: sphere1952 at gmail.com (Jim Williams) Date: Tue, 1 Apr 2014 15:59:57 -0400 Subject: [Opensim-dev] Question re REST verses RPC, et. al. Message-ID: Why are you supporting push at all? Shouldn't this be being deprecated with the intent of removal???? (Also....a new protocol version ought to be as simple as adding /asset1/ next to /asset/ and adding a note to the log that the /asset/ resource is going to be removed at some point in the future.) -- No essence. No permanence. No perfection. Only action. -------------- next part -------------- An HTML attachment was scrubbed... URL: From melanie at t-data.com Tue Apr 1 19:59:56 2014 From: melanie at t-data.com (Melanie) Date: Tue, 01 Apr 2014 21:59:56 +0200 Subject: [Opensim-dev] REST handlers use partial string matching In-Reply-To: <1396381789745-7579127.post@n2.nabble.com> References: <1396357230099-7579119.post@n2.nabble.com> <533AFE9D.1020406@googlemail.com> <1396381789745-7579127.post@n2.nabble.com> Message-ID: <533B1ABC.6010009@t-data.com> HEAD is meant to test if a request endpoint is implemented and to retrieve metadata like detailed capabilities/options/flags. Melanie On 01/04/2014 21:49, Oren Hurvitz wrote: > Re: why use POST instead of HEAD: because this lets me check the existence of > many assets at once with a single HTTP request. The main use of the > AssetsExist call is with HGAssetGatherer, which knows the full list of > assets that it wants to send, so it's able to check all of them at once. > > > > -- > View this message in context: http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119p7579127.html > Sent from the opensim-dev mailing list archive at Nabble.com. > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > From melanie at t-data.com Tue Apr 1 20:02:49 2014 From: melanie at t-data.com (Melanie) Date: Tue, 01 Apr 2014 22:02:49 +0200 Subject: [Opensim-dev] REST handlers use partial string matching In-Reply-To: References: <1396357230099-7579119.post@n2.nabble.com> <533AFE9D.1020406@googlemail.com> <1396381789745-7579127.post@n2.nabble.com> Message-ID: <533B1B69.8050200@t-data.com> Because REST is cleaner and more modularized than RPC. Just compare the code and you will see that. Efficiency is achieved by designing the REST calls intelligently. The /asset/ endpoint for instance can benefit from keep-alive because it supports HEAD/GET?POST so multiple operations can reuse the connection. The exists query is orthogonal to that and should be another request endpoint. Melanie On 01/04/2014 21:56, Dahlia Trimble wrote: > Not sure about this particular application but keeping a connection open > can eliminate the need to instantiate a connection whenever a request is > made; a process that can make several round trips to multiple endpoints. > > > On Tue, Apr 1, 2014 at 12:52 PM, Mic Bowman wrote: > >> Do you really save much with a single request vs a keep alive on the >> connection? HTTP connection overhead is likely much smaller than the >> database operations... do you have a feel for how much we'll save with the >> multiplexed call? >> >> --mic >> >> >> >> On Tue, Apr 1, 2014 at 12:49 PM, Oren Hurvitz wrote: >> >>> Re: why use POST instead of HEAD: because this lets me check the >>> existence of >>> many assets at once with a single HTTP request. The main use of the >>> AssetsExist call is with HGAssetGatherer, which knows the full list of >>> assets that it wants to send, so it's able to check all of them at once. >>> >>> >>> >>> -- >>> View this message in context: >>> http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119p7579127.html >>> Sent from the opensim-dev mailing list archive at Nabble.com. >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev From sphere1952 at gmail.com Tue Apr 1 20:14:31 2014 From: sphere1952 at gmail.com (Jim Williams) Date: Tue, 1 Apr 2014 16:14:31 -0400 Subject: [Opensim-dev] REST handlers use partial string matching In-Reply-To: <533B1A85.7070207@t-data.com> References: <1396357230099-7579119.post@n2.nabble.com> <533AFD82.9010603@t-data.com> <533AFF8B.6050607@googlemail.com> <533B0CCE.5000308@t-data.com> <533B1A85.7070207@t-data.com> Message-ID: I said Semantic, not syntactic. :) I agree, but syntactically we should be doing no semantic thinking at all until we get to the handler for file.php (Python), who would do the semantic parsing and might feel like doing some pattern matching on the elements to the right. That is, we shouldn't even be looking at the last element during syntactic analysis. It's probably a mistake to even parse the string to the right of file.php, other than to find its end, but almost all parsers I've ever seen don't know when to stop. On Tue, Apr 1, 2014 at 3:59 PM, Melanie wrote: > Well, with URLs, it's not known which part (word) of the url local > part is a directory and which is a file/script. > > http://www.example.com/dir/file.php/extra/info > > is legal. At the time of parsing, it is not intrinsically knowable > that file.php is a script. Therefore, you can't look at just the > last element, but need to match wordwise left to right. > > Melanie > > On 01/04/2014 21:47, Jim Williams wrote: > > I think the correct way to look at this is that any URI > "..../handler/..." > > should be passed to the correct "handler" handler; which should then pass > > the rest of the path on to any sub-handlers as appropriate. You > shouldn't > > be looking at the parts of a path element unless it is the leaf (follows > > the last slash). The URI began life as a directory tree, and you would > not > > match part of the directory thinking it was a file. Any valid semantic > URI > > parser will interpret elements of a URI strictly in context, and never > > assume anything about elements except within the context of the element > to > > its immediate left. > > > > It would be ok for /asset and /asset_test to be treated as a match, but > > never ok for /asset/ and /asset_test or /asset_test/ to match. One is > > matching a directory to a file, and the other is matching two different > > directories. > > > > > > > > On Tue, Apr 1, 2014 at 3:08 PM, Mic Bowman wrote: > > > >> so what you're saying is just make sure the '/' is part of the match? to > >> terminate the match? i think the problem is that /asset matches > /asset_test > >> which is not what is expected. so all registered partial matches should > >> include the trailing '/' to disambiguate... or am i missing the point? > >> > >> > >> > >> On Tue, Apr 1, 2014 at 12:00 PM, Melanie wrote: > >> > >>> It is required because it's the basis of "extra path info". It's not > >>> part of REST, but rather part of HTTP. > >>> > >>> Requesting > >>> > >>> /asset/456392f6-c0b3-a346-6465-8218cbe7abe84592 > >>> > >>> which is not a registered URL, will invoke > >>> > >>> /asset/ > >>> > >>> which is. The ID passed as part of the URL is then given to that > >>> handler as the extra path info. You have the same thing in apache. > >>> > >>> Basically, any URL longer than and starting with a registered URL > >>> will invoke that registered URL with extra path info. > >>> The fallacy in our server is that the matching isn't by path parts, > >>> but character-wise. > >>> > >>> Melanie > >>> > >>> On 01/04/2014 20:03, Justin Clark-Casey wrote: > >>> > In what context is such partial matching required? It is not a > >>> requirement of REST, as far as I know. > >>> > > >>> > On 01/04/14 18:55, Melanie wrote: > >>> >> The REST URLs need to use partial matching, however, current > >>> >> semantics are broken. > >>> >> > >>> >> Without partial matching, URLS like /assets/782911..... would not > >>> >> work. the issue here is that it should match whole URL parts, not > >>> >> partial URL parts. Matching partial words as it does now seems like > >>> >> someone was cutting corners, it's not by design. > >>> >> > >>> >> /assets/ should match /assets/9887234...... but not /assets_exist. > >>> >> The slash is the differentiator and partial compares of URL string > >>> >> prefixes should be done by full-string matches of slash/delimited > >>> >> parts, not prefix matching of the entire URL. > >>> >> > >>> >> Melanie > >>> >> > >>> >> On 01/04/2014 15:00, Oren Hurvitz wrote: > >>> >>> I tried to add a REST handler at the endpoint "/assets_exist". It > >>> turns out > >>> >>> that I can't do that, because REST handlers are searched using > partial > >>> >>> string matches, so servers that don't implement the new handler > will > >>> >>> mistakenly choose the "/assets" endpoint instead. > >>> >>> > >>> >>> For now, I solved the problem by using a different endpoint: > >>> >>> "/get_assets_exist". > >>> >>> > >>> >>> For the future, I think that this should be changed so that only > full > >>> string > >>> >>> matches work. Otherwise each time a new handler is added it will > have > >>> to > >>> >>> find an endpoint name that isn't a prefix of any current endpoint > -- a > >>> >>> difficult and error-prone task. Before I do that, does anyone know > of > >>> >>> endpoints that rely on the current behavior (partial string > matches)? > >>> >>> > >>> >>> > >>> >>> > >>> >>> -- > >>> >>> View this message in context: > >>> > http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119.html > >>> >>> Sent from the opensim-dev mailing list archive at Nabble.com. > >>> >>> _______________________________________________ > >>> >>> Opensim-dev mailing list > >>> >>> Opensim-dev at lists.berlios.de > >>> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> >>> > >>> >>> > >>> >> _______________________________________________ > >>> >> Opensim-dev mailing list > >>> >> Opensim-dev at lists.berlios.de > >>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> >> > >>> > > >>> > > >>> _______________________________________________ > >>> Opensim-dev mailing list > >>> Opensim-dev at lists.berlios.de > >>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> > >> > >> > >> _______________________________________________ > >> Opensim-dev mailing list > >> Opensim-dev at lists.berlios.de > >> https://lists.berlios.de/mailman/listinfo/opensim-dev > >> > > > > > > > > > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- No essence. No permanence. No perfection. Only action. -------------- next part -------------- An HTML attachment was scrubbed... URL: From diva at metaverseink.com Tue Apr 1 20:15:50 2014 From: diva at metaverseink.com (Diva Canto) Date: Tue, 01 Apr 2014 13:15:50 -0700 Subject: [Opensim-dev] REST handlers use partial string matching In-Reply-To: <533B1B69.8050200@t-data.com> References: <1396357230099-7579119.post@n2.nabble.com> <533AFE9D.1020406@googlemail.com> <1396381789745-7579127.post@n2.nabble.com> <533B1B69.8050200@t-data.com> Message-ID: <533B1E76.8000805@metaverseink.com> BTW, for assets, in particular, there is already a GET metadata method, which is the same endpoint of the data itself, just with one more path compoenent /metadata/, if I remember correctly. This should be enough to know if the asset exists. Doesn't address the issue of multiple UUIDs in one call vs one at a time. On 4/1/2014 1:02 PM, Melanie wrote: > Because REST is cleaner and more modularized than RPC. Just compare > the code and you will see that. Efficiency is achieved by designing > the REST calls intelligently. The /asset/ endpoint for instance can > benefit from keep-alive because it supports HEAD/GET?POST so > multiple operations can reuse the connection. > The exists query is orthogonal to that and should be another request > endpoint. > > Melanie > > On 01/04/2014 21:56, Dahlia Trimble wrote: >> Not sure about this particular application but keeping a connection open >> can eliminate the need to instantiate a connection whenever a request is >> made; a process that can make several round trips to multiple endpoints. >> >> >> On Tue, Apr 1, 2014 at 12:52 PM, Mic Bowman wrote: >> >>> Do you really save much with a single request vs a keep alive on the >>> connection? HTTP connection overhead is likely much smaller than the >>> database operations... do you have a feel for how much we'll save with the >>> multiplexed call? >>> >>> --mic >>> >>> >>> >>> On Tue, Apr 1, 2014 at 12:49 PM, Oren Hurvitz wrote: >>> >>>> Re: why use POST instead of HEAD: because this lets me check the >>>> existence of >>>> many assets at once with a single HTTP request. The main use of the >>>> AssetsExist call is with HGAssetGatherer, which knows the full list of >>>> assets that it wants to send, so it's able to check all of them at once. >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>>> http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119p7579127.html >>>> Sent from the opensim-dev mailing list archive at Nabble.com. >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> Opensim-dev at lists.berlios.de >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> >>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > From orenh at kitely.com Tue Apr 1 21:21:12 2014 From: orenh at kitely.com (Oren Hurvitz) Date: Tue, 1 Apr 2014 14:21:12 -0700 (PDT) Subject: [Opensim-dev] REST handlers use partial string matching In-Reply-To: References: <1396357230099-7579119.post@n2.nabble.com> <533AFE9D.1020406@googlemail.com> <1396381789745-7579127.post@n2.nabble.com> Message-ID: <1396387272022-7579137.post@n2.nabble.com> The AssetsExist API is implemented efficiently in all levels of the stack including the database, where a single query checks all the assets. So a single HTTP request will be vastly more efficient than multiple calls, even if KeepAlive works. And I never trust KeepAlive anyway because I've used proxies that didn't enable KeepAlive by default (mod_ajp_proxy). -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119p7579137.html Sent from the opensim-dev mailing list archive at Nabble.com. From jjustincc at googlemail.com Wed Apr 2 01:41:53 2014 From: jjustincc at googlemail.com (Justin Clark-Casey) Date: Wed, 02 Apr 2014 02:41:53 +0100 Subject: [Opensim-dev] Preparing for OpenSimulator 0.8 Message-ID: <533B6AE1.5020108@googlemail.com> Hi folks. For the past 3 years, we've had a significant OpenSimulator release at about 4 to 8 month intervals. As the last major release (0.7.6) was in September 2013, we are due for another, and this seems like a reasonable point. From my perspective, releases drive a very significant level of OpenSimulator adoption. It's also the case that I may have a limited window of time to act as release manager, after which things may get very busy for me for an extended period. There was some disagreement over how the last release was handled, particularly over the period when I asked that developers take care to leave master stable. However, it's quite hard for me to see how this could be done in another way without significantly more manpower. Even when the release is branched, if the release branch and master diverge significantly (or master is broken) then a lot of the testing done by users is lost - very few people actually pick up and test release candidates. So unless there is disagreement, I'm going to ask that people take care to keep master stable until the end of April or release, whichever occurs first. This certainly does not mean a halt to development on master, it's just a request that people take a common sense approach to holding off from putting in destabilising or very complicated changes for a while, unless these are to fix significant bugs or regressions. I'm very happy to hear alternatives, though I would also need people to help if they involve more work. In any case, Robert has very kindly volunteered to look at some of the current regressions but more help is always very welcome. The current regressions or very major bugs have a 0.8 target in Mantis. As with every release so far, only major regressions are guaranteed to receive some sort of attention, where the answer may still be WONTFIX for this release. Regards, -- Justin Clark-Casey (justincc) OSVW Consulting http://justincc.org http://twitter.com/justincc From nebadon2025 at gmail.com Wed Apr 2 01:45:13 2014 From: nebadon2025 at gmail.com (Michael Emory Cerquoni) Date: Tue, 1 Apr 2014 21:45:13 -0400 Subject: [Opensim-dev] Preparing for OpenSimulator 0.8 In-Reply-To: <533B6AE1.5020108@googlemail.com> References: <533B6AE1.5020108@googlemail.com> Message-ID: +1 no disagreement here! anyone who wants to get crazy can do so in a new branch for now? On Apr 1, 2014 9:42 PM, "Justin Clark-Casey" wrote: > Hi folks. For the past 3 years, we've had a significant OpenSimulator > release at about 4 to 8 month intervals. > > As the last major release (0.7.6) was in September 2013, we are due for > another, and this seems like a reasonable point. From my perspective, > releases drive a very significant level of OpenSimulator adoption. It's > also the case that I may have a limited window of time to act as release > manager, after which things may get very busy for me for an extended period. > > There was some disagreement over how the last release was handled, > particularly over the period when I asked that developers take care to > leave master stable. However, it's quite hard for me to see how this could > be done in another way without significantly more manpower. Even when the > release is branched, if the release branch and master diverge significantly > (or master is broken) then a lot of the testing done by users is lost - > very few people actually pick up and test release candidates. > > So unless there is disagreement, I'm going to ask that people take care to > keep master stable until the end of April or release, whichever occurs > first. This certainly does not mean a halt to development on master, it's > just a request that people take a common sense approach to holding off from > putting in destabilising or very complicated changes for a while, unless > these are to fix significant bugs or regressions. > > I'm very happy to hear alternatives, though I would also need people to > help if they involve more work. In any case, Robert has very kindly > volunteered to look at some of the current regressions but more help is > always very welcome. > > The current regressions or very major bugs have a 0.8 target in Mantis. > As with every release so far, only major regressions are guaranteed to > receive some sort of attention, where the answer may still be WONTFIX for > this release. > > Regards, > > -- > Justin Clark-Casey (justincc) > OSVW Consulting > http://justincc.org > http://twitter.com/justincc > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From orenh at kitely.com Wed Apr 2 06:07:42 2014 From: orenh at kitely.com (Oren Hurvitz) Date: Tue, 1 Apr 2014 23:07:42 -0700 (PDT) Subject: [Opensim-dev] REST handlers use partial string matching In-Reply-To: <533B19E2.7030002@t-data.com> References: <1396357230099-7579119.post@n2.nabble.com> <533AFD82.9010603@t-data.com> <533AFF8B.6050607@googlemail.com> <533B0CCE.5000308@t-data.com> <533B19E2.7030002@t-data.com> Message-ID: <1396418862788-7579140.post@n2.nabble.com> I changed BaseHttpServer to require handler paths to match a full path component. For example, these match: "/assets" and "/assets/12345" But these don't match: "/assets" and "/assets_exist" -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119p7579140.html Sent from the opensim-dev mailing list archive at Nabble.com. From melanie at t-data.com Wed Apr 2 06:13:52 2014 From: melanie at t-data.com (Melanie) Date: Wed, 02 Apr 2014 08:13:52 +0200 Subject: [Opensim-dev] REST handlers use partial string matching In-Reply-To: <1396418862788-7579140.post@n2.nabble.com> References: <1396357230099-7579119.post@n2.nabble.com> <533AFD82.9010603@t-data.com> <533AFF8B.6050607@googlemail.com> <533B0CCE.5000308@t-data.com> <533B19E2.7030002@t-data.com> <1396418862788-7579140.post@n2.nabble.com> Message-ID: <533BAAA0.2060103@t-data.com> Thanks, that was a good catch! Melanie On 02/04/2014 08:07, Oren Hurvitz wrote: > I changed BaseHttpServer to require handler paths to match a full path > component. > > For example, these match: "/assets" and "/assets/12345" > But these don't match: "/assets" and "/assets_exist" > > > > > -- > View this message in context: http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119p7579140.html > Sent from the opensim-dev mailing list archive at Nabble.com. > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > From orenh at kitely.com Wed Apr 2 07:11:38 2014 From: orenh at kitely.com (Oren Hurvitz) Date: Wed, 2 Apr 2014 00:11:38 -0700 (PDT) Subject: [Opensim-dev] Optimize pushing assets to other grids In-Reply-To: <5339B3D2.4060902@metaverseink.com> References: <1396190871524-7579093.post@n2.nabble.com> <5338312A.4070302@metaverseink.com> <1396266948910-7579100.post@n2.nabble.com> <5339995A.4010208@t-data.com> <1396284763662-7579112.post@n2.nabble.com> <5339B3D2.4060902@metaverseink.com> Message-ID: <1396422698476-7579142.post@n2.nabble.com> I've added AssetsExist to master. It's implemented using REST, at "/get_assets_exist". Regarding getting server capabilities: later I realized that Hypergrid already has the "helo" command, which serves this purpose. Currently it returns only one type of property: whether the server is based on Robust or Simian. But it would be trivial to allow it to return other properties and preferences as well. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579142.html Sent from the opensim-dev mailing list archive at Nabble.com. From orenh at kitely.com Wed Apr 2 09:00:31 2014 From: orenh at kitely.com (Oren Hurvitz) Date: Wed, 2 Apr 2014 02:00:31 -0700 (PDT) Subject: [Opensim-dev] Viewer doesn't render attachments after teleport Message-ID: <1396429231035-7579143.post@n2.nabble.com> I'm seeing strange behavior from viewers: after an avatar HG teleports to another grid, his attachments sometimes aren't visible to *some* of the avatars in the region. The isn't that the attachments have been detached: the log shows that they came across perfectly. And some of the avatars in the region *do* see the attachments, while some do not. For example, in Singularity, an avatar already in the region sees the incoming avatar's attachments, whereas the incoming avatar himself does not! In Firestorm the problem is the reverse: the incoming avatar does see his attachments, but the avatar already in the grid doesn't. Waiting doesn't solve the problem. But other actions sometimes do: * Most tellingly, sometimes merely changing the zoom level of the viewer (using the mousewheel) makes the attachments appear. No packets are sent to or from the viewer at this time (I checked). * If the avatar walks forward then sometimes one or more of the attachments appear. But strangely, walking backwards doesn't make them appear. I looked carefully at the packets being sent to see if anything is missing, or whether the packets differ between avatars that do see the attachments and those who don't, but I can't see a difference. And in any case, the fact that sometimes the attachments can appear even without any packets being sent (as in the mousewheel example) means that it's something to do with the viewer. I don't want to just say "it's a viewer problem" and move on, because it's a problem for users of OpenSim. My working assumption is that by sending additional packets, or at different times, we can make the viewer refresh itself and show the attachments. This would only need to happen shortly after a teleport. Does anyone know what we could do to force the viewer to redraw the attachments? I tried sending additional "ObjectUpdate" packets for the attachments, but this didn't help. Oren -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Viewer-doesn-t-render-attachments-after-teleport-tp7579143.html Sent from the opensim-dev mailing list archive at Nabble.com. From orenh at kitely.com Wed Apr 2 09:05:36 2014 From: orenh at kitely.com (Oren Hurvitz) Date: Wed, 2 Apr 2014 02:05:36 -0700 (PDT) Subject: [Opensim-dev] Viewer doesn't render attachments after teleport In-Reply-To: <1396429231035-7579143.post@n2.nabble.com> References: <1396429231035-7579143.post@n2.nabble.com> Message-ID: <1396429536428-7579144.post@n2.nabble.com> Here's another interesting finding: even when the attachments aren't visible, I can click on them to edit them. The viewer renders a yellow outline around the shape of the attachment (in Singularity), even while the area inside the outline still doesn't show the attachment. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Viewer-doesn-t-render-attachments-after-teleport-tp7579143p7579144.html Sent from the opensim-dev mailing list archive at Nabble.com. From sphere1952 at gmail.com Wed Apr 2 11:01:17 2014 From: sphere1952 at gmail.com (Jim Williams) Date: Wed, 2 Apr 2014 07:01:17 -0400 Subject: [Opensim-dev] Viewer doesn't render attachments after teleport In-Reply-To: <1396429231035-7579143.post@n2.nabble.com> References: <1396429231035-7579143.post@n2.nabble.com> Message-ID: Are you sure this is just attachments? I've been having to right-click on certain objects after teleport for months now (in FS) under certain circumstances. This has been happening both in OSG and Metropolis. The problem usually happens if I jump again too soon after a teleport, and it is usually the same prims each time -- though which prims may change over time. I haven't noticed this to be specific to HG, though I do tend to double jump more when Hyperjumping. Mostly, I've learned to wait a few seconds before jumping a second time. On Wed, Apr 2, 2014 at 5:00 AM, Oren Hurvitz wrote: > I'm seeing strange behavior from viewers: after an avatar HG teleports to > another grid, his attachments sometimes aren't visible to *some* of the > avatars in the region. > > The isn't that the attachments have been detached: the log shows that they > came across perfectly. And some of the avatars in the region *do* see the > attachments, while some do not. For example, in Singularity, an avatar > already in the region sees the incoming avatar's attachments, whereas the > incoming avatar himself does not! In Firestorm the problem is the reverse: > the incoming avatar does see his attachments, but the avatar already in the > grid doesn't. > > Waiting doesn't solve the problem. But other actions sometimes do: > * Most tellingly, sometimes merely changing the zoom level of the viewer > (using the mousewheel) makes the attachments appear. No packets are sent to > or from the viewer at this time (I checked). > * If the avatar walks forward then sometimes one or more of the attachments > appear. But strangely, walking backwards doesn't make them appear. > > I looked carefully at the packets being sent to see if anything is missing, > or whether the packets differ between avatars that do see the attachments > and those who don't, but I can't see a difference. And in any case, the > fact > that sometimes the attachments can appear even without any packets being > sent (as in the mousewheel example) means that it's something to do with > the > viewer. > > I don't want to just say "it's a viewer problem" and move on, because it's > a > problem for users of OpenSim. My working assumption is that by sending > additional packets, or at different times, we can make the viewer refresh > itself and show the attachments. This would only need to happen shortly > after a teleport. > > Does anyone know what we could do to force the viewer to redraw the > attachments? I tried sending additional "ObjectUpdate" packets for the > attachments, but this didn't help. > > Oren > > > > -- > View this message in context: > http://opensim-dev.2196679.n2.nabble.com/Viewer-doesn-t-render-attachments-after-teleport-tp7579143.html > Sent from the opensim-dev mailing list archive at Nabble.com. > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- No essence. No permanence. No perfection. Only action. -------------- next part -------------- An HTML attachment was scrubbed... URL: From orenh at kitely.com Wed Apr 2 11:16:45 2014 From: orenh at kitely.com (Oren Hurvitz) Date: Wed, 2 Apr 2014 04:16:45 -0700 (PDT) Subject: [Opensim-dev] Viewer doesn't render attachments after teleport In-Reply-To: <1396429536428-7579144.post@n2.nabble.com> References: <1396429231035-7579143.post@n2.nabble.com> <1396429536428-7579144.post@n2.nabble.com> Message-ID: <1396437405521-7579146.post@n2.nabble.com> I got some great advice off-list from Nicky Perian. When there's a problem of missing prims, go to the Graphics Preferences and toggle the option "Basic shaders". I tried this, and toggling this option (on or off, both work) makes the missing prims appear immediately. This proves that the viewer has the correct data, and it's just not showing it. But I still want to find some combination of packets that will make the viewers show the prims, since obviously most users will not know to use this trick, and it's a hassle. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Viewer-doesn-t-render-attachments-after-teleport-tp7579143p7579146.html Sent from the opensim-dev mailing list archive at Nabble.com. From melanie at t-data.com Wed Apr 2 11:20:29 2014 From: melanie at t-data.com (Melanie) Date: Wed, 02 Apr 2014 13:20:29 +0200 Subject: [Opensim-dev] Viewer doesn't render attachments after teleport In-Reply-To: <1396437405521-7579146.post@n2.nabble.com> References: <1396429231035-7579143.post@n2.nabble.com> <1396429536428-7579144.post@n2.nabble.com> <1396437405521-7579146.post@n2.nabble.com> Message-ID: <533BF27D.5000707@t-data.com> I don't know if this may be related, but for some reason OpenSim fails to update the viewer's notion of position properly. The most noticeable effect is that sometimes after changing regions or even parcels, sound is no longer heard. The audibility check happens viewerside, just as the object visibility check. If the viewer gets a wrong location, it may consider the attachments as "too far away" and not render them - that is probably related to why zooming can make them appear. Therefore I don't believe we need to send any extra packets related to these objects, but rather we are missing some packet or sending wrong data related to the avatar's location. This appears to be the case on moving in world as well as teleports, but I have so far never observed it at login. Melanie On 02/04/2014 13:16, Oren Hurvitz wrote: > I got some great advice off-list from Nicky Perian. When there's a problem of > missing prims, go to the Graphics Preferences and toggle the option "Basic > shaders". I tried this, and toggling this option (on or off, both work) > makes the missing prims appear immediately. > > This proves that the viewer has the correct data, and it's just not showing > it. But I still want to find some combination of packets that will make the > viewers show the prims, since obviously most users will not know to use this > trick, and it's a hassle. > > > > -- > View this message in context: http://opensim-dev.2196679.n2.nabble.com/Viewer-doesn-t-render-attachments-after-teleport-tp7579143p7579146.html > Sent from the opensim-dev mailing list archive at Nabble.com. > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > From dahliatrimble at gmail.com Wed Apr 2 11:39:13 2014 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Wed, 2 Apr 2014 04:39:13 -0700 Subject: [Opensim-dev] Viewer doesn't render attachments after teleport In-Reply-To: <1396429536428-7579144.post@n2.nabble.com> References: <1396429231035-7579143.post@n2.nabble.com> <1396429536428-7579144.post@n2.nabble.com> Message-ID: I'd probably check the order of the packets. I'd suspect the ObjectUpdate for the agent should be sent first, then any attachment ObjectUpdate packets. It probably wouldn't hurt if the root prim is sent before any child prims but I'd hope the viewers could handle that situation. On Wed, Apr 2, 2014 at 2:05 AM, Oren Hurvitz wrote: > Here's another interesting finding: even when the attachments aren't > visible, > I can click on them to edit them. The viewer renders a yellow outline > around > the shape of the attachment (in Singularity), even while the area inside > the > outline still doesn't show the attachment. > > > > -- > View this message in context: > http://opensim-dev.2196679.n2.nabble.com/Viewer-doesn-t-render-attachments-after-teleport-tp7579143p7579144.html > Sent from the opensim-dev mailing list archive at Nabble.com. > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dahliatrimble at gmail.com Wed Apr 2 11:44:05 2014 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Wed, 2 Apr 2014 04:44:05 -0700 Subject: [Opensim-dev] Viewer doesn't render attachments after teleport In-Reply-To: <533BF27D.5000707@t-data.com> References: <1396429231035-7579143.post@n2.nabble.com> <1396429536428-7579144.post@n2.nabble.com> <1396437405521-7579146.post@n2.nabble.com> <533BF27D.5000707@t-data.com> Message-ID: Attachment positions are relative to bones. They really cannot be "too far away" On Wed, Apr 2, 2014 at 4:20 AM, Melanie wrote: > I don't know if this may be related, but for some reason OpenSim > fails to update the viewer's notion of position properly. > > The most noticeable effect is that sometimes after changing regions > or even parcels, sound is no longer heard. The audibility check > happens viewerside, just as the object visibility check. > > If the viewer gets a wrong location, it may consider the attachments > as "too far away" and not render them - that is probably related to > why zooming can make them appear. > > Therefore I don't believe we need to send any extra packets related > to these objects, but rather we are missing some packet or sending > wrong data related to the avatar's location. > > This appears to be the case on moving in world as well as teleports, > but I have so far never observed it at login. > > Melanie > > > On 02/04/2014 13:16, Oren Hurvitz wrote: > > I got some great advice off-list from Nicky Perian. When there's a > problem of > > missing prims, go to the Graphics Preferences and toggle the option > "Basic > > shaders". I tried this, and toggling this option (on or off, both work) > > makes the missing prims appear immediately. > > > > This proves that the viewer has the correct data, and it's just not > showing > > it. But I still want to find some combination of packets that will make > the > > viewers show the prims, since obviously most users will not know to use > this > > trick, and it's a hassle. > > > > > > > > -- > > View this message in context: > http://opensim-dev.2196679.n2.nabble.com/Viewer-doesn-t-render-attachments-after-teleport-tp7579143p7579146.html > > Sent from the opensim-dev mailing list archive at Nabble.com. > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dahliatrimble at gmail.com Wed Apr 2 11:50:28 2014 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Wed, 2 Apr 2014 04:50:28 -0700 Subject: [Opensim-dev] Viewer doesn't render attachments after teleport In-Reply-To: References: <1396429231035-7579143.post@n2.nabble.com> <1396429536428-7579144.post@n2.nabble.com> <1396437405521-7579146.post@n2.nabble.com> <533BF27D.5000707@t-data.com> Message-ID: I've seen attachment rezzing failures in SL for years. Right-clicking usually fixes it. If there is an issue then I suspect it's a long-standing viewer bug that may be exacerbated by some combination of legal protocol. If it is somehow related to packet ordering, then we might be able to send it in a particular order but given the non-stream nature of UDP we cannot guarantee it will be received in any order. On Wed, Apr 2, 2014 at 4:44 AM, Dahlia Trimble wrote: > Attachment positions are relative to bones. They really cannot be "too far > away" > > > On Wed, Apr 2, 2014 at 4:20 AM, Melanie wrote: > >> I don't know if this may be related, but for some reason OpenSim >> fails to update the viewer's notion of position properly. >> >> The most noticeable effect is that sometimes after changing regions >> or even parcels, sound is no longer heard. The audibility check >> happens viewerside, just as the object visibility check. >> >> If the viewer gets a wrong location, it may consider the attachments >> as "too far away" and not render them - that is probably related to >> why zooming can make them appear. >> >> Therefore I don't believe we need to send any extra packets related >> to these objects, but rather we are missing some packet or sending >> wrong data related to the avatar's location. >> >> This appears to be the case on moving in world as well as teleports, >> but I have so far never observed it at login. >> >> Melanie >> >> >> On 02/04/2014 13:16, Oren Hurvitz wrote: >> > I got some great advice off-list from Nicky Perian. When there's a >> problem of >> > missing prims, go to the Graphics Preferences and toggle the option >> "Basic >> > shaders". I tried this, and toggling this option (on or off, both work) >> > makes the missing prims appear immediately. >> > >> > This proves that the viewer has the correct data, and it's just not >> showing >> > it. But I still want to find some combination of packets that will make >> the >> > viewers show the prims, since obviously most users will not know to use >> this >> > trick, and it's a hassle. >> > >> > >> > >> > -- >> > View this message in context: >> http://opensim-dev.2196679.n2.nabble.com/Viewer-doesn-t-render-attachments-after-teleport-tp7579143p7579146.html >> > Sent from the opensim-dev mailing list archive at Nabble.com. >> > _______________________________________________ >> > Opensim-dev mailing list >> > Opensim-dev at lists.berlios.de >> > https://lists.berlios.de/mailman/listinfo/opensim-dev >> > >> > >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sphere1952 at gmail.com Wed Apr 2 14:07:59 2014 From: sphere1952 at gmail.com (Jim Williams) Date: Wed, 2 Apr 2014 10:07:59 -0400 Subject: [Opensim-dev] Preparing for OpenSimulator 0.8 In-Reply-To: <533B6AE1.5020108@googlemail.com> References: <533B6AE1.5020108@googlemail.com> Message-ID: Hi Justin, The fact that your message is a plea rather than an announcement makes it rather clear why I felt I had to leave OSG and move my sim to Metro. It also explains to me why I felt I had to add myself to this list at the same time -- self protection. If your release cycle is 4 months shouldn't there be a hard and fast feature freeze at the end of the first month? And there should be no back-talk or exceptions. Bug fixes ought to be just about 3/4 of the effort anyway. What OpenSim needs is credibility as a stable working system, not more features. If it''s a choice between what is going on now and having no development on OpenSim, I think I'd rather see no development. I have no way of stopping the badness from happening at my end other than complaining about it. On Tue, Apr 1, 2014 at 9:41 PM, Justin Clark-Casey wrote: > Hi folks. For the past 3 years, we've had a significant OpenSimulator > release at about 4 to 8 month intervals. > > As the last major release (0.7.6) was in September 2013, we are due for > another, and this seems like a reasonable point. From my perspective, > releases drive a very significant level of OpenSimulator adoption. It's > also the case that I may have a limited window of time to act as release > manager, after which things may get very busy for me for an extended period. > > There was some disagreement over how the last release was handled, > particularly over the period when I asked that developers take care to > leave master stable. However, it's quite hard for me to see how this could > be done in another way without significantly more manpower. Even when the > release is branched, if the release branch and master diverge significantly > (or master is broken) then a lot of the testing done by users is lost - > very few people actually pick up and test release candidates. > > So unless there is disagreement, I'm going to ask that people take care to > keep master stable until the end of April or release, whichever occurs > first. This certainly does not mean a halt to development on master, it's > just a request that people take a common sense approach to holding off from > putting in destabilising or very complicated changes for a while, unless > these are to fix significant bugs or regressions. > > I'm very happy to hear alternatives, though I would also need people to > help if they involve more work. In any case, Robert has very kindly > volunteered to look at some of the current regressions but more help is > always very welcome. > > The current regressions or very major bugs have a 0.8 target in Mantis. > As with every release so far, only major regressions are guaranteed to > receive some sort of attention, where the answer may still be WONTFIX for > this release. > > Regards, > > -- > Justin Clark-Casey (justincc) > OSVW Consulting > http://justincc.org > http://twitter.com/justincc > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- No essence. No permanence. No perfection. Only action. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nebadon2025 at gmail.com Wed Apr 2 14:22:57 2014 From: nebadon2025 at gmail.com (Michael Emory Cerquoni) Date: Wed, 2 Apr 2014 10:22:57 -0400 Subject: [Opensim-dev] Preparing for OpenSimulator 0.8 In-Reply-To: References: <533B6AE1.5020108@googlemail.com> Message-ID: Jim, You are way off topic here, this has nothing to do with OSG or Metro grids, I don't know why you suddenly feel the need to criticize everyone and everything announced here, but it has finally gotten to the point where I feel I need to step in and say something about this, your comments of late seem unproductive and volatile as if you are just trying to start arguments, please keep the drama out of these communications, Justin is simply trying to keep things moving forward in a productive manner and all I see from you lately is negativity and nothing that lends to any kind of improvement, this is a developer channel, if you want to lend to development than do something productive other than criticize, start submitting patches or get directly involved in debugging and filing bug reports or something, but please take the drama else where it is no appreciated. On Wed, Apr 2, 2014 at 10:07 AM, Jim Williams wrote: > Hi Justin, > > The fact that your message is a plea rather than an announcement makes it > rather clear why I felt I had to leave OSG and move my sim to Metro. It > also explains to me why I felt I had to add myself to this list at the same > time -- self protection. > > If your release cycle is 4 months shouldn't there be a hard and fast > feature freeze at the end of the first month? And there should be no > back-talk or exceptions. Bug fixes ought to be just about 3/4 of the > effort anyway. What OpenSim needs is credibility as a stable working > system, not more features. > > If it''s a choice between what is going on now and having no development > on OpenSim, I think I'd rather see no development. I have no way of > stopping the badness from happening at my end other than complaining about > it. > > > > On Tue, Apr 1, 2014 at 9:41 PM, Justin Clark-Casey < > jjustincc at googlemail.com> wrote: > >> Hi folks. For the past 3 years, we've had a significant OpenSimulator >> release at about 4 to 8 month intervals. >> >> As the last major release (0.7.6) was in September 2013, we are due for >> another, and this seems like a reasonable point. From my perspective, >> releases drive a very significant level of OpenSimulator adoption. It's >> also the case that I may have a limited window of time to act as release >> manager, after which things may get very busy for me for an extended period. >> >> There was some disagreement over how the last release was handled, >> particularly over the period when I asked that developers take care to >> leave master stable. However, it's quite hard for me to see how this could >> be done in another way without significantly more manpower. Even when the >> release is branched, if the release branch and master diverge significantly >> (or master is broken) then a lot of the testing done by users is lost - >> very few people actually pick up and test release candidates. >> >> So unless there is disagreement, I'm going to ask that people take care >> to keep master stable until the end of April or release, whichever occurs >> first. This certainly does not mean a halt to development on master, it's >> just a request that people take a common sense approach to holding off from >> putting in destabilising or very complicated changes for a while, unless >> these are to fix significant bugs or regressions. >> >> I'm very happy to hear alternatives, though I would also need people to >> help if they involve more work. In any case, Robert has very kindly >> volunteered to look at some of the current regressions but more help is >> always very welcome. >> >> The current regressions or very major bugs have a 0.8 target in Mantis. >> As with every release so far, only major regressions are guaranteed to >> receive some sort of attention, where the answer may still be WONTFIX for >> this release. >> >> Regards, >> >> -- >> Justin Clark-Casey (justincc) >> OSVW Consulting >> http://justincc.org >> http://twitter.com/justincc >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > -- > No essence. No permanence. No perfection. Only action. > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- Michael Emory Cerquoni -------------- next part -------------- An HTML attachment was scrubbed... URL: From diva at metaverseink.com Wed Apr 2 14:34:22 2014 From: diva at metaverseink.com (Diva Canto) Date: Wed, 02 Apr 2014 07:34:22 -0700 Subject: [Opensim-dev] Optimize pushing assets to other grids In-Reply-To: <1396422698476-7579142.post@n2.nabble.com> References: <1396190871524-7579093.post@n2.nabble.com> <5338312A.4070302@metaverseink.com> <1396266948910-7579100.post@n2.nabble.com> <5339995A.4010208@t-data.com> <1396284763662-7579112.post@n2.nabble.com> <5339B3D2.4060902@metaverseink.com> <1396422698476-7579142.post@n2.nabble.com> Message-ID: <533C1FEE.7020400@metaverseink.com> Yep, that's exactly its purpose. Feel free to add more info in the response. On 4/2/2014 12:11 AM, Oren Hurvitz wrote: > I've added AssetsExist to master. It's implemented using REST, at > "/get_assets_exist". > > Regarding getting server capabilities: later I realized that Hypergrid > already has the "helo" command, which serves this purpose. Currently it > returns only one type of property: whether the server is based on Robust or > Simian. But it would be trivial to allow it to return other properties and > preferences as well. > > > > -- > View this message in context: http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579142.html > Sent from the opensim-dev mailing list archive at Nabble.com. > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > From sphere1952 at gmail.com Wed Apr 2 14:39:46 2014 From: sphere1952 at gmail.com (Jim Williams) Date: Wed, 2 Apr 2014 10:39:46 -0400 Subject: [Opensim-dev] Preparing for OpenSimulator 0.8 In-Reply-To: References: <533B6AE1.5020108@googlemail.com> Message-ID: The basic problem is that their development will effect me as a user. I have no complaints about what Justin is trying to do. My complaint is how he has to word what he is doing, and I think it is because there is something wrong with the organization of this development project. Having looked at that organization, I'd say that the basic problem is that it is oriented about what potential developers might want to do rather than about what users might want. It's an organization I would want nothing to do with even if I wanted to work upon OpenSim rather than within it. Not only do I not want to do development, I want to use the system which was developed. The only reason I joined this list is because I think that the development currently happening is a threat to my continued enjoyment of the product. The difference between me and most end users is that I'm a retired programmer -- I know how these things go. So, you may drop dead for all I care. You are not helping to protect my environment. On Wed, Apr 2, 2014 at 10:22 AM, Michael Emory Cerquoni < nebadon2025 at gmail.com> wrote: > Jim, > > You are way off topic here, this has nothing to do with OSG or Metro > grids, I don't know why you suddenly feel the need to criticize everyone > and everything announced here, but it has finally gotten to the point where > I feel I need to step in and say something about this, your comments of > late seem unproductive and volatile as if you are just trying to start > arguments, please keep the drama out of these communications, Justin is > simply trying to keep things moving forward in a productive manner and all > I see from you lately is negativity and nothing that lends to any kind of > improvement, this is a developer channel, if you want to lend to > development than do something productive other than criticize, start > submitting patches or get directly involved in debugging and filing bug > reports or something, but please take the drama else where it is no > appreciated. > > > On Wed, Apr 2, 2014 at 10:07 AM, Jim Williams wrote: > >> Hi Justin, >> >> The fact that your message is a plea rather than an announcement makes it >> rather clear why I felt I had to leave OSG and move my sim to Metro. It >> also explains to me why I felt I had to add myself to this list at the same >> time -- self protection. >> >> If your release cycle is 4 months shouldn't there be a hard and fast >> feature freeze at the end of the first month? And there should be no >> back-talk or exceptions. Bug fixes ought to be just about 3/4 of the >> effort anyway. What OpenSim needs is credibility as a stable working >> system, not more features. >> >> If it''s a choice between what is going on now and having no development >> on OpenSim, I think I'd rather see no development. I have no way of >> stopping the badness from happening at my end other than complaining about >> it. >> >> >> >> On Tue, Apr 1, 2014 at 9:41 PM, Justin Clark-Casey < >> jjustincc at googlemail.com> wrote: >> >>> Hi folks. For the past 3 years, we've had a significant OpenSimulator >>> release at about 4 to 8 month intervals. >>> >>> As the last major release (0.7.6) was in September 2013, we are due for >>> another, and this seems like a reasonable point. From my perspective, >>> releases drive a very significant level of OpenSimulator adoption. It's >>> also the case that I may have a limited window of time to act as release >>> manager, after which things may get very busy for me for an extended period. >>> >>> There was some disagreement over how the last release was handled, >>> particularly over the period when I asked that developers take care to >>> leave master stable. However, it's quite hard for me to see how this could >>> be done in another way without significantly more manpower. Even when the >>> release is branched, if the release branch and master diverge significantly >>> (or master is broken) then a lot of the testing done by users is lost - >>> very few people actually pick up and test release candidates. >>> >>> So unless there is disagreement, I'm going to ask that people take care >>> to keep master stable until the end of April or release, whichever occurs >>> first. This certainly does not mean a halt to development on master, it's >>> just a request that people take a common sense approach to holding off from >>> putting in destabilising or very complicated changes for a while, unless >>> these are to fix significant bugs or regressions. >>> >>> I'm very happy to hear alternatives, though I would also need people to >>> help if they involve more work. In any case, Robert has very kindly >>> volunteered to look at some of the current regressions but more help is >>> always very welcome. >>> >>> The current regressions or very major bugs have a 0.8 target in Mantis. >>> As with every release so far, only major regressions are guaranteed to >>> receive some sort of attention, where the answer may still be WONTFIX for >>> this release. >>> >>> Regards, >>> >>> -- >>> Justin Clark-Casey (justincc) >>> OSVW Consulting >>> http://justincc.org >>> http://twitter.com/justincc >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >> >> >> -- >> No essence. No permanence. No perfection. Only action. >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > -- > Michael Emory Cerquoni > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- No essence. No permanence. No perfection. Only action. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nebadon2025 at gmail.com Wed Apr 2 14:44:24 2014 From: nebadon2025 at gmail.com (Michael Emory Cerquoni) Date: Wed, 2 Apr 2014 10:44:24 -0400 Subject: [Opensim-dev] Preparing for OpenSimulator 0.8 In-Reply-To: References: <533B6AE1.5020108@googlemail.com> Message-ID: Well if you are wondering why no one takes you seriously its because of stuff like the last line of your email, good luck with that! On Wed, Apr 2, 2014 at 10:39 AM, Jim Williams wrote: > The basic problem is that their development will effect me as a user. > > I have no complaints about what Justin is trying to do. My complaint is > how he has to word what he is doing, and I think it is because there is > something wrong with the organization of this development project. Having > looked at that organization, I'd say that the basic problem is that it is > oriented about what potential developers might want to do rather than about > what users might want. It's an organization I would want nothing to do > with even if I wanted to work upon OpenSim rather than within it. > > Not only do I not want to do development, I want to use the system which > was developed. The only reason I joined this list is because I think that > the development currently happening is a threat to my continued enjoyment > of the product. The difference between me and most end users is that I'm a > retired programmer -- I know how these things go. > > So, you may drop dead for all I care. You are not helping to protect my > environment. > > > > On Wed, Apr 2, 2014 at 10:22 AM, Michael Emory Cerquoni < > nebadon2025 at gmail.com> wrote: > >> Jim, >> >> You are way off topic here, this has nothing to do with OSG or Metro >> grids, I don't know why you suddenly feel the need to criticize everyone >> and everything announced here, but it has finally gotten to the point where >> I feel I need to step in and say something about this, your comments of >> late seem unproductive and volatile as if you are just trying to start >> arguments, please keep the drama out of these communications, Justin is >> simply trying to keep things moving forward in a productive manner and all >> I see from you lately is negativity and nothing that lends to any kind of >> improvement, this is a developer channel, if you want to lend to >> development than do something productive other than criticize, start >> submitting patches or get directly involved in debugging and filing bug >> reports or something, but please take the drama else where it is no >> appreciated. >> >> >> On Wed, Apr 2, 2014 at 10:07 AM, Jim Williams wrote: >> >>> Hi Justin, >>> >>> The fact that your message is a plea rather than an announcement makes >>> it rather clear why I felt I had to leave OSG and move my sim to Metro. It >>> also explains to me why I felt I had to add myself to this list at the same >>> time -- self protection. >>> >>> If your release cycle is 4 months shouldn't there be a hard and fast >>> feature freeze at the end of the first month? And there should be no >>> back-talk or exceptions. Bug fixes ought to be just about 3/4 of the >>> effort anyway. What OpenSim needs is credibility as a stable working >>> system, not more features. >>> >>> If it''s a choice between what is going on now and having no development >>> on OpenSim, I think I'd rather see no development. I have no way of >>> stopping the badness from happening at my end other than complaining about >>> it. >>> >>> >>> >>> On Tue, Apr 1, 2014 at 9:41 PM, Justin Clark-Casey < >>> jjustincc at googlemail.com> wrote: >>> >>>> Hi folks. For the past 3 years, we've had a significant OpenSimulator >>>> release at about 4 to 8 month intervals. >>>> >>>> As the last major release (0.7.6) was in September 2013, we are due for >>>> another, and this seems like a reasonable point. From my perspective, >>>> releases drive a very significant level of OpenSimulator adoption. It's >>>> also the case that I may have a limited window of time to act as release >>>> manager, after which things may get very busy for me for an extended period. >>>> >>>> There was some disagreement over how the last release was handled, >>>> particularly over the period when I asked that developers take care to >>>> leave master stable. However, it's quite hard for me to see how this could >>>> be done in another way without significantly more manpower. Even when the >>>> release is branched, if the release branch and master diverge significantly >>>> (or master is broken) then a lot of the testing done by users is lost - >>>> very few people actually pick up and test release candidates. >>>> >>>> So unless there is disagreement, I'm going to ask that people take care >>>> to keep master stable until the end of April or release, whichever occurs >>>> first. This certainly does not mean a halt to development on master, it's >>>> just a request that people take a common sense approach to holding off from >>>> putting in destabilising or very complicated changes for a while, unless >>>> these are to fix significant bugs or regressions. >>>> >>>> I'm very happy to hear alternatives, though I would also need people to >>>> help if they involve more work. In any case, Robert has very kindly >>>> volunteered to look at some of the current regressions but more help is >>>> always very welcome. >>>> >>>> The current regressions or very major bugs have a 0.8 target in Mantis. >>>> As with every release so far, only major regressions are guaranteed to >>>> receive some sort of attention, where the answer may still be WONTFIX for >>>> this release. >>>> >>>> Regards, >>>> >>>> -- >>>> Justin Clark-Casey (justincc) >>>> OSVW Consulting >>>> http://justincc.org >>>> http://twitter.com/justincc >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> Opensim-dev at lists.berlios.de >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> >>> >>> >>> >>> -- >>> No essence. No permanence. No perfection. Only action. >>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >> >> >> -- >> Michael Emory Cerquoni >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > -- > No essence. No permanence. No perfection. Only action. > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- Michael Emory Cerquoni -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmickeyb at gmail.com Wed Apr 2 15:37:39 2014 From: cmickeyb at gmail.com (Mic Bowman) Date: Wed, 2 Apr 2014 08:37:39 -0700 Subject: [Opensim-dev] Optimize pushing assets to other grids In-Reply-To: <1396422698476-7579142.post@n2.nabble.com> References: <1396190871524-7579093.post@n2.nabble.com> <5338312A.4070302@metaverseink.com> <1396266948910-7579100.post@n2.nabble.com> <5339995A.4010208@t-data.com> <1396284763662-7579112.post@n2.nabble.com> <5339B3D2.4060902@metaverseink.com> <1396422698476-7579142.post@n2.nabble.com> Message-ID: How is this hooked up in the simulator? I'll need to update the simian connectors. On Wed, Apr 2, 2014 at 12:11 AM, Oren Hurvitz wrote: > I've added AssetsExist to master. It's implemented using REST, at > "/get_assets_exist". > > Regarding getting server capabilities: later I realized that Hypergrid > already has the "helo" command, which serves this purpose. Currently it > returns only one type of property: whether the server is based on Robust or > Simian. But it would be trivial to allow it to return other properties and > preferences as well. > > > > -- > View this message in context: > http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579142.html > Sent from the opensim-dev mailing list archive at Nabble.com. > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From orenh at kitely.com Wed Apr 2 15:46:58 2014 From: orenh at kitely.com (Oren Hurvitz) Date: Wed, 2 Apr 2014 08:46:58 -0700 (PDT) Subject: [Opensim-dev] Optimize pushing assets to other grids In-Reply-To: References: <5338312A.4070302@metaverseink.com> <1396266948910-7579100.post@n2.nabble.com> <5339995A.4010208@t-data.com> <1396284763662-7579112.post@n2.nabble.com> <5339B3D2.4060902@metaverseink.com> <1396422698476-7579142.post@n2.nabble.com> Message-ID: I already implemented SimianAssetServiceConnector.AssetsExist(). But since I didn't change Simian itself, it works by simply calling GetMetadata() to check if each asset exists. You can either leave this as-is, or implement an explicit AssetsExist operation that checks all the assets at once, like I've done in Robust. On Wed, Apr 2, 2014 at 6:38 PM, Mic Bowman [via opensim-dev] < ml-node+s2196679n7579156h50 at n2.nabble.com> wrote: > How is this hooked up in the simulator? I'll need to update the simian > connectors. > > > On Wed, Apr 2, 2014 at 12:11 AM, Oren Hurvitz <[hidden email] > > wrote: > >> I've added AssetsExist to master. It's implemented using REST, at >> "/get_assets_exist". >> >> Regarding getting server capabilities: later I realized that Hypergrid >> already has the "helo" command, which serves this purpose. Currently it >> returns only one type of property: whether the server is based on Robust >> or >> Simian. But it would be trivial to allow it to return other properties and >> preferences as well. >> >> >> >> -- >> View this message in context: >> http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579142.html >> Sent from the opensim-dev mailing list archive at Nabble.com. >> _______________________________________________ >> Opensim-dev mailing list >> [hidden email] >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > _______________________________________________ > Opensim-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/opensim-dev > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579156.html > To unsubscribe from Optimize pushing assets to other grids, click here > . > NAML > -- Oren Hurvitz VP R&D Kitely Ltd. Email: orenh at kitely.com -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579157.html Sent from the opensim-dev mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ai.ai.austin at gmail.com Wed Apr 2 16:34:10 2014 From: ai.ai.austin at gmail.com (Ai Austin) Date: Wed, 02 Apr 2014 17:34:10 +0100 Subject: [Opensim-dev] Preparing for OpenSimulator 0.8 In-Reply-To: References: Message-ID: <533c3c03.a4f2c20a.287e.563b@mx.google.com> >From: Jim Williams >Not only do I not want to do development, I want to use the system >which was developed. ... So, you may drop dead for all I care. You >are not helping to protect my environment. Whoooaaa Jim... take it easy... that's way out of order in an open source contributed effort community.. and really not nice on a list for the developers who put their time and effort in to give us all software we can enjoy and use. I for one will be very pleased to see the stable release of 0.8.0 which testing is showing is very stable and up-to-date running on our own grid, on add-on regions on OSGrid and doing hypergrid jumps to a range of other grids. I am very glad that Justin one again is willing to take on the release preparation on behalf of all of us in the community.. developers, testers, documenters, wiki and blog writers, and users. From robertltux at gmail.com Wed Apr 2 17:17:00 2014 From: robertltux at gmail.com (Robert Martin) Date: Wed, 2 Apr 2014 13:17:00 -0400 Subject: [Opensim-dev] Preparing for OpenSimulator 0.8 In-Reply-To: <533c3c03.a4f2c20a.287e.563b@mx.google.com> References: <533c3c03.a4f2c20a.287e.563b@mx.google.com> Message-ID: from my POV i would think that a Freeze For Release would be a good idea since a constant MUST DO NEW FEATURE thing is what prevents having a good release. One thing that would be nice as a sidebar would be for there to be a single shell exe that starts the webserver then starts the sim and gives an all clear when the sim is ready (of course having a good working web control panel would be good). On Wed, Apr 2, 2014 at 12:34 PM, Ai Austin wrote: > >> From: Jim Williams >> Not only do I not want to do development, I want to use the system which >> was developed. ... So, you may drop dead for all I care. You are not >> helping to protect my environment. > > > Whoooaaa Jim... take it easy... that's way out of order in an open source > contributed effort community.. and really not nice on a list for the > developers who put their time and effort in to give us all software we can > enjoy and use. > > I for one will be very pleased to see the stable release of 0.8.0 which > testing is showing is very stable and up-to-date running on our own grid, on > add-on regions on OSGrid and doing hypergrid jumps to a range of other > grids. I am very glad that Justin one again is willing to take on the > release preparation on behalf of all of us in the community.. developers, > testers, documenters, wiki and blog writers, and users. > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev -- Robert L Martin From nebadon2025 at gmail.com Wed Apr 2 19:28:23 2014 From: nebadon2025 at gmail.com (Michael Emory Cerquoni) Date: Wed, 2 Apr 2014 15:28:23 -0400 Subject: [Opensim-dev] Optimize pushing assets to other grids In-Reply-To: References: <5338312A.4070302@metaverseink.com> <1396266948910-7579100.post@n2.nabble.com> <5339995A.4010208@t-data.com> <1396284763662-7579112.post@n2.nabble.com> <5339B3D2.4060902@metaverseink.com> <1396422698476-7579142.post@n2.nabble.com> Message-ID: excuse my ignorance here but are these changes directly to the asset server itself or are these simulator level changes? On Wed, Apr 2, 2014 at 11:46 AM, Oren Hurvitz wrote: > I already implemented SimianAssetServiceConnector.AssetsExist(). But since > I didn't change Simian itself, it works by simply calling GetMetadata() to > check if each asset exists. You can either leave this as-is, or implement > an explicit AssetsExist operation that checks all the assets at once, like > I've done in Robust. > > > On Wed, Apr 2, 2014 at 6:38 PM, Mic Bowman [via opensim-dev] <[hidden > email] > wrote: > >> How is this hooked up in the simulator? I'll need to update the simian >> connectors. >> >> >> On Wed, Apr 2, 2014 at 12:11 AM, Oren Hurvitz <[hidden email] >> > wrote: >> >>> I've added AssetsExist to master. It's implemented using REST, at >>> "/get_assets_exist". >>> >>> Regarding getting server capabilities: later I realized that Hypergrid >>> already has the "helo" command, which serves this purpose. Currently it >>> returns only one type of property: whether the server is based on Robust >>> or >>> Simian. But it would be trivial to allow it to return other properties >>> and >>> preferences as well. >>> >>> >>> >>> -- >>> View this message in context: >>> http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579142.html >>> Sent from the opensim-dev mailing list archive at Nabble.com. >>> _______________________________________________ >>> Opensim-dev mailing list >>> [hidden email] >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >> >> _______________________________________________ >> Opensim-dev mailing list >> [hidden email] >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> ------------------------------ >> If you reply to this email, your message will be added to the >> discussion below: >> >> http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579156.html >> To unsubscribe from Optimize pushing assets to other grids, click here. >> NAML >> > > > > -- > Oren Hurvitz > VP R&D > Kitely Ltd. > > Email: [hidden email][hidden > email] > > ------------------------------ > View this message in context: Re: Optimize pushing assets to other grids > Sent from the opensim-dev mailing list archiveat Nabble.com. > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- Michael Emory Cerquoni -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmickeyb at gmail.com Wed Apr 2 20:16:18 2014 From: cmickeyb at gmail.com (Mic Bowman) Date: Wed, 2 Apr 2014 13:16:18 -0700 Subject: [Opensim-dev] Optimize pushing assets to other grids In-Reply-To: References: <5338312A.4070302@metaverseink.com> <1396266948910-7579100.post@n2.nabble.com> <5339995A.4010208@t-data.com> <1396284763662-7579112.post@n2.nabble.com> <5339B3D2.4060902@metaverseink.com> <1396422698476-7579142.post@n2.nabble.com> Message-ID: Thanks. I'll take a look at what you've got. It's pretty easy to add the call to the Simian services. PHP you know. I don't have to screw around with http path prefix matching or anything... :-) --mic On Wed, Apr 2, 2014 at 8:46 AM, Oren Hurvitz wrote: > I already implemented SimianAssetServiceConnector.AssetsExist(). But since > I didn't change Simian itself, it works by simply calling GetMetadata() to > check if each asset exists. You can either leave this as-is, or implement > an explicit AssetsExist operation that checks all the assets at once, like > I've done in Robust. > > > On Wed, Apr 2, 2014 at 6:38 PM, Mic Bowman [via opensim-dev] <[hidden > email] > wrote: > >> How is this hooked up in the simulator? I'll need to update the simian >> connectors. >> >> >> On Wed, Apr 2, 2014 at 12:11 AM, Oren Hurvitz <[hidden email] >> > wrote: >> >>> I've added AssetsExist to master. It's implemented using REST, at >>> "/get_assets_exist". >>> >>> Regarding getting server capabilities: later I realized that Hypergrid >>> already has the "helo" command, which serves this purpose. Currently it >>> returns only one type of property: whether the server is based on Robust >>> or >>> Simian. But it would be trivial to allow it to return other properties >>> and >>> preferences as well. >>> >>> >>> >>> -- >>> View this message in context: >>> http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579142.html >>> Sent from the opensim-dev mailing list archive at Nabble.com. >>> _______________________________________________ >>> Opensim-dev mailing list >>> [hidden email] >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >> >> _______________________________________________ >> Opensim-dev mailing list >> [hidden email] >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> ------------------------------ >> If you reply to this email, your message will be added to the >> discussion below: >> >> http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579156.html >> To unsubscribe from Optimize pushing assets to other grids, click here. >> NAML >> > > > > -- > Oren Hurvitz > VP R&D > Kitely Ltd. > > Email: [hidden email][hidden > email] > > ------------------------------ > View this message in context: Re: Optimize pushing assets to other grids > Sent from the opensim-dev mailing list archiveat Nabble.com. > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From orenh at kitely.com Wed Apr 2 20:43:43 2014 From: orenh at kitely.com (Oren Hurvitz) Date: Wed, 2 Apr 2014 13:43:43 -0700 (PDT) Subject: [Opensim-dev] Optimize pushing assets to other grids In-Reply-To: References: <5339995A.4010208@t-data.com> <1396284763662-7579112.post@n2.nabble.com> <5339B3D2.4060902@metaverseink.com> <1396422698476-7579142.post@n2.nabble.com> Message-ID: The actual work is done in the assets server, and there's code in the simulators to call this API. On Wed, Apr 2, 2014 at 10:28 PM, Nebadon Izumi [via opensim-dev] < ml-node+s2196679n7579160h74 at n2.nabble.com> wrote: > excuse my ignorance here but are these changes directly to the asset > server itself or are these simulator level changes? > -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579162.html Sent from the opensim-dev mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From diva at metaverseink.com Wed Apr 2 20:50:57 2014 From: diva at metaverseink.com (Diva Canto) Date: Wed, 02 Apr 2014 13:50:57 -0700 Subject: [Opensim-dev] Optimize pushing assets to other grids In-Reply-To: References: <5339995A.4010208@t-data.com> <1396284763662-7579112.post@n2.nabble.com> <5339B3D2.4060902@metaverseink.com> <1396422698476-7579142.post@n2.nabble.com> Message-ID: <533C7831.9010403@metaverseink.com> I'm guessing OSGrid's asset server won't be able to reply to this new service, unless you change it. I'm also guessing that's ok -- it will behave as it behaves currently, the assets are copied over again. On 4/2/2014 1:43 PM, Oren Hurvitz wrote: > The actual work is done in the assets server, and there's code in the > simulators to call this API. > > > On Wed, Apr 2, 2014 at 10:28 PM, Nebadon Izumi [via opensim-dev] > <[hidden email] > wrote: > > excuse my ignorance here but are these changes directly to the > asset server itself or are these simulator level changes? > > > ------------------------------------------------------------------------ > View this message in context: Re: Optimize pushing assets to other > grids > > Sent from the opensim-dev mailing list archive > at Nabble.com. > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From nickyperian at gmail.com Wed Apr 2 21:42:39 2014 From: nickyperian at gmail.com (Nicky Perian) Date: Wed, 2 Apr 2014 16:42:39 -0500 Subject: [Opensim-dev] Viewer doesn't render attachments after teleport In-Reply-To: References: <1396429231035-7579143.post@n2.nabble.com> <1396429536428-7579144.post@n2.nabble.com> <1396437405521-7579146.post@n2.nabble.com> <533BF27D.5000707@t-data.com> Message-ID: Kokua's feature Refresh scene does the following and can be manually done on any viewer. Graphics->Advanced->Basic shaders tick to off. At this point the frame rate will climb to as high a value that the network will allow. In Kokua an info log message is written just to eat a little time at the high frame rate. Then, Basis shaders are ticked back on. This dresses the scene. Based on that I don't know if the prim/attachment is fully present in the viewer or not. Does the high frame rate over ride some net latency and pull all the prim's elementary data in or was it there all along and the redressing just put everything in order? LL has viewer interesting (interest list) in work and didn't want me to do any work on the missing prim issue until that viewer is in release. The Refresh scene was put in instead of a hackish approach of dropping Basic shaders before TP and turning them back on at completion. There appears to be some thread issues in TP's as my experimentation showed that setting a variable before TP did not necessarily insure that the arrival part of TP would have that same value. As noted in this thread about ordering, I think there is merit in exploring that aspect. On Wed, Apr 2, 2014 at 6:50 AM, Dahlia Trimble wrote: > I've seen attachment rezzing failures in SL for years. Right-clicking > usually fixes it. If there is an issue then I suspect it's a long-standing > viewer bug that may be exacerbated by some combination of legal protocol. > If it is somehow related to packet ordering, then we might be able to send > it in a particular order but given the non-stream nature of UDP we cannot > guarantee it will be received in any order. > > > On Wed, Apr 2, 2014 at 4:44 AM, Dahlia Trimble wrote: > >> Attachment positions are relative to bones. They really cannot be "too >> far away" >> >> >> On Wed, Apr 2, 2014 at 4:20 AM, Melanie wrote: >> >>> I don't know if this may be related, but for some reason OpenSim >>> fails to update the viewer's notion of position properly. >>> >>> The most noticeable effect is that sometimes after changing regions >>> or even parcels, sound is no longer heard. The audibility check >>> happens viewerside, just as the object visibility check. >>> >>> If the viewer gets a wrong location, it may consider the attachments >>> as "too far away" and not render them - that is probably related to >>> why zooming can make them appear. >>> >>> Therefore I don't believe we need to send any extra packets related >>> to these objects, but rather we are missing some packet or sending >>> wrong data related to the avatar's location. >>> >>> This appears to be the case on moving in world as well as teleports, >>> but I have so far never observed it at login. >>> >>> Melanie >>> >>> >>> On 02/04/2014 13:16, Oren Hurvitz wrote: >>> > I got some great advice off-list from Nicky Perian. When there's a >>> problem of >>> > missing prims, go to the Graphics Preferences and toggle the option >>> "Basic >>> > shaders". I tried this, and toggling this option (on or off, both work) >>> > makes the missing prims appear immediately. >>> > >>> > This proves that the viewer has the correct data, and it's just not >>> showing >>> > it. But I still want to find some combination of packets that will >>> make the >>> > viewers show the prims, since obviously most users will not know to >>> use this >>> > trick, and it's a hassle. >>> > >>> > >>> > >>> > -- >>> > View this message in context: >>> http://opensim-dev.2196679.n2.nabble.com/Viewer-doesn-t-render-attachments-after-teleport-tp7579143p7579146.html >>> > Sent from the opensim-dev mailing list archive at Nabble.com. >>> > _______________________________________________ >>> > Opensim-dev mailing list >>> > Opensim-dev at lists.berlios.de >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev >>> > >>> > >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >> > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fly.man.opensim at gmail.com Wed Apr 2 22:00:27 2014 From: fly.man.opensim at gmail.com (Fly Man) Date: Thu, 3 Apr 2014 00:00:27 +0200 Subject: [Opensim-dev] Preparing for OpenSimulator 0.8 In-Reply-To: References: <533c3c03.a4f2c20a.287e.563b@mx.google.com> Message-ID: I think sometimes it matters that there's a stable release schedule, Sept 2013 is far in the past and there has been a lot of changes in Opensim since then. Strangely enough there haven't been "in between" releases or something like that. At this moment I think a lot of grid owners are sweating as a new release might blow their support channels as the users will want to new features asap. My advice: Do a "in between" release so people can see the changes and use the 0.8 release as the large release for a lot of features that people have been wanting. Use the "in between" to see if there's any large issues arising. 2014-04-02 19:17 GMT+02:00 Robert Martin : > from my POV i would think that a Freeze For Release would be a good > idea since a constant MUST DO NEW FEATURE thing is what prevents > having a good release. > > One thing that would be nice as a sidebar would be for there to be a > single shell exe that starts the webserver then starts the sim and > gives an all clear when the sim is ready (of course having a good > working web control panel would be good). > > On Wed, Apr 2, 2014 at 12:34 PM, Ai Austin wrote: > > > >> From: Jim Williams > >> Not only do I not want to do development, I want to use the system which > >> was developed. ... So, you may drop dead for all I care. You are not > >> helping to protect my environment. > > > > > > Whoooaaa Jim... take it easy... that's way out of order in an open source > > contributed effort community.. and really not nice on a list for the > > developers who put their time and effort in to give us all software we > can > > enjoy and use. > > > > I for one will be very pleased to see the stable release of 0.8.0 which > > testing is showing is very stable and up-to-date running on our own > grid, on > > add-on regions on OSGrid and doing hypergrid jumps to a range of other > > grids. I am very glad that Justin one again is willing to take on the > > release preparation on behalf of all of us in the community.. developers, > > testers, documenters, wiki and blog writers, and users. > > > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > -- > Robert L Martin > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nebadon2025 at gmail.com Wed Apr 2 22:13:59 2014 From: nebadon2025 at gmail.com (Michael Emory Cerquoni) Date: Wed, 2 Apr 2014 18:13:59 -0400 Subject: [Opensim-dev] Preparing for OpenSimulator 0.8 In-Reply-To: References: <533c3c03.a4f2c20a.287e.563b@mx.google.com> Message-ID: OSgrid does releases very often and we do not modify the code in anyway all we do is add the osprofile and ossearch dlls to our release, anyone wanting to test newer releases could always use an OSgrid release and report bugs this way, we even provide zips of the source that come directly from http://opensimulator.org/viewgit, just need to replace our ini's with your own ini files and you are running the same code that we would push out into an official release basically. http://www.osgrid.org/index.php/downloads On Wed, Apr 2, 2014 at 6:00 PM, Fly Man wrote: > I think sometimes it matters that there's a stable release schedule, Sept > 2013 is far in the past and there has been a lot of changes in Opensim > since then. > > Strangely enough there haven't been "in between" releases or something > like that. At this moment I think a lot of grid owners are sweating as a > new release might blow their support channels as the users will want to new > features asap. > > My advice: Do a "in between" release so people can see the changes and use > the 0.8 release as the large release for a lot of features that people have > been wanting. Use the "in between" to see if there's any large issues > arising. > > > 2014-04-02 19:17 GMT+02:00 Robert Martin : > > from my POV i would think that a Freeze For Release would be a good >> idea since a constant MUST DO NEW FEATURE thing is what prevents >> having a good release. >> >> One thing that would be nice as a sidebar would be for there to be a >> single shell exe that starts the webserver then starts the sim and >> gives an all clear when the sim is ready (of course having a good >> working web control panel would be good). >> >> On Wed, Apr 2, 2014 at 12:34 PM, Ai Austin >> wrote: >> > >> >> From: Jim Williams >> >> Not only do I not want to do development, I want to use the system >> which >> >> was developed. ... So, you may drop dead for all I care. You are not >> >> helping to protect my environment. >> > >> > >> > Whoooaaa Jim... take it easy... that's way out of order in an open >> source >> > contributed effort community.. and really not nice on a list for the >> > developers who put their time and effort in to give us all software we >> can >> > enjoy and use. >> > >> > I for one will be very pleased to see the stable release of 0.8.0 which >> > testing is showing is very stable and up-to-date running on our own >> grid, on >> > add-on regions on OSGrid and doing hypergrid jumps to a range of other >> > grids. I am very glad that Justin one again is willing to take on the >> > release preparation on behalf of all of us in the community.. >> developers, >> > testers, documenters, wiki and blog writers, and users. >> > >> > >> > _______________________________________________ >> > Opensim-dev mailing list >> > Opensim-dev at lists.berlios.de >> > https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> >> >> -- >> Robert L Martin >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- Michael Emory Cerquoni -------------- next part -------------- An HTML attachment was scrubbed... URL: From jjustincc at googlemail.com Thu Apr 3 00:56:07 2014 From: jjustincc at googlemail.com (Justin Clark-Casey) Date: Thu, 03 Apr 2014 01:56:07 +0100 Subject: [Opensim-dev] Preparing for OpenSimulator 0.8 In-Reply-To: References: <533B6AE1.5020108@googlemail.com> Message-ID: <533CB1A7.3000502@googlemail.com> Yes, that would be one alternative. But to emphasise, I'm only asking for a common-sense approach to avoid destabilising master right now, not a blanket ban on commits or anything like that. On 02/04/14 02:45, Michael Emory Cerquoni wrote: > +1 no disagreement here! anyone who wants to get crazy can do so in a new branch for now? > > On Apr 1, 2014 9:42 PM, "Justin Clark-Casey" > wrote: > > Hi folks. For the past 3 years, we've had a significant OpenSimulator release at about 4 to 8 month intervals. > > As the last major release (0.7.6) was in September 2013, we are due for another, and this seems like a reasonable > point. From my perspective, releases drive a very significant level of OpenSimulator adoption. It's also the case > that I may have a limited window of time to act as release manager, after which things may get very busy for me for > an extended period. > > There was some disagreement over how the last release was handled, particularly over the period when I asked that > developers take care to leave master stable. However, it's quite hard for me to see how this could be done in > another way without significantly more manpower. Even when the release is branched, if the release branch and > master diverge significantly (or master is broken) then a lot of the testing done by users is lost - very few people > actually pick up and test release candidates. > > So unless there is disagreement, I'm going to ask that people take care to keep master stable until the end of April > or release, whichever occurs first. This certainly does not mean a halt to development on master, it's just a > request that people take a common sense approach to holding off from putting in destabilising or very complicated > changes for a while, unless these are to fix significant bugs or regressions. > > I'm very happy to hear alternatives, though I would also need people to help if they involve more work. In any > case, Robert has very kindly volunteered to look at some of the current regressions but more help is always very > welcome. > > The current regressions or very major bugs have a 0.8 target in Mantis. As with every release so far, only major > regressions are guaranteed to receive some sort of attention, where the answer may still be WONTFIX for this release. > > Regards, > > -- > Justin Clark-Casey (justincc) > OSVW Consulting > http://justincc.org > http://twitter.com/justincc > _________________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/__mailman/listinfo/opensim-dev > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- Justin Clark-Casey (justincc) OSVW Consulting http://justincc.org http://twitter.com/justincc From jjustincc at googlemail.com Thu Apr 3 01:01:33 2014 From: jjustincc at googlemail.com (Justin Clark-Casey) Date: Thu, 03 Apr 2014 02:01:33 +0100 Subject: [Opensim-dev] REST handlers use partial string matching In-Reply-To: <1396381789745-7579127.post@n2.nabble.com> References: <1396357230099-7579119.post@n2.nabble.com> <533AFE9D.1020406@googlemail.com> <1396381789745-7579127.post@n2.nabble.com> Message-ID: <533CB2ED.1050601@googlemail.com> Yeah, it's an interesting problem. A quick google doesn't reveal any obvious solutions, though one StackOverflow thread [1] has an interesting approach of wrapping multiple requests in a 'batch' request. So I don't object to this, but I don't think that we should kid ourselves that we're writing pure REST interfaces. get_asset_exists is effectively an RPC call which POSTs a bunch of UUIDs and gets data back - it is not an HTTP verb operating on a resource. Also, it would be great if you could add this new call to [2]. I'm very slowly trying to document all the various interfaces, protocols and calls, so that it's possible for other projects to implement them, to get a better overview of interfaces in OpenSimulator, etc. [1] http://stackoverflow.com/questions/14636332/convention-for-combining-rest-requests-and-replies [2] http://opensimulator.org/wiki/AssetService On 01/04/14 20:49, Oren Hurvitz wrote: > Re: why use POST instead of HEAD: because this lets me check the existence of > many assets at once with a single HTTP request. The main use of the > AssetsExist call is with HGAssetGatherer, which knows the full list of > assets that it wants to send, so it's able to check all of them at once. > > > > -- > View this message in context: http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119p7579127.html > Sent from the opensim-dev mailing list archive at Nabble.com. > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > . > -- Justin Clark-Casey (justincc) OSVW Consulting http://justincc.org http://twitter.com/justincc From jjustincc at googlemail.com Thu Apr 3 01:08:36 2014 From: jjustincc at googlemail.com (Justin Clark-Casey) Date: Thu, 03 Apr 2014 02:08:36 +0100 Subject: [Opensim-dev] Viewer doesn't render attachments after teleport In-Reply-To: <533BF27D.5000707@t-data.com> References: <1396429231035-7579143.post@n2.nabble.com> <1396429536428-7579144.post@n2.nabble.com> <1396437405521-7579146.post@n2.nabble.com> <533BF27D.5000707@t-data.com> Message-ID: <533CB494.6020207@googlemail.com> I also used to see this issue a lot when testing attachments. At the time, I remember looking into it and adjusting a few things to make OpenSimulator's output packet order match LL much more closely but with no effect. I haven't seen it for a while so I was hoping it had gone away, though that may also just be because I don't get the chance to go in-world very often. One possible thing to investigate is whether SOG updates with a position of <0,0,0> are somehow getting out to the region before attachments are properly set up. This might account for audio issues, etc. It might also be a shot in the dark, though I think this used to happen under some circumstances (along with other effects such as HUD attachments wrongly appearing on other viewer's screens). On 02/04/14 12:20, Melanie wrote: > I don't know if this may be related, but for some reason OpenSim > fails to update the viewer's notion of position properly. > > The most noticeable effect is that sometimes after changing regions > or even parcels, sound is no longer heard. The audibility check > happens viewerside, just as the object visibility check. > > If the viewer gets a wrong location, it may consider the attachments > as "too far away" and not render them - that is probably related to > why zooming can make them appear. > > Therefore I don't believe we need to send any extra packets related > to these objects, but rather we are missing some packet or sending > wrong data related to the avatar's location. > > This appears to be the case on moving in world as well as teleports, > but I have so far never observed it at login. > > Melanie > > > On 02/04/2014 13:16, Oren Hurvitz wrote: >> I got some great advice off-list from Nicky Perian. When there's a problem of >> missing prims, go to the Graphics Preferences and toggle the option "Basic >> shaders". I tried this, and toggling this option (on or off, both work) >> makes the missing prims appear immediately. >> >> This proves that the viewer has the correct data, and it's just not showing >> it. But I still want to find some combination of packets that will make the >> viewers show the prims, since obviously most users will not know to use this >> trick, and it's a hassle. >> >> >> >> -- >> View this message in context: http://opensim-dev.2196679.n2.nabble.com/Viewer-doesn-t-render-attachments-after-teleport-tp7579143p7579146.html >> Sent from the opensim-dev mailing list archive at Nabble.com. >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > . > -- Justin Clark-Casey (justincc) OSVW Consulting http://justincc.org http://twitter.com/justincc From rigun at rigutech.nl Sun Apr 6 09:49:35 2014 From: rigun at rigutech.nl (R.Gunther) Date: Sun, 06 Apr 2014 11:49:35 +0200 Subject: [Opensim-dev] HG friedns 0.8dev not compatible with 0.7.6.n ? Message-ID: <5341232F.8050909@rigutech.nl> Running my own grid works fine. But for some reason if i make friends with users on diva or old 0.7 opens/grid. Friends seems to fail. i have friend myself in osgriud and thats the only one thats working right ? Do i have a setting wrongh, or are the 0.7.6 grids setup wrong. I use the build in core freinds / groups for that. Or is there a bug ? Richard From aine.caoimhe at rogers.com Mon Apr 7 10:29:22 2014 From: aine.caoimhe at rogers.com (Aine) Date: Mon, 7 Apr 2014 06:29:22 -0400 Subject: [Opensim-dev] HG friedns 0.8dev not compatible with 0.7.6.n ? In-Reply-To: <5341232F.8050909@rigutech.nl> References: <5341232F.8050909@rigutech.nl> Message-ID: <001201cf524c$3e7d60b0$bb782210$@caoimhe@rogers.com> This is a bug that first appeared approximately a year ago and is somewhat more widespread issue. See: http://opensimulator.org/mantis/view.php?id=6603 http://opensimulator.org/mantis/view.php?id=6769 -----Original Message----- From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of R.Gunther Sent: Sunday, April 06, 2014 5:50 AM To: opensim-dev at lists.berlios.de Subject: [Opensim-dev] HG friedns 0.8dev not compatible with 0.7.6.n ? Running my own grid works fine. But for some reason if i make friends with users on diva or old 0.7 opens/grid. Friends seems to fail. i have friend myself in osgriud and thats the only one thats working right ? Do i have a setting wrongh, or are the 0.7.6 grids setup wrong. I use the build in core freinds / groups for that. Or is there a bug ? Richard _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4355 / Virus Database: 3722/7309 - Release Date: 04/06/14 From j.frank.nichols at gmail.com Mon Apr 7 19:02:05 2014 From: j.frank.nichols at gmail.com (Frank Nichols) Date: Mon, 7 Apr 2014 15:02:05 -0400 Subject: [Opensim-dev] OpenSimDefaults.ini clean up Message-ID: <9A70FC02-12BB-4E89-B64C-9EF8DEBA25D4@gmail.com> I would appreciate any comments on changing the OpenSimDefaults.ini file so that it will be the same form factor as the OpenSim.ini.example file. Currently the defaults file is an older format and as such it is difficult to compare the two when looking for changes or settings. I suggest (and am willing to do the work to make a patch) that the defaults file be updated to the same form factor as the OpenSim.ini.example file. In the case of any settings in the defaults that are not in the OpenSim.ini.example, those would be consolidated at the end of each associated section - i.e.. any thing in defaults [Startup] that is not in the .example [Startup] would be moved to the end of the defaults [Startup] section and updated to the same form factor as the rest of the settings. When completed the two files run when through diff would result in ONLY those lines that are different - those being lines in defaults not in example and the line for the default setting - i.e.: An example to demonstrate: OpenSim.ini.example [Startup] ;# {ConsolePrompt} {} {ConsolePrompt} {} "Region (\R) " ;; Console prompt ;; Certain special characters can be used to customize the prompt ;; Currently, these are ;; \R - substitute region name ;; \\ - substitute \ ; ConsolePrompt = "Region (\R) " OpenSimDefaults.ini currently: [Startup] ; Console prompt ; Certain special characters can be used to customize the prompt ; Currently, these are ; \R - substitute region name ; \\ - substtitue \ ConsolePrompt = "Region (\R) " OpenSimDefaults.ini proposed: [Startup] ;# {ConsolePrompt} {} {ConsolePrompt} {} "Region (\R) " ;; Console prompt ;; Certain special characters can be used to customize the prompt ;; Currently, these are ;; \R - substitute region name ;; \\ - substitute \ ConsolePrompt = "Region (\R) " The proposed change would make comparing the two files for changes and differences easier. It would be a clean diff obviously, since the defaults is 1800 lines and the example is only 1000. But, it might help. Frank Nichols From jak at ateb.co.uk Tue Apr 8 11:49:04 2014 From: jak at ateb.co.uk (Jak Daniels) Date: Tue, 08 Apr 2014 12:49:04 +0100 Subject: [Opensim-dev] OpenSimDefaults.ini clean up In-Reply-To: <9A70FC02-12BB-4E89-B64C-9EF8DEBA25D4@gmail.com> References: <9A70FC02-12BB-4E89-B64C-9EF8DEBA25D4@gmail.com> Message-ID: <5343E230.2090003@ateb.co.uk> +1 for this, however moving things in defaults that are not in example to the end of a section, particularly in the larger sections might move a setting more out of context and make the defaults file less readable. Jak On 07/04/2014 20:02, Frank Nichols wrote: > I would appreciate any comments on changing the OpenSimDefaults.ini file so that it will be the same form factor as the OpenSim.ini.example file. Currently the defaults file is an older format and as such it is difficult to compare the two when looking for changes or settings. > > I suggest (and am willing to do the work to make a patch) that the defaults file be updated to the same form factor as the OpenSim.ini.example file. In the case of any settings in the defaults that are not in the OpenSim.ini.example, those would be consolidated at the end of each associated section - i.e.. any thing in defaults [Startup] that is not in the .example [Startup] would be moved to the end of the defaults [Startup] section and updated to the same form factor as the rest of the settings. > > When completed the two files run when through diff would result in ONLY those lines that are different - those being lines in defaults not in example and the line for the default setting - i.e.: > > An example to demonstrate: > > OpenSim.ini.example > > [Startup] > ;# {ConsolePrompt} {} {ConsolePrompt} {} "Region (\R) " > ;; Console prompt > ;; Certain special characters can be used to customize the prompt > ;; Currently, these are > ;; \R - substitute region name > ;; \\ - substitute \ > ; ConsolePrompt = "Region (\R) " > > OpenSimDefaults.ini currently: > > [Startup] > ; Console prompt > ; Certain special characters can be used to customize the prompt > ; Currently, these are > ; \R - substitute region name > ; \\ - substtitue \ > ConsolePrompt = "Region (\R) " > > > OpenSimDefaults.ini proposed: > > [Startup] > ;# {ConsolePrompt} {} {ConsolePrompt} {} "Region (\R) " > ;; Console prompt > ;; Certain special characters can be used to customize the prompt > ;; Currently, these are > ;; \R - substitute region name > ;; \\ - substitute \ > ConsolePrompt = "Region (\R) " > > The proposed change would make comparing the two files for changes and differences easier. It would be a clean diff obviously, since the defaults is 1800 lines and the example is only 1000. But, it might help. > > Frank Nichols > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From ste at smxy.org Tue Apr 8 14:19:10 2014 From: ste at smxy.org (Shaun T. Erickson) Date: Tue, 08 Apr 2014 10:19:10 -0400 Subject: [Opensim-dev] OpenSimDefaults.ini clean up In-Reply-To: <5343E230.2090003@ateb.co.uk> References: <9A70FC02-12BB-4E89-B64C-9EF8DEBA25D4@gmail.com> <5343E230.2090003@ateb.co.uk> Message-ID: <5344055E.5000207@smxy.org> Yeah, I would definitely vote against moving things to the end of sections. It's perfectly fine to have, say: A B C D E in the defaults file, but only have, say: A C E in OpenSim.ini.example. -ste On 4/8/14, 7:49 AM, Jak Daniels wrote: > +1 for this, however moving things in defaults that are not in example > to the end of a section, particularly in the larger sections might > move a setting more out of context and make the defaults file less > readable. -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.stallings at gmail.com Tue Apr 8 14:32:40 2014 From: james.stallings at gmail.com (James Stallings II) Date: Tue, 8 Apr 2014 09:32:40 -0500 Subject: [Opensim-dev] OpenSimDefaults.ini clean up In-Reply-To: <5344055E.5000207@smxy.org> References: <9A70FC02-12BB-4E89-B64C-9EF8DEBA25D4@gmail.com> <5343E230.2090003@ateb.co.uk> <5344055E.5000207@smxy.org> Message-ID: I think if any of this is touched, it should be to the OpenSim.ini file, to remove the proprietary formatting for the gui configurator that is not present in opensim core. For my part, it isn't a problem; but as far as I'm concerned modifying the format of OpenSimDefaults.ini is probably going at it a bit backward. Cheers James On Tue, Apr 8, 2014 at 9:19 AM, Shaun T. Erickson wrote: > Yeah, I would definitely vote against moving things to the end of > sections. It's perfectly fine to have, say: > > A > B > C > D > E > > in the defaults file, but only have, say: > > A > C > E > > in OpenSim.ini.example. > > -ste > > > On 4/8/14, 7:49 AM, Jak Daniels wrote: > > +1 for this, however moving things in defaults that are not in example to > the end of a section, particularly in the larger sections might move a > setting more out of context and make the defaults file less readable. > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From marceled9 at gmail.com Tue Apr 8 15:20:56 2014 From: marceled9 at gmail.com (M.E. Verhagen) Date: Tue, 8 Apr 2014 17:20:56 +0200 Subject: [Opensim-dev] OpenSimDefaults.ini clean up In-Reply-To: References: <9A70FC02-12BB-4E89-B64C-9EF8DEBA25D4@gmail.com> <5343E230.2090003@ateb.co.uk> <5344055E.5000207@smxy.org> Message-ID: I would be careful with touching the defaults in the defaults file. It is always good to have a file where you can look up the defaults when you somehow messed up in opensim.ini. You probably will never need those settings which are in defaults but not in opensim.ini. -------------- next part -------------- An HTML attachment was scrubbed... URL: From melanie at t-data.com Tue Apr 8 15:23:25 2014 From: melanie at t-data.com (Melanie) Date: Tue, 08 Apr 2014 17:23:25 +0200 Subject: [Opensim-dev] OpenSimDefaults.ini clean up In-Reply-To: References: <9A70FC02-12BB-4E89-B64C-9EF8DEBA25D4@gmail.com> <5343E230.2090003@ateb.co.uk> <5344055E.5000207@smxy.org> Message-ID: <5344146D.6050203@t-data.com> The GUI configurator doesn't even exist yet. It's not proprietary, it's just not done yet. The work was put in to create this formatting to encourage the creation of such a GUI tool. It will certainly not be removed. - Melanie On 08/04/2014 16:32, James Stallings II wrote: > I think if any of this is touched, it should be to the OpenSim.ini file, to > remove the proprietary formatting for the gui configurator that is not > present in opensim core. > > For my part, it isn't a problem; but as far as I'm concerned modifying the > format of OpenSimDefaults.ini is probably going at it a bit backward. > > Cheers > James > > > > On Tue, Apr 8, 2014 at 9:19 AM, Shaun T. Erickson wrote: > >> Yeah, I would definitely vote against moving things to the end of >> sections. It's perfectly fine to have, say: >> >> A >> B >> C >> D >> E >> >> in the defaults file, but only have, say: >> >> A >> C >> E >> >> in OpenSim.ini.example. >> >> -ste >> >> >> On 4/8/14, 7:49 AM, Jak Daniels wrote: >> >> +1 for this, however moving things in defaults that are not in example to >> the end of a section, particularly in the larger sections might move a >> setting more out of context and make the defaults file less readable. >> >> >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev From melanie at t-data.com Tue Apr 8 15:25:41 2014 From: melanie at t-data.com (Melanie) Date: Tue, 08 Apr 2014 17:25:41 +0200 Subject: [Opensim-dev] OpenSimDefaults.ini clean up In-Reply-To: <5344055E.5000207@smxy.org> References: <9A70FC02-12BB-4E89-B64C-9EF8DEBA25D4@gmail.com> <5343E230.2090003@ateb.co.uk> <5344055E.5000207@smxy.org> Message-ID: <534414F5.9080305@t-data.com> I'm also against moving things to the end of sections. Having the options present in Opensim.ini in the same order as in the defaults file makes sense for diffing, but moving them to the end of sections does not because it would cause the readability issues mentioned as well as make it even more confusing if someone copies a section to their ini from the defaults file, breaking that scheme. The defaults file is overwritten in every update. - Melanie On 08/04/2014 16:19, Shaun T. Erickson wrote: > Yeah, I would definitely vote against moving things to the end of > sections. It's perfectly fine to have, say: > > A > B > C > D > E > > in the defaults file, but only have, say: > > A > C > E > > in OpenSim.ini.example. > > -ste > > On 4/8/14, 7:49 AM, Jak Daniels wrote: >> +1 for this, however moving things in defaults that are not in example >> to the end of a section, particularly in the larger sections might >> move a setting more out of context and make the defaults file less >> readable. > > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev From marcus.llewellyn at gmail.com Tue Apr 8 16:43:05 2014 From: marcus.llewellyn at gmail.com (Marcus Llewellyn) Date: Tue, 8 Apr 2014 11:43:05 -0500 Subject: [Opensim-dev] OpenSimDefaults.ini clean up In-Reply-To: <534414F5.9080305@t-data.com> References: <9A70FC02-12BB-4E89-B64C-9EF8DEBA25D4@gmail.com> <5343E230.2090003@ateb.co.uk> <5344055E.5000207@smxy.org> <534414F5.9080305@t-data.com> Message-ID: In regard to the specially formatted comments meant to aid external configuration tools, it may be worth considering adding these to OpenSimDefaults.ini. Currently, OpenSim.ini.example contains them, but OpenSimDefaults does not. When one strips OpenSim.ini.example down to *only* active sections, keys, and values while including those configuration comments, you end up easily seeing that every single option is being paired with a special configuration comment. On the other hand, if you do the same thing to a grid's OpenSim.ini file (I used OSgrid's), it becomes much less consistent. Sections like Startup or XEngine will only have a few of these config/option pairings. Some sections like RegionReady, VivoxVoice, and BulletSim have none at all. The authors of these OpenSIm.ini files aren't at fault. They simply have more imperative things to do than track down all of the possible option values or dependencies. Since, presumably, options added to OpenSim.ini files like OSgrid's are largely derived from OpenSimDefaults.ini, it could be of benefit to provide the config comments in OpenSimDefaults as well. OpenSim.ini.example is setup only for standalones. Simulators configured for grids obviously use more options (about 7 times the options in OSgrid's case). Any future configuration tool would probably be most useful on configuration files meant for either mode of operation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.stallings at gmail.com Tue Apr 8 22:45:15 2014 From: james.stallings at gmail.com (James Stallings II) Date: Tue, 8 Apr 2014 17:45:15 -0500 Subject: [Opensim-dev] OpenSimDefaults.ini clean up In-Reply-To: References: <9A70FC02-12BB-4E89-B64C-9EF8DEBA25D4@gmail.com> <5343E230.2090003@ateb.co.uk> <5344055E.5000207@smxy.org> <534414F5.9080305@t-data.com> Message-ID: Actually Mel, I would not suggest that you do so. I've found some fairly useful workflows involving the shell utilities find, diff, grep and sed that really kind of move such concerns aside, allowing me to analyze and/or edit large groups of files all in one big glorious command line invocation :3 Note that heavy CYA safety nets are in place ;) It isn't especially advanced by way of technique what I'm doing, really just using those tools together for their intended purposes. If someone does get around to writing a gui configurator, that would be awesome (/me pokes marcus) Sorry for the confusion about the proprietary nature of the thing Mel, I guess I got the wrong idea last time we spoke of it, and that has been quite some time. In any case, my strategy is basically to use grep as a filter to get rid of the 'comments' on the fly, single out things I need to compare, etc which I then pass to diff or sed. I use find to generate lists of paths to the files I need to compare or edit (or not, depending whether I'm working on files in bulk). It's kind of a cowboy way of doing things, but it's very quick and effective if you don't get too crazy with it. Safe too if you make sure to keep good backups. Cheers! James/Hiro On Tue, Apr 8, 2014 at 11:43 AM, Marcus Llewellyn < marcus.llewellyn at gmail.com> wrote: > In regard to the specially formatted comments meant to aid external > configuration tools, it may be worth considering adding these to > OpenSimDefaults.ini. Currently, OpenSim.ini.example contains them, but > OpenSimDefaults does not. > > When one strips OpenSim.ini.example down to *only* active sections, keys, > and values while including those configuration comments, you end up easily > seeing that every single option is being paired with a special > configuration comment. > > On the other hand, if you do the same thing to a grid's OpenSim.ini file > (I used OSgrid's), it becomes much less consistent. Sections like Startup > or XEngine will only have a few of these config/option pairings. Some > sections like RegionReady, VivoxVoice, and BulletSim have none at all. The > authors of these OpenSIm.ini files aren't at fault. They simply have more > imperative things to do than track down all of the possible option values > or dependencies. > > Since, presumably, options added to OpenSim.ini files like OSgrid's are > largely derived from OpenSimDefaults.ini, it could be of benefit to provide > the config comments in OpenSimDefaults as well. OpenSim.ini.example is > setup only for standalones. Simulators configured for grids obviously use > more options (about 7 times the options in OSgrid's case). Any future > configuration tool would probably be most useful on configuration files > meant for either mode of operation. > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From melanie at t-data.com Tue Apr 8 22:48:41 2014 From: melanie at t-data.com (Melanie) Date: Wed, 09 Apr 2014 00:48:41 +0200 Subject: [Opensim-dev] OpenSimDefaults.ini clean up In-Reply-To: References: <9A70FC02-12BB-4E89-B64C-9EF8DEBA25D4@gmail.com> <5343E230.2090003@ateb.co.uk> <5344055E.5000207@smxy.org> <534414F5.9080305@t-data.com> Message-ID: <53447CC9.5090103@t-data.com> Well, you're familiar with the command line, which many are now. Also, without cygwin, Windows is somewhat command line challenged. As for the "proprietary" bit - Avination does not use ini files. This encoding was done for the benefit of the open source community, we ourselves have no need of it. Melanie On 09/04/2014 00:45, James Stallings II wrote: > Actually Mel, I would not suggest that you do so. I've found some fairly > useful workflows involving the shell utilities find, diff, grep and sed > that really kind of move such concerns aside, allowing me to analyze and/or > edit large groups of files all in one big glorious command line invocation > :3 > > Note that heavy CYA safety nets are in place ;) > > It isn't especially advanced by way of technique what I'm doing, really > just using those tools together for their intended purposes. > > If someone does get around to writing a gui configurator, that would be > awesome (/me pokes marcus) > > Sorry for the confusion about the proprietary nature of the thing Mel, I > guess I got the wrong idea last time we spoke of it, and that has been > quite some time. > > In any case, my strategy is basically to use grep as a filter to get rid of > the 'comments' on the fly, single out things I need to compare, etc which I > then pass to diff or sed. I use find to generate lists of paths to the > files I need to compare or edit (or not, depending whether I'm working on > files in bulk). > > It's kind of a cowboy way of doing things, but it's very quick and > effective if you don't get too crazy with it. Safe too if you make sure to > keep good backups. > > > Cheers! > James/Hiro > > > > On Tue, Apr 8, 2014 at 11:43 AM, Marcus Llewellyn < > marcus.llewellyn at gmail.com> wrote: > >> In regard to the specially formatted comments meant to aid external >> configuration tools, it may be worth considering adding these to >> OpenSimDefaults.ini. Currently, OpenSim.ini.example contains them, but >> OpenSimDefaults does not. >> >> When one strips OpenSim.ini.example down to *only* active sections, keys, >> and values while including those configuration comments, you end up easily >> seeing that every single option is being paired with a special >> configuration comment. >> >> On the other hand, if you do the same thing to a grid's OpenSim.ini file >> (I used OSgrid's), it becomes much less consistent. Sections like Startup >> or XEngine will only have a few of these config/option pairings. Some >> sections like RegionReady, VivoxVoice, and BulletSim have none at all. The >> authors of these OpenSIm.ini files aren't at fault. They simply have more >> imperative things to do than track down all of the possible option values >> or dependencies. >> >> Since, presumably, options added to OpenSim.ini files like OSgrid's are >> largely derived from OpenSimDefaults.ini, it could be of benefit to provide >> the config comments in OpenSimDefaults as well. OpenSim.ini.example is >> setup only for standalones. Simulators configured for grids obviously use >> more options (about 7 times the options in OSgrid's case). Any future >> configuration tool would probably be most useful on configuration files >> meant for either mode of operation. >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev From james.stallings at gmail.com Thu Apr 10 14:01:56 2014 From: james.stallings at gmail.com (James Stallings II) Date: Thu, 10 Apr 2014 09:01:56 -0500 Subject: [Opensim-dev] Parcel Access Enforcement Message-ID: Greetings Devs :) I have a use case that requires the unlikely and less than popular parcel permissions access control featureset. Historically speaking, this has not been an area of development that has seen much love, and understandably so; none of us are particularly interested in fully duplicating the operational envelope of the Second Life experience. That coupled with the ability to deploy regions at whim, it is no wonder no one wants to involve themselves particularly deeply with making this work properly. That being said, I have a need at present, and there is also the simple fact that we have a dearth of UI components in the viewer we may well never get shut of, and a lot of of unfinished and/or unpolished code in the repo that touches on this functionality. The short story is, it may be above the waterline, but there is a hole in the boat, and one of my users is driving it headlong into the surf. So much for metaphors. I have heard a variety of conflicting reports about the state of this part of the codebase; some say it works well; others say it should not be counted on to work at all. The commit logs tell the tale that some have taken an interest and are working diligently to eliminate certain bugs; unfortunately, the work in progress has not yet brought the functionality into a state where it is yet useful, at least according to my testing. I'm not unwilling to undertake the work needed to bring this situation into a more satisfactory light; indeed, I've already begun, and I need only a little guidance today. I have thoroughly instrumented the method "public void EventManagerOnAvatarEnteringNewParcel(ScenePresence avatar, int localLandID, UUID regionID)" in the land management module, and was immediately confronted with a couple of surprises: First, when the code is called at all, it is called twice; and as far as I can tell, it is called only after a successful login has been completed. Neither does it seem to be called when an avatar teleports into the region. Instead, the method "public bool TestLandRestrictions(UUID agentID, out string reason, ref float posX, ref float posY)" is called from "OpenSim/Region/Framework/Scenes/Scene.cs" and "OpenSim/Region/Framework/Scenes/ScenePresence.cs", and mediates (rather less than consistently) whether the avatar is allowed into the parcel on the region. Being aware that there are several ways for an avatar to enter a parcel, which I will leave off enumerating at present, I would suggest that perhaps I have some misapprehensions as to the proper stages of authentication at login-time. So my question is this: should both of these functions come into play as an avatar enters a region (and consequently, a parcel)? or should there be a single methoid conducting these presence permission checks? Please advise at your convenience :) Many thanks and cheers James/Hiro -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.stallings at gmail.com Thu Apr 10 14:30:03 2014 From: james.stallings at gmail.com (James Stallings II) Date: Thu, 10 Apr 2014 09:30:03 -0500 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: References: Message-ID: After some further exploration, I have seen where the method calls taking precedence from out of Scene are handling ViaLogin; but they are also doing some of the same lifting performed in the Land Management module. This seems to be duplication of effort, if not duplication of code; and is certainly less elegant than I would hope to find in our codebase (in an ideal world ;) This is likely the result of the ad-hoc nature of the development life of the project over the years; I can see the scene code being a good deal older than the Land Management module. I'll be working with this throughout the day, hoping to improve the code as I'm able; your thoughts, advice and commentary are solicited and appreciated. Cheers James On Thu, Apr 10, 2014 at 9:01 AM, James Stallings II < james.stallings at gmail.com> wrote: > Greetings Devs :) > > I have a use case that requires the unlikely and less than popular parcel > permissions access control featureset. > > Historically speaking, this has not been an area of development that has > seen much love, and understandably so; none of us are particularly > interested in fully duplicating the operational envelope of the Second Life > experience. That coupled with the ability to deploy regions at whim, it is > no wonder no one wants to involve themselves particularly deeply with > making this work properly. > > That being said, I have a need at present, and there is also the simple > fact that we have a dearth of UI components in the viewer we may well never > get shut of, and a lot of of unfinished and/or unpolished code in the repo > that touches on this functionality. > > The short story is, it may be above the waterline, but there is a hole in > the boat, and one of my users is driving it headlong into the surf. > > So much for metaphors. > > I have heard a variety of conflicting reports about the state of this part > of the codebase; some say it works well; others say it should not be > counted on to work at all. The commit logs tell the tale that some have > taken an interest and are working diligently to eliminate certain bugs; > unfortunately, the work in progress has not yet brought the functionality > into a state where it is yet useful, at least according to my testing. > > I'm not unwilling to undertake the work needed to bring this situation > into a more satisfactory light; indeed, I've already begun, and I need only > a little guidance today. > > I have thoroughly instrumented the method "public void > EventManagerOnAvatarEnteringNewParcel(ScenePresence avatar, int > localLandID, UUID regionID)" > in the land management module, and was immediately confronted with a > couple of surprises: > First, when the code is called at all, it is called twice; and as far as I > can tell, it is called only after a successful login has been completed. > Neither does it seem to be called when an avatar teleports into the region. > > Instead, the method "public bool TestLandRestrictions(UUID agentID, out > string reason, ref float posX, ref float posY)" is called from > "OpenSim/Region/Framework/Scenes/Scene.cs" and > "OpenSim/Region/Framework/Scenes/ScenePresence.cs", and mediates (rather > less than consistently) whether the avatar is allowed into the parcel on > the region. > > Being aware that there are several ways for an avatar to enter a parcel, > which I will leave off enumerating at present, I would suggest that perhaps > I have some misapprehensions as to the proper stages of authentication at > login-time. > > So my question is this: should both of these functions come into play as > an avatar enters a region (and consequently, a parcel)? or should there be > a single methoid conducting these presence permission checks? > > Please advise at your convenience :) > > Many thanks and cheers > James/Hiro > > > -- > =================================== > http://osgrid.org/ > http://simhost.com > http://twitter.com/jstallings2 > > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.stallings at gmail.com Thu Apr 10 15:05:21 2014 From: james.stallings at gmail.com (James Stallings II) Date: Thu, 10 Apr 2014 10:05:21 -0500 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: References: Message-ID: Subsequent work (instrumentation to Scene) shows that the permissions checking code is also being called twice there. Cheers James On Thu, Apr 10, 2014 at 9:30 AM, James Stallings II < james.stallings at gmail.com> wrote: > After some further exploration, I have seen where the method calls taking > precedence from out of Scene are handling ViaLogin; but they are also doing > some of the same lifting performed in the Land Management module. This > seems to be duplication of effort, if not duplication of code; and is > certainly less elegant than I would hope to find in our codebase (in an > ideal world ;) > > This is likely the result of the ad-hoc nature of the development life of > the project over the years; I can see the scene code being a good deal > older than the Land Management module. > > I'll be working with this throughout the day, hoping to improve the code > as I'm able; your thoughts, advice and commentary are solicited and > appreciated. > > Cheers > James > > > > On Thu, Apr 10, 2014 at 9:01 AM, James Stallings II < > james.stallings at gmail.com> wrote: > >> Greetings Devs :) >> >> I have a use case that requires the unlikely and less than popular parcel >> permissions access control featureset. >> >> Historically speaking, this has not been an area of development that has >> seen much love, and understandably so; none of us are particularly >> interested in fully duplicating the operational envelope of the Second Life >> experience. That coupled with the ability to deploy regions at whim, it is >> no wonder no one wants to involve themselves particularly deeply with >> making this work properly. >> >> That being said, I have a need at present, and there is also the simple >> fact that we have a dearth of UI components in the viewer we may well never >> get shut of, and a lot of of unfinished and/or unpolished code in the repo >> that touches on this functionality. >> >> The short story is, it may be above the waterline, but there is a hole in >> the boat, and one of my users is driving it headlong into the surf. >> >> So much for metaphors. >> >> I have heard a variety of conflicting reports about the state of this >> part of the codebase; some say it works well; others say it should not be >> counted on to work at all. The commit logs tell the tale that some have >> taken an interest and are working diligently to eliminate certain bugs; >> unfortunately, the work in progress has not yet brought the functionality >> into a state where it is yet useful, at least according to my testing. >> >> I'm not unwilling to undertake the work needed to bring this situation >> into a more satisfactory light; indeed, I've already begun, and I need only >> a little guidance today. >> >> I have thoroughly instrumented the method "public void >> EventManagerOnAvatarEnteringNewParcel(ScenePresence avatar, int >> localLandID, UUID regionID)" >> in the land management module, and was immediately confronted with a >> couple of surprises: >> First, when the code is called at all, it is called twice; and as far as >> I can tell, it is called only after a successful login has been completed. >> Neither does it seem to be called when an avatar teleports into the region. >> >> Instead, the method "public bool TestLandRestrictions(UUID agentID, out >> string reason, ref float posX, ref float posY)" is called from >> "OpenSim/Region/Framework/Scenes/Scene.cs" and >> "OpenSim/Region/Framework/Scenes/ScenePresence.cs", and mediates (rather >> less than consistently) whether the avatar is allowed into the parcel on >> the region. >> >> Being aware that there are several ways for an avatar to enter a parcel, >> which I will leave off enumerating at present, I would suggest that perhaps >> I have some misapprehensions as to the proper stages of authentication at >> login-time. >> >> So my question is this: should both of these functions come into play as >> an avatar enters a region (and consequently, a parcel)? or should there be >> a single methoid conducting these presence permission checks? >> >> Please advise at your convenience :) >> >> Many thanks and cheers >> James/Hiro >> >> >> -- >> =================================== >> http://osgrid.org/ >> http://simhost.com >> http://twitter.com/jstallings2 >> >> > > > -- > =================================== > http://osgrid.org/ > http://simhost.com > http://twitter.com/jstallings2 > > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From melanie at t-data.com Thu Apr 10 15:10:54 2014 From: melanie at t-data.com (Melanie) Date: Thu, 10 Apr 2014 17:10:54 +0200 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: References: Message-ID: <5346B47E.2000204@t-data.com> The code for parcel access works, as far as I'm aware. It was originally fixed in Avination and that should have been donated to OpenSim a long time ago. Maybe a good starting point is to see what you would like that doesnt' work before you go and fix things that aren't broken. Melanie On 10/04/2014 17:05, James Stallings II wrote: > Subsequent work (instrumentation to Scene) shows that the permissions > checking code is also being called twice there. > > Cheers > James > > > > On Thu, Apr 10, 2014 at 9:30 AM, James Stallings II < > james.stallings at gmail.com> wrote: > >> After some further exploration, I have seen where the method calls taking >> precedence from out of Scene are handling ViaLogin; but they are also doing >> some of the same lifting performed in the Land Management module. This >> seems to be duplication of effort, if not duplication of code; and is >> certainly less elegant than I would hope to find in our codebase (in an >> ideal world ;) >> >> This is likely the result of the ad-hoc nature of the development life of >> the project over the years; I can see the scene code being a good deal >> older than the Land Management module. >> >> I'll be working with this throughout the day, hoping to improve the code >> as I'm able; your thoughts, advice and commentary are solicited and >> appreciated. >> >> Cheers >> James >> >> >> >> On Thu, Apr 10, 2014 at 9:01 AM, James Stallings II < >> james.stallings at gmail.com> wrote: >> >>> Greetings Devs :) >>> >>> I have a use case that requires the unlikely and less than popular parcel >>> permissions access control featureset. >>> >>> Historically speaking, this has not been an area of development that has >>> seen much love, and understandably so; none of us are particularly >>> interested in fully duplicating the operational envelope of the Second Life >>> experience. That coupled with the ability to deploy regions at whim, it is >>> no wonder no one wants to involve themselves particularly deeply with >>> making this work properly. >>> >>> That being said, I have a need at present, and there is also the simple >>> fact that we have a dearth of UI components in the viewer we may well never >>> get shut of, and a lot of of unfinished and/or unpolished code in the repo >>> that touches on this functionality. >>> >>> The short story is, it may be above the waterline, but there is a hole in >>> the boat, and one of my users is driving it headlong into the surf. >>> >>> So much for metaphors. >>> >>> I have heard a variety of conflicting reports about the state of this >>> part of the codebase; some say it works well; others say it should not be >>> counted on to work at all. The commit logs tell the tale that some have >>> taken an interest and are working diligently to eliminate certain bugs; >>> unfortunately, the work in progress has not yet brought the functionality >>> into a state where it is yet useful, at least according to my testing. >>> >>> I'm not unwilling to undertake the work needed to bring this situation >>> into a more satisfactory light; indeed, I've already begun, and I need only >>> a little guidance today. >>> >>> I have thoroughly instrumented the method "public void >>> EventManagerOnAvatarEnteringNewParcel(ScenePresence avatar, int >>> localLandID, UUID regionID)" >>> in the land management module, and was immediately confronted with a >>> couple of surprises: >>> First, when the code is called at all, it is called twice; and as far as >>> I can tell, it is called only after a successful login has been completed. >>> Neither does it seem to be called when an avatar teleports into the region. >>> >>> Instead, the method "public bool TestLandRestrictions(UUID agentID, out >>> string reason, ref float posX, ref float posY)" is called from >>> "OpenSim/Region/Framework/Scenes/Scene.cs" and >>> "OpenSim/Region/Framework/Scenes/ScenePresence.cs", and mediates (rather >>> less than consistently) whether the avatar is allowed into the parcel on >>> the region. >>> >>> Being aware that there are several ways for an avatar to enter a parcel, >>> which I will leave off enumerating at present, I would suggest that perhaps >>> I have some misapprehensions as to the proper stages of authentication at >>> login-time. >>> >>> So my question is this: should both of these functions come into play as >>> an avatar enters a region (and consequently, a parcel)? or should there be >>> a single methoid conducting these presence permission checks? >>> >>> Please advise at your convenience :) >>> >>> Many thanks and cheers >>> James/Hiro >>> >>> >>> -- >>> =================================== >>> http://osgrid.org/ >>> http://simhost.com >>> http://twitter.com/jstallings2 >>> >>> >> >> >> -- >> =================================== >> http://osgrid.org/ >> http://simhost.com >> http://twitter.com/jstallings2 >> >> > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev From james.stallings at gmail.com Thu Apr 10 15:20:44 2014 From: james.stallings at gmail.com (James Stallings II) Date: Thu, 10 Apr 2014 10:20:44 -0500 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: <5346B47E.2000204@t-data.com> References: <5346B47E.2000204@t-data.com> Message-ID: "Maybe a good starting point is to see what you would like that doesnt' work before you go and fix things that..." Actually, that *is* where I began. My user reports various failures, which are repeatable on the running regions. No amount of reconfiguration predictably affects the experience on the regions. We do have a couple of regions that seem to work perfectly, including that which I'm working with; it started working after I completely replaced the OpenSim.ini with one that was identical excepting the http_listener specifcation. Unfortunately, repeating this process with the same OpenSim.ini on a different region that doesn't work did not produce a region that does. To say that it works intermittently is a bit of an understatement; though it does seem that once it begins working it continues to do so. Try not to be so defensive Mel; I'm not attacking you or your work, I'm just attempting to figure out what's happening on these regions. I have eliminated everything I can find but the code, which I am told by others is not to be trusted as fully functional; and I am not afraid to get in and get my hands dirty. Cheers James On Thu, Apr 10, 2014 at 10:10 AM, Melanie wrote: > The code for parcel access works, as far as I'm aware. It was > originally fixed in Avination and that should have been donated to > OpenSim a long time ago. Maybe a good starting point is to see what > you would like that doesnt' work before you go and fix things that > aren't broken. > > Melanie > > > On 10/04/2014 17:05, James Stallings II wrote: > > Subsequent work (instrumentation to Scene) shows that the permissions > > checking code is also being called twice there. > > > > Cheers > > James > > > > > > > > On Thu, Apr 10, 2014 at 9:30 AM, James Stallings II < > > james.stallings at gmail.com> wrote: > > > >> After some further exploration, I have seen where the method calls > taking > >> precedence from out of Scene are handling ViaLogin; but they are also > doing > >> some of the same lifting performed in the Land Management module. This > >> seems to be duplication of effort, if not duplication of code; and is > >> certainly less elegant than I would hope to find in our codebase (in an > >> ideal world ;) > >> > >> This is likely the result of the ad-hoc nature of the development life > of > >> the project over the years; I can see the scene code being a good deal > >> older than the Land Management module. > >> > >> I'll be working with this throughout the day, hoping to improve the code > >> as I'm able; your thoughts, advice and commentary are solicited and > >> appreciated. > >> > >> Cheers > >> James > >> > >> > >> > >> On Thu, Apr 10, 2014 at 9:01 AM, James Stallings II < > >> james.stallings at gmail.com> wrote: > >> > >>> Greetings Devs :) > >>> > >>> I have a use case that requires the unlikely and less than popular > parcel > >>> permissions access control featureset. > >>> > >>> Historically speaking, this has not been an area of development that > has > >>> seen much love, and understandably so; none of us are particularly > >>> interested in fully duplicating the operational envelope of the Second > Life > >>> experience. That coupled with the ability to deploy regions at whim, > it is > >>> no wonder no one wants to involve themselves particularly deeply with > >>> making this work properly. > >>> > >>> That being said, I have a need at present, and there is also the simple > >>> fact that we have a dearth of UI components in the viewer we may well > never > >>> get shut of, and a lot of of unfinished and/or unpolished code in the > repo > >>> that touches on this functionality. > >>> > >>> The short story is, it may be above the waterline, but there is a hole > in > >>> the boat, and one of my users is driving it headlong into the surf. > >>> > >>> So much for metaphors. > >>> > >>> I have heard a variety of conflicting reports about the state of this > >>> part of the codebase; some say it works well; others say it should not > be > >>> counted on to work at all. The commit logs tell the tale that some have > >>> taken an interest and are working diligently to eliminate certain bugs; > >>> unfortunately, the work in progress has not yet brought the > functionality > >>> into a state where it is yet useful, at least according to my testing. > >>> > >>> I'm not unwilling to undertake the work needed to bring this situation > >>> into a more satisfactory light; indeed, I've already begun, and I need > only > >>> a little guidance today. > >>> > >>> I have thoroughly instrumented the method "public void > >>> EventManagerOnAvatarEnteringNewParcel(ScenePresence avatar, int > >>> localLandID, UUID regionID)" > >>> in the land management module, and was immediately confronted with a > >>> couple of surprises: > >>> First, when the code is called at all, it is called twice; and as far > as > >>> I can tell, it is called only after a successful login has been > completed. > >>> Neither does it seem to be called when an avatar teleports into the > region. > >>> > >>> Instead, the method "public bool TestLandRestrictions(UUID agentID, out > >>> string reason, ref float posX, ref float posY)" is called from > >>> "OpenSim/Region/Framework/Scenes/Scene.cs" and > >>> "OpenSim/Region/Framework/Scenes/ScenePresence.cs", and mediates > (rather > >>> less than consistently) whether the avatar is allowed into the parcel > on > >>> the region. > >>> > >>> Being aware that there are several ways for an avatar to enter a > parcel, > >>> which I will leave off enumerating at present, I would suggest that > perhaps > >>> I have some misapprehensions as to the proper stages of authentication > at > >>> login-time. > >>> > >>> So my question is this: should both of these functions come into play > as > >>> an avatar enters a region (and consequently, a parcel)? or should > there be > >>> a single methoid conducting these presence permission checks? > >>> > >>> Please advise at your convenience :) > >>> > >>> Many thanks and cheers > >>> James/Hiro > >>> > >>> > >>> -- > >>> =================================== > >>> http://osgrid.org/ > >>> http://simhost.com > >>> http://twitter.com/jstallings2 > >>> > >>> > >> > >> > >> -- > >> =================================== > >> http://osgrid.org/ > >> http://simhost.com > >> http://twitter.com/jstallings2 > >> > >> > > > > > > > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From melanie at t-data.com Thu Apr 10 15:23:18 2014 From: melanie at t-data.com (Melanie) Date: Thu, 10 Apr 2014 17:23:18 +0200 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: References: <5346B47E.2000204@t-data.com> Message-ID: <5346B766.1050005@t-data.com> I'm not even being defensive. I just don't like the idea of poking code with a sharp stick instead of debugging it properly. - Melanie On 10/04/2014 17:20, James Stallings II wrote: > "Maybe a good starting point is to see what you would like that doesnt' > work before you go and fix things that..." > > Actually, that *is* where I began. > > My user reports various failures, which are repeatable on the running > regions. No amount of reconfiguration predictably affects the experience on > the regions. > > We do have a couple of regions that seem to work perfectly, including that > which I'm working with; it started working after I completely replaced the > OpenSim.ini with one that was identical excepting the http_listener > specifcation. Unfortunately, repeating this process with the same > OpenSim.ini on a different region that doesn't work did not produce a > region that does. > > To say that it works intermittently is a bit of an understatement; though > it does seem that once it begins working it continues to do so. > > > Try not to be so defensive Mel; I'm not attacking you or your work, I'm > just attempting to figure out what's happening on these regions. I have > eliminated everything I can find but the code, which I am told by others is > not to be trusted as fully functional; and I am not afraid to get in and > get my hands dirty. > > > Cheers > James > > > > On Thu, Apr 10, 2014 at 10:10 AM, Melanie wrote: > >> The code for parcel access works, as far as I'm aware. It was >> originally fixed in Avination and that should have been donated to >> OpenSim a long time ago. Maybe a good starting point is to see what >> you would like that doesnt' work before you go and fix things that >> aren't broken. >> >> Melanie >> >> >> On 10/04/2014 17:05, James Stallings II wrote: >> > Subsequent work (instrumentation to Scene) shows that the permissions >> > checking code is also being called twice there. >> > >> > Cheers >> > James >> > >> > >> > >> > On Thu, Apr 10, 2014 at 9:30 AM, James Stallings II < >> > james.stallings at gmail.com> wrote: >> > >> >> After some further exploration, I have seen where the method calls >> taking >> >> precedence from out of Scene are handling ViaLogin; but they are also >> doing >> >> some of the same lifting performed in the Land Management module. This >> >> seems to be duplication of effort, if not duplication of code; and is >> >> certainly less elegant than I would hope to find in our codebase (in an >> >> ideal world ;) >> >> >> >> This is likely the result of the ad-hoc nature of the development life >> of >> >> the project over the years; I can see the scene code being a good deal >> >> older than the Land Management module. >> >> >> >> I'll be working with this throughout the day, hoping to improve the code >> >> as I'm able; your thoughts, advice and commentary are solicited and >> >> appreciated. >> >> >> >> Cheers >> >> James >> >> >> >> >> >> >> >> On Thu, Apr 10, 2014 at 9:01 AM, James Stallings II < >> >> james.stallings at gmail.com> wrote: >> >> >> >>> Greetings Devs :) >> >>> >> >>> I have a use case that requires the unlikely and less than popular >> parcel >> >>> permissions access control featureset. >> >>> >> >>> Historically speaking, this has not been an area of development that >> has >> >>> seen much love, and understandably so; none of us are particularly >> >>> interested in fully duplicating the operational envelope of the Second >> Life >> >>> experience. That coupled with the ability to deploy regions at whim, >> it is >> >>> no wonder no one wants to involve themselves particularly deeply with >> >>> making this work properly. >> >>> >> >>> That being said, I have a need at present, and there is also the simple >> >>> fact that we have a dearth of UI components in the viewer we may well >> never >> >>> get shut of, and a lot of of unfinished and/or unpolished code in the >> repo >> >>> that touches on this functionality. >> >>> >> >>> The short story is, it may be above the waterline, but there is a hole >> in >> >>> the boat, and one of my users is driving it headlong into the surf. >> >>> >> >>> So much for metaphors. >> >>> >> >>> I have heard a variety of conflicting reports about the state of this >> >>> part of the codebase; some say it works well; others say it should not >> be >> >>> counted on to work at all. The commit logs tell the tale that some have >> >>> taken an interest and are working diligently to eliminate certain bugs; >> >>> unfortunately, the work in progress has not yet brought the >> functionality >> >>> into a state where it is yet useful, at least according to my testing. >> >>> >> >>> I'm not unwilling to undertake the work needed to bring this situation >> >>> into a more satisfactory light; indeed, I've already begun, and I need >> only >> >>> a little guidance today. >> >>> >> >>> I have thoroughly instrumented the method "public void >> >>> EventManagerOnAvatarEnteringNewParcel(ScenePresence avatar, int >> >>> localLandID, UUID regionID)" >> >>> in the land management module, and was immediately confronted with a >> >>> couple of surprises: >> >>> First, when the code is called at all, it is called twice; and as far >> as >> >>> I can tell, it is called only after a successful login has been >> completed. >> >>> Neither does it seem to be called when an avatar teleports into the >> region. >> >>> >> >>> Instead, the method "public bool TestLandRestrictions(UUID agentID, out >> >>> string reason, ref float posX, ref float posY)" is called from >> >>> "OpenSim/Region/Framework/Scenes/Scene.cs" and >> >>> "OpenSim/Region/Framework/Scenes/ScenePresence.cs", and mediates >> (rather >> >>> less than consistently) whether the avatar is allowed into the parcel >> on >> >>> the region. >> >>> >> >>> Being aware that there are several ways for an avatar to enter a >> parcel, >> >>> which I will leave off enumerating at present, I would suggest that >> perhaps >> >>> I have some misapprehensions as to the proper stages of authentication >> at >> >>> login-time. >> >>> >> >>> So my question is this: should both of these functions come into play >> as >> >>> an avatar enters a region (and consequently, a parcel)? or should >> there be >> >>> a single methoid conducting these presence permission checks? >> >>> >> >>> Please advise at your convenience :) >> >>> >> >>> Many thanks and cheers >> >>> James/Hiro >> >>> >> >>> >> >>> -- >> >>> =================================== >> >>> http://osgrid.org/ >> >>> http://simhost.com >> >>> http://twitter.com/jstallings2 >> >>> >> >>> >> >> >> >> >> >> -- >> >> =================================== >> >> http://osgrid.org/ >> >> http://simhost.com >> >> http://twitter.com/jstallings2 >> >> >> >> >> > >> > >> > >> > >> > _______________________________________________ >> > Opensim-dev mailing list >> > Opensim-dev at lists.berlios.de >> > https://lists.berlios.de/mailman/listinfo/opensim-dev >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev From james.stallings at gmail.com Thu Apr 10 15:25:17 2014 From: james.stallings at gmail.com (James Stallings II) Date: Thu, 10 Apr 2014 10:25:17 -0500 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: <5346B766.1050005@t-data.com> References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> Message-ID: The only code I'm affecting the local copy on my server; it isn't as if I'm going to break break the central repo back to 2006. Hell, I don't even have commit. And FWIW, last I hear adding log statements to code is a valid tried and true debugging method. On Thu, Apr 10, 2014 at 10:23 AM, Melanie wrote: > I'm not even being defensive. I just don't like the idea of poking > code with a sharp stick instead of debugging it properly. > > - Melanie > > On 10/04/2014 17:20, James Stallings II wrote: > > "Maybe a good starting point is to see what you would like that doesnt' > > work before you go and fix things that..." > > > > Actually, that *is* where I began. > > > > My user reports various failures, which are repeatable on the running > > regions. No amount of reconfiguration predictably affects the experience > on > > the regions. > > > > We do have a couple of regions that seem to work perfectly, including > that > > which I'm working with; it started working after I completely replaced > the > > OpenSim.ini with one that was identical excepting the http_listener > > specifcation. Unfortunately, repeating this process with the same > > OpenSim.ini on a different region that doesn't work did not produce a > > region that does. > > > > To say that it works intermittently is a bit of an understatement; though > > it does seem that once it begins working it continues to do so. > > > > > > Try not to be so defensive Mel; I'm not attacking you or your work, I'm > > just attempting to figure out what's happening on these regions. I have > > eliminated everything I can find but the code, which I am told by others > is > > not to be trusted as fully functional; and I am not afraid to get in and > > get my hands dirty. > > > > > > Cheers > > James > > > > > > > > On Thu, Apr 10, 2014 at 10:10 AM, Melanie wrote: > > > >> The code for parcel access works, as far as I'm aware. It was > >> originally fixed in Avination and that should have been donated to > >> OpenSim a long time ago. Maybe a good starting point is to see what > >> you would like that doesnt' work before you go and fix things that > >> aren't broken. > >> > >> Melanie > >> > >> > >> On 10/04/2014 17:05, James Stallings II wrote: > >> > Subsequent work (instrumentation to Scene) shows that the permissions > >> > checking code is also being called twice there. > >> > > >> > Cheers > >> > James > >> > > >> > > >> > > >> > On Thu, Apr 10, 2014 at 9:30 AM, James Stallings II < > >> > james.stallings at gmail.com> wrote: > >> > > >> >> After some further exploration, I have seen where the method calls > >> taking > >> >> precedence from out of Scene are handling ViaLogin; but they are also > >> doing > >> >> some of the same lifting performed in the Land Management module. > This > >> >> seems to be duplication of effort, if not duplication of code; and is > >> >> certainly less elegant than I would hope to find in our codebase (in > an > >> >> ideal world ;) > >> >> > >> >> This is likely the result of the ad-hoc nature of the development > life > >> of > >> >> the project over the years; I can see the scene code being a good > deal > >> >> older than the Land Management module. > >> >> > >> >> I'll be working with this throughout the day, hoping to improve the > code > >> >> as I'm able; your thoughts, advice and commentary are solicited and > >> >> appreciated. > >> >> > >> >> Cheers > >> >> James > >> >> > >> >> > >> >> > >> >> On Thu, Apr 10, 2014 at 9:01 AM, James Stallings II < > >> >> james.stallings at gmail.com> wrote: > >> >> > >> >>> Greetings Devs :) > >> >>> > >> >>> I have a use case that requires the unlikely and less than popular > >> parcel > >> >>> permissions access control featureset. > >> >>> > >> >>> Historically speaking, this has not been an area of development that > >> has > >> >>> seen much love, and understandably so; none of us are particularly > >> >>> interested in fully duplicating the operational envelope of the > Second > >> Life > >> >>> experience. That coupled with the ability to deploy regions at whim, > >> it is > >> >>> no wonder no one wants to involve themselves particularly deeply > with > >> >>> making this work properly. > >> >>> > >> >>> That being said, I have a need at present, and there is also the > simple > >> >>> fact that we have a dearth of UI components in the viewer we may > well > >> never > >> >>> get shut of, and a lot of of unfinished and/or unpolished code in > the > >> repo > >> >>> that touches on this functionality. > >> >>> > >> >>> The short story is, it may be above the waterline, but there is a > hole > >> in > >> >>> the boat, and one of my users is driving it headlong into the surf. > >> >>> > >> >>> So much for metaphors. > >> >>> > >> >>> I have heard a variety of conflicting reports about the state of > this > >> >>> part of the codebase; some say it works well; others say it should > not > >> be > >> >>> counted on to work at all. The commit logs tell the tale that some > have > >> >>> taken an interest and are working diligently to eliminate certain > bugs; > >> >>> unfortunately, the work in progress has not yet brought the > >> functionality > >> >>> into a state where it is yet useful, at least according to my > testing. > >> >>> > >> >>> I'm not unwilling to undertake the work needed to bring this > situation > >> >>> into a more satisfactory light; indeed, I've already begun, and I > need > >> only > >> >>> a little guidance today. > >> >>> > >> >>> I have thoroughly instrumented the method "public void > >> >>> EventManagerOnAvatarEnteringNewParcel(ScenePresence avatar, int > >> >>> localLandID, UUID regionID)" > >> >>> in the land management module, and was immediately confronted with a > >> >>> couple of surprises: > >> >>> First, when the code is called at all, it is called twice; and as > far > >> as > >> >>> I can tell, it is called only after a successful login has been > >> completed. > >> >>> Neither does it seem to be called when an avatar teleports into the > >> region. > >> >>> > >> >>> Instead, the method "public bool TestLandRestrictions(UUID agentID, > out > >> >>> string reason, ref float posX, ref float posY)" is called from > >> >>> "OpenSim/Region/Framework/Scenes/Scene.cs" and > >> >>> "OpenSim/Region/Framework/Scenes/ScenePresence.cs", and mediates > >> (rather > >> >>> less than consistently) whether the avatar is allowed into the > parcel > >> on > >> >>> the region. > >> >>> > >> >>> Being aware that there are several ways for an avatar to enter a > >> parcel, > >> >>> which I will leave off enumerating at present, I would suggest that > >> perhaps > >> >>> I have some misapprehensions as to the proper stages of > authentication > >> at > >> >>> login-time. > >> >>> > >> >>> So my question is this: should both of these functions come into > play > >> as > >> >>> an avatar enters a region (and consequently, a parcel)? or should > >> there be > >> >>> a single methoid conducting these presence permission checks? > >> >>> > >> >>> Please advise at your convenience :) > >> >>> > >> >>> Many thanks and cheers > >> >>> James/Hiro > >> >>> > >> >>> > >> >>> -- > >> >>> =================================== > >> >>> http://osgrid.org/ > >> >>> http://simhost.com > >> >>> http://twitter.com/jstallings2 > >> >>> > >> >>> > >> >> > >> >> > >> >> -- > >> >> =================================== > >> >> http://osgrid.org/ > >> >> http://simhost.com > >> >> http://twitter.com/jstallings2 > >> >> > >> >> > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > Opensim-dev mailing list > >> > Opensim-dev at lists.berlios.de > >> > https://lists.berlios.de/mailman/listinfo/opensim-dev > >> _______________________________________________ > >> Opensim-dev mailing list > >> Opensim-dev at lists.berlios.de > >> https://lists.berlios.de/mailman/listinfo/opensim-dev > >> > > > > > > > > > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From melanie at t-data.com Thu Apr 10 15:49:33 2014 From: melanie at t-data.com (Melanie) Date: Thu, 10 Apr 2014 17:49:33 +0200 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> Message-ID: <5346BD8D.3050804@t-data.com> Indeed it is :) - Melanie On 10/04/2014 17:25, James Stallings II wrote: > The only code I'm affecting the local copy on my server; it isn't as if I'm > going to break break the central repo back to 2006. Hell, I don't even have > commit. And FWIW, last I hear adding log statements to code is a valid > tried and true debugging method. > > > > > > > On Thu, Apr 10, 2014 at 10:23 AM, Melanie wrote: > >> I'm not even being defensive. I just don't like the idea of poking >> code with a sharp stick instead of debugging it properly. >> >> - Melanie >> >> On 10/04/2014 17:20, James Stallings II wrote: >> > "Maybe a good starting point is to see what you would like that doesnt' >> > work before you go and fix things that..." >> > >> > Actually, that *is* where I began. >> > >> > My user reports various failures, which are repeatable on the running >> > regions. No amount of reconfiguration predictably affects the experience >> on >> > the regions. >> > >> > We do have a couple of regions that seem to work perfectly, including >> that >> > which I'm working with; it started working after I completely replaced >> the >> > OpenSim.ini with one that was identical excepting the http_listener >> > specifcation. Unfortunately, repeating this process with the same >> > OpenSim.ini on a different region that doesn't work did not produce a >> > region that does. >> > >> > To say that it works intermittently is a bit of an understatement; though >> > it does seem that once it begins working it continues to do so. >> > >> > >> > Try not to be so defensive Mel; I'm not attacking you or your work, I'm >> > just attempting to figure out what's happening on these regions. I have >> > eliminated everything I can find but the code, which I am told by others >> is >> > not to be trusted as fully functional; and I am not afraid to get in and >> > get my hands dirty. >> > >> > >> > Cheers >> > James >> > >> > >> > >> > On Thu, Apr 10, 2014 at 10:10 AM, Melanie wrote: >> > >> >> The code for parcel access works, as far as I'm aware. It was >> >> originally fixed in Avination and that should have been donated to >> >> OpenSim a long time ago. Maybe a good starting point is to see what >> >> you would like that doesnt' work before you go and fix things that >> >> aren't broken. >> >> >> >> Melanie >> >> >> >> >> >> On 10/04/2014 17:05, James Stallings II wrote: >> >> > Subsequent work (instrumentation to Scene) shows that the permissions >> >> > checking code is also being called twice there. >> >> > >> >> > Cheers >> >> > James >> >> > >> >> > >> >> > >> >> > On Thu, Apr 10, 2014 at 9:30 AM, James Stallings II < >> >> > james.stallings at gmail.com> wrote: >> >> > >> >> >> After some further exploration, I have seen where the method calls >> >> taking >> >> >> precedence from out of Scene are handling ViaLogin; but they are also >> >> doing >> >> >> some of the same lifting performed in the Land Management module. >> This >> >> >> seems to be duplication of effort, if not duplication of code; and is >> >> >> certainly less elegant than I would hope to find in our codebase (in >> an >> >> >> ideal world ;) >> >> >> >> >> >> This is likely the result of the ad-hoc nature of the development >> life >> >> of >> >> >> the project over the years; I can see the scene code being a good >> deal >> >> >> older than the Land Management module. >> >> >> >> >> >> I'll be working with this throughout the day, hoping to improve the >> code >> >> >> as I'm able; your thoughts, advice and commentary are solicited and >> >> >> appreciated. >> >> >> >> >> >> Cheers >> >> >> James >> >> >> >> >> >> >> >> >> >> >> >> On Thu, Apr 10, 2014 at 9:01 AM, James Stallings II < >> >> >> james.stallings at gmail.com> wrote: >> >> >> >> >> >>> Greetings Devs :) >> >> >>> >> >> >>> I have a use case that requires the unlikely and less than popular >> >> parcel >> >> >>> permissions access control featureset. >> >> >>> >> >> >>> Historically speaking, this has not been an area of development that >> >> has >> >> >>> seen much love, and understandably so; none of us are particularly >> >> >>> interested in fully duplicating the operational envelope of the >> Second >> >> Life >> >> >>> experience. That coupled with the ability to deploy regions at whim, >> >> it is >> >> >>> no wonder no one wants to involve themselves particularly deeply >> with >> >> >>> making this work properly. >> >> >>> >> >> >>> That being said, I have a need at present, and there is also the >> simple >> >> >>> fact that we have a dearth of UI components in the viewer we may >> well >> >> never >> >> >>> get shut of, and a lot of of unfinished and/or unpolished code in >> the >> >> repo >> >> >>> that touches on this functionality. >> >> >>> >> >> >>> The short story is, it may be above the waterline, but there is a >> hole >> >> in >> >> >>> the boat, and one of my users is driving it headlong into the surf. >> >> >>> >> >> >>> So much for metaphors. >> >> >>> >> >> >>> I have heard a variety of conflicting reports about the state of >> this >> >> >>> part of the codebase; some say it works well; others say it should >> not >> >> be >> >> >>> counted on to work at all. The commit logs tell the tale that some >> have >> >> >>> taken an interest and are working diligently to eliminate certain >> bugs; >> >> >>> unfortunately, the work in progress has not yet brought the >> >> functionality >> >> >>> into a state where it is yet useful, at least according to my >> testing. >> >> >>> >> >> >>> I'm not unwilling to undertake the work needed to bring this >> situation >> >> >>> into a more satisfactory light; indeed, I've already begun, and I >> need >> >> only >> >> >>> a little guidance today. >> >> >>> >> >> >>> I have thoroughly instrumented the method "public void >> >> >>> EventManagerOnAvatarEnteringNewParcel(ScenePresence avatar, int >> >> >>> localLandID, UUID regionID)" >> >> >>> in the land management module, and was immediately confronted with a >> >> >>> couple of surprises: >> >> >>> First, when the code is called at all, it is called twice; and as >> far >> >> as >> >> >>> I can tell, it is called only after a successful login has been >> >> completed. >> >> >>> Neither does it seem to be called when an avatar teleports into the >> >> region. >> >> >>> >> >> >>> Instead, the method "public bool TestLandRestrictions(UUID agentID, >> out >> >> >>> string reason, ref float posX, ref float posY)" is called from >> >> >>> "OpenSim/Region/Framework/Scenes/Scene.cs" and >> >> >>> "OpenSim/Region/Framework/Scenes/ScenePresence.cs", and mediates >> >> (rather >> >> >>> less than consistently) whether the avatar is allowed into the >> parcel >> >> on >> >> >>> the region. >> >> >>> >> >> >>> Being aware that there are several ways for an avatar to enter a >> >> parcel, >> >> >>> which I will leave off enumerating at present, I would suggest that >> >> perhaps >> >> >>> I have some misapprehensions as to the proper stages of >> authentication >> >> at >> >> >>> login-time. >> >> >>> >> >> >>> So my question is this: should both of these functions come into >> play >> >> as >> >> >>> an avatar enters a region (and consequently, a parcel)? or should >> >> there be >> >> >>> a single methoid conducting these presence permission checks? >> >> >>> >> >> >>> Please advise at your convenience :) >> >> >>> >> >> >>> Many thanks and cheers >> >> >>> James/Hiro >> >> >>> >> >> >>> >> >> >>> -- >> >> >>> =================================== >> >> >>> http://osgrid.org/ >> >> >>> http://simhost.com >> >> >>> http://twitter.com/jstallings2 >> >> >>> >> >> >>> >> >> >> >> >> >> >> >> >> -- >> >> >> =================================== >> >> >> http://osgrid.org/ >> >> >> http://simhost.com >> >> >> http://twitter.com/jstallings2 >> >> >> >> >> >> >> >> > >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > Opensim-dev mailing list >> >> > Opensim-dev at lists.berlios.de >> >> > https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> _______________________________________________ >> >> Opensim-dev mailing list >> >> Opensim-dev at lists.berlios.de >> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> >> > >> > >> > >> > >> > >> > _______________________________________________ >> > Opensim-dev mailing list >> > Opensim-dev at lists.berlios.de >> > https://lists.berlios.de/mailman/listinfo/opensim-dev >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev From james.stallings at gmail.com Thu Apr 10 15:52:09 2014 From: james.stallings at gmail.com (James Stallings II) Date: Thu, 10 Apr 2014 10:52:09 -0500 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> Message-ID: So, Melanie, I'll bite: What do you suggest for 'proper debugging' in this context? On Thu, Apr 10, 2014 at 10:25 AM, James Stallings II < james.stallings at gmail.com> wrote: > The only code I'm affecting the local copy on my server; it isn't as if > I'm going to break break the central repo back to 2006. Hell, I don't even > have commit. And FWIW, last I hear adding log statements to code is a valid > tried and true debugging method. > > > > > > > On Thu, Apr 10, 2014 at 10:23 AM, Melanie wrote: > >> I'm not even being defensive. I just don't like the idea of poking >> code with a sharp stick instead of debugging it properly. >> >> - Melanie >> >> On 10/04/2014 17:20, James Stallings II wrote: >> > "Maybe a good starting point is to see what you would like that doesnt' >> > work before you go and fix things that..." >> > >> > Actually, that *is* where I began. >> > >> > My user reports various failures, which are repeatable on the running >> > regions. No amount of reconfiguration predictably affects the >> experience on >> > the regions. >> > >> > We do have a couple of regions that seem to work perfectly, including >> that >> > which I'm working with; it started working after I completely replaced >> the >> > OpenSim.ini with one that was identical excepting the http_listener >> > specifcation. Unfortunately, repeating this process with the same >> > OpenSim.ini on a different region that doesn't work did not produce a >> > region that does. >> > >> > To say that it works intermittently is a bit of an understatement; >> though >> > it does seem that once it begins working it continues to do so. >> > >> > >> > Try not to be so defensive Mel; I'm not attacking you or your work, I'm >> > just attempting to figure out what's happening on these regions. I have >> > eliminated everything I can find but the code, which I am told by >> others is >> > not to be trusted as fully functional; and I am not afraid to get in and >> > get my hands dirty. >> > >> > >> > Cheers >> > James >> > >> > >> > >> > On Thu, Apr 10, 2014 at 10:10 AM, Melanie wrote: >> > >> >> The code for parcel access works, as far as I'm aware. It was >> >> originally fixed in Avination and that should have been donated to >> >> OpenSim a long time ago. Maybe a good starting point is to see what >> >> you would like that doesnt' work before you go and fix things that >> >> aren't broken. >> >> >> >> Melanie >> >> >> >> >> >> On 10/04/2014 17:05, James Stallings II wrote: >> >> > Subsequent work (instrumentation to Scene) shows that the permissions >> >> > checking code is also being called twice there. >> >> > >> >> > Cheers >> >> > James >> >> > >> >> > >> >> > >> >> > On Thu, Apr 10, 2014 at 9:30 AM, James Stallings II < >> >> > james.stallings at gmail.com> wrote: >> >> > >> >> >> After some further exploration, I have seen where the method calls >> >> taking >> >> >> precedence from out of Scene are handling ViaLogin; but they are >> also >> >> doing >> >> >> some of the same lifting performed in the Land Management module. >> This >> >> >> seems to be duplication of effort, if not duplication of code; and >> is >> >> >> certainly less elegant than I would hope to find in our codebase >> (in an >> >> >> ideal world ;) >> >> >> >> >> >> This is likely the result of the ad-hoc nature of the development >> life >> >> of >> >> >> the project over the years; I can see the scene code being a good >> deal >> >> >> older than the Land Management module. >> >> >> >> >> >> I'll be working with this throughout the day, hoping to improve the >> code >> >> >> as I'm able; your thoughts, advice and commentary are solicited and >> >> >> appreciated. >> >> >> >> >> >> Cheers >> >> >> James >> >> >> >> >> >> >> >> >> >> >> >> On Thu, Apr 10, 2014 at 9:01 AM, James Stallings II < >> >> >> james.stallings at gmail.com> wrote: >> >> >> >> >> >>> Greetings Devs :) >> >> >>> >> >> >>> I have a use case that requires the unlikely and less than popular >> >> parcel >> >> >>> permissions access control featureset. >> >> >>> >> >> >>> Historically speaking, this has not been an area of development >> that >> >> has >> >> >>> seen much love, and understandably so; none of us are particularly >> >> >>> interested in fully duplicating the operational envelope of the >> Second >> >> Life >> >> >>> experience. That coupled with the ability to deploy regions at >> whim, >> >> it is >> >> >>> no wonder no one wants to involve themselves particularly deeply >> with >> >> >>> making this work properly. >> >> >>> >> >> >>> That being said, I have a need at present, and there is also the >> simple >> >> >>> fact that we have a dearth of UI components in the viewer we may >> well >> >> never >> >> >>> get shut of, and a lot of of unfinished and/or unpolished code in >> the >> >> repo >> >> >>> that touches on this functionality. >> >> >>> >> >> >>> The short story is, it may be above the waterline, but there is a >> hole >> >> in >> >> >>> the boat, and one of my users is driving it headlong into the surf. >> >> >>> >> >> >>> So much for metaphors. >> >> >>> >> >> >>> I have heard a variety of conflicting reports about the state of >> this >> >> >>> part of the codebase; some say it works well; others say it should >> not >> >> be >> >> >>> counted on to work at all. The commit logs tell the tale that some >> have >> >> >>> taken an interest and are working diligently to eliminate certain >> bugs; >> >> >>> unfortunately, the work in progress has not yet brought the >> >> functionality >> >> >>> into a state where it is yet useful, at least according to my >> testing. >> >> >>> >> >> >>> I'm not unwilling to undertake the work needed to bring this >> situation >> >> >>> into a more satisfactory light; indeed, I've already begun, and I >> need >> >> only >> >> >>> a little guidance today. >> >> >>> >> >> >>> I have thoroughly instrumented the method "public void >> >> >>> EventManagerOnAvatarEnteringNewParcel(ScenePresence avatar, int >> >> >>> localLandID, UUID regionID)" >> >> >>> in the land management module, and was immediately confronted with >> a >> >> >>> couple of surprises: >> >> >>> First, when the code is called at all, it is called twice; and as >> far >> >> as >> >> >>> I can tell, it is called only after a successful login has been >> >> completed. >> >> >>> Neither does it seem to be called when an avatar teleports into the >> >> region. >> >> >>> >> >> >>> Instead, the method "public bool TestLandRestrictions(UUID >> agentID, out >> >> >>> string reason, ref float posX, ref float posY)" is called from >> >> >>> "OpenSim/Region/Framework/Scenes/Scene.cs" and >> >> >>> "OpenSim/Region/Framework/Scenes/ScenePresence.cs", and mediates >> >> (rather >> >> >>> less than consistently) whether the avatar is allowed into the >> parcel >> >> on >> >> >>> the region. >> >> >>> >> >> >>> Being aware that there are several ways for an avatar to enter a >> >> parcel, >> >> >>> which I will leave off enumerating at present, I would suggest that >> >> perhaps >> >> >>> I have some misapprehensions as to the proper stages of >> authentication >> >> at >> >> >>> login-time. >> >> >>> >> >> >>> So my question is this: should both of these functions come into >> play >> >> as >> >> >>> an avatar enters a region (and consequently, a parcel)? or should >> >> there be >> >> >>> a single methoid conducting these presence permission checks? >> >> >>> >> >> >>> Please advise at your convenience :) >> >> >>> >> >> >>> Many thanks and cheers >> >> >>> James/Hiro >> >> >>> >> >> >>> >> >> >>> -- >> >> >>> =================================== >> >> >>> http://osgrid.org/ >> >> >>> http://simhost.com >> >> >>> http://twitter.com/jstallings2 >> >> >>> >> >> >>> >> >> >> >> >> >> >> >> >> -- >> >> >> =================================== >> >> >> http://osgrid.org/ >> >> >> http://simhost.com >> >> >> http://twitter.com/jstallings2 >> >> >> >> >> >> >> >> > >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > Opensim-dev mailing list >> >> > Opensim-dev at lists.berlios.de >> >> > https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> _______________________________________________ >> >> Opensim-dev mailing list >> >> Opensim-dev at lists.berlios.de >> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> >> > >> > >> > >> > >> > >> > _______________________________________________ >> > Opensim-dev mailing list >> > Opensim-dev at lists.berlios.de >> > https://lists.berlios.de/mailman/listinfo/opensim-dev >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > -- > =================================== > http://osgrid.org/ > http://simhost.com > http://twitter.com/jstallings2 > > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From melanie at t-data.com Thu Apr 10 15:56:35 2014 From: melanie at t-data.com (Melanie) Date: Thu, 10 Apr 2014 17:56:35 +0200 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> Message-ID: <5346BF33.80203@t-data.com> No biting needed :) Debug output is a pretty good start and you did answer my concern when you mentioned the intermittent nature of the issue. I was worried that this would lead to a refactoring frenzy, possibly breaking even the parts that do work, but the fact that it's not consistently reproducible means that you're doing the proper debugging already. - Melanie On 10/04/2014 17:52, James Stallings II wrote: > So, Melanie, I'll bite: What do you suggest for 'proper debugging' in this > context? > > > On Thu, Apr 10, 2014 at 10:25 AM, James Stallings II < > james.stallings at gmail.com> wrote: > >> The only code I'm affecting the local copy on my server; it isn't as if >> I'm going to break break the central repo back to 2006. Hell, I don't even >> have commit. And FWIW, last I hear adding log statements to code is a valid >> tried and true debugging method. >> >> >> >> >> >> >> On Thu, Apr 10, 2014 at 10:23 AM, Melanie wrote: >> >>> I'm not even being defensive. I just don't like the idea of poking >>> code with a sharp stick instead of debugging it properly. >>> >>> - Melanie >>> >>> On 10/04/2014 17:20, James Stallings II wrote: >>> > "Maybe a good starting point is to see what you would like that doesnt' >>> > work before you go and fix things that..." >>> > >>> > Actually, that *is* where I began. >>> > >>> > My user reports various failures, which are repeatable on the running >>> > regions. No amount of reconfiguration predictably affects the >>> experience on >>> > the regions. >>> > >>> > We do have a couple of regions that seem to work perfectly, including >>> that >>> > which I'm working with; it started working after I completely replaced >>> the >>> > OpenSim.ini with one that was identical excepting the http_listener >>> > specifcation. Unfortunately, repeating this process with the same >>> > OpenSim.ini on a different region that doesn't work did not produce a >>> > region that does. >>> > >>> > To say that it works intermittently is a bit of an understatement; >>> though >>> > it does seem that once it begins working it continues to do so. >>> > >>> > >>> > Try not to be so defensive Mel; I'm not attacking you or your work, I'm >>> > just attempting to figure out what's happening on these regions. I have >>> > eliminated everything I can find but the code, which I am told by >>> others is >>> > not to be trusted as fully functional; and I am not afraid to get in and >>> > get my hands dirty. >>> > >>> > >>> > Cheers >>> > James >>> > >>> > >>> > >>> > On Thu, Apr 10, 2014 at 10:10 AM, Melanie wrote: >>> > >>> >> The code for parcel access works, as far as I'm aware. It was >>> >> originally fixed in Avination and that should have been donated to >>> >> OpenSim a long time ago. Maybe a good starting point is to see what >>> >> you would like that doesnt' work before you go and fix things that >>> >> aren't broken. >>> >> >>> >> Melanie >>> >> >>> >> >>> >> On 10/04/2014 17:05, James Stallings II wrote: >>> >> > Subsequent work (instrumentation to Scene) shows that the permissions >>> >> > checking code is also being called twice there. >>> >> > >>> >> > Cheers >>> >> > James >>> >> > >>> >> > >>> >> > >>> >> > On Thu, Apr 10, 2014 at 9:30 AM, James Stallings II < >>> >> > james.stallings at gmail.com> wrote: >>> >> > >>> >> >> After some further exploration, I have seen where the method calls >>> >> taking >>> >> >> precedence from out of Scene are handling ViaLogin; but they are >>> also >>> >> doing >>> >> >> some of the same lifting performed in the Land Management module. >>> This >>> >> >> seems to be duplication of effort, if not duplication of code; and >>> is >>> >> >> certainly less elegant than I would hope to find in our codebase >>> (in an >>> >> >> ideal world ;) >>> >> >> >>> >> >> This is likely the result of the ad-hoc nature of the development >>> life >>> >> of >>> >> >> the project over the years; I can see the scene code being a good >>> deal >>> >> >> older than the Land Management module. >>> >> >> >>> >> >> I'll be working with this throughout the day, hoping to improve the >>> code >>> >> >> as I'm able; your thoughts, advice and commentary are solicited and >>> >> >> appreciated. >>> >> >> >>> >> >> Cheers >>> >> >> James >>> >> >> >>> >> >> >>> >> >> >>> >> >> On Thu, Apr 10, 2014 at 9:01 AM, James Stallings II < >>> >> >> james.stallings at gmail.com> wrote: >>> >> >> >>> >> >>> Greetings Devs :) >>> >> >>> >>> >> >>> I have a use case that requires the unlikely and less than popular >>> >> parcel >>> >> >>> permissions access control featureset. >>> >> >>> >>> >> >>> Historically speaking, this has not been an area of development >>> that >>> >> has >>> >> >>> seen much love, and understandably so; none of us are particularly >>> >> >>> interested in fully duplicating the operational envelope of the >>> Second >>> >> Life >>> >> >>> experience. That coupled with the ability to deploy regions at >>> whim, >>> >> it is >>> >> >>> no wonder no one wants to involve themselves particularly deeply >>> with >>> >> >>> making this work properly. >>> >> >>> >>> >> >>> That being said, I have a need at present, and there is also the >>> simple >>> >> >>> fact that we have a dearth of UI components in the viewer we may >>> well >>> >> never >>> >> >>> get shut of, and a lot of of unfinished and/or unpolished code in >>> the >>> >> repo >>> >> >>> that touches on this functionality. >>> >> >>> >>> >> >>> The short story is, it may be above the waterline, but there is a >>> hole >>> >> in >>> >> >>> the boat, and one of my users is driving it headlong into the surf. >>> >> >>> >>> >> >>> So much for metaphors. >>> >> >>> >>> >> >>> I have heard a variety of conflicting reports about the state of >>> this >>> >> >>> part of the codebase; some say it works well; others say it should >>> not >>> >> be >>> >> >>> counted on to work at all. The commit logs tell the tale that some >>> have >>> >> >>> taken an interest and are working diligently to eliminate certain >>> bugs; >>> >> >>> unfortunately, the work in progress has not yet brought the >>> >> functionality >>> >> >>> into a state where it is yet useful, at least according to my >>> testing. >>> >> >>> >>> >> >>> I'm not unwilling to undertake the work needed to bring this >>> situation >>> >> >>> into a more satisfactory light; indeed, I've already begun, and I >>> need >>> >> only >>> >> >>> a little guidance today. >>> >> >>> >>> >> >>> I have thoroughly instrumented the method "public void >>> >> >>> EventManagerOnAvatarEnteringNewParcel(ScenePresence avatar, int >>> >> >>> localLandID, UUID regionID)" >>> >> >>> in the land management module, and was immediately confronted with >>> a >>> >> >>> couple of surprises: >>> >> >>> First, when the code is called at all, it is called twice; and as >>> far >>> >> as >>> >> >>> I can tell, it is called only after a successful login has been >>> >> completed. >>> >> >>> Neither does it seem to be called when an avatar teleports into the >>> >> region. >>> >> >>> >>> >> >>> Instead, the method "public bool TestLandRestrictions(UUID >>> agentID, out >>> >> >>> string reason, ref float posX, ref float posY)" is called from >>> >> >>> "OpenSim/Region/Framework/Scenes/Scene.cs" and >>> >> >>> "OpenSim/Region/Framework/Scenes/ScenePresence.cs", and mediates >>> >> (rather >>> >> >>> less than consistently) whether the avatar is allowed into the >>> parcel >>> >> on >>> >> >>> the region. >>> >> >>> >>> >> >>> Being aware that there are several ways for an avatar to enter a >>> >> parcel, >>> >> >>> which I will leave off enumerating at present, I would suggest that >>> >> perhaps >>> >> >>> I have some misapprehensions as to the proper stages of >>> authentication >>> >> at >>> >> >>> login-time. >>> >> >>> >>> >> >>> So my question is this: should both of these functions come into >>> play >>> >> as >>> >> >>> an avatar enters a region (and consequently, a parcel)? or should >>> >> there be >>> >> >>> a single methoid conducting these presence permission checks? >>> >> >>> >>> >> >>> Please advise at your convenience :) >>> >> >>> >>> >> >>> Many thanks and cheers >>> >> >>> James/Hiro >>> >> >>> >>> >> >>> >>> >> >>> -- >>> >> >>> =================================== >>> >> >>> http://osgrid.org/ >>> >> >>> http://simhost.com >>> >> >>> http://twitter.com/jstallings2 >>> >> >>> >>> >> >>> >>> >> >> >>> >> >> >>> >> >> -- >>> >> >> =================================== >>> >> >> http://osgrid.org/ >>> >> >> http://simhost.com >>> >> >> http://twitter.com/jstallings2 >>> >> >> >>> >> >> >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > _______________________________________________ >>> >> > Opensim-dev mailing list >>> >> > Opensim-dev at lists.berlios.de >>> >> > https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> _______________________________________________ >>> >> Opensim-dev mailing list >>> >> Opensim-dev at lists.berlios.de >>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >>> > >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > Opensim-dev mailing list >>> > Opensim-dev at lists.berlios.de >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >> >> >> -- >> =================================== >> http://osgrid.org/ >> http://simhost.com >> http://twitter.com/jstallings2 >> >> > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev From rknop at pobox.com Thu Apr 10 15:59:01 2014 From: rknop at pobox.com (Robert A. Knop Jr.) Date: Thu, 10 Apr 2014 08:59:01 -0700 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> Message-ID: <20140410155900.GA3167@schumann> On Thu, Apr 10, 2014 at 10:25:17AM -0500, James Stallings II wrote: > And FWIW, last I hear adding log statements to code is a valid > tried and true debugging method. I wish to subscribe all of my students in my programming class to your newsletter. (The number of times I told them to print stuff to figure out where the code was, and the number of times I told them to print in more places, was phenomenal. They got tired of hearing me say it, but somehow still needed to hear it.) (They often needed similar guidance in figuring out how to use breakpoints in debuggers.) -Rob -- --Rob Knop E-mail: rknop at pobox.com Home Page: http://www.pobox.com/~rknop/ Blog: http://www.galacticinteractions.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 828 bytes Desc: Digital signature URL: From james.stallings at gmail.com Thu Apr 10 16:07:27 2014 From: james.stallings at gmail.com (James Stallings II) Date: Thu, 10 Apr 2014 11:07:27 -0500 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: <5346BF33.80203@t-data.com> References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> <5346BF33.80203@t-data.com> Message-ID: Thanks, I appreciate that :) Don't worry about a refactoring effort. I'm very much aware that Scene and ScenePresence are complicated beyond my understanding (this is why I brought the matter to the list) and am not about to call for much of anything except expert advice. For now, my focus is on determining first why the two authentication methods are each called twice; and then (and only then! ;) will I try to make some determination as to whether it's right and proper that they should. One thing I had tried earlier (and this is more in line with poking things with sticks) is to comment out the calls to TestLandRestrictions in scene, to attempt letting the Land Management module to bear the full responsibility of authenticating the inbound avatar. This kind of worked; the avatar was allowed into the parcel, but was warned that he was banned and should leave immediately. No other enforcement of access took place. This is what brought me to the understanding of the ViaLogin subtlety, and so I returned those calls in scene to their proper places. It occurs to me that scene might be modified slightly to rely on the Land Management module for access permisison enforcement, but I already suspect that this would not be productive for reasons that I have not yet been able to fully articulate to myself. The hunt continues. I do appreciate what you do Melanie, and I do appreciate it when you help me. Cheers! James On Thu, Apr 10, 2014 at 10:56 AM, Melanie wrote: > No biting needed :) > > Debug output is a pretty good start and you did answer my concern > when you mentioned the intermittent nature of the issue. > I was worried that this would lead to a refactoring frenzy, possibly > breaking even the parts that do work, but the fact that it's not > consistently reproducible means that you're doing the proper > debugging already. > > - Melanie > > On 10/04/2014 17:52, James Stallings II wrote: > > So, Melanie, I'll bite: What do you suggest for 'proper debugging' in > this > > context? > > > > > > On Thu, Apr 10, 2014 at 10:25 AM, James Stallings II < > > james.stallings at gmail.com> wrote: > > > >> The only code I'm affecting the local copy on my server; it isn't as if > >> I'm going to break break the central repo back to 2006. Hell, I don't > even > >> have commit. And FWIW, last I hear adding log statements to code is a > valid > >> tried and true debugging method. > >> > >> > >> > >> > >> > >> > >> On Thu, Apr 10, 2014 at 10:23 AM, Melanie wrote: > >> > >>> I'm not even being defensive. I just don't like the idea of poking > >>> code with a sharp stick instead of debugging it properly. > >>> > >>> - Melanie > >>> > >>> On 10/04/2014 17:20, James Stallings II wrote: > >>> > "Maybe a good starting point is to see what you would like that > doesnt' > >>> > work before you go and fix things that..." > >>> > > >>> > Actually, that *is* where I began. > >>> > > >>> > My user reports various failures, which are repeatable on the running > >>> > regions. No amount of reconfiguration predictably affects the > >>> experience on > >>> > the regions. > >>> > > >>> > We do have a couple of regions that seem to work perfectly, including > >>> that > >>> > which I'm working with; it started working after I completely > replaced > >>> the > >>> > OpenSim.ini with one that was identical excepting the http_listener > >>> > specifcation. Unfortunately, repeating this process with the same > >>> > OpenSim.ini on a different region that doesn't work did not produce a > >>> > region that does. > >>> > > >>> > To say that it works intermittently is a bit of an understatement; > >>> though > >>> > it does seem that once it begins working it continues to do so. > >>> > > >>> > > >>> > Try not to be so defensive Mel; I'm not attacking you or your work, > I'm > >>> > just attempting to figure out what's happening on these regions. I > have > >>> > eliminated everything I can find but the code, which I am told by > >>> others is > >>> > not to be trusted as fully functional; and I am not afraid to get in > and > >>> > get my hands dirty. > >>> > > >>> > > >>> > Cheers > >>> > James > >>> > > >>> > > >>> > > >>> > On Thu, Apr 10, 2014 at 10:10 AM, Melanie > wrote: > >>> > > >>> >> The code for parcel access works, as far as I'm aware. It was > >>> >> originally fixed in Avination and that should have been donated to > >>> >> OpenSim a long time ago. Maybe a good starting point is to see what > >>> >> you would like that doesnt' work before you go and fix things that > >>> >> aren't broken. > >>> >> > >>> >> Melanie > >>> >> > >>> >> > >>> >> On 10/04/2014 17:05, James Stallings II wrote: > >>> >> > Subsequent work (instrumentation to Scene) shows that the > permissions > >>> >> > checking code is also being called twice there. > >>> >> > > >>> >> > Cheers > >>> >> > James > >>> >> > > >>> >> > > >>> >> > > >>> >> > On Thu, Apr 10, 2014 at 9:30 AM, James Stallings II < > >>> >> > james.stallings at gmail.com> wrote: > >>> >> > > >>> >> >> After some further exploration, I have seen where the method > calls > >>> >> taking > >>> >> >> precedence from out of Scene are handling ViaLogin; but they are > >>> also > >>> >> doing > >>> >> >> some of the same lifting performed in the Land Management module. > >>> This > >>> >> >> seems to be duplication of effort, if not duplication of code; > and > >>> is > >>> >> >> certainly less elegant than I would hope to find in our codebase > >>> (in an > >>> >> >> ideal world ;) > >>> >> >> > >>> >> >> This is likely the result of the ad-hoc nature of the development > >>> life > >>> >> of > >>> >> >> the project over the years; I can see the scene code being a good > >>> deal > >>> >> >> older than the Land Management module. > >>> >> >> > >>> >> >> I'll be working with this throughout the day, hoping to improve > the > >>> code > >>> >> >> as I'm able; your thoughts, advice and commentary are solicited > and > >>> >> >> appreciated. > >>> >> >> > >>> >> >> Cheers > >>> >> >> James > >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> On Thu, Apr 10, 2014 at 9:01 AM, James Stallings II < > >>> >> >> james.stallings at gmail.com> wrote: > >>> >> >> > >>> >> >>> Greetings Devs :) > >>> >> >>> > >>> >> >>> I have a use case that requires the unlikely and less than > popular > >>> >> parcel > >>> >> >>> permissions access control featureset. > >>> >> >>> > >>> >> >>> Historically speaking, this has not been an area of development > >>> that > >>> >> has > >>> >> >>> seen much love, and understandably so; none of us are > particularly > >>> >> >>> interested in fully duplicating the operational envelope of the > >>> Second > >>> >> Life > >>> >> >>> experience. That coupled with the ability to deploy regions at > >>> whim, > >>> >> it is > >>> >> >>> no wonder no one wants to involve themselves particularly deeply > >>> with > >>> >> >>> making this work properly. > >>> >> >>> > >>> >> >>> That being said, I have a need at present, and there is also the > >>> simple > >>> >> >>> fact that we have a dearth of UI components in the viewer we may > >>> well > >>> >> never > >>> >> >>> get shut of, and a lot of of unfinished and/or unpolished code > in > >>> the > >>> >> repo > >>> >> >>> that touches on this functionality. > >>> >> >>> > >>> >> >>> The short story is, it may be above the waterline, but there is > a > >>> hole > >>> >> in > >>> >> >>> the boat, and one of my users is driving it headlong into the > surf. > >>> >> >>> > >>> >> >>> So much for metaphors. > >>> >> >>> > >>> >> >>> I have heard a variety of conflicting reports about the state of > >>> this > >>> >> >>> part of the codebase; some say it works well; others say it > should > >>> not > >>> >> be > >>> >> >>> counted on to work at all. The commit logs tell the tale that > some > >>> have > >>> >> >>> taken an interest and are working diligently to eliminate > certain > >>> bugs; > >>> >> >>> unfortunately, the work in progress has not yet brought the > >>> >> functionality > >>> >> >>> into a state where it is yet useful, at least according to my > >>> testing. > >>> >> >>> > >>> >> >>> I'm not unwilling to undertake the work needed to bring this > >>> situation > >>> >> >>> into a more satisfactory light; indeed, I've already begun, and > I > >>> need > >>> >> only > >>> >> >>> a little guidance today. > >>> >> >>> > >>> >> >>> I have thoroughly instrumented the method "public void > >>> >> >>> EventManagerOnAvatarEnteringNewParcel(ScenePresence avatar, int > >>> >> >>> localLandID, UUID regionID)" > >>> >> >>> in the land management module, and was immediately confronted > with > >>> a > >>> >> >>> couple of surprises: > >>> >> >>> First, when the code is called at all, it is called twice; and > as > >>> far > >>> >> as > >>> >> >>> I can tell, it is called only after a successful login has been > >>> >> completed. > >>> >> >>> Neither does it seem to be called when an avatar teleports into > the > >>> >> region. > >>> >> >>> > >>> >> >>> Instead, the method "public bool TestLandRestrictions(UUID > >>> agentID, out > >>> >> >>> string reason, ref float posX, ref float posY)" is called from > >>> >> >>> "OpenSim/Region/Framework/Scenes/Scene.cs" and > >>> >> >>> "OpenSim/Region/Framework/Scenes/ScenePresence.cs", and mediates > >>> >> (rather > >>> >> >>> less than consistently) whether the avatar is allowed into the > >>> parcel > >>> >> on > >>> >> >>> the region. > >>> >> >>> > >>> >> >>> Being aware that there are several ways for an avatar to enter a > >>> >> parcel, > >>> >> >>> which I will leave off enumerating at present, I would suggest > that > >>> >> perhaps > >>> >> >>> I have some misapprehensions as to the proper stages of > >>> authentication > >>> >> at > >>> >> >>> login-time. > >>> >> >>> > >>> >> >>> So my question is this: should both of these functions come into > >>> play > >>> >> as > >>> >> >>> an avatar enters a region (and consequently, a parcel)? or > should > >>> >> there be > >>> >> >>> a single methoid conducting these presence permission checks? > >>> >> >>> > >>> >> >>> Please advise at your convenience :) > >>> >> >>> > >>> >> >>> Many thanks and cheers > >>> >> >>> James/Hiro > >>> >> >>> > >>> >> >>> > >>> >> >>> -- > >>> >> >>> =================================== > >>> >> >>> http://osgrid.org/ > >>> >> >>> http://simhost.com > >>> >> >>> http://twitter.com/jstallings2 > >>> >> >>> > >>> >> >>> > >>> >> >> > >>> >> >> > >>> >> >> -- > >>> >> >> =================================== > >>> >> >> http://osgrid.org/ > >>> >> >> http://simhost.com > >>> >> >> http://twitter.com/jstallings2 > >>> >> >> > >>> >> >> > >>> >> > > >>> >> > > >>> >> > > >>> >> > > >>> >> > _______________________________________________ > >>> >> > Opensim-dev mailing list > >>> >> > Opensim-dev at lists.berlios.de > >>> >> > https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> >> _______________________________________________ > >>> >> Opensim-dev mailing list > >>> >> Opensim-dev at lists.berlios.de > >>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> >> > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > _______________________________________________ > >>> > Opensim-dev mailing list > >>> > Opensim-dev at lists.berlios.de > >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> _______________________________________________ > >>> Opensim-dev mailing list > >>> Opensim-dev at lists.berlios.de > >>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> > >> > >> > >> > >> -- > >> =================================== > >> http://osgrid.org/ > >> http://simhost.com > >> http://twitter.com/jstallings2 > >> > >> > > > > > > > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.stallings at gmail.com Thu Apr 10 16:14:59 2014 From: james.stallings at gmail.com (James Stallings II) Date: Thu, 10 Apr 2014 11:14:59 -0500 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: <20140410155900.GA3167@schumann> References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> <20140410155900.GA3167@schumann> Message-ID: It would seem that the two invocations of the TestLandRestrictions method in Scene occur in each of NewUserConnection and QueryAccess. EventManagerOnAvatarEnteringNewParcel is, fairly obviously, and event callback method; at this point I don't have but a guess where this might be called excepting from within EventManagerOnSignificantClientMovement. I'd like to think that the two calls to TestLandRestrictions in Scene might be reduced to one; but I'm not yet convinced it is the way to go. More to follow. Cheers On Thu, Apr 10, 2014 at 10:59 AM, Robert A. Knop Jr. wrote: > On Thu, Apr 10, 2014 at 10:25:17AM -0500, James Stallings II wrote: > > And FWIW, last I hear adding log statements to code is a valid > > tried and true debugging method. > > I wish to subscribe all of my students in my programming class to your > newsletter. > > (The number of times I told them to print stuff to figure out where the > code was, and the number of times I told them to print in more places, > was phenomenal. They got tired of hearing me say it, but somehow still > needed to hear it.) > > (They often needed similar guidance in figuring out how to use > breakpoints in debuggers.) > > -Rob > > -- > --Rob Knop > E-mail: rknop at pobox.com > Home Page: http://www.pobox.com/~rknop/ > Blog: http://www.galacticinteractions.org/ > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.stallings at gmail.com Thu Apr 10 16:26:45 2014 From: james.stallings at gmail.com (James Stallings II) Date: Thu, 10 Apr 2014 11:26:45 -0500 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> <20140410155900.GA3167@schumann> Message-ID: One thing that may be happening is that our test is illuminating an edge case: there is only the default parcel on the region, and as a result, there is no 'nearest safe place/target' to which to move the banned avatar; that would involve a teleport off the region. On Thu, Apr 10, 2014 at 11:14 AM, James Stallings II < james.stallings at gmail.com> wrote: > It would seem that the two invocations of the TestLandRestrictions method > in Scene occur in each of NewUserConnection and > QueryAccess. EventManagerOnAvatarEnteringNewParcel is, fairly obviously, > and event callback method; at this point I don't have but a guess where > this might be called excepting from > within EventManagerOnSignificantClientMovement. > > I'd like to think that the two calls to TestLandRestrictions in Scene > might be reduced to one; but I'm not yet convinced it is the way to go. > > More to follow. > > Cheers > > > > On Thu, Apr 10, 2014 at 10:59 AM, Robert A. Knop Jr. wrote: > >> On Thu, Apr 10, 2014 at 10:25:17AM -0500, James Stallings II wrote: >> > And FWIW, last I hear adding log statements to code is a valid >> > tried and true debugging method. >> >> I wish to subscribe all of my students in my programming class to your >> newsletter. >> >> (The number of times I told them to print stuff to figure out where the >> code was, and the number of times I told them to print in more places, >> was phenomenal. They got tired of hearing me say it, but somehow still >> needed to hear it.) >> >> (They often needed similar guidance in figuring out how to use >> breakpoints in debuggers.) >> >> -Rob >> >> -- >> --Rob Knop >> E-mail: rknop at pobox.com >> Home Page: http://www.pobox.com/~rknop/ >> Blog: http://www.galacticinteractions.org/ >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > -- > =================================== > http://osgrid.org/ > http://simhost.com > http://twitter.com/jstallings2 > > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From melanie at t-data.com Thu Apr 10 16:29:32 2014 From: melanie at t-data.com (Melanie) Date: Thu, 10 Apr 2014 18:29:32 +0200 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> <20140410155900.GA3167@schumann> Message-ID: <5346C6EC.9080906@t-data.com> The QueryAccess is a pre-authorization. So the double call is intentional and unavoidable. - Melanie On 10/04/2014 18:14, James Stallings II wrote: > It would seem that the two invocations of the TestLandRestrictions method > in Scene occur in each of NewUserConnection and > QueryAccess. EventManagerOnAvatarEnteringNewParcel is, fairly obviously, > and event callback method; at this point I don't have but a guess where > this might be called excepting from > within EventManagerOnSignificantClientMovement. > > I'd like to think that the two calls to TestLandRestrictions in Scene might > be reduced to one; but I'm not yet convinced it is the way to go. > > More to follow. > > Cheers > > > > On Thu, Apr 10, 2014 at 10:59 AM, Robert A. Knop Jr. wrote: > >> On Thu, Apr 10, 2014 at 10:25:17AM -0500, James Stallings II wrote: >> > And FWIW, last I hear adding log statements to code is a valid >> > tried and true debugging method. >> >> I wish to subscribe all of my students in my programming class to your >> newsletter. >> >> (The number of times I told them to print stuff to figure out where the >> code was, and the number of times I told them to print in more places, >> was phenomenal. They got tired of hearing me say it, but somehow still >> needed to hear it.) >> >> (They often needed similar guidance in figuring out how to use >> breakpoints in debuggers.) >> >> -Rob >> >> -- >> --Rob Knop >> E-mail: rknop at pobox.com >> Home Page: http://www.pobox.com/~rknop/ >> Blog: http://www.galacticinteractions.org/ >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev From james.stallings at gmail.com Thu Apr 10 16:30:46 2014 From: james.stallings at gmail.com (James Stallings II) Date: Thu, 10 Apr 2014 11:30:46 -0500 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: <5346C6EC.9080906@t-data.com> References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> <20140410155900.GA3167@schumann> <5346C6EC.9080906@t-data.com> Message-ID: I kinder suspected something to that effect. It goes without saying that a lot occurs during the login process than is immediately apparent when one sits and watches the consoles. Right now I'm leaning towards the previously-mentioned edge case. On Thu, Apr 10, 2014 at 11:29 AM, Melanie wrote: > The QueryAccess is a pre-authorization. So the double call is > intentional and unavoidable. > > - Melanie > > On 10/04/2014 18:14, James Stallings II wrote: > > It would seem that the two invocations of the TestLandRestrictions method > > in Scene occur in each of NewUserConnection and > > QueryAccess. EventManagerOnAvatarEnteringNewParcel is, fairly obviously, > > and event callback method; at this point I don't have but a guess where > > this might be called excepting from > > within EventManagerOnSignificantClientMovement. > > > > I'd like to think that the two calls to TestLandRestrictions in Scene > might > > be reduced to one; but I'm not yet convinced it is the way to go. > > > > More to follow. > > > > Cheers > > > > > > > > On Thu, Apr 10, 2014 at 10:59 AM, Robert A. Knop Jr. >wrote: > > > >> On Thu, Apr 10, 2014 at 10:25:17AM -0500, James Stallings II wrote: > >> > And FWIW, last I hear adding log statements to code is a valid > >> > tried and true debugging method. > >> > >> I wish to subscribe all of my students in my programming class to your > >> newsletter. > >> > >> (The number of times I told them to print stuff to figure out where the > >> code was, and the number of times I told them to print in more places, > >> was phenomenal. They got tired of hearing me say it, but somehow still > >> needed to hear it.) > >> > >> (They often needed similar guidance in figuring out how to use > >> breakpoints in debuggers.) > >> > >> -Rob > >> > >> -- > >> --Rob Knop > >> E-mail: rknop at pobox.com > >> Home Page: http://www.pobox.com/~rknop/ > >> Blog: http://www.galacticinteractions.org/ > >> > >> _______________________________________________ > >> Opensim-dev mailing list > >> Opensim-dev at lists.berlios.de > >> https://lists.berlios.de/mailman/listinfo/opensim-dev > >> > > > > > > > > > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.stallings at gmail.com Thu Apr 10 16:33:40 2014 From: james.stallings at gmail.com (James Stallings II) Date: Thu, 10 Apr 2014 11:33:40 -0500 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> <20140410155900.GA3167@schumann> <5346C6EC.9080906@t-data.com> Message-ID: Quick question (related) is there a configuration point I'm missing that enables 'forceful bans'? On Thu, Apr 10, 2014 at 11:30 AM, James Stallings II < james.stallings at gmail.com> wrote: > I kinder suspected something to that effect. It goes without saying that a > lot occurs during the login process than is immediately apparent when one > sits and watches the consoles. > > Right now I'm leaning towards the previously-mentioned edge case. > > > On Thu, Apr 10, 2014 at 11:29 AM, Melanie wrote: > >> The QueryAccess is a pre-authorization. So the double call is >> intentional and unavoidable. >> >> - Melanie >> >> On 10/04/2014 18:14, James Stallings II wrote: >> > It would seem that the two invocations of the TestLandRestrictions >> method >> > in Scene occur in each of NewUserConnection and >> > QueryAccess. EventManagerOnAvatarEnteringNewParcel is, fairly obviously, >> > and event callback method; at this point I don't have but a guess where >> > this might be called excepting from >> > within EventManagerOnSignificantClientMovement. >> > >> > I'd like to think that the two calls to TestLandRestrictions in Scene >> might >> > be reduced to one; but I'm not yet convinced it is the way to go. >> > >> > More to follow. >> > >> > Cheers >> > >> > >> > >> > On Thu, Apr 10, 2014 at 10:59 AM, Robert A. Knop Jr. > >wrote: >> > >> >> On Thu, Apr 10, 2014 at 10:25:17AM -0500, James Stallings II wrote: >> >> > And FWIW, last I hear adding log statements to code is a valid >> >> > tried and true debugging method. >> >> >> >> I wish to subscribe all of my students in my programming class to your >> >> newsletter. >> >> >> >> (The number of times I told them to print stuff to figure out where the >> >> code was, and the number of times I told them to print in more places, >> >> was phenomenal. They got tired of hearing me say it, but somehow still >> >> needed to hear it.) >> >> >> >> (They often needed similar guidance in figuring out how to use >> >> breakpoints in debuggers.) >> >> >> >> -Rob >> >> >> >> -- >> >> --Rob Knop >> >> E-mail: rknop at pobox.com >> >> Home Page: http://www.pobox.com/~rknop/ >> >> Blog: http://www.galacticinteractions.org/ >> >> >> >> _______________________________________________ >> >> Opensim-dev mailing list >> >> Opensim-dev at lists.berlios.de >> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> >> > >> > >> > >> > >> > >> > _______________________________________________ >> > Opensim-dev mailing list >> > Opensim-dev at lists.berlios.de >> > https://lists.berlios.de/mailman/listinfo/opensim-dev >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > -- > =================================== > http://osgrid.org/ > http://simhost.com > http://twitter.com/jstallings2 > > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From melanie at t-data.com Thu Apr 10 16:37:01 2014 From: melanie at t-data.com (Melanie) Date: Thu, 10 Apr 2014 18:37:01 +0200 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> <20140410155900.GA3167@schumann> <5346C6EC.9080906@t-data.com> Message-ID: <5346C8AD.5000809@t-data.com> Yes. allow_forceful_banlines, I believe. Long time since I looked at it. - Melanie On 10/04/2014 18:33, James Stallings II wrote: > Quick question (related) is there a configuration point I'm missing that > enables 'forceful bans'? > > > > On Thu, Apr 10, 2014 at 11:30 AM, James Stallings II < > james.stallings at gmail.com> wrote: > >> I kinder suspected something to that effect. It goes without saying that a >> lot occurs during the login process than is immediately apparent when one >> sits and watches the consoles. >> >> Right now I'm leaning towards the previously-mentioned edge case. >> >> >> On Thu, Apr 10, 2014 at 11:29 AM, Melanie wrote: >> >>> The QueryAccess is a pre-authorization. So the double call is >>> intentional and unavoidable. >>> >>> - Melanie >>> >>> On 10/04/2014 18:14, James Stallings II wrote: >>> > It would seem that the two invocations of the TestLandRestrictions >>> method >>> > in Scene occur in each of NewUserConnection and >>> > QueryAccess. EventManagerOnAvatarEnteringNewParcel is, fairly obviously, >>> > and event callback method; at this point I don't have but a guess where >>> > this might be called excepting from >>> > within EventManagerOnSignificantClientMovement. >>> > >>> > I'd like to think that the two calls to TestLandRestrictions in Scene >>> might >>> > be reduced to one; but I'm not yet convinced it is the way to go. >>> > >>> > More to follow. >>> > >>> > Cheers >>> > >>> > >>> > >>> > On Thu, Apr 10, 2014 at 10:59 AM, Robert A. Knop Jr. >> >wrote: >>> > >>> >> On Thu, Apr 10, 2014 at 10:25:17AM -0500, James Stallings II wrote: >>> >> > And FWIW, last I hear adding log statements to code is a valid >>> >> > tried and true debugging method. >>> >> >>> >> I wish to subscribe all of my students in my programming class to your >>> >> newsletter. >>> >> >>> >> (The number of times I told them to print stuff to figure out where the >>> >> code was, and the number of times I told them to print in more places, >>> >> was phenomenal. They got tired of hearing me say it, but somehow still >>> >> needed to hear it.) >>> >> >>> >> (They often needed similar guidance in figuring out how to use >>> >> breakpoints in debuggers.) >>> >> >>> >> -Rob >>> >> >>> >> -- >>> >> --Rob Knop >>> >> E-mail: rknop at pobox.com >>> >> Home Page: http://www.pobox.com/~rknop/ >>> >> Blog: http://www.galacticinteractions.org/ >>> >> >>> >> _______________________________________________ >>> >> Opensim-dev mailing list >>> >> Opensim-dev at lists.berlios.de >>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >>> > >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > Opensim-dev mailing list >>> > Opensim-dev at lists.berlios.de >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >> >> >> -- >> =================================== >> http://osgrid.org/ >> http://simhost.com >> http://twitter.com/jstallings2 >> >> > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev From james.stallings at gmail.com Thu Apr 10 16:37:59 2014 From: james.stallings at gmail.com (James Stallings II) Date: Thu, 10 Apr 2014 11:37:59 -0500 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: <5346C8AD.5000809@t-data.com> References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> <20140410155900.GA3167@schumann> <5346C6EC.9080906@t-data.com> <5346C8AD.5000809@t-data.com> Message-ID: I thought I recalled such a thing, been about as long since I looked at it ;) Thanks Mel James On Thu, Apr 10, 2014 at 11:37 AM, Melanie wrote: > Yes. allow_forceful_banlines, I believe. Long time since I looked at it. > > - Melanie > > On 10/04/2014 18:33, James Stallings II wrote: > > Quick question (related) is there a configuration point I'm missing that > > enables 'forceful bans'? > > > > > > > > On Thu, Apr 10, 2014 at 11:30 AM, James Stallings II < > > james.stallings at gmail.com> wrote: > > > >> I kinder suspected something to that effect. It goes without saying > that a > >> lot occurs during the login process than is immediately apparent when > one > >> sits and watches the consoles. > >> > >> Right now I'm leaning towards the previously-mentioned edge case. > >> > >> > >> On Thu, Apr 10, 2014 at 11:29 AM, Melanie wrote: > >> > >>> The QueryAccess is a pre-authorization. So the double call is > >>> intentional and unavoidable. > >>> > >>> - Melanie > >>> > >>> On 10/04/2014 18:14, James Stallings II wrote: > >>> > It would seem that the two invocations of the TestLandRestrictions > >>> method > >>> > in Scene occur in each of NewUserConnection and > >>> > QueryAccess. EventManagerOnAvatarEnteringNewParcel is, fairly > obviously, > >>> > and event callback method; at this point I don't have but a guess > where > >>> > this might be called excepting from > >>> > within EventManagerOnSignificantClientMovement. > >>> > > >>> > I'd like to think that the two calls to TestLandRestrictions in Scene > >>> might > >>> > be reduced to one; but I'm not yet convinced it is the way to go. > >>> > > >>> > More to follow. > >>> > > >>> > Cheers > >>> > > >>> > > >>> > > >>> > On Thu, Apr 10, 2014 at 10:59 AM, Robert A. Knop Jr. < > rknop at pobox.com > >>> >wrote: > >>> > > >>> >> On Thu, Apr 10, 2014 at 10:25:17AM -0500, James Stallings II wrote: > >>> >> > And FWIW, last I hear adding log statements to code is a valid > >>> >> > tried and true debugging method. > >>> >> > >>> >> I wish to subscribe all of my students in my programming class to > your > >>> >> newsletter. > >>> >> > >>> >> (The number of times I told them to print stuff to figure out where > the > >>> >> code was, and the number of times I told them to print in more > places, > >>> >> was phenomenal. They got tired of hearing me say it, but somehow > still > >>> >> needed to hear it.) > >>> >> > >>> >> (They often needed similar guidance in figuring out how to use > >>> >> breakpoints in debuggers.) > >>> >> > >>> >> -Rob > >>> >> > >>> >> -- > >>> >> --Rob Knop > >>> >> E-mail: rknop at pobox.com > >>> >> Home Page: http://www.pobox.com/~rknop/ > >>> >> Blog: http://www.galacticinteractions.org/ > >>> >> > >>> >> _______________________________________________ > >>> >> Opensim-dev mailing list > >>> >> Opensim-dev at lists.berlios.de > >>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> >> > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > _______________________________________________ > >>> > Opensim-dev mailing list > >>> > Opensim-dev at lists.berlios.de > >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> _______________________________________________ > >>> Opensim-dev mailing list > >>> Opensim-dev at lists.berlios.de > >>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> > >> > >> > >> > >> -- > >> =================================== > >> http://osgrid.org/ > >> http://simhost.com > >> http://twitter.com/jstallings2 > >> > >> > > > > > > > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.stallings at gmail.com Thu Apr 10 16:43:15 2014 From: james.stallings at gmail.com (James Stallings II) Date: Thu, 10 Apr 2014 11:43:15 -0500 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> <20140410155900.GA3167@schumann> <5346C6EC.9080906@t-data.com> <5346C8AD.5000809@t-data.com> Message-ID: Mel, cant get a grep on allow_f* anywhere in the source tree, looks like it has gone the way of the elves On Thu, Apr 10, 2014 at 11:37 AM, James Stallings II < james.stallings at gmail.com> wrote: > I thought I recalled such a thing, been about as long since I looked at it > ;) > > Thanks Mel > > > James > > > > On Thu, Apr 10, 2014 at 11:37 AM, Melanie wrote: > >> Yes. allow_forceful_banlines, I believe. Long time since I looked at it. >> >> - Melanie >> >> On 10/04/2014 18:33, James Stallings II wrote: >> > Quick question (related) is there a configuration point I'm missing that >> > enables 'forceful bans'? >> > >> > >> > >> > On Thu, Apr 10, 2014 at 11:30 AM, James Stallings II < >> > james.stallings at gmail.com> wrote: >> > >> >> I kinder suspected something to that effect. It goes without saying >> that a >> >> lot occurs during the login process than is immediately apparent when >> one >> >> sits and watches the consoles. >> >> >> >> Right now I'm leaning towards the previously-mentioned edge case. >> >> >> >> >> >> On Thu, Apr 10, 2014 at 11:29 AM, Melanie wrote: >> >> >> >>> The QueryAccess is a pre-authorization. So the double call is >> >>> intentional and unavoidable. >> >>> >> >>> - Melanie >> >>> >> >>> On 10/04/2014 18:14, James Stallings II wrote: >> >>> > It would seem that the two invocations of the TestLandRestrictions >> >>> method >> >>> > in Scene occur in each of NewUserConnection and >> >>> > QueryAccess. EventManagerOnAvatarEnteringNewParcel is, fairly >> obviously, >> >>> > and event callback method; at this point I don't have but a guess >> where >> >>> > this might be called excepting from >> >>> > within EventManagerOnSignificantClientMovement. >> >>> > >> >>> > I'd like to think that the two calls to TestLandRestrictions in >> Scene >> >>> might >> >>> > be reduced to one; but I'm not yet convinced it is the way to go. >> >>> > >> >>> > More to follow. >> >>> > >> >>> > Cheers >> >>> > >> >>> > >> >>> > >> >>> > On Thu, Apr 10, 2014 at 10:59 AM, Robert A. Knop Jr. < >> rknop at pobox.com >> >>> >wrote: >> >>> > >> >>> >> On Thu, Apr 10, 2014 at 10:25:17AM -0500, James Stallings II wrote: >> >>> >> > And FWIW, last I hear adding log statements to code is a valid >> >>> >> > tried and true debugging method. >> >>> >> >> >>> >> I wish to subscribe all of my students in my programming class to >> your >> >>> >> newsletter. >> >>> >> >> >>> >> (The number of times I told them to print stuff to figure out >> where the >> >>> >> code was, and the number of times I told them to print in more >> places, >> >>> >> was phenomenal. They got tired of hearing me say it, but somehow >> still >> >>> >> needed to hear it.) >> >>> >> >> >>> >> (They often needed similar guidance in figuring out how to use >> >>> >> breakpoints in debuggers.) >> >>> >> >> >>> >> -Rob >> >>> >> >> >>> >> -- >> >>> >> --Rob Knop >> >>> >> E-mail: rknop at pobox.com >> >>> >> Home Page: http://www.pobox.com/~rknop/ >> >>> >> Blog: http://www.galacticinteractions.org/ >> >>> >> >> >>> >> _______________________________________________ >> >>> >> Opensim-dev mailing list >> >>> >> Opensim-dev at lists.berlios.de >> >>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >>> >> >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > _______________________________________________ >> >>> > Opensim-dev mailing list >> >>> > Opensim-dev at lists.berlios.de >> >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev >> >>> _______________________________________________ >> >>> Opensim-dev mailing list >> >>> Opensim-dev at lists.berlios.de >> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >>> >> >> >> >> >> >> >> >> -- >> >> =================================== >> >> http://osgrid.org/ >> >> http://simhost.com >> >> http://twitter.com/jstallings2 >> >> >> >> >> > >> > >> > >> > >> > _______________________________________________ >> > Opensim-dev mailing list >> > Opensim-dev at lists.berlios.de >> > https://lists.berlios.de/mailman/listinfo/opensim-dev >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > -- > =================================== > http://osgrid.org/ > http://simhost.com > http://twitter.com/jstallings2 > > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From melanie at t-data.com Thu Apr 10 16:45:04 2014 From: melanie at t-data.com (Melanie) Date: Thu, 10 Apr 2014 18:45:04 +0200 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> <20140410155900.GA3167@schumann> <5346C6EC.9080906@t-data.com> <5346C8AD.5000809@t-data.com> Message-ID: <5346CA90.90707@t-data.com> Why, the elves are still around! I know a couple. - Melanie On 10/04/2014 18:43, James Stallings II wrote: > Mel, cant get a grep on allow_f* anywhere in the source tree, looks like it > has gone the way of the elves > > > On Thu, Apr 10, 2014 at 11:37 AM, James Stallings II < > james.stallings at gmail.com> wrote: > >> I thought I recalled such a thing, been about as long since I looked at it >> ;) >> >> Thanks Mel >> >> >> James >> >> >> >> On Thu, Apr 10, 2014 at 11:37 AM, Melanie wrote: >> >>> Yes. allow_forceful_banlines, I believe. Long time since I looked at it. >>> >>> - Melanie >>> >>> On 10/04/2014 18:33, James Stallings II wrote: >>> > Quick question (related) is there a configuration point I'm missing that >>> > enables 'forceful bans'? >>> > >>> > >>> > >>> > On Thu, Apr 10, 2014 at 11:30 AM, James Stallings II < >>> > james.stallings at gmail.com> wrote: >>> > >>> >> I kinder suspected something to that effect. It goes without saying >>> that a >>> >> lot occurs during the login process than is immediately apparent when >>> one >>> >> sits and watches the consoles. >>> >> >>> >> Right now I'm leaning towards the previously-mentioned edge case. >>> >> >>> >> >>> >> On Thu, Apr 10, 2014 at 11:29 AM, Melanie wrote: >>> >> >>> >>> The QueryAccess is a pre-authorization. So the double call is >>> >>> intentional and unavoidable. >>> >>> >>> >>> - Melanie >>> >>> >>> >>> On 10/04/2014 18:14, James Stallings II wrote: >>> >>> > It would seem that the two invocations of the TestLandRestrictions >>> >>> method >>> >>> > in Scene occur in each of NewUserConnection and >>> >>> > QueryAccess. EventManagerOnAvatarEnteringNewParcel is, fairly >>> obviously, >>> >>> > and event callback method; at this point I don't have but a guess >>> where >>> >>> > this might be called excepting from >>> >>> > within EventManagerOnSignificantClientMovement. >>> >>> > >>> >>> > I'd like to think that the two calls to TestLandRestrictions in >>> Scene >>> >>> might >>> >>> > be reduced to one; but I'm not yet convinced it is the way to go. >>> >>> > >>> >>> > More to follow. >>> >>> > >>> >>> > Cheers >>> >>> > >>> >>> > >>> >>> > >>> >>> > On Thu, Apr 10, 2014 at 10:59 AM, Robert A. Knop Jr. < >>> rknop at pobox.com >>> >>> >wrote: >>> >>> > >>> >>> >> On Thu, Apr 10, 2014 at 10:25:17AM -0500, James Stallings II wrote: >>> >>> >> > And FWIW, last I hear adding log statements to code is a valid >>> >>> >> > tried and true debugging method. >>> >>> >> >>> >>> >> I wish to subscribe all of my students in my programming class to >>> your >>> >>> >> newsletter. >>> >>> >> >>> >>> >> (The number of times I told them to print stuff to figure out >>> where the >>> >>> >> code was, and the number of times I told them to print in more >>> places, >>> >>> >> was phenomenal. They got tired of hearing me say it, but somehow >>> still >>> >>> >> needed to hear it.) >>> >>> >> >>> >>> >> (They often needed similar guidance in figuring out how to use >>> >>> >> breakpoints in debuggers.) >>> >>> >> >>> >>> >> -Rob >>> >>> >> >>> >>> >> -- >>> >>> >> --Rob Knop >>> >>> >> E-mail: rknop at pobox.com >>> >>> >> Home Page: http://www.pobox.com/~rknop/ >>> >>> >> Blog: http://www.galacticinteractions.org/ >>> >>> >> >>> >>> >> _______________________________________________ >>> >>> >> Opensim-dev mailing list >>> >>> >> Opensim-dev at lists.berlios.de >>> >>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> >> >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > _______________________________________________ >>> >>> > Opensim-dev mailing list >>> >>> > Opensim-dev at lists.berlios.de >>> >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> _______________________________________________ >>> >>> Opensim-dev mailing list >>> >>> Opensim-dev at lists.berlios.de >>> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> >>> >> >>> >> >>> >> >>> >> -- >>> >> =================================== >>> >> http://osgrid.org/ >>> >> http://simhost.com >>> >> http://twitter.com/jstallings2 >>> >> >>> >> >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > Opensim-dev mailing list >>> > Opensim-dev at lists.berlios.de >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >> >> >> -- >> =================================== >> http://osgrid.org/ >> http://simhost.com >> http://twitter.com/jstallings2 >> >> > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev From melanie at t-data.com Thu Apr 10 16:48:26 2014 From: melanie at t-data.com (Melanie) Date: Thu, 10 Apr 2014 18:48:26 +0200 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> <20140410155900.GA3167@schumann> <5346C6EC.9080906@t-data.com> <5346C8AD.5000809@t-data.com> Message-ID: <5346CB5A.3080702@t-data.com> The setting is still there. It is defaulted to true and the code to set it from files has been removed and is dead. So bans should be forceful. - Melanie On 10/04/2014 18:43, James Stallings II wrote: > Mel, cant get a grep on allow_f* anywhere in the source tree, looks like it > has gone the way of the elves > > > On Thu, Apr 10, 2014 at 11:37 AM, James Stallings II < > james.stallings at gmail.com> wrote: > >> I thought I recalled such a thing, been about as long since I looked at it >> ;) >> >> Thanks Mel >> >> >> James >> >> >> >> On Thu, Apr 10, 2014 at 11:37 AM, Melanie wrote: >> >>> Yes. allow_forceful_banlines, I believe. Long time since I looked at it. >>> >>> - Melanie >>> >>> On 10/04/2014 18:33, James Stallings II wrote: >>> > Quick question (related) is there a configuration point I'm missing that >>> > enables 'forceful bans'? >>> > >>> > >>> > >>> > On Thu, Apr 10, 2014 at 11:30 AM, James Stallings II < >>> > james.stallings at gmail.com> wrote: >>> > >>> >> I kinder suspected something to that effect. It goes without saying >>> that a >>> >> lot occurs during the login process than is immediately apparent when >>> one >>> >> sits and watches the consoles. >>> >> >>> >> Right now I'm leaning towards the previously-mentioned edge case. >>> >> >>> >> >>> >> On Thu, Apr 10, 2014 at 11:29 AM, Melanie wrote: >>> >> >>> >>> The QueryAccess is a pre-authorization. So the double call is >>> >>> intentional and unavoidable. >>> >>> >>> >>> - Melanie >>> >>> >>> >>> On 10/04/2014 18:14, James Stallings II wrote: >>> >>> > It would seem that the two invocations of the TestLandRestrictions >>> >>> method >>> >>> > in Scene occur in each of NewUserConnection and >>> >>> > QueryAccess. EventManagerOnAvatarEnteringNewParcel is, fairly >>> obviously, >>> >>> > and event callback method; at this point I don't have but a guess >>> where >>> >>> > this might be called excepting from >>> >>> > within EventManagerOnSignificantClientMovement. >>> >>> > >>> >>> > I'd like to think that the two calls to TestLandRestrictions in >>> Scene >>> >>> might >>> >>> > be reduced to one; but I'm not yet convinced it is the way to go. >>> >>> > >>> >>> > More to follow. >>> >>> > >>> >>> > Cheers >>> >>> > >>> >>> > >>> >>> > >>> >>> > On Thu, Apr 10, 2014 at 10:59 AM, Robert A. Knop Jr. < >>> rknop at pobox.com >>> >>> >wrote: >>> >>> > >>> >>> >> On Thu, Apr 10, 2014 at 10:25:17AM -0500, James Stallings II wrote: >>> >>> >> > And FWIW, last I hear adding log statements to code is a valid >>> >>> >> > tried and true debugging method. >>> >>> >> >>> >>> >> I wish to subscribe all of my students in my programming class to >>> your >>> >>> >> newsletter. >>> >>> >> >>> >>> >> (The number of times I told them to print stuff to figure out >>> where the >>> >>> >> code was, and the number of times I told them to print in more >>> places, >>> >>> >> was phenomenal. They got tired of hearing me say it, but somehow >>> still >>> >>> >> needed to hear it.) >>> >>> >> >>> >>> >> (They often needed similar guidance in figuring out how to use >>> >>> >> breakpoints in debuggers.) >>> >>> >> >>> >>> >> -Rob >>> >>> >> >>> >>> >> -- >>> >>> >> --Rob Knop >>> >>> >> E-mail: rknop at pobox.com >>> >>> >> Home Page: http://www.pobox.com/~rknop/ >>> >>> >> Blog: http://www.galacticinteractions.org/ >>> >>> >> >>> >>> >> _______________________________________________ >>> >>> >> Opensim-dev mailing list >>> >>> >> Opensim-dev at lists.berlios.de >>> >>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> >> >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > _______________________________________________ >>> >>> > Opensim-dev mailing list >>> >>> > Opensim-dev at lists.berlios.de >>> >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> _______________________________________________ >>> >>> Opensim-dev mailing list >>> >>> Opensim-dev at lists.berlios.de >>> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> >>> >> >>> >> >>> >> >>> >> -- >>> >> =================================== >>> >> http://osgrid.org/ >>> >> http://simhost.com >>> >> http://twitter.com/jstallings2 >>> >> >>> >> >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > Opensim-dev mailing list >>> > Opensim-dev at lists.berlios.de >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >> >> >> -- >> =================================== >> http://osgrid.org/ >> http://simhost.com >> http://twitter.com/jstallings2 >> >> > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev From james.stallings at gmail.com Thu Apr 10 16:48:18 2014 From: james.stallings at gmail.com (James Stallings II) Date: Thu, 10 Apr 2014 11:48:18 -0500 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: <5346CB5A.3080702@t-data.com> References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> <20140410155900.GA3167@schumann> <5346C6EC.9080906@t-data.com> <5346C8AD.5000809@t-data.com> <5346CB5A.3080702@t-data.com> Message-ID: Fair enough, tyvm :) On Thu, Apr 10, 2014 at 11:48 AM, Melanie wrote: > The setting is still there. It is defaulted to true and the code to > set it from files has been removed and is dead. So bans should be > forceful. > > - Melanie > > On 10/04/2014 18:43, James Stallings II wrote: > > Mel, cant get a grep on allow_f* anywhere in the source tree, looks like > it > > has gone the way of the elves > > > > > > On Thu, Apr 10, 2014 at 11:37 AM, James Stallings II < > > james.stallings at gmail.com> wrote: > > > >> I thought I recalled such a thing, been about as long since I looked at > it > >> ;) > >> > >> Thanks Mel > >> > >> > >> James > >> > >> > >> > >> On Thu, Apr 10, 2014 at 11:37 AM, Melanie wrote: > >> > >>> Yes. allow_forceful_banlines, I believe. Long time since I looked at > it. > >>> > >>> - Melanie > >>> > >>> On 10/04/2014 18:33, James Stallings II wrote: > >>> > Quick question (related) is there a configuration point I'm missing > that > >>> > enables 'forceful bans'? > >>> > > >>> > > >>> > > >>> > On Thu, Apr 10, 2014 at 11:30 AM, James Stallings II < > >>> > james.stallings at gmail.com> wrote: > >>> > > >>> >> I kinder suspected something to that effect. It goes without saying > >>> that a > >>> >> lot occurs during the login process than is immediately apparent > when > >>> one > >>> >> sits and watches the consoles. > >>> >> > >>> >> Right now I'm leaning towards the previously-mentioned edge case. > >>> >> > >>> >> > >>> >> On Thu, Apr 10, 2014 at 11:29 AM, Melanie > wrote: > >>> >> > >>> >>> The QueryAccess is a pre-authorization. So the double call is > >>> >>> intentional and unavoidable. > >>> >>> > >>> >>> - Melanie > >>> >>> > >>> >>> On 10/04/2014 18:14, James Stallings II wrote: > >>> >>> > It would seem that the two invocations of the > TestLandRestrictions > >>> >>> method > >>> >>> > in Scene occur in each of NewUserConnection and > >>> >>> > QueryAccess. EventManagerOnAvatarEnteringNewParcel is, fairly > >>> obviously, > >>> >>> > and event callback method; at this point I don't have but a guess > >>> where > >>> >>> > this might be called excepting from > >>> >>> > within EventManagerOnSignificantClientMovement. > >>> >>> > > >>> >>> > I'd like to think that the two calls to TestLandRestrictions in > >>> Scene > >>> >>> might > >>> >>> > be reduced to one; but I'm not yet convinced it is the way to go. > >>> >>> > > >>> >>> > More to follow. > >>> >>> > > >>> >>> > Cheers > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> > On Thu, Apr 10, 2014 at 10:59 AM, Robert A. Knop Jr. < > >>> rknop at pobox.com > >>> >>> >wrote: > >>> >>> > > >>> >>> >> On Thu, Apr 10, 2014 at 10:25:17AM -0500, James Stallings II > wrote: > >>> >>> >> > And FWIW, last I hear adding log statements to code is a valid > >>> >>> >> > tried and true debugging method. > >>> >>> >> > >>> >>> >> I wish to subscribe all of my students in my programming class > to > >>> your > >>> >>> >> newsletter. > >>> >>> >> > >>> >>> >> (The number of times I told them to print stuff to figure out > >>> where the > >>> >>> >> code was, and the number of times I told them to print in more > >>> places, > >>> >>> >> was phenomenal. They got tired of hearing me say it, but > somehow > >>> still > >>> >>> >> needed to hear it.) > >>> >>> >> > >>> >>> >> (They often needed similar guidance in figuring out how to use > >>> >>> >> breakpoints in debuggers.) > >>> >>> >> > >>> >>> >> -Rob > >>> >>> >> > >>> >>> >> -- > >>> >>> >> --Rob Knop > >>> >>> >> E-mail: rknop at pobox.com > >>> >>> >> Home Page: http://www.pobox.com/~rknop/ > >>> >>> >> Blog: http://www.galacticinteractions.org/ > >>> >>> >> > >>> >>> >> _______________________________________________ > >>> >>> >> Opensim-dev mailing list > >>> >>> >> Opensim-dev at lists.berlios.de > >>> >>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> >>> >> > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> > _______________________________________________ > >>> >>> > Opensim-dev mailing list > >>> >>> > Opensim-dev at lists.berlios.de > >>> >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> >>> _______________________________________________ > >>> >>> Opensim-dev mailing list > >>> >>> Opensim-dev at lists.berlios.de > >>> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> >>> > >>> >> > >>> >> > >>> >> > >>> >> -- > >>> >> =================================== > >>> >> http://osgrid.org/ > >>> >> http://simhost.com > >>> >> http://twitter.com/jstallings2 > >>> >> > >>> >> > >>> > > >>> > > >>> > > >>> > > >>> > _______________________________________________ > >>> > Opensim-dev mailing list > >>> > Opensim-dev at lists.berlios.de > >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> _______________________________________________ > >>> Opensim-dev mailing list > >>> Opensim-dev at lists.berlios.de > >>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> > >> > >> > >> > >> -- > >> =================================== > >> http://osgrid.org/ > >> http://simhost.com > >> http://twitter.com/jstallings2 > >> > >> > > > > > > > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.stallings at gmail.com Thu Apr 10 16:44:06 2014 From: james.stallings at gmail.com (James Stallings II) Date: Thu, 10 Apr 2014 11:44:06 -0500 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> <20140410155900.GA3167@schumann> <5346C6EC.9080906@t-data.com> <5346C8AD.5000809@t-data.com> Message-ID: There are still getters and setters on the property, but I cant ref the config point anywhere On Thu, Apr 10, 2014 at 11:43 AM, James Stallings II < james.stallings at gmail.com> wrote: > Mel, cant get a grep on allow_f* anywhere in the source tree, looks like > it has gone the way of the elves > > > On Thu, Apr 10, 2014 at 11:37 AM, James Stallings II < > james.stallings at gmail.com> wrote: > >> I thought I recalled such a thing, been about as long since I looked at >> it ;) >> >> Thanks Mel >> >> >> James >> >> >> >> On Thu, Apr 10, 2014 at 11:37 AM, Melanie wrote: >> >>> Yes. allow_forceful_banlines, I believe. Long time since I looked at it. >>> >>> - Melanie >>> >>> On 10/04/2014 18:33, James Stallings II wrote: >>> > Quick question (related) is there a configuration point I'm missing >>> that >>> > enables 'forceful bans'? >>> > >>> > >>> > >>> > On Thu, Apr 10, 2014 at 11:30 AM, James Stallings II < >>> > james.stallings at gmail.com> wrote: >>> > >>> >> I kinder suspected something to that effect. It goes without saying >>> that a >>> >> lot occurs during the login process than is immediately apparent when >>> one >>> >> sits and watches the consoles. >>> >> >>> >> Right now I'm leaning towards the previously-mentioned edge case. >>> >> >>> >> >>> >> On Thu, Apr 10, 2014 at 11:29 AM, Melanie wrote: >>> >> >>> >>> The QueryAccess is a pre-authorization. So the double call is >>> >>> intentional and unavoidable. >>> >>> >>> >>> - Melanie >>> >>> >>> >>> On 10/04/2014 18:14, James Stallings II wrote: >>> >>> > It would seem that the two invocations of the TestLandRestrictions >>> >>> method >>> >>> > in Scene occur in each of NewUserConnection and >>> >>> > QueryAccess. EventManagerOnAvatarEnteringNewParcel is, fairly >>> obviously, >>> >>> > and event callback method; at this point I don't have but a guess >>> where >>> >>> > this might be called excepting from >>> >>> > within EventManagerOnSignificantClientMovement. >>> >>> > >>> >>> > I'd like to think that the two calls to TestLandRestrictions in >>> Scene >>> >>> might >>> >>> > be reduced to one; but I'm not yet convinced it is the way to go. >>> >>> > >>> >>> > More to follow. >>> >>> > >>> >>> > Cheers >>> >>> > >>> >>> > >>> >>> > >>> >>> > On Thu, Apr 10, 2014 at 10:59 AM, Robert A. Knop Jr. < >>> rknop at pobox.com >>> >>> >wrote: >>> >>> > >>> >>> >> On Thu, Apr 10, 2014 at 10:25:17AM -0500, James Stallings II >>> wrote: >>> >>> >> > And FWIW, last I hear adding log statements to code is a valid >>> >>> >> > tried and true debugging method. >>> >>> >> >>> >>> >> I wish to subscribe all of my students in my programming class to >>> your >>> >>> >> newsletter. >>> >>> >> >>> >>> >> (The number of times I told them to print stuff to figure out >>> where the >>> >>> >> code was, and the number of times I told them to print in more >>> places, >>> >>> >> was phenomenal. They got tired of hearing me say it, but somehow >>> still >>> >>> >> needed to hear it.) >>> >>> >> >>> >>> >> (They often needed similar guidance in figuring out how to use >>> >>> >> breakpoints in debuggers.) >>> >>> >> >>> >>> >> -Rob >>> >>> >> >>> >>> >> -- >>> >>> >> --Rob Knop >>> >>> >> E-mail: rknop at pobox.com >>> >>> >> Home Page: http://www.pobox.com/~rknop/ >>> >>> >> Blog: http://www.galacticinteractions.org/ >>> >>> >> >>> >>> >> _______________________________________________ >>> >>> >> Opensim-dev mailing list >>> >>> >> Opensim-dev at lists.berlios.de >>> >>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> >> >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > _______________________________________________ >>> >>> > Opensim-dev mailing list >>> >>> > Opensim-dev at lists.berlios.de >>> >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> _______________________________________________ >>> >>> Opensim-dev mailing list >>> >>> Opensim-dev at lists.berlios.de >>> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> >>> >> >>> >> >>> >> >>> >> -- >>> >> =================================== >>> >> http://osgrid.org/ >>> >> http://simhost.com >>> >> http://twitter.com/jstallings2 >>> >> >>> >> >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > Opensim-dev mailing list >>> > Opensim-dev at lists.berlios.de >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >> >> >> -- >> =================================== >> http://osgrid.org/ >> http://simhost.com >> http://twitter.com/jstallings2 >> >> > > > -- > =================================== > http://osgrid.org/ > http://simhost.com > http://twitter.com/jstallings2 > > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From melanie at t-data.com Thu Apr 10 16:51:39 2014 From: melanie at t-data.com (Melanie) Date: Thu, 10 Apr 2014 18:51:39 +0200 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> <20140410155900.GA3167@schumann> <5346C6EC.9080906@t-data.com> <5346C8AD.5000809@t-data.com> Message-ID: <5346CC1B.9080905@t-data.com> It used to go through event manager - an ancient way of doing it. - Melanie On 10/04/2014 18:44, James Stallings II wrote: > There are still getters and setters on the property, but I cant ref the > config point anywhere > > > On Thu, Apr 10, 2014 at 11:43 AM, James Stallings II < > james.stallings at gmail.com> wrote: > >> Mel, cant get a grep on allow_f* anywhere in the source tree, looks like >> it has gone the way of the elves >> >> >> On Thu, Apr 10, 2014 at 11:37 AM, James Stallings II < >> james.stallings at gmail.com> wrote: >> >>> I thought I recalled such a thing, been about as long since I looked at >>> it ;) >>> >>> Thanks Mel >>> >>> >>> James >>> >>> >>> >>> On Thu, Apr 10, 2014 at 11:37 AM, Melanie wrote: >>> >>>> Yes. allow_forceful_banlines, I believe. Long time since I looked at it. >>>> >>>> - Melanie >>>> >>>> On 10/04/2014 18:33, James Stallings II wrote: >>>> > Quick question (related) is there a configuration point I'm missing >>>> that >>>> > enables 'forceful bans'? >>>> > >>>> > >>>> > >>>> > On Thu, Apr 10, 2014 at 11:30 AM, James Stallings II < >>>> > james.stallings at gmail.com> wrote: >>>> > >>>> >> I kinder suspected something to that effect. It goes without saying >>>> that a >>>> >> lot occurs during the login process than is immediately apparent when >>>> one >>>> >> sits and watches the consoles. >>>> >> >>>> >> Right now I'm leaning towards the previously-mentioned edge case. >>>> >> >>>> >> >>>> >> On Thu, Apr 10, 2014 at 11:29 AM, Melanie wrote: >>>> >> >>>> >>> The QueryAccess is a pre-authorization. So the double call is >>>> >>> intentional and unavoidable. >>>> >>> >>>> >>> - Melanie >>>> >>> >>>> >>> On 10/04/2014 18:14, James Stallings II wrote: >>>> >>> > It would seem that the two invocations of the TestLandRestrictions >>>> >>> method >>>> >>> > in Scene occur in each of NewUserConnection and >>>> >>> > QueryAccess. EventManagerOnAvatarEnteringNewParcel is, fairly >>>> obviously, >>>> >>> > and event callback method; at this point I don't have but a guess >>>> where >>>> >>> > this might be called excepting from >>>> >>> > within EventManagerOnSignificantClientMovement. >>>> >>> > >>>> >>> > I'd like to think that the two calls to TestLandRestrictions in >>>> Scene >>>> >>> might >>>> >>> > be reduced to one; but I'm not yet convinced it is the way to go. >>>> >>> > >>>> >>> > More to follow. >>>> >>> > >>>> >>> > Cheers >>>> >>> > >>>> >>> > >>>> >>> > >>>> >>> > On Thu, Apr 10, 2014 at 10:59 AM, Robert A. Knop Jr. < >>>> rknop at pobox.com >>>> >>> >wrote: >>>> >>> > >>>> >>> >> On Thu, Apr 10, 2014 at 10:25:17AM -0500, James Stallings II >>>> wrote: >>>> >>> >> > And FWIW, last I hear adding log statements to code is a valid >>>> >>> >> > tried and true debugging method. >>>> >>> >> >>>> >>> >> I wish to subscribe all of my students in my programming class to >>>> your >>>> >>> >> newsletter. >>>> >>> >> >>>> >>> >> (The number of times I told them to print stuff to figure out >>>> where the >>>> >>> >> code was, and the number of times I told them to print in more >>>> places, >>>> >>> >> was phenomenal. They got tired of hearing me say it, but somehow >>>> still >>>> >>> >> needed to hear it.) >>>> >>> >> >>>> >>> >> (They often needed similar guidance in figuring out how to use >>>> >>> >> breakpoints in debuggers.) >>>> >>> >> >>>> >>> >> -Rob >>>> >>> >> >>>> >>> >> -- >>>> >>> >> --Rob Knop >>>> >>> >> E-mail: rknop at pobox.com >>>> >>> >> Home Page: http://www.pobox.com/~rknop/ >>>> >>> >> Blog: http://www.galacticinteractions.org/ >>>> >>> >> >>>> >>> >> _______________________________________________ >>>> >>> >> Opensim-dev mailing list >>>> >>> >> Opensim-dev at lists.berlios.de >>>> >>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> >>> >> >>>> >>> > >>>> >>> > >>>> >>> > >>>> >>> > >>>> >>> > >>>> >>> > _______________________________________________ >>>> >>> > Opensim-dev mailing list >>>> >>> > Opensim-dev at lists.berlios.de >>>> >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> >>> _______________________________________________ >>>> >>> Opensim-dev mailing list >>>> >>> Opensim-dev at lists.berlios.de >>>> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> >>> >>>> >> >>>> >> >>>> >> >>>> >> -- >>>> >> =================================== >>>> >> http://osgrid.org/ >>>> >> http://simhost.com >>>> >> http://twitter.com/jstallings2 >>>> >> >>>> >> >>>> > >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > Opensim-dev mailing list >>>> > Opensim-dev at lists.berlios.de >>>> > https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> Opensim-dev at lists.berlios.de >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> >>> >>> >>> >>> -- >>> =================================== >>> http://osgrid.org/ >>> http://simhost.com >>> http://twitter.com/jstallings2 >>> >>> >> >> >> -- >> =================================== >> http://osgrid.org/ >> http://simhost.com >> http://twitter.com/jstallings2 >> >> > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev From james.stallings at gmail.com Thu Apr 10 17:02:45 2014 From: james.stallings at gmail.com (James Stallings II) Date: Thu, 10 Apr 2014 12:02:45 -0500 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: <5346CA90.90707@t-data.com> References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> <20140410155900.GA3167@schumann> <5346C6EC.9080906@t-data.com> <5346C8AD.5000809@t-data.com> <5346CA90.90707@t-data.com> Message-ID: I think the default parcel is definitely an edge case. I created a small completely public parcel in the center of the region, and banned the test avatar outside it; everything works pretty much as one would hope, including the forceful banlines (it even displayed banlines, ugh). But, as designed. There was one problem, seems the av will get stuck to the banlines if s/he attempts crossing them; but a relog fixes it. In all honesty, not the very worst thing I ever had happen when hitting a banline. I'll see if I can figure out why, though. PS I was referring to those elves that left with Bilbo and Frodo for the Distant Shores ;) Cheers On Thu, Apr 10, 2014 at 11:45 AM, Melanie wrote: > Why, the elves are still around! I know a couple. > > - Melanie > > On 10/04/2014 18:43, James Stallings II wrote: > > Mel, cant get a grep on allow_f* anywhere in the source tree, looks like > it > > has gone the way of the elves > > > > > > On Thu, Apr 10, 2014 at 11:37 AM, James Stallings II < > > james.stallings at gmail.com> wrote: > > > >> I thought I recalled such a thing, been about as long since I looked at > it > >> ;) > >> > >> Thanks Mel > >> > >> > >> James > >> > >> > >> > >> On Thu, Apr 10, 2014 at 11:37 AM, Melanie wrote: > >> > >>> Yes. allow_forceful_banlines, I believe. Long time since I looked at > it. > >>> > >>> - Melanie > >>> > >>> On 10/04/2014 18:33, James Stallings II wrote: > >>> > Quick question (related) is there a configuration point I'm missing > that > >>> > enables 'forceful bans'? > >>> > > >>> > > >>> > > >>> > On Thu, Apr 10, 2014 at 11:30 AM, James Stallings II < > >>> > james.stallings at gmail.com> wrote: > >>> > > >>> >> I kinder suspected something to that effect. It goes without saying > >>> that a > >>> >> lot occurs during the login process than is immediately apparent > when > >>> one > >>> >> sits and watches the consoles. > >>> >> > >>> >> Right now I'm leaning towards the previously-mentioned edge case. > >>> >> > >>> >> > >>> >> On Thu, Apr 10, 2014 at 11:29 AM, Melanie > wrote: > >>> >> > >>> >>> The QueryAccess is a pre-authorization. So the double call is > >>> >>> intentional and unavoidable. > >>> >>> > >>> >>> - Melanie > >>> >>> > >>> >>> On 10/04/2014 18:14, James Stallings II wrote: > >>> >>> > It would seem that the two invocations of the > TestLandRestrictions > >>> >>> method > >>> >>> > in Scene occur in each of NewUserConnection and > >>> >>> > QueryAccess. EventManagerOnAvatarEnteringNewParcel is, fairly > >>> obviously, > >>> >>> > and event callback method; at this point I don't have but a guess > >>> where > >>> >>> > this might be called excepting from > >>> >>> > within EventManagerOnSignificantClientMovement. > >>> >>> > > >>> >>> > I'd like to think that the two calls to TestLandRestrictions in > >>> Scene > >>> >>> might > >>> >>> > be reduced to one; but I'm not yet convinced it is the way to go. > >>> >>> > > >>> >>> > More to follow. > >>> >>> > > >>> >>> > Cheers > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> > On Thu, Apr 10, 2014 at 10:59 AM, Robert A. Knop Jr. < > >>> rknop at pobox.com > >>> >>> >wrote: > >>> >>> > > >>> >>> >> On Thu, Apr 10, 2014 at 10:25:17AM -0500, James Stallings II > wrote: > >>> >>> >> > And FWIW, last I hear adding log statements to code is a valid > >>> >>> >> > tried and true debugging method. > >>> >>> >> > >>> >>> >> I wish to subscribe all of my students in my programming class > to > >>> your > >>> >>> >> newsletter. > >>> >>> >> > >>> >>> >> (The number of times I told them to print stuff to figure out > >>> where the > >>> >>> >> code was, and the number of times I told them to print in more > >>> places, > >>> >>> >> was phenomenal. They got tired of hearing me say it, but > somehow > >>> still > >>> >>> >> needed to hear it.) > >>> >>> >> > >>> >>> >> (They often needed similar guidance in figuring out how to use > >>> >>> >> breakpoints in debuggers.) > >>> >>> >> > >>> >>> >> -Rob > >>> >>> >> > >>> >>> >> -- > >>> >>> >> --Rob Knop > >>> >>> >> E-mail: rknop at pobox.com > >>> >>> >> Home Page: http://www.pobox.com/~rknop/ > >>> >>> >> Blog: http://www.galacticinteractions.org/ > >>> >>> >> > >>> >>> >> _______________________________________________ > >>> >>> >> Opensim-dev mailing list > >>> >>> >> Opensim-dev at lists.berlios.de > >>> >>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> >>> >> > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> > _______________________________________________ > >>> >>> > Opensim-dev mailing list > >>> >>> > Opensim-dev at lists.berlios.de > >>> >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> >>> _______________________________________________ > >>> >>> Opensim-dev mailing list > >>> >>> Opensim-dev at lists.berlios.de > >>> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> >>> > >>> >> > >>> >> > >>> >> > >>> >> -- > >>> >> =================================== > >>> >> http://osgrid.org/ > >>> >> http://simhost.com > >>> >> http://twitter.com/jstallings2 > >>> >> > >>> >> > >>> > > >>> > > >>> > > >>> > > >>> > _______________________________________________ > >>> > Opensim-dev mailing list > >>> > Opensim-dev at lists.berlios.de > >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> _______________________________________________ > >>> Opensim-dev mailing list > >>> Opensim-dev at lists.berlios.de > >>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> > >> > >> > >> > >> -- > >> =================================== > >> http://osgrid.org/ > >> http://simhost.com > >> http://twitter.com/jstallings2 > >> > >> > > > > > > > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jjustincc at googlemail.com Thu Apr 10 23:52:05 2014 From: jjustincc at googlemail.com (Justin Clark-Casey) Date: Fri, 11 Apr 2014 00:52:05 +0100 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> <20140410155900.GA3167@schumann> <5346C6EC.9080906@t-data.com> <5346C8AD.5000809@t-data.com> <5346CA90.90707@t-data.com> Message-ID: <53472EA5.1060009@googlemail.com> Yeah, there are definitely issues with consistent enforcement of ban lines on avatar movement. I remember looking at that some time ago but unfortunately not a simple thing to properly fix. On 10/04/14 18:02, James Stallings II wrote: > I think the default parcel is definitely an edge case. I created a small completely public parcel in the center of the > region, and banned the test avatar outside it; everything works pretty much as one would hope, including the forceful > banlines (it even displayed banlines, ugh). But, as designed. > > There was one problem, seems the av will get stuck to the banlines if s/he attempts crossing them; but a relog fixes it. > In all honesty, not the very worst thing I ever had happen when hitting a banline. I'll see if I can figure out why, though. > > PS I was referring to those elves that left with Bilbo and Frodo for the Distant Shores ;) > > Cheers > > > > On Thu, Apr 10, 2014 at 11:45 AM, Melanie > wrote: > > Why, the elves are still around! I know a couple. > > - Melanie > > On 10/04/2014 18:43, James Stallings II wrote: > > Mel, cant get a grep on allow_f* anywhere in the source tree, looks like it > > has gone the way of the elves > > > > > > On Thu, Apr 10, 2014 at 11:37 AM, James Stallings II < > > james.stallings at gmail.com > wrote: > > > >> I thought I recalled such a thing, been about as long since I looked at it > >> ;) > >> > >> Thanks Mel > >> > >> > >> James > >> > >> > >> > >> On Thu, Apr 10, 2014 at 11:37 AM, Melanie > wrote: > >> > >>> Yes. allow_forceful_banlines, I believe. Long time since I looked at it. > >>> > >>> - Melanie > >>> > >>> On 10/04/2014 18:33, James Stallings II wrote: > >>> > Quick question (related) is there a configuration point I'm missing that > >>> > enables 'forceful bans'? > >>> > > >>> > > >>> > > >>> > On Thu, Apr 10, 2014 at 11:30 AM, James Stallings II < > >>> > james.stallings at gmail.com > wrote: > >>> > > >>> >> I kinder suspected something to that effect. It goes without saying > >>> that a > >>> >> lot occurs during the login process than is immediately apparent when > >>> one > >>> >> sits and watches the consoles. > >>> >> > >>> >> Right now I'm leaning towards the previously-mentioned edge case. > >>> >> > >>> >> > >>> >> On Thu, Apr 10, 2014 at 11:29 AM, Melanie > wrote: > >>> >> > >>> >>> The QueryAccess is a pre-authorization. So the double call is > >>> >>> intentional and unavoidable. > >>> >>> > >>> >>> - Melanie > >>> >>> > >>> >>> On 10/04/2014 18:14, James Stallings II wrote: > >>> >>> > It would seem that the two invocations of the TestLandRestrictions > >>> >>> method > >>> >>> > in Scene occur in each of NewUserConnection and > >>> >>> > QueryAccess. EventManagerOnAvatarEnteringNewParcel is, fairly > >>> obviously, > >>> >>> > and event callback method; at this point I don't have but a guess > >>> where > >>> >>> > this might be called excepting from > >>> >>> > within EventManagerOnSignificantClientMovement. > >>> >>> > > >>> >>> > I'd like to think that the two calls to TestLandRestrictions in > >>> Scene > >>> >>> might > >>> >>> > be reduced to one; but I'm not yet convinced it is the way to go. > >>> >>> > > >>> >>> > More to follow. > >>> >>> > > >>> >>> > Cheers > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> > On Thu, Apr 10, 2014 at 10:59 AM, Robert A. Knop Jr. < > >>> rknop at pobox.com > >>> >>> >wrote: > >>> >>> > > >>> >>> >> On Thu, Apr 10, 2014 at 10:25:17AM -0500, James Stallings II wrote: > >>> >>> >> > And FWIW, last I hear adding log statements to code is a valid > >>> >>> >> > tried and true debugging method. > >>> >>> >> > >>> >>> >> I wish to subscribe all of my students in my programming class to > >>> your > >>> >>> >> newsletter. > >>> >>> >> > >>> >>> >> (The number of times I told them to print stuff to figure out > >>> where the > >>> >>> >> code was, and the number of times I told them to print in more > >>> places, > >>> >>> >> was phenomenal. They got tired of hearing me say it, but somehow > >>> still > >>> >>> >> needed to hear it.) > >>> >>> >> > >>> >>> >> (They often needed similar guidance in figuring out how to use > >>> >>> >> breakpoints in debuggers.) > >>> >>> >> > >>> >>> >> -Rob > >>> >>> >> > >>> >>> >> -- > >>> >>> >> --Rob Knop > >>> >>> >> E-mail: rknop at pobox.com > >>> >>> >> Home Page: http://www.pobox.com/~rknop/ > >>> >>> >> Blog: http://www.galacticinteractions.org/ > >>> >>> >> > >>> >>> >> _______________________________________________ > >>> >>> >> Opensim-dev mailing list > >>> >>> >> Opensim-dev at lists.berlios.de > >>> >>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> >>> >> > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> > _______________________________________________ > >>> >>> > Opensim-dev mailing list > >>> >>> > Opensim-dev at lists.berlios.de > >>> >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> >>> _______________________________________________ > >>> >>> Opensim-dev mailing list > >>> >>> Opensim-dev at lists.berlios.de > >>> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> >>> > >>> >> > >>> >> > >>> >> > >>> >> -- > >>> >> =================================== > >>> >> http://osgrid.org/ > >>> >> http://simhost.com > >>> >> http://twitter.com/jstallings2 > >>> >> > >>> >> > >>> > > >>> > > >>> > > >>> > > >>> > _______________________________________________ > >>> > Opensim-dev mailing list > >>> > Opensim-dev at lists.berlios.de > >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> _______________________________________________ > >>> Opensim-dev mailing list > >>> Opensim-dev at lists.berlios.de > >>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> > >> > >> > >> > >> -- > >> =================================== > >> http://osgrid.org/ > >> http://simhost.com > >> http://twitter.com/jstallings2 > >> > >> > > > > > > > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > > -- > =================================== > http://osgrid.org/ > http://simhost.com > http://twitter.com/jstallings2 > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- Justin Clark-Casey (justincc) OSVW Consulting http://justincc.org http://twitter.com/justincc From melanie at t-data.com Fri Apr 11 01:03:47 2014 From: melanie at t-data.com (Melanie) Date: Fri, 11 Apr 2014 03:03:47 +0200 Subject: [Opensim-dev] Legacy region XML support - Remove? Message-ID: <53473F73.20409@t-data.com> Hi, the RegionInfo class supports an ancient form of XML, one that is based on attributes rather than tags. At this point, we believe no one uses this format anymore. Further, NINI offers another form of XML that is much more up to date and a better replacement for the ancient XML in any case. The affected installations would be those that use pre-0.6 configuration files (regions.xml) or use web loading. The old config files would need to be redone by hand in .ini format, and people who web-load would need to change the server scripts to provide the same data in the new format, which is not too hard a task. I propose to remove the support for the legacy format, which has last been updated in 2007 and has been unused for two major revisions. Thoughts are welcome. Melanie From james.stallings at gmail.com Fri Apr 11 01:58:13 2014 From: james.stallings at gmail.com (James Stallings II) Date: Thu, 10 Apr 2014 20:58:13 -0500 Subject: [Opensim-dev] Legacy region XML support - Remove? In-Reply-To: <53473F73.20409@t-data.com> References: <53473F73.20409@t-data.com> Message-ID: For my part, I thought it was long gone :) On Thu, Apr 10, 2014 at 8:03 PM, Melanie wrote: > Hi, > > the RegionInfo class supports an ancient form of XML, one that is > based on attributes rather than tags. > > At this point, we believe no one uses this format anymore. Further, > NINI offers another form of XML that is much more up to date and a > better replacement for the ancient XML in any case. > > The affected installations would be those that use pre-0.6 > configuration files (regions.xml) or use web loading. > > The old config files would need to be redone by hand in .ini format, > and people who web-load would need to change the server scripts to > provide the same data in the new format, which is not too hard a task. > > I propose to remove the support for the legacy format, which has > last been updated in 2007 and has been unused for two major revisions. > > Thoughts are welcome. > > Melanie > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From fly.man.opensim at gmail.com Fri Apr 11 09:36:22 2014 From: fly.man.opensim at gmail.com (Fly Man) Date: Fri, 11 Apr 2014 11:36:22 +0200 Subject: [Opensim-dev] Legacy region XML support - Remove? In-Reply-To: References: <53473F73.20409@t-data.com> Message-ID: +1 as long as there's a good wiki page written to convert the old files to the new format 2014-04-11 3:58 GMT+02:00 James Stallings II : > For my part, I thought it was long gone :) > > > On Thu, Apr 10, 2014 at 8:03 PM, Melanie wrote: > >> Hi, >> >> the RegionInfo class supports an ancient form of XML, one that is >> based on attributes rather than tags. >> >> At this point, we believe no one uses this format anymore. Further, >> NINI offers another form of XML that is much more up to date and a >> better replacement for the ancient XML in any case. >> >> The affected installations would be those that use pre-0.6 >> configuration files (regions.xml) or use web loading. >> >> The old config files would need to be redone by hand in .ini format, >> and people who web-load would need to change the server scripts to >> provide the same data in the new format, which is not too hard a task. >> >> I propose to remove the support for the legacy format, which has >> last been updated in 2007 and has been unused for two major revisions. >> >> Thoughts are welcome. >> >> Melanie >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > -- > =================================== > http://osgrid.org/ > http://simhost.com > http://twitter.com/jstallings2 > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rigun at rigutech.nl Fri Apr 11 11:10:57 2014 From: rigun at rigutech.nl (R.Gunther) Date: Fri, 11 Apr 2014 13:10:57 +0200 Subject: [Opensim-dev] Legacy region XML support - Remove? In-Reply-To: <53473F73.20409@t-data.com> References: <53473F73.20409@t-data.com> Message-ID: <5347CDC1.7070102@rigutech.nl> Suprissed its still there, well people did have time enough to change the xml files to ini files on newer versions. For me, using long time ini files so you can remove it. On 2014-04-11 03:03, Melanie wrote: > Hi, > > the RegionInfo class supports an ancient form of XML, one that is > based on attributes rather than tags. > > At this point, we believe no one uses this format anymore. Further, > NINI offers another form of XML that is much more up to date and a > better replacement for the ancient XML in any case. > > The affected installations would be those that use pre-0.6 > configuration files (regions.xml) or use web loading. > > The old config files would need to be redone by hand in .ini format, > and people who web-load would need to change the server scripts to > provide the same data in the new format, which is not too hard a task. > > I propose to remove the support for the legacy format, which has > last been updated in 2007 and has been unused for two major revisions. > > Thoughts are welcome. > > Melanie > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > From abitar.com at gmail.com Fri Apr 11 13:35:04 2014 From: abitar.com at gmail.com (David Saunders) Date: Fri, 11 Apr 2014 09:35:04 -0400 Subject: [Opensim-dev] Legacy region XML support - Remove? In-Reply-To: <5347CDC1.7070102@rigutech.nl> References: <53473F73.20409@t-data.com> <5347CDC1.7070102@rigutech.nl> Message-ID: How does this relate to the XML format for web configuration? On Fri, Apr 11, 2014 at 7:10 AM, R.Gunther wrote: > Suprissed its still there, well people did have time enough to change the > xml files to ini files on newer versions. > For me, using long time ini files so you can remove it. > > > On 2014-04-11 03:03, Melanie wrote: > >> Hi, >> >> the RegionInfo class supports an ancient form of XML, one that is >> based on attributes rather than tags. >> >> At this point, we believe no one uses this format anymore. Further, >> NINI offers another form of XML that is much more up to date and a >> better replacement for the ancient XML in any case. >> >> The affected installations would be those that use pre-0.6 >> configuration files (regions.xml) or use web loading. >> >> The old config files would need to be redone by hand in .ini format, >> and people who web-load would need to change the server scripts to >> provide the same data in the new format, which is not too hard a task. >> >> I propose to remove the support for the legacy format, which has >> last been updated in 2007 and has been unused for two major revisions. >> >> Thoughts are welcome. >> >> Melanie >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From melanie at t-data.com Fri Apr 11 13:42:53 2014 From: melanie at t-data.com (Melanie) Date: Fri, 11 Apr 2014 15:42:53 +0200 Subject: [Opensim-dev] Legacy region XML support - Remove? In-Reply-To: References: <53473F73.20409@t-data.com> <5347CDC1.7070102@rigutech.nl> Message-ID: <5347F15D.108@t-data.com> That format needs to be changed. The old format is: The new format will be:
Server script that generate the old format dynamically need to be changed to generate the new format instead, - Melanie ... On 11/04/2014 15:35, David Saunders wrote: > How does this relate to the XML format for web configuration? > > > On Fri, Apr 11, 2014 at 7:10 AM, R.Gunther wrote: > >> Suprissed its still there, well people did have time enough to change the >> xml files to ini files on newer versions. >> For me, using long time ini files so you can remove it. >> >> >> On 2014-04-11 03:03, Melanie wrote: >> >>> Hi, >>> >>> the RegionInfo class supports an ancient form of XML, one that is >>> based on attributes rather than tags. >>> >>> At this point, we believe no one uses this format anymore. Further, >>> NINI offers another form of XML that is much more up to date and a >>> better replacement for the ancient XML in any case. >>> >>> The affected installations would be those that use pre-0.6 >>> configuration files (regions.xml) or use web loading. >>> >>> The old config files would need to be redone by hand in .ini format, >>> and people who web-load would need to change the server scripts to >>> provide the same data in the new format, which is not too hard a task. >>> >>> I propose to remove the support for the legacy format, which has >>> last been updated in 2007 and has been unused for two major revisions. >>> >>> Thoughts are welcome. >>> >>> Melanie >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev From jjustincc at googlemail.com Sat Apr 12 01:14:39 2014 From: jjustincc at googlemail.com (Justin Clark-Casey) Date: Sat, 12 Apr 2014 02:14:39 +0100 Subject: [Opensim-dev] Legacy region XML support - Remove? In-Reply-To: <53473F73.20409@t-data.com> References: <53473F73.20409@t-data.com> Message-ID: <5348937F.80602@googlemail.com> I don't see any problem with removing this - it's an extremely old format that I'd be surprised if anybody still uses. On 11/04/14 02:03, Melanie wrote: > Hi, > > the RegionInfo class supports an ancient form of XML, one that is > based on attributes rather than tags. > > At this point, we believe no one uses this format anymore. Further, > NINI offers another form of XML that is much more up to date and a > better replacement for the ancient XML in any case. > > The affected installations would be those that use pre-0.6 > configuration files (regions.xml) or use web loading. > > The old config files would need to be redone by hand in .ini format, > and people who web-load would need to change the server scripts to > provide the same data in the new format, which is not too hard a task. > > I propose to remove the support for the legacy format, which has > last been updated in 2007 and has been unused for two major revisions. > > Thoughts are welcome. > > Melanie > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > . > -- Justin Clark-Casey (justincc) OSVW Consulting http://justincc.org http://twitter.com/justincc From nebadon2025 at gmail.com Sat Apr 12 05:36:00 2014 From: nebadon2025 at gmail.com (Michael Emory Cerquoni) Date: Sat, 12 Apr 2014 07:36:00 +0200 Subject: [Opensim-dev] Legacy region XML support - Remove? In-Reply-To: <5348937F.80602@googlemail.com> References: <53473F73.20409@t-data.com> <5348937F.80602@googlemail.com> Message-ID: +1 the only grid I know that probably was using it was Reaction Grid, and they are no longer open so I also doubt anyone else is using it at this point either. On Sat, Apr 12, 2014 at 3:14 AM, Justin Clark-Casey < jjustincc at googlemail.com> wrote: > I don't see any problem with removing this - it's an extremely old format > that I'd be surprised if anybody still uses. > > > On 11/04/14 02:03, Melanie wrote: > >> Hi, >> >> the RegionInfo class supports an ancient form of XML, one that is >> based on attributes rather than tags. >> >> At this point, we believe no one uses this format anymore. Further, >> NINI offers another form of XML that is much more up to date and a >> better replacement for the ancient XML in any case. >> >> The affected installations would be those that use pre-0.6 >> configuration files (regions.xml) or use web loading. >> >> The old config files would need to be redone by hand in .ini format, >> and people who web-load would need to change the server scripts to >> provide the same data in the new format, which is not too hard a task. >> >> I propose to remove the support for the legacy format, which has >> last been updated in 2007 and has been unused for two major revisions. >> >> Thoughts are welcome. >> >> Melanie >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> . >> >> > > -- > Justin Clark-Casey (justincc) > OSVW Consulting > http://justincc.org > http://twitter.com/justincc > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- Michael Emory Cerquoni -------------- next part -------------- An HTML attachment was scrubbed... URL: From abitar.com at gmail.com Sat Apr 12 12:27:54 2014 From: abitar.com at gmail.com (David Saunders) Date: Sat, 12 Apr 2014 08:27:54 -0400 Subject: [Opensim-dev] Legacy region XML support - Remove? In-Reply-To: References: <53473F73.20409@t-data.com> <5348937F.80602@googlemail.com> Message-ID: Hey I Just dug though my web based region file, and its base on a single line XML format Would this be needed to updated with this proposal? On Sat, Apr 12, 2014 at 1:36 AM, Michael Emory Cerquoni < nebadon2025 at gmail.com> wrote: > +1 the only grid I know that probably was using it was Reaction Grid, and > they are no longer open so I also doubt anyone else is using it at this > point either. > > > On Sat, Apr 12, 2014 at 3:14 AM, Justin Clark-Casey < > jjustincc at googlemail.com> wrote: > >> I don't see any problem with removing this - it's an extremely old format >> that I'd be surprised if anybody still uses. >> >> >> On 11/04/14 02:03, Melanie wrote: >> >>> Hi, >>> >>> the RegionInfo class supports an ancient form of XML, one that is >>> based on attributes rather than tags. >>> >>> At this point, we believe no one uses this format anymore. Further, >>> NINI offers another form of XML that is much more up to date and a >>> better replacement for the ancient XML in any case. >>> >>> The affected installations would be those that use pre-0.6 >>> configuration files (regions.xml) or use web loading. >>> >>> The old config files would need to be redone by hand in .ini format, >>> and people who web-load would need to change the server scripts to >>> provide the same data in the new format, which is not too hard a task. >>> >>> I propose to remove the support for the legacy format, which has >>> last been updated in 2007 and has been unused for two major revisions. >>> >>> Thoughts are welcome. >>> >>> Melanie >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> . >>> >>> >> >> -- >> Justin Clark-Casey (justincc) >> OSVW Consulting >> http://justincc.org >> http://twitter.com/justincc >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > -- > Michael Emory Cerquoni > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From melanie at t-data.com Sat Apr 12 12:44:11 2014 From: melanie at t-data.com (Melanie) Date: Sat, 12 Apr 2014 14:44:11 +0200 Subject: [Opensim-dev] Legacy region XML support - Remove? In-Reply-To: References: <53473F73.20409@t-data.com> <5348937F.80602@googlemail.com> Message-ID: <5349351B.6050601@t-data.com> Yes - Melanie On 12/04/2014 14:27, David Saunders wrote: > Hey > I Just dug though my web based region file, and its base on a single > line XML format > > Would this be needed to updated with this proposal? > > > > > > > > On Sat, Apr 12, 2014 at 1:36 AM, Michael Emory Cerquoni < > nebadon2025 at gmail.com> wrote: > >> +1 the only grid I know that probably was using it was Reaction Grid, and >> they are no longer open so I also doubt anyone else is using it at this >> point either. >> >> >> On Sat, Apr 12, 2014 at 3:14 AM, Justin Clark-Casey < >> jjustincc at googlemail.com> wrote: >> >>> I don't see any problem with removing this - it's an extremely old format >>> that I'd be surprised if anybody still uses. >>> >>> >>> On 11/04/14 02:03, Melanie wrote: >>> >>>> Hi, >>>> >>>> the RegionInfo class supports an ancient form of XML, one that is >>>> based on attributes rather than tags. >>>> >>>> At this point, we believe no one uses this format anymore. Further, >>>> NINI offers another form of XML that is much more up to date and a >>>> better replacement for the ancient XML in any case. >>>> >>>> The affected installations would be those that use pre-0.6 >>>> configuration files (regions.xml) or use web loading. >>>> >>>> The old config files would need to be redone by hand in .ini format, >>>> and people who web-load would need to change the server scripts to >>>> provide the same data in the new format, which is not too hard a task. >>>> >>>> I propose to remove the support for the legacy format, which has >>>> last been updated in 2007 and has been unused for two major revisions. >>>> >>>> Thoughts are welcome. >>>> >>>> Melanie >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> Opensim-dev at lists.berlios.de >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> . >>>> >>>> >>> >>> -- >>> Justin Clark-Casey (justincc) >>> OSVW Consulting >>> http://justincc.org >>> http://twitter.com/justincc >>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >> >> >> -- >> Michael Emory Cerquoni >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev From jamesh at bluewallgroup.com Sat Apr 12 16:25:50 2014 From: jamesh at bluewallgroup.com (James Hughes) Date: Sat, 12 Apr 2014 12:25:50 -0400 Subject: [Opensim-dev] Legacy region XML support - Remove? In-Reply-To: <5347F15D.108@t-data.com> References: <53473F73.20409@t-data.com> <5347CDC1.7070102@rigutech.nl> <5347F15D.108@t-data.com> Message-ID: <5349690E.5060106@bluewallgroup.com> On 04/11/2014 09:42 AM, Melanie wrote: > That format needs to be changed. The old format is: > > > > The new format will be: > > >
> > >
> > +1 BlueWall From melanie at t-data.com Sat Apr 12 17:04:22 2014 From: melanie at t-data.com (Melanie) Date: Sat, 12 Apr 2014 19:04:22 +0200 Subject: [Opensim-dev] Legacy region XML support - Removed! In-Reply-To: <5349690E.5060106@bluewallgroup.com> References: <53473F73.20409@t-data.com> <5347CDC1.7070102@rigutech.nl> <5347F15D.108@t-data.com> <5349690E.5060106@bluewallgroup.com> Message-ID: <53497216.4090104@t-data.com> I have now removed support for the legacy format. The new format for XML, both for files and for web loading, is below:
Multiple "Section" statements can be placed within "Nini". - Melanie From fly.man.opensim at gmail.com Sun Apr 13 19:19:21 2014 From: fly.man.opensim at gmail.com (Fly Man) Date: Sun, 13 Apr 2014 21:19:21 +0200 Subject: [Opensim-dev] Legacy region XML support - Remove? In-Reply-To: <5348937F.80602@googlemail.com> References: <53473F73.20409@t-data.com> <5348937F.80602@googlemail.com> Message-ID: Some people still use the old format to load regions, makes it easier to load balance the region server when doing rolling restarts :) 2014-04-12 3:14 GMT+02:00 Justin Clark-Casey : > I don't see any problem with removing this - it's an extremely old format > that I'd be surprised if anybody still uses. > > > On 11/04/14 02:03, Melanie wrote: > >> Hi, >> >> the RegionInfo class supports an ancient form of XML, one that is >> based on attributes rather than tags. >> >> At this point, we believe no one uses this format anymore. Further, >> NINI offers another form of XML that is much more up to date and a >> better replacement for the ancient XML in any case. >> >> The affected installations would be those that use pre-0.6 >> configuration files (regions.xml) or use web loading. >> >> The old config files would need to be redone by hand in .ini format, >> and people who web-load would need to change the server scripts to >> provide the same data in the new format, which is not too hard a task. >> >> I propose to remove the support for the legacy format, which has >> last been updated in 2007 and has been unused for two major revisions. >> >> Thoughts are welcome. >> >> Melanie >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> . >> >> > > -- > Justin Clark-Casey (justincc) > OSVW Consulting > http://justincc.org > http://twitter.com/justincc > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.stallings at gmail.com Wed Apr 16 20:05:09 2014 From: james.stallings at gmail.com (James Stallings II) Date: Wed, 16 Apr 2014 15:05:09 -0500 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: <53472EA5.1060009@googlemail.com> References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> <20140410155900.GA3167@schumann> <5346C6EC.9080906@t-data.com> <5346C8AD.5000809@t-data.com> <5346CA90.90707@t-data.com> <53472EA5.1060009@googlemail.com> Message-ID: Follow-up: I never did get this issue resolved; indeed, it only got less predictable in it's manifestation. I was unable to satisfactorily lay the blame at opensim's feet though; there were many other issues, and literally nothing we did in the config files or with the binaries impacted opensim's operation either positively or negatively as far as this suite of parcel-related issues was concerned. At this point, we're shifting back to 'known good configurations' that really don't involve opensim directly (reinstall the boxes, shift to windows). I'm very interested to see whether that impacts the the problem at all. Will update again after the fact. Cheers James On Thu, Apr 10, 2014 at 6:52 PM, Justin Clark-Casey < jjustincc at googlemail.com> wrote: > Yeah, there are definitely issues with consistent enforcement of ban lines > on avatar movement. I remember looking at that some time ago but > unfortunately not a simple thing to properly fix. > > > On 10/04/14 18:02, James Stallings II wrote: > >> I think the default parcel is definitely an edge case. I created a small >> completely public parcel in the center of the >> region, and banned the test avatar outside it; everything works pretty >> much as one would hope, including the forceful >> banlines (it even displayed banlines, ugh). But, as designed. >> >> There was one problem, seems the av will get stuck to the banlines if >> s/he attempts crossing them; but a relog fixes it. >> In all honesty, not the very worst thing I ever had happen when hitting a >> banline. I'll see if I can figure out why, though. >> >> PS I was referring to those elves that left with Bilbo and Frodo for the >> Distant Shores ;) >> >> Cheers >> >> >> >> On Thu, Apr 10, 2014 at 11:45 AM, Melanie > melanie at t-data.com>> wrote: >> >> Why, the elves are still around! I know a couple. >> >> - Melanie >> >> On 10/04/2014 18:43, James Stallings II wrote: >> > Mel, cant get a grep on allow_f* anywhere in the source tree, >> looks like it >> > has gone the way of the elves >> > >> > >> > On Thu, Apr 10, 2014 at 11:37 AM, James Stallings II < >> > james.stallings at gmail.com > >> wrote: >> > >> >> I thought I recalled such a thing, been about as long since I >> looked at it >> >> ;) >> >> >> >> Thanks Mel >> >> >> >> >> >> James >> >> >> >> >> >> >> >> On Thu, Apr 10, 2014 at 11:37 AM, Melanie > melanie at t-data.com>> wrote: >> >> >> >>> Yes. allow_forceful_banlines, I believe. Long time since I >> looked at it. >> >>> >> >>> - Melanie >> >>> >> >>> On 10/04/2014 18:33, James Stallings II wrote: >> >>> > Quick question (related) is there a configuration point I'm >> missing that >> >>> > enables 'forceful bans'? >> >>> > >> >>> > >> >>> > >> >>> > On Thu, Apr 10, 2014 at 11:30 AM, James Stallings II < >> >>> > james.stallings at gmail.com > >> wrote: >> >>> > >> >>> >> I kinder suspected something to that effect. It goes without >> saying >> >>> that a >> >>> >> lot occurs during the login process than is immediately >> apparent when >> >>> one >> >>> >> sits and watches the consoles. >> >>> >> >> >>> >> Right now I'm leaning towards the previously-mentioned edge >> case. >> >>> >> >> >>> >> >> >>> >> On Thu, Apr 10, 2014 at 11:29 AM, Melanie > melanie at t-data.com>> wrote: >> >>> >> >> >>> >>> The QueryAccess is a pre-authorization. So the double call is >> >>> >>> intentional and unavoidable. >> >>> >>> >> >>> >>> - Melanie >> >>> >>> >> >>> >>> On 10/04/2014 18:14, James Stallings II wrote: >> >>> >>> > It would seem that the two invocations of the >> TestLandRestrictions >> >>> >>> method >> >>> >>> > in Scene occur in each of NewUserConnection and >> >>> >>> > QueryAccess. EventManagerOnAvatarEnteringNewParcel is, >> fairly >> >>> obviously, >> >>> >>> > and event callback method; at this point I don't have but >> a guess >> >>> where >> >>> >>> > this might be called excepting from >> >>> >>> > within EventManagerOnSignificantClientMovement. >> >>> >>> > >> >>> >>> > I'd like to think that the two calls to >> TestLandRestrictions in >> >>> Scene >> >>> >>> might >> >>> >>> > be reduced to one; but I'm not yet convinced it is the way >> to go. >> >>> >>> > >> >>> >>> > More to follow. >> >>> >>> > >> >>> >>> > Cheers >> >>> >>> > >> >>> >>> > >> >>> >>> > >> >>> >>> > On Thu, Apr 10, 2014 at 10:59 AM, Robert A. Knop Jr. < >> >>> rknop at pobox.com >> >> >>> >>> >wrote: >> >>> >>> > >> >>> >>> >> On Thu, Apr 10, 2014 at 10:25:17AM -0500, James Stallings >> II wrote: >> >>> >>> >> > And FWIW, last I hear adding log statements to code is >> a valid >> >>> >>> >> > tried and true debugging method. >> >>> >>> >> >> >>> >>> >> I wish to subscribe all of my students in my programming >> class to >> >>> your >> >>> >>> >> newsletter. >> >>> >>> >> >> >>> >>> >> (The number of times I told them to print stuff to figure >> out >> >>> where the >> >>> >>> >> code was, and the number of times I told them to print in >> more >> >>> places, >> >>> >>> >> was phenomenal. They got tired of hearing me say it, but >> somehow >> >>> still >> >>> >>> >> needed to hear it.) >> >>> >>> >> >> >>> >>> >> (They often needed similar guidance in figuring out how >> to use >> >>> >>> >> breakpoints in debuggers.) >> >>> >>> >> >> >>> >>> >> -Rob >> >>> >>> >> >> >>> >>> >> -- >> >>> >>> >> --Rob Knop >> >>> >>> >> E-mail: rknop at pobox.com >> >> >>> >>> >> Home Page: http://www.pobox.com/~rknop/ >> >>> >>> >> Blog: http://www.galacticinteractions.org/ >> >>> >>> >> >> >>> >>> >> _______________________________________________ >> >>> >>> >> Opensim-dev mailing list >> >>> >>> >> Opensim-dev at lists.berlios.de > berlios.de> >> >> >>> >>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >>> >>> >> >> >>> >>> > >> >>> >>> > >> >>> >>> > >> >>> >>> > >> >>> >>> > >> >>> >>> > _______________________________________________ >> >>> >>> > Opensim-dev mailing list >> >>> >>> > Opensim-dev at lists.berlios.de > berlios.de> >> >> >>> >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev >> >>> >>> _______________________________________________ >> >>> >>> Opensim-dev mailing list >> >>> >>> Opensim-dev at lists.berlios.de > berlios.de> >> >> >>> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >>> >>> >> >>> >> >> >>> >> >> >>> >> >> >>> >> -- >> >>> >> =================================== >> >>> >> http://osgrid.org/ >> >>> >> http://simhost.com >> >>> >> http://twitter.com/jstallings2 >> >>> >> >> >>> >> >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > _______________________________________________ >> >>> > Opensim-dev mailing list >> >>> > Opensim-dev at lists.berlios.de > berlios.de> >> >> >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev >> >>> _______________________________________________ >> >>> Opensim-dev mailing list >> >>> Opensim-dev at lists.berlios.de > berlios.de> >> >> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >>> >> >> >> >> >> >> >> >> -- >> >> =================================== >> >> http://osgrid.org/ >> >> http://simhost.com >> >> http://twitter.com/jstallings2 >> >> >> >> >> > >> > >> > >> > >> > _______________________________________________ >> > Opensim-dev mailing list >> > Opensim-dev at lists.berlios.de >> >> > https://lists.berlios.de/mailman/listinfo/opensim-dev >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> >> >> >> -- >> =================================== >> http://osgrid.org/ >> http://simhost.com >> http://twitter.com/jstallings2 >> >> >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> > > -- > Justin Clark-Casey (justincc) > OSVW Consulting > http://justincc.org > http://twitter.com/justincc > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From orenh at kitely.com Fri Apr 18 08:44:29 2014 From: orenh at kitely.com (Oren Hurvitz) Date: Fri, 18 Apr 2014 11:44:29 +0300 Subject: [Opensim-dev] Error detection when storing an asset Message-ID: I have found that when OpenSim tries to store an asset using AssetServicesConnector, it doesn't handle failures well. There are several problems in AssetServicesConnector.Store(), and some of them seem to be based on historical considerations that may no longer be relevant, so I'd like to see if anyone knows about these issues before pushing a change. AssetServicesConnector.Store() uses SynchronousRestObjectRequester to send the request. The first problem is that SynchronousRestObjectRequester.MakeRequest() hides exceptions and just returns null. This is a mistake: MakeRequest() should propagate exceptions, so that callers will know that an error occurred. Store() already catches these exceptions (as it should), so this won't make a big difference in our case. But of course, this change in behavior to MakeRequest() may affect other places in the code as well. It's better to fail-fast when errors occur, and not hide them, because doing so makes the errors much harder to diagnose once they become apparent. This brings me to the next problem... The second problem is that AssetServicesConnector.Store() compares the return value from MakeRequest to string.Empty, but in fact the return value that is returned in case of error is null. So it mistakenly treats 'null' as a valid Asset ID, which causes it to cache the asset. This can cause the operation to appear to have succeeded for a while, since OpenSim will have the asset available, but the moment the asset is loaded from the asset server "the jig is up" and the asset will be missing. This can explain many problems people have had with disappearing assets. The third problem is a comment found in this method, which says that a return value of 'null' is considered to be success because of "old asset servers that don't send any reply back". That's a really old comment (from 2009). Can I assume that we no longer need to support such servers and we can treat 'null' as the error value that it is? Oren -------------- next part -------------- An HTML attachment was scrubbed... URL: From melanie at t-data.com Fri Apr 18 09:39:42 2014 From: melanie at t-data.com (Melanie) Date: Fri, 18 Apr 2014 11:39:42 +0200 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: References: Message-ID: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> Hi Oren, I disagree about propagating exceptions. To the caller, asset calls are opaque and cannot fail. There are too many places where exceptions would cause issues and the focus has always been on keeping the sim up and running at almost any cost. That said, no old asset servers (UGAIM) exist anymore, so the comment and the bad handling of null returns should be fixed. I would like to see assets being cached on asset server failure, but then retried using a disk based queue with exponential back-off. Allowing an asset to fail storing is better than having the sim crash, but of course storing it as soon as the asset server is back is preferable. We have something similar, but memory based, for Avination and it has served us well. I believe even our code may still have the bad return calue checking in it. I will see about putting our asset retry code into core as a starting point, then the rough edges can be smoothed and disk based queueing introduced so that assets can be retried even across a simulator restart. - Melanie On 18 Apr 2014, at 10:44, Oren Hurvitz wrote: I have found that when OpenSim tries to store an asset using AssetServicesConnector, it doesn't handle failures well. There are several problems in AssetServicesConnector.Store(), and some of them seem to be based on historical considerations that may no longer be relevant, so I'd like to see if anyone knows about these issues before pushing a change. AssetServicesConnector.Store() uses SynchronousRestObjectRequester to send the request. The first problem is that SynchronousRestObjectRequester.MakeRequest() hides exceptions and just returns null. This is a mistake: MakeRequest() should propagate exceptions, so that callers will know that an error occurred. Store() already catches these exceptions (as it should), so this won't make a big difference in our case. But of course, this change in behavior to MakeRequest() may affect other places in the code as well. It's better to fail-fast when errors occur, and not hide them, because doing so makes the errors much harder to diagnose once they become apparent. This brings me to the next problem... The second problem is that AssetServicesConnector.Store() compares the return value from MakeRequest to string.Empty, but in fact the return value that is returned in case of error is null. So it mistakenly treats 'null' as a valid Asset ID, which causes it to cache the asset. This can cause the operation to appear to have succeeded for a while, since OpenSim will have the asset available, but the moment the asset is loaded from the asset server "the jig is up" and the asset will be missing. This can explain many problems people have had with disappearing assets. The third problem is a comment found in this method, which says that a return value of 'null' is considered to be success because of "old asset servers that don't send any reply back". That's a really old comment (from 2009). Can I assume that we no longer need to support such servers and we can treat 'null' as the error value that it is? Oren _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev From orenh at kitely.com Fri Apr 18 11:05:45 2014 From: orenh at kitely.com (Oren Hurvitz) Date: Fri, 18 Apr 2014 04:05:45 -0700 (PDT) Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> Message-ID: <1397819145848-7579225.post@n2.nabble.com> Regarding the hiding of exceptions: to be clear, I was already bitten by this behavior; that's why I started to investigate how assets are stored. I have therefore already changed Kitely's version of OpenSim to propagate exceptions, and the question is whether other people would like me to contribute this change. If anyone has an opinion then please reply. Regarding your suggestion to save assets to local disk and retry them later: this is basically what a persistent message queue does. If you're going to go that route then it would be best to add a real message queue rather than a home-grown one. I would LOVE it if OpenSim used a message queue for communications, as it would allow ripping out thousands of lines of homemade communications code, and would be faster and more reliable to boot. But that's a bigger issue and I'll put it aside for now. In this particular case, using a persistent message queue isn't be the right solution: the right solution is to report failures immediately. Otherwise you'd get weird behavior such as a user who thinks they've successfully worn a piece of clothing, but when they teleport to another region it disappears because the other region can't load the asset (because it was never saved). To prevent these problems you need to fail-fast, and tell the user immediately when a problem happens. This doesn't mean to crash the sim; I strongly doubt any asset failure would cause that, it would just fail the specific packet or message that is currently being handled, as it should. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Error-detection-when-storing-an-asset-tp7579223p7579225.html Sent from the opensim-dev mailing list archive at Nabble.com. From mike.chase at alternatemetaverse.com Fri Apr 18 11:28:17 2014 From: mike.chase at alternatemetaverse.com (Mike Chase) Date: Fri, 18 Apr 2014 07:28:17 -0400 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: <1397819145848-7579225.post@n2.nabble.com> References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> Message-ID: <030a01cf5af9$4d8126e0$e88374a0$@alternatemetaverse.com> I'm inclined to agree with Oren. Asset Writes could fail for a variety of reasons and there are lots of use cases where you need to know the asset is on disk. I think propagating exceptions is the more sound approach IMO. I also agree re: the custom comms vs a persistent queue mechanism but I don't want to derail this topic. That can wait for another day. Mike -----Original Message----- From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Oren Hurvitz Sent: Friday, April 18, 2014 7:06 AM To: opensim-dev at lists.berlios.de Subject: Re: [Opensim-dev] Error detection when storing an asset Regarding the hiding of exceptions: to be clear, I was already bitten by this behavior; that's why I started to investigate how assets are stored. I have therefore already changed Kitely's version of OpenSim to propagate exceptions, and the question is whether other people would like me to contribute this change. If anyone has an opinion then please reply. Regarding your suggestion to save assets to local disk and retry them later: this is basically what a persistent message queue does. If you're going to go that route then it would be best to add a real message queue rather than a home-grown one. I would LOVE it if OpenSim used a message queue for communications, as it would allow ripping out thousands of lines of homemade communications code, and would be faster and more reliable to boot. But that's a bigger issue and I'll put it aside for now. In this particular case, using a persistent message queue isn't be the right solution: the right solution is to report failures immediately. Otherwise you'd get weird behavior such as a user who thinks they've successfully worn a piece of clothing, but when they teleport to another region it disappears because the other region can't load the asset (because it was never saved). To prevent these problems you need to fail-fast, and tell the user immediately when a problem happens. This doesn't mean to crash the sim; I strongly doubt any asset failure would cause that, it would just fail the specific packet or message that is currently being handled, as it should. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Error-detection-when-storing-an-ass et-tp7579223p7579225.html Sent from the opensim-dev mailing list archive at Nabble.com. _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev From melanie at t-data.com Fri Apr 18 15:23:18 2014 From: melanie at t-data.com (Melanie) Date: Fri, 18 Apr 2014 17:23:18 +0200 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: <1397819145848-7579225.post@n2.nabble.com> References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> Message-ID: In most cases there is no viable failure path that does not detrimentally affect user experience. The viewer is unable to handle asset upload failure gracefully and transparently to the user. As far as messge queues go, I have in-depth knowledge of MQ Series, IBM's message queue service. I agree that such a framework would be beneficial to many communications tasks in OpenSim, but that is, as you say, a matter for another day. The asset subsystem, however, should present an error-free interface to the upper layers, as there is much code that depends on assets never failing and provides no usable error path. Our retry solution combines a good user experience without user visible error messages with a sound subsystem that can tolerate transient erros like asset server failovers, net glitches or temporary overload conditions. Asset writing, btw, is not related to wearing clothing as baked textures do not go to the asset server, but to the XBakes server. In standalones, they are not persisted but are transferred from one region to another. Your obeservation about message queueing is a good one, I may spend a few cycles to see if an appropriately licensed implementation in C# exists. - Melanie On 18 Apr 2014, at 13:05, Oren Hurvitz wrote: Regarding the hiding of exceptions: to be clear, I was already bitten by this behavior; that's why I started to investigate how assets are stored. I have therefore already changed Kitely's version of OpenSim to propagate exceptions, and the question is whether other people would like me to contribute this change. If anyone has an opinion then please reply. Regarding your suggestion to save assets to local disk and retry them later: this is basically what a persistent message queue does. If you're going to go that route then it would be best to add a real message queue rather than a home-grown one. I would LOVE it if OpenSim used a message queue for communications, as it would allow ripping out thousands of lines of homemade communications code, and would be faster and more reliable to boot. But that's a bigger issue and I'll put it aside for now. In this particular case, using a persistent message queue isn't be the right solution: the right solution is to report failures immediately. Otherwise you'd get weird behavior such as a user who thinks they've successfully worn a piece of clothing, but when they teleport to another region it disappears because the other region can't load the asset (because it was never saved). To prevent these problems you need to fail-fast, and tell the user immediately when a problem happens. This doesn't mean to crash the sim; I strongly doubt any asset failure would cause that, it would just fail the specific packet or message that is currently being handled, as it should. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Error-detection-when-storing-an-asset-tp7579223p7579225.html Sent from the opensim-dev mailing list archive at Nabble.com. _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev From ste at smxy.org Fri Apr 18 17:21:46 2014 From: ste at smxy.org (Shaun T. Erickson) Date: Fri, 18 Apr 2014 13:21:46 -0400 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> Message-ID: <53515F2A.3050600@smxy.org> There's also the free ActiveMQ. On 4/18/14, 11:23 AM, Melanie wrote: > MQ Series, IBM's message queue service From mike.chase at alternatemetaverse.com Fri Apr 18 19:13:44 2014 From: mike.chase at alternatemetaverse.com (Mike Chase) Date: Fri, 18 Apr 2014 15:13:44 -0400 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: <53515F2A.3050600@smxy.org> References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> <53515F2A.3050600@smxy.org> Message-ID: <03c701cf5b3a$52527480$f6f75d80$@alternatemetaverse.com> Or RabbitMQ... Or even ZeroMQ if an external MQ service is deemed too heavy. Mike -----Original Message----- From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Shaun T. Erickson Sent: Friday, April 18, 2014 1:22 PM To: opensim-dev at lists.berlios.de Subject: Re: [Opensim-dev] Error detection when storing an asset There's also the free ActiveMQ. On 4/18/14, 11:23 AM, Melanie wrote: > MQ Series, IBM's message queue service _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev From melanie at t-data.com Fri Apr 18 19:40:56 2014 From: melanie at t-data.com (Melanie) Date: Fri, 18 Apr 2014 21:40:56 +0200 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: <030a01cf5af9$4d8126e0$e88374a0$@alternatemetaverse.com> References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> <030a01cf5af9$4d8126e0$e88374a0$@alternatemetaverse.com> Message-ID: <53517FC8.2@t-data.com> Name one valid use case where current OpenSim is able to handle such an exception gracefully, e.g. without user-visible error. - Melanie On 18/04/2014 13:28, Mike Chase wrote: > I'm inclined to agree with Oren. Asset Writes could fail for a variety of > reasons and there are lots of use cases where you need to know the asset is > on disk. I think propagating exceptions is the more sound approach IMO. > > I also agree re: the custom comms vs a persistent queue mechanism but I > don't want to derail this topic. That can wait for another day. > > Mike > > -----Original Message----- > From: opensim-dev-bounces at lists.berlios.de > [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Oren Hurvitz > Sent: Friday, April 18, 2014 7:06 AM > To: opensim-dev at lists.berlios.de > Subject: Re: [Opensim-dev] Error detection when storing an asset > > Regarding the hiding of exceptions: to be clear, I was already bitten by > this behavior; that's why I started to investigate how assets are stored. I > have therefore already changed Kitely's version of OpenSim to propagate > exceptions, and the question is whether other people would like me to > contribute this change. If anyone has an opinion then please reply. > > Regarding your suggestion to save assets to local disk and retry them later: > this is basically what a persistent message queue does. If you're going to > go that route then it would be best to add a real message queue rather than > a home-grown one. I would LOVE it if OpenSim used a message queue for > communications, as it would allow ripping out thousands of lines of homemade > communications code, and would be faster and more reliable to boot. But > that's a bigger issue and I'll put it aside for now. > > In this particular case, using a persistent message queue isn't be the right > solution: the right solution is to report failures immediately. Otherwise > you'd get weird behavior such as a user who thinks they've successfully worn > a piece of clothing, but when they teleport to another region it disappears > because the other region can't load the asset (because it was never saved). > To prevent these problems you need to fail-fast, and tell the user > immediately when a problem happens. This doesn't mean to crash the sim; I > strongly doubt any asset failure would cause that, it would just fail the > specific packet or message that is currently being handled, as it should. > > > > -- > View this message in context: > http://opensim-dev.2196679.n2.nabble.com/Error-detection-when-storing-an-ass > et-tp7579223p7579225.html > Sent from the opensim-dev mailing list archive at Nabble.com. > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > From orenh at kitely.com Fri Apr 18 20:56:54 2014 From: orenh at kitely.com (Oren Hurvitz) Date: Fri, 18 Apr 2014 23:56:54 +0300 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: <53517FC8.2@t-data.com> References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> <030a01cf5af9$4d8126e0$e88374a0$@alternatemetaverse.com> <53517FC8.2@t-data.com> Message-ID: There seems to be a misunderstanding here. We're talking about a case where the operation has FAILED. The only question is whether to pretend that it succeeded, so that the user will find out that it failed later, to their surprise, or to report failure immediately. Obviously it's better to report failure immediately. On Fri, Apr 18, 2014 at 10:40 PM, Melanie wrote: > Name one valid use case where current OpenSim is able to handle such > an exception gracefully, e.g. without user-visible error. > > - Melanie > > On 18/04/2014 13:28, Mike Chase wrote: > > I'm inclined to agree with Oren. Asset Writes could fail for a variety > of > > reasons and there are lots of use cases where you need to know the asset > is > > on disk. I think propagating exceptions is the more sound approach IMO. > > > > I also agree re: the custom comms vs a persistent queue mechanism but I > > don't want to derail this topic. That can wait for another day. > > > > Mike > > > > -----Original Message----- > > From: opensim-dev-bounces at lists.berlios.de > > [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Oren Hurvitz > > Sent: Friday, April 18, 2014 7:06 AM > > To: opensim-dev at lists.berlios.de > > Subject: Re: [Opensim-dev] Error detection when storing an asset > > > > Regarding the hiding of exceptions: to be clear, I was already bitten by > > this behavior; that's why I started to investigate how assets are > stored. I > > have therefore already changed Kitely's version of OpenSim to propagate > > exceptions, and the question is whether other people would like me to > > contribute this change. If anyone has an opinion then please reply. > > > > Regarding your suggestion to save assets to local disk and retry them > later: > > this is basically what a persistent message queue does. If you're going > to > > go that route then it would be best to add a real message queue rather > than > > a home-grown one. I would LOVE it if OpenSim used a message queue for > > communications, as it would allow ripping out thousands of lines of > homemade > > communications code, and would be faster and more reliable to boot. But > > that's a bigger issue and I'll put it aside for now. > > > > In this particular case, using a persistent message queue isn't be the > right > > solution: the right solution is to report failures immediately. Otherwise > > you'd get weird behavior such as a user who thinks they've successfully > worn > > a piece of clothing, but when they teleport to another region it > disappears > > because the other region can't load the asset (because it was never > saved). > > To prevent these problems you need to fail-fast, and tell the user > > immediately when a problem happens. This doesn't mean to crash the sim; I > > strongly doubt any asset failure would cause that, it would just fail the > > specific packet or message that is currently being handled, as it should. > > > > > > > > -- > > View this message in context: > > > http://opensim-dev.2196679.n2.nabble.com/Error-detection-when-storing-an-ass > > et-tp7579223p7579225.html > > Sent from the opensim-dev mailing list archive at Nabble.com. > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- Oren Hurvitz VP R&D Kitely Ltd. Email: orenh at kitely.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From orenh at kitely.com Fri Apr 18 21:23:47 2014 From: orenh at kitely.com (Oren Hurvitz) Date: Sat, 19 Apr 2014 00:23:47 +0300 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: <03c701cf5b3a$52527480$f6f75d80$@alternatemetaverse.com> References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> <53515F2A.3050600@smxy.org> <03c701cf5b3a$52527480$f6f75d80$@alternatemetaverse.com> Message-ID: There are several popular open-source message queues that we could use. If we're going to do that then we need to have an open discussion about the pros and cons of the various packages in order to decide which one to use. In the past I've used JBoss Messaging, but that's been discontinued so it isn't relevant. A big decision will be whether to use a message queue that's completely embedded in OpenSim, or one that runs standalone. OK, I've already said too much; I'm hijacking my own thread... On Fri, Apr 18, 2014 at 10:13 PM, Mike Chase < mike.chase at alternatemetaverse.com> wrote: > Or RabbitMQ... Or even ZeroMQ if an external MQ service is deemed too > heavy. > > Mike > > -----Original Message----- > From: opensim-dev-bounces at lists.berlios.de > [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Shaun T. > Erickson > Sent: Friday, April 18, 2014 1:22 PM > To: opensim-dev at lists.berlios.de > Subject: Re: [Opensim-dev] Error detection when storing an asset > > There's also the free ActiveMQ. > > On 4/18/14, 11:23 AM, Melanie wrote: > > MQ Series, IBM's message queue service > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- Oren Hurvitz VP R&D Kitely Ltd. Email: orenh at kitely.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From melanie at t-data.com Fri Apr 18 21:43:31 2014 From: melanie at t-data.com (Melanie) Date: Fri, 18 Apr 2014 23:43:31 +0200 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> <030a01cf5af9$4d8126e0$e88374a0$@alternatemetaverse.com> <53517FC8.2@t-data.com> Message-ID: <53519C83.60306@t-data.com> The point is no NOT let it fail. Asset storing never fails permanently if it's retried until successful. The upper layers (all the way to the viewer) are not equipped to handle an asset storing failure. Propagating the exception would just annoy the user with needless messages. Since asset servers can be "gone" for a while, for instance when there is a net failure, there is no way to give it a timeout, either. A sim in OSGrid, if it gets disconnected, could run on locally cached assets and manage to reconnect after 20 minutes and simply upload all new assets since then. Screaming "failure" at the user is pointless in such a scenario. - Melanie On 18/04/2014 22:56, Oren Hurvitz wrote: > There seems to be a misunderstanding here. We're talking about a case where > the operation has FAILED. The only question is whether to pretend that it > succeeded, so that the user will find out that it failed later, to their > surprise, or to report failure immediately. Obviously it's better to report > failure immediately. > > > > On Fri, Apr 18, 2014 at 10:40 PM, Melanie wrote: > >> Name one valid use case where current OpenSim is able to handle such >> an exception gracefully, e.g. without user-visible error. >> >> - Melanie >> >> On 18/04/2014 13:28, Mike Chase wrote: >> > I'm inclined to agree with Oren. Asset Writes could fail for a variety >> of >> > reasons and there are lots of use cases where you need to know the asset >> is >> > on disk. I think propagating exceptions is the more sound approach IMO. >> > >> > I also agree re: the custom comms vs a persistent queue mechanism but I >> > don't want to derail this topic. That can wait for another day. >> > >> > Mike >> > >> > -----Original Message----- >> > From: opensim-dev-bounces at lists.berlios.de >> > [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Oren Hurvitz >> > Sent: Friday, April 18, 2014 7:06 AM >> > To: opensim-dev at lists.berlios.de >> > Subject: Re: [Opensim-dev] Error detection when storing an asset >> > >> > Regarding the hiding of exceptions: to be clear, I was already bitten by >> > this behavior; that's why I started to investigate how assets are >> stored. I >> > have therefore already changed Kitely's version of OpenSim to propagate >> > exceptions, and the question is whether other people would like me to >> > contribute this change. If anyone has an opinion then please reply. >> > >> > Regarding your suggestion to save assets to local disk and retry them >> later: >> > this is basically what a persistent message queue does. If you're going >> to >> > go that route then it would be best to add a real message queue rather >> than >> > a home-grown one. I would LOVE it if OpenSim used a message queue for >> > communications, as it would allow ripping out thousands of lines of >> homemade >> > communications code, and would be faster and more reliable to boot. But >> > that's a bigger issue and I'll put it aside for now. >> > >> > In this particular case, using a persistent message queue isn't be the >> right >> > solution: the right solution is to report failures immediately. Otherwise >> > you'd get weird behavior such as a user who thinks they've successfully >> worn >> > a piece of clothing, but when they teleport to another region it >> disappears >> > because the other region can't load the asset (because it was never >> saved). >> > To prevent these problems you need to fail-fast, and tell the user >> > immediately when a problem happens. This doesn't mean to crash the sim; I >> > strongly doubt any asset failure would cause that, it would just fail the >> > specific packet or message that is currently being handled, as it should. >> > >> > >> > >> > -- >> > View this message in context: >> > >> http://opensim-dev.2196679.n2.nabble.com/Error-detection-when-storing-an-ass >> > et-tp7579223p7579225.html >> > Sent from the opensim-dev mailing list archive at Nabble.com. >> > _______________________________________________ >> > Opensim-dev mailing list >> > Opensim-dev at lists.berlios.de >> > https://lists.berlios.de/mailman/listinfo/opensim-dev >> > >> > _______________________________________________ >> > Opensim-dev mailing list >> > Opensim-dev at lists.berlios.de >> > https://lists.berlios.de/mailman/listinfo/opensim-dev >> > >> > >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev From orenh at kitely.com Fri Apr 18 22:12:07 2014 From: orenh at kitely.com (Oren Hurvitz) Date: Sat, 19 Apr 2014 01:12:07 +0300 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: <53519C83.60306@t-data.com> References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> <030a01cf5af9$4d8126e0$e88374a0$@alternatemetaverse.com> <53517FC8.2@t-data.com> <53519C83.60306@t-data.com> Message-ID: I feel that we've transcended from this mortal coil into heavenly spheres. Such powerful realms require poetry to comprehend, so I must quote from the poem "Eloisa to Abelard": "How happy is the blameless vestal's lot! The world forgetting, by the world forgot. Eternal sunshine of the spotless mind! Each pray'r accepted, and each wish resign'd;" To deny failure is to deny reality. On Sat, Apr 19, 2014 at 12:43 AM, Melanie wrote: > The point is no NOT let it fail. Asset storing never fails > permanently if it's retried until successful. The upper layers (all > the way to the viewer) are not equipped to handle an asset storing > failure. Propagating the exception would just annoy the user with > needless messages. Since asset servers can be "gone" for a while, > for instance when there is a net failure, there is no way to give it > a timeout, either. A sim in OSGrid, if it gets disconnected, could > run on locally cached assets and manage to reconnect after 20 > minutes and simply upload all new assets since then. Screaming > "failure" at the user is pointless in such a scenario. > > - Melanie > > On 18/04/2014 22:56, Oren Hurvitz wrote: > > There seems to be a misunderstanding here. We're talking about a case > where > > the operation has FAILED. The only question is whether to pretend that it > > succeeded, so that the user will find out that it failed later, to their > > surprise, or to report failure immediately. Obviously it's better to > report > > failure immediately. > > > > > > > > On Fri, Apr 18, 2014 at 10:40 PM, Melanie wrote: > > > >> Name one valid use case where current OpenSim is able to handle such > >> an exception gracefully, e.g. without user-visible error. > >> > >> - Melanie > >> > >> On 18/04/2014 13:28, Mike Chase wrote: > >> > I'm inclined to agree with Oren. Asset Writes could fail for a > variety > >> of > >> > reasons and there are lots of use cases where you need to know the > asset > >> is > >> > on disk. I think propagating exceptions is the more sound approach > IMO. > >> > > >> > I also agree re: the custom comms vs a persistent queue mechanism but > I > >> > don't want to derail this topic. That can wait for another day. > >> > > >> > Mike > >> > > >> > -----Original Message----- > >> > From: opensim-dev-bounces at lists.berlios.de > >> > [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Oren > Hurvitz > >> > Sent: Friday, April 18, 2014 7:06 AM > >> > To: opensim-dev at lists.berlios.de > >> > Subject: Re: [Opensim-dev] Error detection when storing an asset > >> > > >> > Regarding the hiding of exceptions: to be clear, I was already bitten > by > >> > this behavior; that's why I started to investigate how assets are > >> stored. I > >> > have therefore already changed Kitely's version of OpenSim to > propagate > >> > exceptions, and the question is whether other people would like me to > >> > contribute this change. If anyone has an opinion then please reply. > >> > > >> > Regarding your suggestion to save assets to local disk and retry them > >> later: > >> > this is basically what a persistent message queue does. If you're > going > >> to > >> > go that route then it would be best to add a real message queue rather > >> than > >> > a home-grown one. I would LOVE it if OpenSim used a message queue for > >> > communications, as it would allow ripping out thousands of lines of > >> homemade > >> > communications code, and would be faster and more reliable to boot. > But > >> > that's a bigger issue and I'll put it aside for now. > >> > > >> > In this particular case, using a persistent message queue isn't be the > >> right > >> > solution: the right solution is to report failures immediately. > Otherwise > >> > you'd get weird behavior such as a user who thinks they've > successfully > >> worn > >> > a piece of clothing, but when they teleport to another region it > >> disappears > >> > because the other region can't load the asset (because it was never > >> saved). > >> > To prevent these problems you need to fail-fast, and tell the user > >> > immediately when a problem happens. This doesn't mean to crash the > sim; I > >> > strongly doubt any asset failure would cause that, it would just fail > the > >> > specific packet or message that is currently being handled, as it > should. > >> > > >> > > >> > > >> > -- > >> > View this message in context: > >> > > >> > http://opensim-dev.2196679.n2.nabble.com/Error-detection-when-storing-an-ass > >> > et-tp7579223p7579225.html > >> > Sent from the opensim-dev mailing list archive at Nabble.com. > >> > _______________________________________________ > >> > Opensim-dev mailing list > >> > Opensim-dev at lists.berlios.de > >> > https://lists.berlios.de/mailman/listinfo/opensim-dev > >> > > >> > _______________________________________________ > >> > Opensim-dev mailing list > >> > Opensim-dev at lists.berlios.de > >> > https://lists.berlios.de/mailman/listinfo/opensim-dev > >> > > >> > > >> _______________________________________________ > >> Opensim-dev mailing list > >> Opensim-dev at lists.berlios.de > >> https://lists.berlios.de/mailman/listinfo/opensim-dev > >> > > > > > > > > > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- Oren Hurvitz VP R&D Kitely Ltd. Email: orenh at kitely.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From diva at metaverseink.com Fri Apr 18 22:23:47 2014 From: diva at metaverseink.com (Diva Canto) Date: Fri, 18 Apr 2014 15:23:47 -0700 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> <030a01cf5af9$4d8126e0$e88374a0$@alternatemetaverse.com> <53517FC8.2@t-data.com> <53519C83.60306@t-data.com> Message-ID: <5351A5F3.700@metaverseink.com> There are, nevertheless, different approaches to failure, which sort of correlate with approaches to life in general too :-) - constructivist (if life gives you lemons, make a lemonade) - tantrum (complain loudly and as often as you can) - passive-aggressive (don't say anything when it happens, but make a scene later) - ... Melanie's suggested approach is more along the constructivist side. Tantrums are annoying. On 4/18/2014 3:12 PM, Oren Hurvitz wrote: > I feel that we've transcended from this mortal coil into heavenly > spheres. Such powerful realms require poetry to comprehend, so I must > quote from the poem "Eloisa to Abelard": > > "How happy is the blameless vestal's lot! > The world forgetting, by the world forgot. > Eternal sunshine of the spotless mind! > Each pray'r accepted, and each wish resign'd;" > > To deny failure is to deny reality. > > > > > On Sat, Apr 19, 2014 at 12:43 AM, Melanie > wrote: > > The point is no NOT let it fail. Asset storing never fails > permanently if it's retried until successful. The upper layers (all > the way to the viewer) are not equipped to handle an asset storing > failure. Propagating the exception would just annoy the user with > needless messages. Since asset servers can be "gone" for a while, > for instance when there is a net failure, there is no way to give it > a timeout, either. A sim in OSGrid, if it gets disconnected, could > run on locally cached assets and manage to reconnect after 20 > minutes and simply upload all new assets since then. Screaming > "failure" at the user is pointless in such a scenario. > > - Melanie > > On 18/04/2014 22:56, Oren Hurvitz wrote: > > There seems to be a misunderstanding here. We're talking about a > case where > > the operation has FAILED. The only question is whether to > pretend that it > > succeeded, so that the user will find out that it failed later, > to their > > surprise, or to report failure immediately. Obviously it's > better to report > > failure immediately. > > > > > > > > On Fri, Apr 18, 2014 at 10:40 PM, Melanie > wrote: > > > >> Name one valid use case where current OpenSim is able to handle > such > >> an exception gracefully, e.g. without user-visible error. > >> > >> - Melanie > >> > >> On 18/04/2014 13:28, Mike Chase wrote: > >> > I'm inclined to agree with Oren. Asset Writes could fail for > a variety > >> of > >> > reasons and there are lots of use cases where you need to > know the asset > >> is > >> > on disk. I think propagating exceptions is the more sound > approach IMO. > >> > > >> > I also agree re: the custom comms vs a persistent queue > mechanism but I > >> > don't want to derail this topic. That can wait for another day. > >> > > >> > Mike > >> > > >> > -----Original Message----- > >> > From: opensim-dev-bounces at lists.berlios.de > > >> > [mailto:opensim-dev-bounces at lists.berlios.de > ] On Behalf Of Oren > Hurvitz > >> > Sent: Friday, April 18, 2014 7:06 AM > >> > To: opensim-dev at lists.berlios.de > > >> > Subject: Re: [Opensim-dev] Error detection when storing an asset > >> > > >> > Regarding the hiding of exceptions: to be clear, I was > already bitten by > >> > this behavior; that's why I started to investigate how assets are > >> stored. I > >> > have therefore already changed Kitely's version of OpenSim to > propagate > >> > exceptions, and the question is whether other people would > like me to > >> > contribute this change. If anyone has an opinion then please > reply. > >> > > >> > Regarding your suggestion to save assets to local disk and > retry them > >> later: > >> > this is basically what a persistent message queue does. If > you're going > >> to > >> > go that route then it would be best to add a real message > queue rather > >> than > >> > a home-grown one. I would LOVE it if OpenSim used a message > queue for > >> > communications, as it would allow ripping out thousands of > lines of > >> homemade > >> > communications code, and would be faster and more reliable to > boot. But > >> > that's a bigger issue and I'll put it aside for now. > >> > > >> > In this particular case, using a persistent message queue > isn't be the > >> right > >> > solution: the right solution is to report failures > immediately. Otherwise > >> > you'd get weird behavior such as a user who thinks they've > successfully > >> worn > >> > a piece of clothing, but when they teleport to another region it > >> disappears > >> > because the other region can't load the asset (because it was > never > >> saved). > >> > To prevent these problems you need to fail-fast, and tell the > user > >> > immediately when a problem happens. This doesn't mean to > crash the sim; I > >> > strongly doubt any asset failure would cause that, it would > just fail the > >> > specific packet or message that is currently being handled, > as it should. > >> > > >> > > >> > > >> > -- > >> > View this message in context: > >> > > >> > http://opensim-dev.2196679.n2.nabble.com/Error-detection-when-storing-an-ass > >> > et-tp7579223p7579225.html > >> > Sent from the opensim-dev mailing list archive at Nabble.com. > >> > _______________________________________________ > >> > Opensim-dev mailing list > >> > Opensim-dev at lists.berlios.de > > >> > https://lists.berlios.de/mailman/listinfo/opensim-dev > >> > > >> > _______________________________________________ > >> > Opensim-dev mailing list > >> > Opensim-dev at lists.berlios.de > > >> > https://lists.berlios.de/mailman/listinfo/opensim-dev > >> > > >> > > >> _______________________________________________ > >> Opensim-dev mailing list > >> Opensim-dev at lists.berlios.de > >> https://lists.berlios.de/mailman/listinfo/opensim-dev > >> > > > > > > > > > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > > -- > Oren Hurvitz > VP R&D > Kitely Ltd. > > Email: orenh at kitely.com > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmickeyb at gmail.com Fri Apr 18 22:35:09 2014 From: cmickeyb at gmail.com (Mic Bowman) Date: Fri, 18 Apr 2014 15:35:09 -0700 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> <53515F2A.3050600@smxy.org> <03c701cf5b3a$52527480$f6f75d80$@alternatemetaverse.com> Message-ID: can we please not introduce yet another dependency on an external package? we already have a multiplicity of communication mechanisms & styles and if we are going to canonicalize the whole mess, i would not be in favor of message queues as the means to do that. it wouldn't be all that hard to make a retry mechanism with a local log that wouldn't require the complexity jump of message queues. --mic On Fri, Apr 18, 2014 at 2:23 PM, Oren Hurvitz wrote: > There are several popular open-source message queues that we could use. If > we're going to do that then we need to have an open discussion about the > pros and cons of the various packages in order to decide which one to use. > In the past I've used JBoss Messaging, but that's been discontinued so it > isn't relevant. > > A big decision will be whether to use a message queue that's completely > embedded in OpenSim, or one that runs standalone. OK, I've already said too > much; I'm hijacking my own thread... > > > > On Fri, Apr 18, 2014 at 10:13 PM, Mike Chase < > mike.chase at alternatemetaverse.com> wrote: > >> Or RabbitMQ... Or even ZeroMQ if an external MQ service is deemed too >> heavy. >> >> >> Mike >> >> -----Original Message----- >> From: opensim-dev-bounces at lists.berlios.de >> [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Shaun T. >> Erickson >> Sent: Friday, April 18, 2014 1:22 PM >> To: opensim-dev at lists.berlios.de >> Subject: Re: [Opensim-dev] Error detection when storing an asset >> >> There's also the free ActiveMQ. >> >> On 4/18/14, 11:23 AM, Melanie wrote: >> > MQ Series, IBM's message queue service >> >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > -- > Oren Hurvitz > VP R&D > Kitely Ltd. > > Email: orenh at kitely.com > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jjustincc at googlemail.com Sat Apr 19 01:56:40 2014 From: jjustincc at googlemail.com (Justin Clark-Casey) Date: Sat, 19 Apr 2014 02:56:40 +0100 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: <53519C83.60306@t-data.com> References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> <030a01cf5af9$4d8126e0$e88374a0$@alternatemetaverse.com> <53517FC8.2@t-data.com> <53519C83.60306@t-data.com> Message-ID: <5351D7D8.6090107@googlemail.com> There are always times when failure is permanent. For instance, at the moment if the asset service is full. Even if store and forward were added, unrecoverable failure can still occur if both sides are full. I have had to spend my scarce time dealing with many bugs where the investigation has led to a piece of code that simply swallows its exception, where signalling or logging the error condition would have made the cause of complex problems obvious. So I think that lower level components should always appropriately signal failure or other relevant conditions. It's a different question as to whether the caller thinks it appropriate to notify the user, log the problem or do nothing (though it should always be possible to tell somehow when there is an issue). But the caller should be given the capability to deal with errors or other conditions as appropriate. As for Oren's second issue (null being mistaken as indicating a valid asset), this sounds like a straightforward bug that should be fixed. The 3rd issue, where very old asset servers sent no reply, I agree sounds like something we can risk fixing, as nobody is using (or could use) the old UGAIM pre 0.7 service processes any more. Regarding message queueing, I agree that this would be a great approach. However, OpenSimulator would still need some kind of sqlite equivalent so that it can work out of the box, whilst still being pluggable if someone wants to use a more heavyweight system. The sqlite equivalent must have equivalent support by OpenSimulator, just as the sqlite database plugin should have that today. On 18/04/14 22:43, Melanie wrote: > The point is no NOT let it fail. Asset storing never fails > permanently if it's retried until successful. The upper layers (all > the way to the viewer) are not equipped to handle an asset storing > failure. Propagating the exception would just annoy the user with > needless messages. Since asset servers can be "gone" for a while, > for instance when there is a net failure, there is no way to give it > a timeout, either. A sim in OSGrid, if it gets disconnected, could > run on locally cached assets and manage to reconnect after 20 > minutes and simply upload all new assets since then. Screaming > "failure" at the user is pointless in such a scenario. > > - Melanie > > On 18/04/2014 22:56, Oren Hurvitz wrote: >> There seems to be a misunderstanding here. We're talking about a case where >> the operation has FAILED. The only question is whether to pretend that it >> succeeded, so that the user will find out that it failed later, to their >> surprise, or to report failure immediately. Obviously it's better to report >> failure immediately. >> >> >> >> On Fri, Apr 18, 2014 at 10:40 PM, Melanie wrote: >> >>> Name one valid use case where current OpenSim is able to handle such >>> an exception gracefully, e.g. without user-visible error. >>> >>> - Melanie >>> >>> On 18/04/2014 13:28, Mike Chase wrote: >>>> I'm inclined to agree with Oren. Asset Writes could fail for a variety >>> of >>>> reasons and there are lots of use cases where you need to know the asset >>> is >>>> on disk. I think propagating exceptions is the more sound approach IMO. >>>> >>>> I also agree re: the custom comms vs a persistent queue mechanism but I >>>> don't want to derail this topic. That can wait for another day. >>>> >>>> Mike >>>> >>>> -----Original Message----- >>>> From: opensim-dev-bounces at lists.berlios.de >>>> [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Oren Hurvitz >>>> Sent: Friday, April 18, 2014 7:06 AM >>>> To: opensim-dev at lists.berlios.de >>>> Subject: Re: [Opensim-dev] Error detection when storing an asset >>>> >>>> Regarding the hiding of exceptions: to be clear, I was already bitten by >>>> this behavior; that's why I started to investigate how assets are >>> stored. I >>>> have therefore already changed Kitely's version of OpenSim to propagate >>>> exceptions, and the question is whether other people would like me to >>>> contribute this change. If anyone has an opinion then please reply. >>>> >>>> Regarding your suggestion to save assets to local disk and retry them >>> later: >>>> this is basically what a persistent message queue does. If you're going >>> to >>>> go that route then it would be best to add a real message queue rather >>> than >>>> a home-grown one. I would LOVE it if OpenSim used a message queue for >>>> communications, as it would allow ripping out thousands of lines of >>> homemade >>>> communications code, and would be faster and more reliable to boot. But >>>> that's a bigger issue and I'll put it aside for now. >>>> >>>> In this particular case, using a persistent message queue isn't be the >>> right >>>> solution: the right solution is to report failures immediately. Otherwise >>>> you'd get weird behavior such as a user who thinks they've successfully >>> worn >>>> a piece of clothing, but when they teleport to another region it >>> disappears >>>> because the other region can't load the asset (because it was never >>> saved). >>>> To prevent these problems you need to fail-fast, and tell the user >>>> immediately when a problem happens. This doesn't mean to crash the sim; I >>>> strongly doubt any asset failure would cause that, it would just fail the >>>> specific packet or message that is currently being handled, as it should. >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>>> >>> http://opensim-dev.2196679.n2.nabble.com/Error-detection-when-storing-an-ass >>>> et-tp7579223p7579225.html >>>> Sent from the opensim-dev mailing list archive at Nabble.com. >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> Opensim-dev at lists.berlios.de >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> Opensim-dev at lists.berlios.de >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> >>>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >> >> >> >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > . > -- Justin Clark-Casey (justincc) OSVW Consulting http://justincc.org http://twitter.com/justincc From melanie at t-data.com Sat Apr 19 02:12:09 2014 From: melanie at t-data.com (Melanie) Date: Sat, 19 Apr 2014 04:12:09 +0200 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: <5351D7D8.6090107@googlemail.com> References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> <030a01cf5af9$4d8126e0$e88374a0$@alternatemetaverse.com> <53517FC8.2@t-data.com> <53519C83.60306@t-data.com> <5351D7D8.6090107@googlemail.com> Message-ID: <5351DB79.5060308@t-data.com> The kind of permanent failure scenarios outlined below are a death knell for the affected grid; if the asset server is full, any reasonably sized grid will be inconsistent and irrecoverably damaged in less than a day. Therefore, I postulate that that condition does not need to be covered by extra code that would impair legibility since the affected grid would have been neglectful in not monitoring disk usage. I'm concerned about having to have exception catching and handling in every place Get() is called because that would certainly make the code a lot bulkier and less readable for no real-life gain. In particular, since in most cases no intelligent response is possible, it just means ignoring the exception in multiple places rather than just one. Reporting that kind of error to the user is pointless. There is nothing the user can do to recover. - Melanie On 19/04/2014 03:56, Justin Clark-Casey wrote: > There are always times when failure is permanent. For instance, at the moment if the asset service is full. Even if > store and forward were added, unrecoverable failure can still occur if both sides are full. > > I have had to spend my scarce time dealing with many bugs where the investigation has led to a piece of code that simply > swallows its exception, where signalling or logging the error condition would have made the cause of complex problems > obvious. So I think that lower level components should always appropriately signal failure or other relevant > conditions. It's a different question as to whether the caller thinks it appropriate to notify the user, log the > problem or do nothing (though it should always be possible to tell somehow when there is an issue). But the caller > should be given the capability to deal with errors or other conditions as appropriate. > > As for Oren's second issue (null being mistaken as indicating a valid asset), this sounds like a straightforward bug > that should be fixed. > > The 3rd issue, where very old asset servers sent no reply, I agree sounds like something we can risk fixing, as nobody > is using (or could use) the old UGAIM pre 0.7 service processes any more. > > Regarding message queueing, I agree that this would be a great approach. However, OpenSimulator would still need some > kind of sqlite equivalent so that it can work out of the box, whilst still being pluggable if someone wants to use a > more heavyweight system. The sqlite equivalent must have equivalent support by OpenSimulator, just as the sqlite > database plugin should have that today. > > On 18/04/14 22:43, Melanie wrote: >> The point is no NOT let it fail. Asset storing never fails >> permanently if it's retried until successful. The upper layers (all >> the way to the viewer) are not equipped to handle an asset storing >> failure. Propagating the exception would just annoy the user with >> needless messages. Since asset servers can be "gone" for a while, >> for instance when there is a net failure, there is no way to give it >> a timeout, either. A sim in OSGrid, if it gets disconnected, could >> run on locally cached assets and manage to reconnect after 20 >> minutes and simply upload all new assets since then. Screaming >> "failure" at the user is pointless in such a scenario. >> >> - Melanie >> >> On 18/04/2014 22:56, Oren Hurvitz wrote: >>> There seems to be a misunderstanding here. We're talking about a case where >>> the operation has FAILED. The only question is whether to pretend that it >>> succeeded, so that the user will find out that it failed later, to their >>> surprise, or to report failure immediately. Obviously it's better to report >>> failure immediately. >>> >>> >>> >>> On Fri, Apr 18, 2014 at 10:40 PM, Melanie wrote: >>> >>>> Name one valid use case where current OpenSim is able to handle such >>>> an exception gracefully, e.g. without user-visible error. >>>> >>>> - Melanie >>>> >>>> On 18/04/2014 13:28, Mike Chase wrote: >>>>> I'm inclined to agree with Oren. Asset Writes could fail for a variety >>>> of >>>>> reasons and there are lots of use cases where you need to know the asset >>>> is >>>>> on disk. I think propagating exceptions is the more sound approach IMO. >>>>> >>>>> I also agree re: the custom comms vs a persistent queue mechanism but I >>>>> don't want to derail this topic. That can wait for another day. >>>>> >>>>> Mike >>>>> >>>>> -----Original Message----- >>>>> From: opensim-dev-bounces at lists.berlios.de >>>>> [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Oren Hurvitz >>>>> Sent: Friday, April 18, 2014 7:06 AM >>>>> To: opensim-dev at lists.berlios.de >>>>> Subject: Re: [Opensim-dev] Error detection when storing an asset >>>>> >>>>> Regarding the hiding of exceptions: to be clear, I was already bitten by >>>>> this behavior; that's why I started to investigate how assets are >>>> stored. I >>>>> have therefore already changed Kitely's version of OpenSim to propagate >>>>> exceptions, and the question is whether other people would like me to >>>>> contribute this change. If anyone has an opinion then please reply. >>>>> >>>>> Regarding your suggestion to save assets to local disk and retry them >>>> later: >>>>> this is basically what a persistent message queue does. If you're going >>>> to >>>>> go that route then it would be best to add a real message queue rather >>>> than >>>>> a home-grown one. I would LOVE it if OpenSim used a message queue for >>>>> communications, as it would allow ripping out thousands of lines of >>>> homemade >>>>> communications code, and would be faster and more reliable to boot. But >>>>> that's a bigger issue and I'll put it aside for now. >>>>> >>>>> In this particular case, using a persistent message queue isn't be the >>>> right >>>>> solution: the right solution is to report failures immediately. Otherwise >>>>> you'd get weird behavior such as a user who thinks they've successfully >>>> worn >>>>> a piece of clothing, but when they teleport to another region it >>>> disappears >>>>> because the other region can't load the asset (because it was never >>>> saved). >>>>> To prevent these problems you need to fail-fast, and tell the user >>>>> immediately when a problem happens. This doesn't mean to crash the sim; I >>>>> strongly doubt any asset failure would cause that, it would just fail the >>>>> specific packet or message that is currently being handled, as it should. >>>>> >>>>> >>>>> >>>>> -- >>>>> View this message in context: >>>>> >>>> http://opensim-dev.2196679.n2.nabble.com/Error-detection-when-storing-an-ass >>>>> et-tp7579223p7579225.html >>>>> Sent from the opensim-dev mailing list archive at Nabble.com. >>>>> _______________________________________________ >>>>> Opensim-dev mailing list >>>>> Opensim-dev at lists.berlios.de >>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>>> >>>>> _______________________________________________ >>>>> Opensim-dev mailing list >>>>> Opensim-dev at lists.berlios.de >>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>>> >>>>> >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> Opensim-dev at lists.berlios.de >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> . >> > > From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: representing an image, sound bytes, scriptcode, prim shape definition. But What happens when a scripted object is rez'ed, the code modifies the state of the script or prim or the inventory of the object? If a script modifies the link chain of a set of prims, changes the texture or any other mutable property on a prim, do we have a new asset? if it is a new asset, do we copy the textures into this new asset? Is the complete "file" changed, or only parts of the file? I know there is a huge debate on this going on on the sldev mailing list, but I'd prefer to go for something resonably simple and practical, as a first implementation. My suggestion is based on the concept of triplets, much like the triplets in RDF. Basically an asset can be seen as a collection of values, each value consists of three properties: , , to give some examples texture: 329AE20F-38C1-43fb-BDA0-6B13E569FCDF, Type, Texture 329AE20F-38C1-43fb-BDA0-6B13E569FCDF, Name, "Green grass" 329AE20F-38C1-43fb-BDA0-6B13E569FCDF, Width, 256 329AE20F-38C1-43fb-BDA0-6B13E569FCDF, Height, 256 329AE20F-38C1-43fb-BDA0-6B13E569FCDF, Image, 44BD483173EC206D130B5F775B2B31D......... 329AE20F-38C1-43fb-BDA0-6B13E569FCDF, Owner, 61AEA4D9-19CE-4fac-8E44-DFA24903BFB8 prim 61AEA4D9-19CE-4fac-8E44-DFA24903BFB8, Type, Primitive 61AEA4D9-19CE-4fac-8E44-DFA24903BFB8, Shape, Box 61AEA4D9-19CE-4fac-8E44-DFA24903BFB8, Position, 8D45A164-52B1-4dab-A7BE-53A7078CA50B 8D45A164-52B1-4dab-A7BE-53A7078CA50B, X, 125.7 8D45A164-52B1-4dab-A7BE-53A7078CA50B, Y, 10 8D45A164-52B1-4dab-A7BE-53A7078CA50B, Z, 19 61AEA4D9-19CE-4fac-8E44-DFA24903BFB8, Size, EA7254C0-D692-436a-949C-ADFE500E85EF EA7254C0-D692-436a-949C-ADFE500E85EF, Width, 10 EA7254C0-D692-436a-949C-ADFE500E85EF, Height, 2 EA7254C0-D692-436a-949C-ADFE500E85EF, Depth, 0.1 61AEA4D9-19CE-4fac-8E44-DFA24903BFB8, Name, "My plywood box" On first inspection this seems to be too complex, but this scheme can easily be extended to handle versioning, so in case somebody renames our texture in the above example, this can be handled quite easily, by storing this information: texture 0CDE3656-D5A1-4ac2-819C-F8285680BC28, Parent, 329AE20F-38C1-43fb-BDA0-6B13E569FCDF 0CDE3656-D5A1-4ac2-819C-F8285680BC28, Name, "Dark green grass" in essence, this has created a new asset, called "0CDE3656-D5A1-4ac2-819C-F8285680BC28", which inherits most of it's values from "329AE20F-38C1-43fb-BDA0-6B13E569FCDF". This is the strategy, which I'd suggest as a first go for assets, I would welcome any and all comments /Tleiades From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: not the case. =20 For example, consider something like =20 =20 that doesn't look like a bad idea at all to me. /Stefan= --_1d749aed-2031-4a4b-85b7-d636bdf6f011_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > It would be good to see a proposal on how to= change those objects into
> something better. None of us are in love= with them, but better
> approaches haven't popped up yet.

Probably because nobody has made any attempt at discussing and proposing ch= anges; this mail was an attempt to get that ball rolling.
 
There was some energy poured into analyzing how attachments were communicat= ed; that would be a good start, if we could get a wiki page up just detaili= ng what we know about scene entities.
 
> > * Related, we need to revise the xml serialization sche= me and the db
> > * schemes. The xml scheme should be user-friendl= y to the point where
> > * you should be confident to create and e= dit objects in notepad,
> > * basically. This is not the case at t= he moment. Massive duplication,
> > * weird bit values and non-int= uitive value ranges are king at the
> > * moment.
>
>= Given the amount of data in a prim, editing in notepad always is going
= > to be a bad idea. :) I think we've got something like 40 fields that> have to be sensible for the prim to work.

From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: not the case.
 
For example, consider something like
 
<Object position=3D"128.0 128.0 23.0">
<Rectangle extrusion=3D"straight" scale=3D"1.0 2.0 5.0" offset=3D"root"/= >
<Circle extrusion=3D"sphere" scale=3D"1 1 1" offset=3D"0 0 1"/><= BR> </Object>
 
that doesn't look like a bad idea at all to me.

/Stefan
= --_1d749aed-2031-4a4b-85b7-d636bdf6f011_-- From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: problem. It's actually counter-productive, as people, being irrational agents in general, will simply hear the message "you're nuts", and will come back again with more arguments for why they are not being irrational. It's a dead-end conversation.

Option b) is one that most technologists don't believe, because they know quite well that such policing cannot be done with the technology, but with an aggressive costumer protection department. Some technologists may very well follow it, because they know that there is some short-term cash to be made -- until it eventually dissolves when they realize that the costs of keeping the police and prosecution departments far outweigh the revenue, at least in a situation where there is no monopoly and people have choices (history shows that people tend to be attracted by tolerance).

My favorite is option c), and I think that OpenSim is general enough to account for several service models to emerge. People who want extra protection should only produce content on grids that offer that kind of protection, and not on the other, more tolerant, ones. I personally believe that such policing-heavy grids will not have a chance of surviving, unless, besides the protection, they offer some really cool things that attract people to them in the first place; but hey! - the point is that people will have choices.

Diva / Crista

The Burnman wrote:


On Mon, Mar 3, 2008 at 12:10 PM, Brian Wolfe <brianw at terrabox.com> wrote:
(warning, written 15 minutes after waking up and before first coffee was
downed.)

Noted.  ;)
 
Your arguments are spot on. :) I would add that having DRM or attempting
to curtail end users fredom of use is pushing society to being
untrustable. There is an old saying. Say something often enough and it
becomes true. Say people WILL steal content at times, be paranoid about
it and far more people WILL steal your content due to lack of respect ,
which is earned by the creator's lack of trust in others.

There is no paranoia in the valid concern that people will attempt to rip you off.  It happens all the time.  It will never cease to amaze me how entitled people feel to other people's Intellectual Property.  THAT is where the lack of respect and trust comes into play.  An artist or author who wishes to protect their work from those who are low enough to steal from them should not be looked on as paranoid, they are simply trying to enforce their rights under law.  Theft is where the lack of respect and trust come from.
 
However if you as a creator can bring yourself to see the good in
others, most will respect you enough to not steal your work. You will
still have some minor theft happening, but not nearly enough to stop you
from creating and profiting from your creations. This is just life and
society in general and unavoidable.

By your argument, we should do away with police and trust people to behave themselves.  Simply because it is impossible to prevent all theft, does not mean we should just give up in our attempts to make it difficult.
 
Here's another parallel to the whole DRM debate. We trust each other to
not run around killing people. We don't walk around wearing 100%
protective body armour because, well, it's impossibly expensive, and no
one will trust you due to your obvious paranoia. ;) Instead, we walk
around with no armour at all, yet the threat of serious bodily harm is
still there, and we manage to survive just fine.

Tell that to the two teenagers who were shot to death across town here last week.  They were in their driveway playing basketball.  Or the elderly man who was gunned down in his driveway a few towns away the week before that.  The danger is there, and it would certainly be far worse if there were no police to keep it relatively in check.  While there is no such thing as 100% safe, we are more safe due to the protections in place.  This analogy works just as well for asset protection in a metaverse environment.
 
There are bad apples, just don't let one bad apple ruin your
relationship with the rest of the apples.

There are bad apples, that we agree on.  The question is what to do about it.  Do we attempt to curb the bulk of content theft, or do we simply force content creators to deal with a lack of protection for their work?  If you were to poll the vast majority of content creators in Second Life what they would prefer...  no protection for their work, or some protection... what do you think their response would be?  And let's face it...  as it stands... the majority of people who will be designing content for a metaverse based on OpenSim will come from Second Life.

I can understand that from a developers perspective, Intellectual Property Rights protection is a nasty bear to wrestle in the development of the metaverse, but I do not see how the metaverse project benefits from alienating the people who will make the metaverse interesting.  Think about it...  what would you have without content?  Lots of empty space.

I believe that the first metaverse platform to successfully solve the IP Rights issue will end up on the top of the pile.  And with the concept that Charles and I were discussing here last night, I think OpenSim could well be that platform.


_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

--------------040800080008030402040201-- From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: automatically by OpenSim. So, since one table is created correctly, I'm assuming connecting to the database is occurring correctly since otherwise nothing would be created (i.e. in the case of incorrect permissions). I have also tested this on several other CentOS 5 boxes as well as with several disparate MySQL servers on those boxes with both local and remote connections (i.e. with OpenSim both on the same box and on different boxes than the MySQL database). I'm not sure if it is my configuration or a bug, so I figured I would post here first. Any help would be appreciated. Here are some of the system stats from the main machine on which I am testing OpenSim as well as the OpenSim.ini and mysql_connection.ini files: CentOS 5 (i686) MySQL 5.0.22 Kernel 2.6.18 (53.1.13.el5) 512MB RAM GCC 4.1.2 My OpenSim.ini file: [Startup] gridmode = False physics = OpenDynamicsEngine verbose = True physical_prim = True child_get_tasks = False serverside_object_permissions = True storage_plugin = OpenSim.Framework.Data.MySQL.dll storage_connection_string="Data Source=localhost;Database=opensim;User ID=opensim;Password=*******;"; storage_prim_inventories = True startup_console_commands_file = startup_commands.txt shutdown_console_commands_file = shutdown_commands.txt script_engine = OpenSim.Region.ScriptEngine.DotNetEngine.dll asset_database = mysql [StandAlone] accounts_authenticate = true welcome_message = Welcome to OpenSim inventory_plugin = OpenSim.Framework.Data.MySQL.dll userDatabase_plugin = OpenSim.Framework.Data.MySQL.dll asset_plugin = OpenSim.Framework.Data.MySQL.dll dump_assets_to_file = False [Network] default_location_x = 1000 default_location_y = 1000 http_listener_port = 9000 remoting_listener_port = 8895 grid_server_url = http://127.0.0.1:8001 grid_send_key = null grid_recv_key = null user_server_url = http://127.0.0.1:8002 user_send_key = null user_recv_key = null asset_server_url = http://127.0.0.1:8003 inventory_server_url = http://127.0.0.1:8004 [RemoteAdmin] enabled = false My mysql_connection.ini file: [mysqlconnection] hostname=localhost database=opensim username=opensim password=******** pooling=false port=3306 ------=_Part_13453_26798329.1204580145997 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello,

I have been trying for the last several days to get OpenSim working on a CentOS 5 box using MySQL.  It seems to work nicely with SQLite, but I really would like to get MySQL working.  I have tried both with the 0.5.0 release as well as a current SVN copy.  With both, I get MySQL configured and it connects to the database fine.  The problem comes (I believe) when it tries to create the tables the first time.  When I start with 'mono OpenSim.exe', I get the following:

<snippet>
OpenSim 0.4, SVN build

Performing compatibility checks...  Environment is compatible.

Starting...

Creating new local console
Logs will be saved to current directory in ./region-console.log
[DATASTORE
] [03-03 16:03:48] Attempting to load OpenSim.Framework.Data.MySQL.dll
[DATASTORE
] [03-03 16:03:48] MySql - connecting: Data Source=localhost;Database=opensim;User ID=opensim;Password=************;
[DATASTORE
] [03-03 16:03:48] MySql Database doesn't exist... creating
</snippet>

At this point OpenSim just sits there indefinitely.  If I log into MySQL and look at the opensim database, only the 'prims' table is created. 

From what I've read in the documentation, all the tables should be created automatically by OpenSim.  So, since one table is created correctly, I'm assuming connecting to the database is occurring correctly since otherwise nothing would be created (i.e. in the case of incorrect permissions).  I have also tested this on several other CentOS 5 boxes as well as with several disparate MySQL servers on those boxes with both local and remote connections (i.e. with OpenSim both on the same box and on different boxes than the MySQL database).  I'm not sure if it is my configuration or a bug, so I figured I would post here first.  Any help would be appreciated.

Here are some of the system stats from the main machine on which I am testing OpenSim as well as the OpenSim.ini and mysql_connection.ini files:

CentOS 5 (i686)
MySQL 5.0.22
Kernel 2.6.18 (53.1.13.el5)
512MB RAM
GCC 4.1.2

My OpenSim.ini file:

<snippet>
[Startup]
gridmode = False
physics = OpenDynamicsEngine
verbose = True
physical_prim = True
child_get_tasks = False
serverside_object_permissions = True
storage_plugin = OpenSim.Framework.Data.MySQL.dll
storage_connection_string="Data Source=localhost;Database=opensim;User ID=opensim;Password=*******;";
storage_prim_inventories = True
startup_console_commands_file = startup_commands.txt
shutdown_console_commands_file = shutdown_commands.txt
script_engine = OpenSim.Region.ScriptEngine.DotNetEngine.dll
asset_database = mysql
[StandAlone]
accounts_authenticate = true
welcome_message = Welcome to OpenSim
inventory_plugin = OpenSim.Framework.Data.MySQL.dll
userDatabase_plugin = OpenSim.Framework.Data.MySQL.dll
asset_plugin = OpenSim.Framework.Data.MySQL.dll
dump_assets_to_file = False
[Network]
default_location_x = 1000
default_location_y = 1000
http_listener_port = 9000
remoting_listener_port = 8895
grid_server_url = http://127.0.0.1:8001
grid_send_key = null
grid_recv_key = null
user_server_url = http://127.0.0.1:8002
user_send_key = null
user_recv_key = null
asset_server_url = http://127.0.0.1:8003
inventory_server_url = http://127.0.0.1:8004
[RemoteAdmin]
enabled = false
</snippet>

My mysql_connection.ini file:

<snippet>
[mysqlconnection]
hostname=localhost
database=opensim
username=opensim
password=********
pooling=false
port=3306
</snippet>
------=_Part_13453_26798329.1204580145997-- From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: between machines that are across the internet. However, this brings up another interesting topic.. generally Is a cheap DSL connection going to be enough to host a 'ton' of users anyway? You'd think you'd have to want to host a ton of users to get any benefit from using the load balancing. Best Regards Teravus On 3/6/08, Grumly wrote: > > Would this explain why DSL home hosted adjacent sims crossing is so shaky > sometimes ? > In this case, I am afraid such simulators could also not take advantage of > the new load balancing feature. > > *From:* Michael Wright > *Sent:* Thursday, March 06, 2008 12:47 PM > *To:* opensim-dev at lists.berlios.de > *Subject:* Re: [Opensim-dev] Concerning recent grid instability > andinconsistency > > > I haven't had much time to follow this discussion, but just a quick note. > We used to have a REST like communications protocol between the regions, but > this lead to a lot of problems. Granted it was like the rest of the backend > protocols we use, very err primitive. But I just not sure http/xml is the > best protocol to be used there, as a lot of the calls are time critical. And > there are some things we are yet to add which would increase the network > traffic between the regions by quite a bit. Thats why we switched to > remoting so we could at least have a binary protocol. Maybe we do need to > switch to udp, like I believe Linden Labs do (or at least they used to). > > *Brian McBee * wrote: > > Coming late to this discussion, but i have a couple of comments about our > use of remoting in the interregion communications: > > 1. It seems like remoting is really designed for a scenario where you own > both the client and server ends of the connection, and have a reasonable > expectation that the server is up. In a distributed grid environment like > OSGRID is running, that assumption isn't true. > > 2. When playing with the teleport code, I tried to find a way to lower the > timeout on the remoting calls, since a failed teleport took forever to > resolve. It appears that, at least the way we are doing it, the timeout is > hardcoded and cannot be changed. It looks like Microsoft tries to provide a > way to change that timeout, but it doesn't actually work. > > Perhaps longer term, we should be looking at replacing remoting with a > REST interface like we are using for the sim to grid communications. > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > ------------------------------ > Rise to the challenge for Sport Relief with Yahoo! for Good > > ------------------------------ > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > ------=_Part_5443_28098821.1204831788868 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
From what I've read, it can assuming you don't have regions load balancing between machines that are across the internet.
However, this brings up another interesting topic..    generally Is a cheap DSL connection going to be enough to host a 'ton' of users anyway?    You'd think you'd have to want to host a ton of users to get any benefit from using the load balancing.
 
Best Regards
 
Teravus

 
On 3/6/08, Grumly <grumly57 at hotmail.com> wrote:
Would this explain why DSL home hosted adjacent sims crossing is so shaky sometimes ?
In this case, I am afraid such simulators could also not take advantage of the new load balancing feature.
 
Sent: Thursday, March 06, 2008 12:47 PM
Subject: Re: [Opensim-dev] Concerning recent grid instability andinconsistency

 
I haven't had much time to follow this discussion, but just a quick note. We used to have a REST like communications protocol between the regions, but this lead to a lot of problems. Granted it was like the rest of the backend protocols we use, very err primitive. But I just not sure http/xml is the best protocol to be used there, as a lot of the calls are time critical. And there are some things we are yet to add which would increase the network traffic between the regions by quite a bit. Thats why we switched to remoting so we could at least have a binary protocol. Maybe we do need to switch to udp, like I believe Linden Labs do (or at least they used to).

Brian McBee <heartwide at gmail.com> wrote:
Coming late to this discussion, but i have a couple of comments about our use of remoting in the interregion communications:

1. It seems like remoting is really designed for a scenario where you own both the client and server ends of the connection, and have a reasonable expectation that the server is up. In a distributed grid environment like OSGRID is running, that assumption isn't true.

2. When playing with the teleport code, I tried to find a way to lower the timeout on the remoting calls, since a failed teleport took forever to resolve. It appears that, at least the way we are doing it, the timeout is hardcoded and cannot be changed. It looks like Microsoft tries to provide a way to change that timeout, but it doesn't actually work.

Perhaps longer term, we should be looking at replacing remoting with a REST interface like we are using for the sim to grid communications.


_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Rise to the challenge for Sport Relief with Yahoo! for Good

_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev


_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev


------=_Part_5443_28098821.1204831788868-- From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: balancing between machines that are across the internet. However, this brings up another interesting topic.. generally Is a = cheap DSL connection going to be enough to host a 'ton' of users anyway? = You'd think you'd have to want to host a ton of users to get any = benefit from using the load balancing. Best Regards Teravus =20 On 3/6/08, Grumly wrote:=20 Would this explain why DSL home hosted adjacent sims crossing is so = shaky sometimes ? In this case, I am afraid such simulators could also not take = advantage of the new load balancing feature. From: Michael Wright=20 Sent: Thursday, March 06, 2008 12:47 PM To: opensim-dev at lists.berlios.de=20 Subject: Re: [Opensim-dev] Concerning recent grid instability = andinconsistency =20 I haven't had much time to follow this discussion, but just a quick = note. We used to have a REST like communications protocol between the = regions, but this lead to a lot of problems. Granted it was like the = rest of the backend protocols we use, very err primitive. But I just not = sure http/xml is the best protocol to be used there, as a lot of the = calls are time critical. And there are some things we are yet to add = which would increase the network traffic between the regions by quite a = bit. Thats why we switched to remoting so we could at least have a = binary protocol. Maybe we do need to switch to udp, like I believe = Linden Labs do (or at least they used to). Brian McBee wrote:=20 Coming late to this discussion, but i have a couple of comments = about our use of remoting in the interregion communications: 1. It seems like remoting is really designed for a scenario where = you own both the client and server ends of the connection, and have a = reasonable expectation that the server is up. In a distributed grid = environment like OSGRID is running, that assumption isn't true. 2. When playing with the teleport code, I tried to find a way to = lower the timeout on the remoting calls, since a failed teleport took = forever to resolve. It appears that, at least the way we are doing it, = the timeout is hardcoded and cannot be changed. It looks like Microsoft = tries to provide a way to change that timeout, but it doesn't actually = work. Perhaps longer term, we should be looking at replacing remoting with = a REST interface like we are using for the sim to grid communications. _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -------------------------------------------------------------------------= ----- Rise to the challenge for Sport Relief with Yahoo! for Good=20 -------------------------------------------------------------------------= ----- _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -------------------------------------------------------------------------= ------- _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ------=_NextPart_001_01C8_01C87FCF.949045E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
True 3D"Visage
The example you gave is the good one. = In this very=20 case, I would rather use load balancing to move temporary my cheap DSL = hosted=20 region to some powerful servers on the grid, which would be = equipped=20 with a high bandwidth connection. This could be a "rent balanced = servers" rental=20 operation for specials events.
I suppose the move operation may = probably not be as=20 smooth as described in some posts I read.

From: Teravus Ovares
Sent: Thursday, March 06, 2008 8:29 PM
To: opensim-dev at lists.berlios.de= =20
Subject: Re: [Opensim-dev] Concerning recent grid=20 instabilityandinconsistency

From what I've read, it can assuming you don't have regions load = balancing=20 between machines that are across the internet.
However, this brings up another interesting = topic..   =20 generally Is a cheap DSL connection going to be enough to host a 'ton' = of users=20 anyway?    You'd think you'd have to want to host a ton = of users=20 to get any benefit from using the load balancing.
 
Best Regards
 
Teravus

 
On 3/6/08, Grumly=20 <grumly57 at hotmail.com> = wrote:=20
Would this explain why DSL home = hosted adjacent=20 sims crossing is so shaky sometimes ?
In this case, I am afraid such = simulators=20 could also not take advantage of the new load balancing=20 feature.
 
Sent: Thursday, March 06, 2008 12:47 PM
Subject: Re: [Opensim-dev] Concerning recent grid = instability=20 andinconsistency

 
I haven't had much time = to follow=20 this discussion, but just a quick note. We used to have a REST like=20 communications protocol between the regions, but this lead to a lot of = problems. Granted it was like the rest of the backend protocols we = use, very=20 err primitive. But I just not sure http/xml is the best protocol to be = used=20 there, as a lot of the calls are time critical. And there are some = things we=20 are yet to add which would increase the network traffic between the = regions by=20 quite a bit. Thats why we switched to remoting so we could at least = have a=20 binary protocol. Maybe we do need to switch to udp, like I believe = Linden Labs=20 do (or at least they used to).

Brian McBee <heartwide at gmail.com> wrote:=20 Coming=20 late to this discussion, but i have a couple of comments about our = use of=20 remoting in the interregion communications:

1. It seems like = remoting=20 is really designed for a scenario where you own both the client and = server=20 ends of the connection, and have a reasonable expectation that the = server is=20 up. In a distributed grid environment like OSGRID is running, that=20 assumption isn't true.

2. When playing with the teleport = code, I=20 tried to find a way to lower the timeout on the remoting calls, = since a=20 failed teleport took forever to resolve. It appears that, at least = the way=20 we are doing it, the timeout is hardcoded and cannot be changed. It = looks=20 like Microsoft tries to provide a way to change that timeout, but it = doesn't=20 actually work.

Perhaps longer term, we should be looking at = replacing=20 remoting with a REST interface like we are using for the sim to grid = = communications.


______________________________________________= _
Opensim-dev=20 mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev=

Rise to the challenge for Sport Relief with Yahoo! for Good

_______________________________________________
Opensim-dev = mailing=20 list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev=

=


_______________________________________________
Opens= im-dev=20 mailing list
Opensim-dev at lists.berlios.de=
https://lists.berlios.de/mailman/listinfo/opensim-dev=


_______________________________________________
Opensim-dev = mailing=20 list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/= listinfo/opensim-dev
------=_NextPart_001_01C8_01C87FCF.949045E0-- ------=_NextPart_000_01C7_01C87FCF.949045E0 Content-Type: image/gif; name="Emoticon1.gif" Content-Transfer-Encoding: base64 Content-ID: <95A3912E886848EC918F573786AE0336 at LBLAPTOP> R0lGODlhEwATALMPAPXv3v3pTvDHOei2K9u4a9qoLunPkLGLMdOZKfvbQMeyl5p4J+7JbrebXoAy GAAAACH5BAEAAA8ALAAAAAATABMAAASu8EkJDBNjMAOmf5UgJEGQJBj3AVfpuslAdBRDvu8p04YQ CIuFrzQIDgQFA2i4AAAWruYTgwiVFopnNCsUICy3hUMBvY67hcYwIHaU2Q43ZnAYuIDCUixYmC8G NzgmJyIZBQcXgYMnKIUDCA09jA4FgCcFCA4ZdFlHl5SbmQiGBx0GR0iZcXEIo5wUBH1ImK2tGQcN NCCxm70Dh7krBq2VvwgHB1kfExUNBwu4yh4RADs= ------=_NextPart_000_01C7_01C87FCF.949045E0-- From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: =20 * Overly complex (the configuration seem to, in themselves, be on par with = actually coding generic mappers) * Mandating major changes in our object structure (opening up for encapsula= tion violations or forcing dependencies on hibernate) * Totally invasive (as in, in practice demanding its storage philosophy to = be acommodated for and coded into core objects) =20 It has been proven a very bad thing to let objects take care of their own d= b serialization. More often than not, the object cannot be serialized from = within its own context (it might not have data like 'parent' needed for rel= ational storage) - and the object itself should not know about any given se= rialization method. =20 It IS a very bad thing to rely on 'storage' as a prime db serialization con= cept - you want 'changes': the first thing we need to do when we get to opt= imize the db layer, is to introduce more fine-grained update calls, like 'C= hangeOwner' and 'StoreTextures' instead of 'store object, with prims, textu= res and shapes'. I have asked several times how this would be accomodated i= n nhibernate, but have got no answers. =20 Now, I've been asking for some kind of overview of the wins with this and w= hat the drawbacks are, but have so far got none that gives me any idea of w= hat impact this has on our modular approach or on performance. =20 If we're not going to let it 'hibernate' objects, as in 'let the objects th= emselves store themselves' and if we have to set up config files detailing = out the mappings, why simply not just CODE the thing and get the granularit= y, performance and customizability (as in, being able to let the objects be= serialized according to their different internal structures) that comes wi= th it? =20 Best, /Stefan Date: Fri, 4 Apr 2008 10:23:33 +0200From: impalah at gmail.comTo: opensim-dev@= lists.berlios.deSubject: Re: [Opensim-dev] nhibernate progress, baby stepsH= ello everyone:I hadn't any time to "nhibernating" opensim (as I told months= ago) but the code I did is there.Sean I know my code may be "complicated" = when starting, that's for the use of factories and DAO's. My intention was = to convert every nhibernate object in a DAO, so they will know how to save,= update, delete... themselves (a simple call to AssetDAO.Save(id) for examp= le). Well, for testing your approach is better if you don't have enough exp= erience with hibernate.Second, my approach was to not modify the current ob= jects, mapping them to nhibernate classes. Of course the better idea is to = use the libsl-hibernatized objects (with getters and setters) throughout th= e code w/o intermediate mapping classes. I think the advantages of having "= intelligent" getters and setters where we could put validations, or even cl= asses than can serialize (to XML or whatever) are more than the "overload a= nd memory use" disadvantages.Third (fuck, I'm making a list) the ID questio= n: do not use the "auto" ids (generated by nhibernate). Let opensim create = them. The overhead of letting hibernate create these ids is higher than the= CoCreateId call opensim does. If you want to use a byte array for storing = ids (due to better performance), use it; hibernate hasn't any problem with = it (the "recommended id" is an integer because hibernate is often used in "= enterprise environments", there isn't any other reason).Four, I tested my p= revious code (apart from .NET) with mono + SQLite + nhibernate w/o "touchin= g" anything (I used the included sqlite drivers included with opensim). I c= an't help you here.Five, instead of using the hbm.xml files you can use map= ping attributes (that was the point where I stopped). The same with the hib= ernate.cfg.xml, you can set its properties "programatically". The advantage= s: if you change one data object you don't have to change the xml file too;= and less files in the bin directory as well.Six, you can generate the db s= chemma automatically (I think I provided an example), it's db independent. = If you are using mapping attributes instead of hbm.xml just serialize the o= bjects (there are some examples looking for "nhibernate mapping attributes"= in google). It works...Seven, sorry. I wanted to help you developing a hib= ernate base but I had only 1 "relatively" free week to did it. Maybe in the= future.Greetings and good luckImpalah "busy guy" Shenzhou 2008/4/3, Stefan Andersson :=20 Yeah, well; I'm not saying it IS, just that we need to check on it.I glimps= ed that as I was trying to find out what the 'best practice' for storing gu= ids in MySQL databases was; I actually didn't find any good info on that. /= Stefan > Subject: RE: [Opensim-dev] nhibernate progress, baby steps> From: brianw@= terrabox.com> To: stefan at tribalmedia.se> CC: opensim-dev at lists.berlios.de> = Date: Thu, 3 Apr 2008 13:04:37 -0500=20 > > > Ouch. That's not good. > > > On Thu, 2008-04-03 at 19:55 +0200, Stefa= n Andersson wrote:> > It seems the MySQL connector for .net assumes the db = field is a> > string for its internal MySqlDataReader.GetGuid() implementat= ion.> > > > (I could have been looking at source for an old revision of the= > > connector, but that needs to be checked out anyway)> > > > So, that mig= ht mean that going binary could wreck stuff like> > nhibernate, if that's u= sing a DataReader.> > > > Best,> > /Stefan> > > > > > > > > > > > _________= _____________________________________________________________> > > > > Date= : Thu, 3 Apr 2008 13:49:03 -0400> > > From: sean at dague.net> > > To: brianw@= terrabox.com; opensim-dev at lists.berlios.de> > > Subject: Re: [Opensim-dev] = nhibernate progress, baby steps> > > > > > On Thu, Apr 03, 2008 at 11:19:58= AM -0500, Brian Wolfe wrote:> > > > *nod* sounds good to me as well. I just= have one request since> > we'll be> > > > changing things up at this level= . Can we shoot for UUIDs being> > stored as> > > > a byte[16] in order to g= ain the 10x speedup in SQL> > indexing/storage vs> > > > string(32|36) ?> >= > > > > That's definitely an option. It did however seem like there was so= me> > > speedup on LLUUID processing if we kept strings. I'm not sure where= > > the> > > two end up colliding on speedup effects.> > > > > > -Sean> > >= > > > -- > > > ___________________________________________________________= _______> > > > > > Sean Dague Mid-Hudson Valley> > > sean at dague dot net = Linux Users Group> > > http://dague.net http://mhvlug.org> > > > > > There = is no silver bullet. Plus, werewolves make better neighbors> > > than zombi= es, and they tend to keep the vampire population down.> > > _______________= ___________________________________________________> > > __________________= _____________________________Opensim-dev mailing listOpensim-dev at lists.berl= ios.dehttps://lists.berlios.de/mailman/listinfo/opensim-dev= --_3e0aae69-b7da-4b90-ae8a-20bc57d06fce_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At this point I must, again, ask 'what is the poi= nt of nhibernate'?
 
From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID:  
* Overly complex (the configuration seem to, in themselves, be on par with = actually coding generic mappers)
* Mandating major changes in our object structure (opening up for encapsula= tion violations or forcing dependencies on hibernate)
* Totally invasive (as in, in practice demanding its storage philosophy to = be acommodated for and coded into core objects)
 
It has been proven a very bad thing to let objects take care of their own d= b serialization. More often than not, the object cannot be serialized from = within its own context (it might not have data like 'parent' needed for rel= ational storage) - and the object itself should not know about any given se= rialization method.
 
It IS a very bad thing to rely on 'storage' as a prime db serialization con= cept - you want 'changes': the first thing we need to do when we = get to optimize the db layer, is to introduce more fine-grained update call= s, like 'ChangeOwner' and 'StoreTextures' instead of 'store object, with pr= ims, textures and shapes'. I have asked several times how this would be acc= omodated in nhibernate, but have got no answers.
 
Now, I've been asking for some kind of overview of the wins with this and w= hat the drawbacks are, but have so far got none that gives me any idea of w= hat impact this has on our modular approach or on performance.
 
If we're not going to let it 'hibernate' objects, as in 'let the objects th= emselves store themselves' and if we have to set up config files detailing = out the mappings, why simply not just CODE the thing and get the granu= larity, performance and customizability (as in, being able to let= the objects be serialized according to their different internal structures= ) that comes with it?
 
Best,
/Stefan

Date: Fri, 4 Apr 2008 10:23:33 +0200
From: impalah at gmail.com
To: open= sim-dev at lists.berlios.de
Subject: Re: [Opensim-dev] nhibernate progress,= baby steps

Hello everyone:

I hadn't any time to "nhibernatin= g" opensim (as I told months ago) but the code I did is there.

Sean = I know my code may be "complicated" when starting, that's for the use of fa= ctories and DAO's. My intention was to convert every nhibernate object in a= DAO, so they will know how to save, update, delete... themselves (a simple= call to AssetDAO.Save(id) for example). Well, for testing your approach is= better if you don't have enough experience with hibernate.

Second, = my approach was to not modify the current objects, mapping them to nhiberna= te classes. Of course the better idea is to use the libsl-hibernatized obje= cts (with getters and setters) throughout the code w/o intermediate mapping= classes. I think the advantages of having "intelligent" getters and setter= s where we could put validations, or even classes than can serialize (to XM= L or whatever) are more than the "overload and memory use" disadvantages.
Third (fuck, I'm making a list) the ID question: do not use the "auto= " ids (generated by nhibernate). Let opensim create them. The overhead of l= etting hibernate create these ids is higher than the CoCreateId call opensi= m does. If you want to use a byte array for storing ids (due to better perf= ormance), use it; hibernate hasn't any problem with it (the "recommended id= " is an integer because hibernate is often used in "enterprise environments= ", there isn't any other reason).

Four, I tested my previous code (a= part from .NET) with mono + SQLite + nhibernate w/o "touching" anything (I = used the included sqlite drivers included with opensim). I can't help you h= ere.

Five, instead of using the hbm.xml files you can use mapping at= tributes (that was the point where I stopped). The same with the hibernate.= cfg.xml, you can set its properties "programatically". The advantages: if y= ou change one data object you don't have to change the xml file too; and le= ss files in the bin directory as well.

Six, you can generate the db = schemma automatically (I think I provided an example), it's db independent.= If you are using mapping attributes instead of hbm.xml just serialize the = objects (there are some examples looking for "nhibernate mapping attributes= " in google). It works...

Seven, sorry. I wanted to help you develop= ing a hibernate base but I had only 1 "relatively" free week to did it. May= be in the future.

Greetings and good luck

Impalah "busy guy" = Shenzhou




2008/4/3, Stefan Andersson <stefan at tribalmedia.se>:=20
Yeah, well; I'm not saying it IS, just that we need to check on it.
I glimpsed that as I was trying to find out what the 'best practice' f= or storing guids in MySQL databases was; I actually didn't find any good in= fo on that.
 
/Stefan



> Subject: RE: [Opensim-dev] nhibernate progress, baby steps
>= From: brianw at terrabox.com
&g= t; To: stefan at tribalmedia.se> CC: opensim-dev at list= s.berlios.de
> Date: Thu, 3 Apr 2008 13:04:37 -0500=20

>
>
= > Ouch. That's not good.
>
>
> On Thu, 2008-04-03 a= t 19:55 +0200, Stefan Andersson wrote:
> > It seems the MySQL conn= ector for .net assumes the db field is a
> > string for its intern= al MySqlDataReader.GetGuid() implementation.
> >
> > (I = could have been looking at source for an old revision of the
> > c= onnector, but that needs to be checked out anyway)
> >
> &g= t; So, that might mean that going binary could wreck stuff like
> >= ; nhibernate, if that's using a DataReader.
> >
> > Best= ,
> > /Stefan
> >
> >
> >
> &g= t;
> >
> > ____________________________________________= __________________________
> >
> > > Date: Thu, 3 Apr= 2008 13:49:03 -0400
> > > From: sean at dague.net
> > > To: brianw at terrabox.com; opensim-dev at lists.berlios.de
> > > Subject: Re: [Ope= nsim-dev] nhibernate progress, baby steps
> > >
> > &= gt; On Thu, Apr 03, 2008 at 11:19:58AM -0500, Brian Wolfe wrote:
> &g= t; > > *nod* sounds good to me as well. I just have one request since=
> > we'll be
> > > > changing things up at this le= vel. Can we shoot for UUIDs being
> > stored as
> > > = > a byte[16] in order to gain the 10x speedup in SQL
> > indexi= ng/storage vs
> > > > string(32|36) ?
> > >
= > > > That's definitely an option. It did however seem like there = was some
> > > speedup on LLUUID processing if we kept strings.= I'm not sure where
> > the
> > > two end up colliding= on speedup effects.
> > >
> > > -Sean
> >= ; >
> > > --
> > > ___________________________= _______________________________________
> > >
> > >= ; Sean Dague Mid-Hudson Valley
> > > sean at dague dot net Linu= x Users Group
> > > http://dague.net http= ://mhvlug.org
> > >
> > > There is no silver b= ullet. Plus, werewolves make better neighbors
> > > than zombie= s, and they tend to keep the vampire population down.
> > > ___= _______________________________________________________________
> >= ;
>


_________________________________= ______________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists= .berlios.de/mailman/listinfo/opensim-dev


=
= --_3e0aae69-b7da-4b90-ae8a-20bc57d06fce_-- From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID:  
* Overly complex (the configuration seem to, in themselves, be on par with actually coding generic mappers)
* Mandating major changes in our object structure (opening up for encapsulation violations or forcing dependencies on hibernate)
* Totally invasive (as in, in practice demanding its storage philosophy to be acommodated for and coded into core objects)
 
It has been proven a very bad thing to let objects take care of their own db serialization. More often than not, the object cannot be serialized from within its own context (it might not have data like 'parent' needed for relational storage) - and the object itself should not know about any given serialization method.
 
It IS a very bad thing to rely on 'storage' as a prime db serialization concept - you want 'changes': the first thing we need to do when we get to optimize the db layer, is to introduce more fine-grained update calls, like 'ChangeOwner' and 'StoreTextures' instead of 'store object, with prims, textures and shapes'. I have asked several times how this would be accomodated in nhibernate, but have got no answers.
 
Now, I've been asking for some kind of overview of the wins with this and what the drawbacks are, but have so far got none that gives me any idea of what impact this has on our modular approach or on performance.
 
If we're not going to let it 'hibernate' objects, as in 'let the objects themselves store themselves' and if we have to set up config files detailing out the mappings, why simply not just CODE the thing and get the granularity, performance and customizability (as in, being able to let the objects be serialized according to their different internal structures) that comes with it?
 
Best,
/Stefan

Date: Fri, 4 Apr 2008 10:23:33 +0200
From: impalah at gmail.com
To: opensim-dev at lists.berlios.de

Subject: Re: [Opensim-dev] nhibernate progress, baby steps

Hello everyone:

I hadn't any time to "nhibernating" opensim (as I told months ago) but the code I did is there.

Sean I know my code may be "complicated" when starting, that's for the use of factories and DAO's. My intention was to convert every nhibernate object in a DAO, so they will know how to save, update, delete... themselves (a simple call to AssetDAO.Save(id) for example). Well, for testing your approach is better if you don't have enough experience with hibernate.

Second, my approach was to not modify the current objects, mapping them to nhibernate classes. Of course the better idea is to use the libsl-hibernatized objects (with getters and setters) throughout the code w/o intermediate mapping classes. I think the advantages of having "intelligent" getters and setters where we could put validations, or even classes than can serialize (to XML or whatever) are more than the "overload and memory use" disadvantages.

Third (fuck, I'm making a list) the ID question: do not use the "auto" ids (generated by nhibernate). Let opensim create them. The overhead of letting hibernate create these ids is higher than the CoCreateId call opensim does. If you want to use a byte array for storing ids (due to better performance), use it; hibernate hasn't any problem with it (the "recommended id" is an integer because hibernate is often used in "enterprise environments", there isn't any other reason).

Four, I tested my previous code (apart from .NET) with mono + SQLite + nhibernate w/o "touching" anything (I used the included sqlite drivers included with opensim). I can't help you here.

Five, instead of using the hbm.xml files you can use mapping attributes (that was the point where I stopped). The same with the hibernate.cfg.xml, you can set its properties "programatically". The advantages: if you change one data object you don't have to change the xml file too; and less files in the bin directory as well.

Six, you can generate the db schemma automatically (I think I provided an example), it's db independent. If you are using mapping attributes instead of hbm.xml just serialize the objects (there are some examples looking for "nhibernate mapping attributes" in google). It works...

Seven, sorry. I wanted to help you developing a hibernate base but I had only 1 "relatively" free week to did it. Maybe in the future.

Greetings and good luck

Impalah "busy guy" Shenzhou




2008/4/3, Stefan Andersson <stefan at tribalmedia.se>:
Yeah, well; I'm not saying it IS, just that we need to check on it.

I glimpsed that as I was trying to find out what the 'best practice' for storing guids in MySQL databases was; I actually didn't find any good info on that.
 
/Stefan



> Subject: RE: [Opensim-dev] nhibernate progress, baby steps
> From: brianw at terrabox.com
> To: stefan at tribalmedia.se
> CC: opensim-dev at lists.berlios.de
> Date: Thu, 3 Apr 2008 13:04:37 -0500

>
>
> Ouch. That's not good.
>
>
> On Thu, 2008-04-03 at 19:55 +0200, Stefan Andersson wrote:
> > It seems the MySQL connector for .net assumes the db field is a
> > string for its internal MySqlDataReader.GetGuid() implementation.
> >
> > (I could have been looking at source for an old revision of the
> > connector, but that needs to be checked out anyway)
> >
> > So, that might mean that going binary could wreck stuff like
> > nhibernate, if that's using a DataReader.
> >
> > Best,
> > /Stefan
> >
> >
> >
> >
> >
> > ______________________________________________________________________
> >
> > > Date: Thu, 3 Apr 2008 13:49:03 -0400
> > > From: sean at dague.net
> > > To: brianw at terrabox.com; opensim-dev at lists.berlios.de
> > > Subject: Re: [Opensim-dev] nhibernate progress, baby steps
> > >
> > > On Thu, Apr 03, 2008 at 11:19:58AM -0500, Brian Wolfe wrote:
> > > > *nod* sounds good to me as well. I just have one request since
> > we'll be
> > > > changing things up at this level. Can we shoot for UUIDs being
> > stored as
> > > > a byte[16] in order to gain the 10x speedup in SQL
> > indexing/storage vs
> > > > string(32|36) ?
> > >
> > > That's definitely an option. It did however seem like there was some
> > > speedup on LLUUID processing if we kept strings. I'm not sure where
> > the
> > > two end up colliding on speedup effects.
> > >
> > > -Sean
> > >
> > > --
> > > __________________________________________________________________
> > >
> > > Sean Dague Mid-Hudson Valley
> > > sean at dague dot net Linux Users Group
> > > http://dague.net http://mhvlug.org
> > >
> > > There is no silver bullet. Plus, werewolves make better neighbors
> > > than zombies, and they tend to keep the vampire population down.
> > > __________________________________________________________________
> >
>


_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev



_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev


------=_Part_6417_11978504.1207318215374-- From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: I think a number of people were thinking I meant something a lot more complex than I do (at least to start with) So as soon as I get time I'm going to try to write a more clear in depth email. Just that won't be for a few days or more. But yeah basically as you said end to end funnels with servlets attaching to the ends. Dr Scofield wrote: Michael Wright wrote: I guess in some ways it could be thought as a network bus, but I wasn't thinking of the messages being broadcast on the channel, where all endpoints had to listen to all messages and pick out the ones for them. I was thinking, if anything, of more like a cut down web services protocol stack. My prototype channel is just a basic HTTP based one. That just finds where the url of the channel receiver, that the required servlet is currently registered at, is. Then does a HTTP POST of the serialised message to that url. But the implementation should be up to the channels. All the rest of the system should care is that a channel can pass messages from one end point to another, and can map some standard addressing scheme to those endpoints. Allowing for a dynamic system, where the addressable message receivers (the servlets) can move around the endpoints on a channel as needed. And new endpoints can be added. ah. ok. so it's not a network bus, but rather a dual-ended funnel --- like >--< ? with servlets attaching themselves to the respective funnels on each end? cheers, dr scofield? Dr Scofield wrote: interesting thoughts. question: would a channel be something like a network bus? cheers dr scofield Michael Wright wrote: > I'm been thinking and prototyping about some improvements on the grid > servers/protocols. > > One of my aims is to try to separate the network code more from the > logic code. So am thinking of what I'm calling a Channel and servlet > system. > > A servlet is just a class that performs some service. I'm thinking > more in terms of breaking up the current servers into smaller > services/servlets. > > So then we have a collection of servlets that do the various functions > that the current servers do (except I'm not including the asset server > in this as think that is best kept to a proper REST resource based > system). > > Then we come to the channel, maybe this is a bad term for what I'm > thinking, but anyway. The channel has two (or three) parts, the > sender/receivers, which are responsible for the > serialising/deserialising of the messages/datagrams, and also of > sending it to the correct url. To find the url that a message should > be sent to, the other part of the channel is responsible. I'm > currently thinking of this as a basic central hash table service, that > just keeps track of the servlets that are registered on that channel > and the url of the endpoint that they are one. Of course the idea with > the channel is to keep the code separate from the service logic, so > how the servlet tracking is done is up to the implementation. > > While each servlet could actually have its own endpoint/channel > receiver, I'm thinking more of a collection of them sharing a > endpoint. So normally maybe only one endpoint per server instance. > > So all a channel really is: Is a managed collection of known services > and the url they can be reached at. Plus the code for de/serialising > the messages in the format that channel uses. > > The third component is the Router service. Each server instance would > have one of these, that is tasked with routing the messages to and > from the channel endpoint to the correct servlet. A router could be > connected to more than one channel. > > Again a basic concept. The task is just to keep track of servlets in > that instance, to know what channels they should be receiving messages > from. To be able to route a message from a servlet to a channel; > either a particular channel, or the servlet might just say any channel > that has a particular type of service registered on it. Also the > router should be able to do internal routing...from one servlet to > another that is in the same instance. > > > I'm also thinking that the region servers will have such a router and > be registered on a channel(s). And then region modules could send and > receive messages the same way. > > My thoughts and actually my requirements for some other ideas. Is to > have a dynamic modular system. That keeps the network code completely > separate from the services logic. I really think that the current > servers are too err monolithic and really group together a bunch of > services that are separate. I don't mean they should always be on > separate servers, just the code should be separated more and more > modular. > > So my thoughts are lots of smaller services/servlets. And once we do > that, it could lead to lots of url having to be kept track of by each > other servlet if we used the current approach. So thats why I think > the network code , including url management/tracking should be > completely separate. > This also I think/hope could help with scaling things. In that as the > servlets can be grouped together as needed (and even moved around the > server instances). Then a very small grid might only want to run one > backend server instance that had all the servlets that it needs > running. While a much larger grid might have a server instance for > each servlet, and maybe more than one servlet of each type running. > > Also its possible that we could use the same servlets in standalone > mode, as they would just use the internal routing function of the > routing service. > > Another benefit is it helps to make the whole thing more customizable. > In a number of different ways. One of those ways is something that > I've done some prototyping of. Which is as the servlets and router > classes have no network code in at all. Its a simple task to write > different versions of the channel receivers/senders for say a ASP.net > implementation. > > There are still a number of things that need more thought. But thats a > general overview of my ideas > > > ------------------------------------------------------------------------ > Yahoo! for Good helps you make a difference > > > ------------------------------------------------------------------------ > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- dr dirk husemann, mathmatics and computer science, ibm zurich research lab SL: dr scofield ---- drscofield at xyzzyxyzzy.net ---- http://xyzzyxyzzy.net/ RL: hud at zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev --------------------------------- Yahoo! for Good helps you make a difference --------------------------------- _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- dr dirk husemann, mathmatics and computer science, ibm zurich research lab SL: dr scofield ---- drscofield at xyzzyxyzzy.net ---- http://xyzzyxyzzy.net/ RL: hud at zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev --------------------------------- Yahoo! for Good helps you make a difference --0-1037203-1207604039=:17696 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID:
Yahoo! for Good helps you make a difference --0-1037203-1207604039=:17696-- From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: That would allow an identification of the scope of the problem by a grid manager. From there a query to delete any that are empty, with what ever logical qualifiers might be useful. In any case, perhaps I have or have not diagnosed the problem correctly, and any suggestions are appreciated. Charles --0-1656819267-1208732199=:62460 Content-Type: text/html; charset=us-ascii
The situation exists where a number of avatars have multiple root inventory folders on OSGrid, and I suspect on other grids as well. One of the implications is that this obscures the inventory as our search stops at the first root inventory folder it finds, that is the first one whose parentFolderId == zeroes.

Having a query to identify and then remove completely empty root inventory folders might help make this situation better, but it involves a fairly complex mysql query that is currently beyond my abilities. I am hoping someone could help out a little here with a query that can be used to identify multiple root inventory folders in a grids mysql database and a query to would allow them to be deleted, perhaps one by one, that would be fine.

This query involves finding all those avatars with inventoryfolders entries where more then one parentFolderID is zeroes.

From there, it involves walking the subfolders (those folders pointing at each root folder whose parentFolderId is zeroes) and determining if any inventoryitems are pointing at any of those subfolders (Clothes, Objects, Trash, Scripts, Clothes, etc.).

That would allow an identification of the scope of  the problem by a grid manager. From there a query to delete any that are empty, with what ever logical qualifiers might be useful.

In any case, perhaps I have or have not diagnosed the problem correctly, and any suggestions are appreciated.

Charles
--0-1656819267-1208732199=:62460-- From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: each root folder whose parentFolderId is zeroes) and determining if any inventoryitems are pointing at any of those subfolders (Clothes, Objects, Trash, Scripts, Clothes, etc.). That would allow an identification of the scope of the problem by a grid manager. From there a query to delete any that are empty, with what ever logical qualifiers might be useful. In any case, perhaps I have or have not diagnosed the problem correctly, and any suggestions are appreciated. Charles_______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev --=_alternative 003FD97485257432_= Content-Type: text/html; charset="US-ASCII"
Charles

I think you have captured the technical consequences of having multiple inventory roots, but to resolve the issue we need to properly understand the whys and wherefores of multiple roots. Why do avatars have multiple roots? what are the functional differentiators? I.e. why does it matter that we stop at the first? I was recently looking through the new inventory/capabilities code and had had the same thoughts as you expressed. It seems to me that there can be only one (apologies to the Highlander) root directory. Given the information that is in it, there is no reson for this directory to exist outside of an extant presence, and all of the other hierarchies should exist as (apparent) subordinates to this directory. This then raises questions of convenience as a result of having something that is an unnecessary empty layer for the majority of inventories where only one hierarchy exists; there are a number of ways to address that such as collapsing any monotonous hierarchies. I assume the overwhelmingly most important goal is that at the end of the day the inventory is complete, predictable, and unambiguous.

Best regards
Alan
-------------------
T.J. Watson Research Center, Hawthorne, NY
1-914-784-7286
alan_webb at us.ibm.com


Charles Krinke <cfk at pacbell.net>
Sent by: opensim-dev-bounces at lists.berlios.de

04/20/2008 06:56 PM
Please respond to
opensim-dev at lists.berlios.de
To
opensim-dev <opensim-dev at lists.berlios.de>
cc
Subject
[Opensim-dev] multiple, empty, root inventory folders





The situation exists where a number of avatars have multiple root inventory folders on OSGrid, and I suspect on other grids as well. One of the implications is that this obscures the inventory as our search stops at the first root inventory folder it finds, that is the first one whose parentFolderId == zeroes.

Having a query to identify and then remove completely empty root inventory folders might help make this situation better, but it involves a fairly complex mysql query that is currently beyond my abilities. I am hoping someone could help out a little here with a query that can be used to identify multiple root inventory folders in a grids mysql database and a query to would allow them to be deleted, perhaps one by one, that would be fine.

This query involves finding all those avatars with inventoryfolders entries where more then one parentFolderID is zeroes.

From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: at each root folder whose parentFolderId is zeroes) and determining if any inventoryitems are pointing at any of those subfolders (Clothes, Objects, Trash, Scripts, Clothes, etc.).

That would allow an identification of the scope of  the problem by a grid manager. From there a query to delete any that are empty, with what ever logical qualifiers might be useful.

In any case, perhaps I have or have not diagnosed the problem correctly, and any suggestions are appreciated.

Charles_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
--=_alternative 003FD97485257432_=-- From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: ared LSL scripting lib (I suggest calling it OpenSim.Scripting.LSL in accor= dance with our recent ambition to remove superfluous namespace levels)This = project can then hold all types (or extracted basetypes) common to both the= DotNetEngine and the XEngine. These two projects are HIDEOUSLY duplicated = - even the LSLTypes are, which would DEFINITIVELY go into the OpenSim.Scrip= ting.LSL baselib. =20 Doing this would be a good start for further extraction and refactoring eff= orts. =20 I'd do it in the blink of an eye, If I knew somebody would catch the refact= orings and validate them on both engines. Best regards,Stefan AnderssonTribal Media AB Join the 3d web revolution : h= ttp://tribalnet.se/=20 Date: Mon, 9 Jun 2008 19:41:33 -0700From: cfk at pacbell.netTo: opensim-dev at li= sts.berlios.deSubject: Re: [Opensim-dev] Two sets of LSL function implement= ation files. So, how do we evolve this mess back to sanity. At this point we have two co= pies of the LSL function implmentation. Some folks are patching the Common/= copy. Other folks are patching the new file.I looked at the first 100 func= tions (there are 300+). Some in the Common/ are not implemented. Different = ones in the new xengine fork are not implemented. Most are identical. I hav= e been here before with a source code file that gets copied, renamed, then = two different groups start morphing it to a different place. It just gets w= orse and worse.Charles ----- Original Message ----From: Justin Clark-Casey To: opensim-dev at lists.berlios.deSent: Monday, June 9, 2008 12:49:33 PMSu= bject: Re: [Opensim-dev] Two sets of LSL function implementation files.+1 t= ooYes, let's make as much code common as possible, please.Frisby, Adam wrot= e:> +1> > > > If we can avoid duplication (and only splitting where the en= gines > themselves differ) I strongly agree.> > > > Regards,> > > > Adam>= > > > *From:* opensim-dev-bounces at lists.berlios.de > [mailto:opensim-dev-= bounces at lists.berlios.de] *On Behalf Of *Charles Krinke> *Sent:* Monday, 9 = June 2008 1:43 PM> *To:* opensim-dev at lists.berlios.de> *Subject:* [Opensim-= dev] Two sets of LSL function implementation files.> > > > We now have two= sets of the implementation of the LSL scripting > functions themselves.> >= The original one is :> > OpenSim\Region\ScriptEngine\Common\LSL_BuiltIn_Co= mmands.cs> > The new one is :> > OpenSim\Region\ScriptEngine\XEngine\LSL_Sc= riptCommands.cs> > In these files are implementations that are duplicates o= f each other, > such as llSay() and dozens of the others.> > Originally, th= e Common\ directory was defined to hold all the LSL > function implementati= on and I concur with that decision. In fact, I put > all the prototypes in= to that file for all 300+ functions.> > Now, we have added a new copy of th= ese functions and they are beginning > to diverge.> > I believe it is of so= me importance that we put common logic into our > already defined Common\ d= irectory for various scriptengine > implemenations as we move forward.> > C= ertainly, I am not advocating a fire-drill, but rather an evolution > back = to our original mission. This is not to preclude any functional of > Xengin= e or dotnetengine, but rather to concentrating on resolve the > current dup= lication of code from our Common\ directory.> > Charles> > ________________= __________________________________________________> > > -------------------= -----------------------------------------------------> > __________________= _____________________________> Opensim-dev mailing list> Opensim-dev at lists.= berlios.de> https://lists.berlios.de/mailman/listinfo/opensim-dev-- justinc= cJustin Clark-Caseyhttp://justincc.wordpress.com___________________________= ____________________Opensim-dev mailing listOpensim-dev at lists.berlios.dehtt= ps://lists.berlios.de/mailman/listinfo/opensim-dev= --_dc5ebc13-e411-4a88-abab-c358d094219f_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From just glancing at the code, I see no reason w= hy we couldn't create a shared LSL scripting lib (I suggest calling it= OpenSim.Scripting.LSL in accordance with our recent ambition to remov= e superfluous namespace levels)

This project can then hold all types= (or extracted basetypes) common to both the DotNetEngine and the XEngine. = These two projects are HIDEOUSLY duplicated - even the LSLTypes are, which = would DEFINITIVELY go into the OpenSim.Scripting.LSL baselib.
 
Doing this would be a good start for further extraction and refactoring eff= orts.
 
I'd do it in the blink of an eye, If I knew somebody would catch the refact= orings and validate them on both engines.

Best regards,
Stefan Andersson
Tribal Media AB
 
Join = the 3d web revolution : http://tribalnet.se/
 



Date: Mon, 9 Jun 2008 19:41:33 -0700
From: cfk at pacbell.net
To: opensi= m-dev at lists.berlios.de
Subject: Re: [Opensim-dev] Two sets of LSL functi= on implementation files.

So,= how do we evolve this mess back to sanity. At this point we have two copie= s of the LSL function implmentation. Some folks are patching the Common/ co= py. Other folks are patching the new file.

I looked at the first 100= functions (there are 300+). Some in the Common/ are not implemented. Diffe= rent ones in the new xengine fork are not implemented. Most are identical. =

I have been here before with a source code file that gets copied, r= enamed, then two different groups start morphing it to a different place. I= t just gets worse and worse.

Charles

----- Original Message ----
From: Justin Clark-Casey <jjustinc= c at googlemail.com>
To: opensim-dev at lists.berlios.de
Sent: Monday, J= une 9, 2008 12:49:33 PM
Subject: Re: [Opensim-dev] Two sets of LSL funct= ion implementation files.

+1 too

Yes, let's make as much code= common as possible, please.


Frisby, Adam wrote:
> +1
&= gt;
> 
>
> If we can avoid duplication (and only = splitting where the engines
> themselves differ) I strongly agree.>
> 
>
> Regards,
>
>  >
> Adam
>
> 
>
> *From:* opensim-dev-bounces at lists= .berlios.de
> [mailto:opensim-dev-bounces at lists.berlios.de] *On Behalf Of *Char= les Krinke
> *Sent:* Monday, 9 June 2008 1:43 PM
> *To:* opensim-dev at lists.berlios.de<= BR>> *Subject:* [Opensim-dev] Two sets of LSL function implementation fi= les.
>
> 
>
> We now have two sets of the i= mplementation of the LSL scripting
> functions themselves.
> <= BR>> The original one is :
>
> OpenSim\Region\ScriptEngine\= Common\LSL_BuiltIn_Commands.cs
>
> The new one is :
> > OpenSim\Region\ScriptEngine\XEngine\LSL_ScriptCommands.cs
> > In these files are implementations that are duplicates of each other= ,
> such as llSay() and dozens of the others.
>
> Origi= nally, the Common\ directory was defined to hold all the LSL
> funct= ion implementation and I concur  with that decision. In fact, I put > all the prototypes into that file for all 300+ functions.
> > Now, we have added a new copy of these functions and they are beginn= ing
> to diverge.
>
> I believe it is of some importanc= e that we put common logic into our
> already defined Common\ direct= ory for various scriptengine
> implemenations as we move forward.>
> Certainly, I am not advocating a fire-drill, but rather an e= volution
> back to our original mission. This is not to preclude any= functional of
> Xengine or dotnetengine, but rather to concentratin= g on resolve the
> current duplication of code from our Common\ dire= ctory.
>
> Charles
>
> __________________________= ________________________________________
>
>
> --------= ----------------------------------------------------------------
> > _______________________________________________
> Opensim-dev = mailing list
> Opensi= m-dev at lists.berlios.de
> https://lists.berlios.de/mailman/= listinfo/opensim-dev


--
justincc
Justin Clark-Caseyhttp://justinc= c.wordpress.com
_______________________________________________
O= pensim-dev mailing list
= Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman= /listinfo/opensim-dev
= --_dc5ebc13-e411-4a88-abab-c358d094219f_-- From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID:  
Doing this would be a good start for further extraction and refactoring efforts.
 
I'd do it in the blink of an eye, If I knew somebody would catch the refactorings and validate them on both engines.

Best regards,
Stefan Andersson
Tribal Media AB
 
Join the 3d web revolution : http://tribalnet.se/
 



Date: Mon, 9 Jun 2008 19:41:33 -0700
From: cfk at pacbell.net
To: opensim-dev at lists.berlios.de
Subject: Re: [Opensim-dev] Two sets of LSL function implementation files.

So, how do we evolve this mess back to sanity. At this point we have two copies of the LSL function implmentation. Some folks are patching the Common/ copy. Other folks are patching the new file.

I looked at the first 100 functions (there are 300+). Some in the Common/ are not implemented. Different ones in the new xengine fork are not implemented. Most are identical.

I have been here before with a source code file that gets copied, renamed, then two different groups start morphing it to a different place. It just gets worse and worse.

Charles

----- Original Message ----
From: Justin Clark-Casey <jjustincc at googlemail.com>
To: opensim-dev at lists.berlios.de
Sent: Monday, June 9, 2008 12:49:33 PM
Subject: Re: [Opensim-dev] Two sets of LSL function implementation files.

+1 too

Yes, let's make as much code common as possible, please.


Frisby, Adam wrote:
> +1
>
> 
>
> If we can avoid duplication (and only splitting where the engines
> themselves differ) I strongly agree.
>
> 
>
> Regards,
>
> 
>
> Adam
>
> 
>
> *From:* opensim-dev-bounces at lists.berlios.de
> [mailto:opensim-dev-bounces at lists.berlios.de] *On Behalf Of *Charles Krinke
> *Sent:* Monday, 9 June 2008 1:43 PM
> *To:* opensim-dev at lists.berlios.de
> *Subject:* [Opensim-dev] Two sets of LSL function implementation files.
>
> 
>
> We now have two sets of the implementation of the LSL scripting
> functions themselves.
>
> The original one is :
>
> OpenSim\Region\ScriptEngine\Common\LSL_BuiltIn_Commands.cs
>
> The new one is :
>
> OpenSim\Region\ScriptEngine\XEngine\LSL_ScriptCommands.cs
>
> In these files are implementations that are duplicates of each other,
> such as llSay() and dozens of the others.
>
> Originally, the Common\ directory was defined to hold all the LSL
> function implementation and I concur  with that decision. In fact, I put
> all the prototypes into that file for all 300+ functions.
>
> Now, we have added a new copy of these functions and they are beginning
> to diverge.
>
> I believe it is of some importance that we put common logic into our
> already defined Common\ directory for various scriptengine
> implemenations as we move forward.
>
> Certainly, I am not advocating a fire-drill, but rather an evolution
> back to our original mission. This is not to preclude any functional of
> Xengine or dotnetengine, but rather to concentrating on resolve the
> current duplication of code from our Common\ directory.
>
> Charles
>
> __________________________________________________________________
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at 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 at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
--0-240244063-1213105201=:37311-- From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: =20 I'm working with Melanie on solving an issue related to the script engines. =20 Intro Currently we have two script engines, each with its special purpose, that have very much in common. DotNetEngine which will assure that script engine does not bother OpenSim. It does this by queuing its work internally on multiple places and processing queues when it has resources to do so. And XEngine which prioritizes script execution, more suited for applications like gaming servers where for example the bullets needs real-time execution at any cost. Making one engine that supports both will make the engine less efficient and more complex. =20 When DotNetEngine was originally written the purpose of its "Common" component was to provide a common base for script engines. Though it very well could serve its intended purpose there are some problems with it which lead Melanie to rewrite portions of the engine. This is a positive and very welcome step in the evolution of the script engine. Believe it or not we were not able to foresee all usages when DotNetEngine was originally designed. =20 Problem Currently the two script engines share most of their code. There are relatively small differences between them considering the total amount of code. This means that we have a lot of duplicate code to maintain. And without a proper interface/modular system a patch that fixes one bug in one engine may introduce a new bug in the other engine. There has also been some concern about understanding the code of current DotNetEngine. =20 Goal We want to support multiple script engines, and development of new ones. It should be easy for people to write their own script engines. But we need to ensure that the code script engines has in common is actually shared. A preliminary draft has been briefly discussed and put into a picture with boxes and arrows. =20 Basically we do 2 things: 1) We cut the engines into multiple modules that provide services. 2) We create a place for modules to register their services (commands, events, schedulers, compilers, etc). =20 A script engine that starts up can choose what services it want to use (if any). This will also allow us to create new engines which do not necessarily rely on LSL commands, LSL events, current scheduler, etc. And third parties can provide components such as compilers, schedulers, etc. It allows us to run experimental development of parts of the engines without affecting stability for running grids. And if we break something in LSL, it's just a matter of sticking an old LSL .dll in the bin-folder. For example if someone were to write a lexer for the LSL2C# converter it could be provided as an alternative compiler so that adventurous people could test it. =20 Hopefully understanding and maintaining the engine will be much easier for other contributors as each component is fully isolated from the engine itself. =20 So now to the hard part: Should we call it Script Engine Services (SES) or Script Engine Component Services (SECS)? =20 =20 =20 In case you are wondering. Yes, the tube is angry at the square. In fact, that is the only reason it is in the drawing. =20 BR, Tedd ------_=_NextPart_002_01C8D00D.200DC7A3 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Good news = everyone!

From now on there will be lots = of SECS for everyone.

 

I'm working with Melanie on = solving an issue related to the script engines.

 

Intro

Currently we have two script = engines, each with its special purpose, that have very much in = common.

DotNetEngine which will assure = that script engine does not bother OpenSim. It does this by queuing its work = internally on multiple places and processing queues when it has resources to do = so.

And XEngine which prioritizes = script execution, more suited for applications like gaming servers where for = example the bullets needs real-time execution at any cost.

Making one engine that supports = both will make the engine less efficient and more complex.

 

When DotNetEngine was originally = written the purpose of its "Common" component was to provide a common = base for script engines. Though it very well could serve its intended purpose = there are some problems with it which lead Melanie to rewrite portions of the = engine. This is a positive and very welcome step in the evolution of the script = engine. Believe it or not we were not able to foresee all usages when = DotNetEngine was originally designed.

 

Problem

Currently the two script engines = share most of their code. There are relatively small differences between them = considering the total amount of code. This means that we have a lot of duplicate = code to maintain. And without a proper interface/modular system a patch that = fixes one bug in one engine may introduce a new bug in the other = engine.

There has also been some concern = about understanding the code of current DotNetEngine.

 

Goal

We want to support multiple = script engines, and development of new ones. It should be easy for people to write their = own script engines. But we need to ensure that the code script engines has = in common is actually shared.

A preliminary draft has been = briefly discussed and put into a picture with boxes and = arrows.

 

Basically we do 2 = things:

1) We cut the engines into = multiple modules that provide services.

2) We create a place for modules = to register their services (commands, events, schedulers, compilers, = etc).

 

A script engine that starts up = can choose what services it want to use (if any).

This will also allow us to = create new engines which do not necessarily rely on LSL commands, LSL events, = current scheduler, etc. And third parties can provide components such as compilers, = schedulers, etc.

It allows us to run experimental development of parts of the engines without affecting stability for = running grids. And if we break something in LSL, it's just a matter of sticking = an old LSL .dll in the bin-folder.

For example if someone were to = write a lexer for the LSL2C# converter it could be provided as an alternative = compiler so that adventurous people could test it.

 

Hopefully understanding and = maintaining the engine will be much easier for other contributors as each component is = fully isolated from the engine itself.

 

So now to the hard part: Should = we call it Script Engine Services (SES) or Script Engine Component Services = (SECS)?

 

 

In case you are wondering. Yes, = the tube is angry at the square. In fact, that is the only reason it is in the = drawing.

 

BR,

 Tedd

------_=_NextPart_002_01C8D00D.200DC7A3-- ------_=_NextPart_001_01C8D00D.200DC7A3 Content-Type: application/octet-stream; name="oledata.mso" Content-Transfer-Encoding: base64 Content-ID: Content-Description: oledata.mso Content-Location: oledata.mso AJAAAHic7NZlUFxhlydwGgju7hYCJEGCaxonWCC4WzdOcNdGAsGCuzvB3R0ah8bdIQSCuwSbfmdn qt6aDzv71u6Xrd3/rV89t66dunVO3bqTE/ibuTUUWwj/JUAEJITnF3QElH86BvgP/x48BPj5l5d/ 7P7n+o+8/P/8X5UnuH/0DwneO2S4V3D/6DkqHBocOhwGHCYcFhw2HA4c7v8YAQR8OAI4QjgiOGI4 EjhSODI4cjgKOEo4KjhqOBo4Wjg6OHo4BrjXcIxwb+CY4JjhWODewr2Dew/HCscGxw7HAfcBjhOO C44bjgeOF44Pjh9OAE4QTghOGE4E7uO/zzYCgiicGJw4nAScJJwUnDSczH/M9P8LUUWwh28u8F5I I9jBVycEz//6KfifhgQ+Mf/5LMB/cy3eDyA19uQQ4J+/F0bwDnLBu8ULX/nhXeSEd4zzX6hPhoAI +Of3+V+5BxHuKexfKPLf5F+t/386/1v1LxAQPDKO0jy1CRe6XiZSU7+ymr9hCSTnA0j3nYSjhzaD 8EIVykLYMBhQdMpVeelycqZz/DWlxQNKZ8M1Kyo0eirkK2wMWi378rTjNOOGSntXCSdPj0+9Ty9X b243fLO8fQxNnbi498YEsy/v20Ut2r2/r3icFRgQ3jVxvdrMyQYB/hodbAqjYKAiHK3d+oXnrWup vWg9ayUCkc/tcES9bq2ynFECw4zpWfGS0N5/4wWhBX60RPSP2KS/QwP0otBLLTKEMITQH+H14d+g oULRvqGJM1DhK6FZfMPsJeYk2Apx+ORBJ0Mv81oEH4wHxgd9I+2l3Ao6k76jf8QHhDqGnoeih4aF yoUOh3YDVlDEAmMYAvF6QktC8aA8UiwgIRAKiAlEAuID4TAcrZENT1oIgGgYEPHDQiWG8C/xMfEw 8SPwaOmAUqwyrOKs0ix4U6FkUqwMOPjRXxiS6JNeE+CFhRKHMkLlpbhAxBLBsuLlMgUM03h/QrGg ae6+Ry+Ul7QBJwUSWnH7w1q5E+rVOI/xDMj1kArPOlG8RROk6+sg0e/P16ttIWKoh238dFFRdWc9 Qmim+y0JLz/Hu0gw/Xu6gBMbHUoI602ixB8hXBQK5GnfiV+afWmsN46Qxm32TxvtgaLHa5zPlWup llfJ2GMHovYv2cAuz/2Nh+tn98ubdcNn2N8XYbdryC7kU0CQyePL2xVgKJdSbbVWF2/U1LG6aebo s1wrwZjgCyGC1p8aAQF08c5rDa8OBb+tshU8HSQ7TsuHl86b8WdRVk52jcQi3SQlmLKignosfQkn 7ZtKXSAeN4pNe8egV2wsOufbkfoAS64vwjdrnuCODvHBbxxaLw3eqZlCuY9smhvx4BPSWnObmCdC Mmvfi18DnQsbwT+8//q3VTjMypA98Vm+IUcQ6BNPuocep0MoXvJYx0/6qjQb1+46Xa7ObBu3NbKe EjyPn5PpyVj4B/28x7ynC4wiZunEZ0SFdmzXtscaDwIs+PWlIxhJRNHHF2Ze0g/HeRf79HBHB3D2 iE7NA6eyOgbHz4Nv7F2lLRF/d/dcm91gTp1W8j74OWfwPrg4l48jBnG6PrQ1aCOi7NiTk0V2aBh/ OKHxbpJR7tKrCnQnfIwki2yDtj13iGZFMyhSSATnZWNI52L9wkxEit08JfZ2ub19hn5FguxRUOS5 DW6eQxpf1pGK8migOTfjrmXPg96CuTcv1hOQYl9ELOvYnk4pHJG6ls/ORw/FHQ6fnhceRcwh9+4r 2REphM+dTxDaW8h89vkL7YT9Ccde5jBOpfjtzw/Rtwozy6Az0tEewZFgpJoL62l6Hy/8WgWBn+7r yajKxc9Nto9nyV5flSZGAoLIp5BUXha6Mm73dDPx3S25cyv3EEpHpTq8wMbdNK9ZhqbJg6WS8N7G m9BFIF5fX+c0NCQiNtmtIRYrZVqjet+euEodgsgbvpKjYWIidSZUcVTX1SEJl7RtGWsdU38pbl5D VhIhBiGpXkHeQfaoWjLXxVKxkryCnk6r3hm6f1j0kkyuaXCej8AB5a3j5fGL4e3iQiCJZlwwU8gQ HznlhkffPAx5LQInar36i323mPr6lw7xUl89RIVJjrM7Gh7iO+3AIv5JmyuUkPXuWUptryDpH9Qm hfzah9iSVyh8rZ3NhZ98kOIlFzE5+kjxkGrwRI7cN8Ut6H+zQsHu+UPl3L/nCIV2svxwNt6rOfh4 qRU5V/5iMJTrwqkRfCRICQro743l66Gy1+PFNdKXox1mBnFqASrUteU5iLnkg8fsm61pbIrAP75Y rPoQr2F2IRb4VIbTDDQ5he3F02z9sHcIgiqpg0SHbxK6+39zcUiM5x9OPZGtiKSuiCi4SFJ7kCy9 Zsv8RLOttwbZtzqOxgnZf4WCTtK74hT0YfFMEAaqYYxUluvUEXG7Hd8b10VHF8sfnqQhshsGWtSo nE0SAq+gk0aPuSvWjlE2HmJho3n+Rl9xjmtNEjG63Bdwqxa7vyJT+cX9IjihWzRT4/qaPC6P+4c9 fTQPte+BcUNY8IxVIdipTDXXtcRBtiTmR6eDfPCqKn2V+hBubaqOK+nHdI61lpYm5WADE3w1hkJY D6HeZDV7KOApHO1nAli+hUprBL0woyhhJvHiawhXu6qb+QlHrahEa6Q2I3NrUlno5rtdERcGo7ek LLt88i1f3kIsyxJwK+Jw3xMv98PM8cdj+1YmyZZmmHh/AcUqnJ7MTPhyuA6ZexMH9hRTtRKbvVQV kEOtIyzD/PmTwPxJO7b46S4Dfcqhc+hqv+eqJskn/vLmYbYJ+sSVF0TM5Sa6MHHLdqhTH8i0Yrx3 UsW5p2mocPlyGWpwaCUZtTwDTm2TpC1WFz7VNRpZblgHLXiN5jcK7QRHWeyzMy8wUjDeP2b4+OWw 2tYGHSsZdeTU/E6lbXQT7hyPX/wtV7b4u0VDn/tR+xvMYypK0J7wk/+b96RWQ1t7AmXJ3XmfnayG ozyFwGu0+3ZVPRRzaReCfBj91tJReeqO2rGuMm4G8zmTo39Nj6RxRAKkSyaZhorWxaROr/Q9XqlO C76OoNz27XRM/OU7VX04JLLx8CnqK9AulanL9+weN7uCDaLT1kLlo2uo5tf56OYJbinJENgHcQep HaoX/nbsfDrCy9ZzXg9qoqQ+6xLlEAgH0i7vwzBtYCvzGbTyIaulQCgt30Erj1/yuAPPn5tCie+q W6F06ZTUyL7NvyoLzpTu3euAWI7tiBn0ZaZLxM1W22sWfm1P4pcNfc/jCzAGnD0dT98W15DEZCZo f8jWWMPfuGHh1xbnMO0zmDZMuM+RhH1zoJbJdyBlZGOp71tLVjhHveuy9zKJbXHSFLB2D3P1L2c7 +tbrsbIlFK/G7awKKNiDWsnqPBDW1RvMVihPZZ2rpTD7dz7aaPNQL4z9zbNBx8Pi3qBel0cArf2b ciUDH0NAplGOs0uFLYeDwXvO9YCXv4JS946gj46v5I0oR0NZNanZIEsRUXFJWa4qZtF1ZFT8m64P k2/vG5gHrZ5dDZUfdMZYvZ65UAHnuaw6RVkHpYknKZoH+pO8kg8Bmg4j4e4DA2nu5minWOnueQez ewYqxUqQwz96767eE/+1iM4gd/hpwwiRsBw7TCG+2DvpnOUpvfn8J/njzihNdPIRBZvLVWavt8bM kycpcoAKalv2rB/rX1lVuiXmexB8nqr5Ps6EJw2fvVSowMasI7R1B9PVUOvBfNm+1PFQ8pm/mA+4 N2EL90Y3poxpur2kimv5VDZEFJLsUBlegcAsAa8RQs6P/SN3TorHlLmxTTXcucLr3EO+Lekiv03t my0mraMVKlMg58kfwQ9OLWfTZg9IsMLF+k9ZzEaDLr9330SeT3A+iGI7+bcYGX3Wec0DOqm5ty1a 4Exv2Sm+3c1SxBEk59clMnwoOlGd+cUWMWgkVLP7kFs7xx0nuZ5hnYT1GrNu/+2xeLrUitSDtGnF /vSZ8QRQrYKQzWXZAG1A9e32ZxBmG3i9TxosRYDfmFv2Ijkl108cbFzF1vgJnWaSAso6lw2Sp2pO uWrikiAtfhWhwO+mS95ByNEyICcWYhphGv3LefjVMLVc/K9E5EnTYQzcJcZUIKjEJhqUTJFQeDIm 0Akz4uX5Yska2zokPne5ILdR4l5aqm5UYleeQZng2VGnqHMEhvi6epH4KcYVDa/4PM3xLUm7VpQT IHmmQ9A8m6m9m6lRcZse2bss25nYNXE1fqjqKPizGGvO7MkssNx6Mntb8LL5KkmhGPJMI6fFpp2n 6aTRxjO3Fj7IDqh1N2q52lxK9Tnc/cSMaGhQaSvpQb7+ek3gGsraKSRd99bG4jiMuP+B18iG3eoD 6wyG6LpddJ7c38RS148Aunyn/qyLIZTq57q6hUpXEevGYM4vJ+ruJ2o9w1iSmn0Np4chRCLWgl55 F2WfxrX7p2byWfj7kaVdIAf0/IF/dFNnaiZa/FA15DJzK7vQk2lrmQkqhzMpYL4U4iRBQd4j7Mq3 Rss+JoPB1Fqdq0YjZdYkaDQ8fCsCwGp+AwdTmPW7NsZ3r6G73+c2fupVBZnEp8pMBElWeXnZUKTI PMDK83c3SCas5S2XV2bvHpdpHPufLix2Dd5wtEEUs87Bc/rWd6fFdXtMciHOMkY35R0NgkeeXaMd G4qebB7mSu5XY5PEhe95jepJrdDM1wyTGyONuhZEptpn/S+ivDUeMpixdnF9l30iEPuWf0wg1Jct +n2YUlf3/nlzJV54QiQ74jVP7btfrEDshyprW6+BFyoM/oI4Uv44JoxvoWnIVaAknHBv4+5yw6GZ 7HcSVUll0kz6oI4IShc/quhNom1zIzVrIOJ9o5UpNHseUDIg0JLUKtWPIQb/cWxT/yocyhuYtGgh VPpTbi1yUFU/JgQynWfHNF1ORDpdtsqLnX4gD1sxq3Tbb6mnZ2sK8+Nv2F4t7uPwtTPT8XCcD1D+ bqZugnqb8OIA8BZocbx3r/fxA0JCLdMsKYd4y11zIk6K2CN6isA6dRFZ2QIlEIGLn2jtRGs6g+1g 98FLWMLKbZkTxHQkHVwZ+UegqjXe90HjsFN4MVctKaJ29liYoquz1onRAmgVg0sYTaKsBhX2bZfC pxse0STicLAv/1LfQKrAgy2XMdYgw8n+tjXWyCXI7dRZ4WxQZLkDfXlp+Y1uIp+eXvmrueW6ZZTj qmXRhoSklZNVnMeV4iYOa2XrjclKq88/x8tN62I12+M7K/giSp9WsQdqD23Krsz2sg+JosyaVihX Ph9LGaWOrwjKby4JfhJscVa6sjv0aJs5Ol2kmy9MXmN1wguT/lEqG6uKnPXz7sA3j0PKNc+bIVVI HptsO4IlCjncbJvMMU1AGcstIjqc9J1dWMM26YFhww/kZjkmWXOFJFl1AlViA0M2gJHNGN9F8TeM X2vC6bbCqCC7WvTapdqs1+i1iktu5AJ0wvRtrN50NonXQ6xEfjodDRZ1iKrtsPOXn8I+wqwlQtP2 +PiMRk7lRw23HRj2ANO2Xg1exi/LAVc2Ra9ei23vGd8XhF+lZyYuHmyj1NYtTzYR6SYU+Ye3nyMK QMtgieeSkKGD7dLs91i+EesMK+gVnH/n0eiKq9nbe2NOkBPwnQ+1gn1dT4jaXc77zovALmmWhsFd CE7Xrvj5iMqmMXTPyQkaM8ra64/5nXaOfDL1c4WBVhsQD8GL5ISxjqKVIr8J52Bhy5Uvtmdo1SIG jvd3DSrBwvtT86SnLur6951lL834YJnLVVf3E8OXI039LRySTDef9T3iAETL15MyBvxQKmYV9hRV E1nqgP4t48yLqPPj0jcLYERVKL52HnqW91cNP0VHx/X5z3pZcu6262npMD8ftPZV0DjQW/BlL/wp +pT9b03rx46OrSUHh8usBmu7lqaROKcc6OxOEsdAZkcvTuUHaElEEqkBP2u7pt/5CobPy04GdI0Z qEWrmmno+Y7S3UMXY0906dUWs8Eis8Eds4HTdjz7MrPBlXJryr5/g3XDLu8M8RznNaZGFYZ2KfUs yDXGC0OvZGDplXW18mdw2dLt7P2u9yh5mgnFB13Cn7FWIJ4hfhs3myg7QJI4s8f4LvXu1XJuQ741 80JgS8NUQ0lDS0ObdfRsVtlTbuP3Oo9RuZ0ewB+/N9zu5RJCL5QqwSRHSMC729s/nQv10Q22y6OM XdTNii2nvxdPVthpkgkvxSpVcqX2E0p35gCUkWzG7rcedeKkejgfLTmPeNyKvvJ3hqKULlksYdc/ 1WcvwTCM2touq7kW+uXUdhgxXkm6Nq9JihMw5A4Z8KgQ9ekR0ofv6XgNB9csaEY4SRXm9TE4iG3v 3F5GRcAgoX+lqWriye7CJPsx+99DD/uzQ99DjcJTtfqjocsTQW39rR5Rpi0HMk4hQk9nE2oTwbQx UdaFuno9lgn1AXQPr+Kkhgfjowwo/Pjy/vxyLPMewlUSwE/2FP3Y04Hq7bJ9hNazq1nNxHyAmr1d PEy+B7QUEvQs/Z2nD3ZzVt7mrYF5iytE6TqDMp6a4vTi8CoY00Qzq6pjliZq3n/At9Ea5OuRLhEU TmeA1uZi4L1VG1FKIB26GY5KbErYiA8g0SmOzMWba51FeWca/lc3pmhI7WqBRsOnrLlw8l0khn/Z V3W7UvTSpdI3pSrxth62TOlJNN+ZURCiRmc8LyYDWPE+oW+cViV1nCA0T/F8+6wiBG4eaj3/IUiv mNLrMkUJZaGUGs7SQBCGSuCoXNzmgS0UlJUBMsOSlCttG1e2Pn1JNOZEBvaclcdZPioX2BXsswxV 7HfGzd6Jv5gyzy7N8r35Ojll05Y+V+H+kkzAdsao7rt61sn3nFyheQgBxkYbFUFW7VUQ/tQga/eQ coMAKUPMdnlG5tMXMQddW5b5/GMCoZBPaCfynQRreDc6FIwWmxaIMnw/QOkeGt8xUiQvxYktT46Z OTWppvakB20v6XM5/GfP9hMcYjDUXelwWMR1Gf/ooCYFYFXLyxQdioPIWqwBqTgga4bhglemDrVq eZFX5fcz1VyRj7IyTIzxJTvgoeCoFlgWHTBV/09zN2HB2I0+vgwTO/3uyFKBRa2aboratnjx5/PK Gtq41KjrKBUYL5jB1fHX8itThN1aKsbD0kxzCY4lRCfEs7Sto7qsfO53l6E+ll0JjjslDV0QZ3sl BWUC3KFUZRO221utUsTeI98G+8uo+isfV7xbhyuHq54ti3sECVwt0ixJAMlxzzKj4URNxlgEzVYK dOVHv6oV4iPYjiCajBpzBrn+ba5L16TiejkjjbM8i438pB4tpiIKco+IXUjnuFSnRMhZ/bhUogr9 R4QPWCiBbKZtdb6WQ2jhbzFuvo5+T8uwsxaOER9al99KMQEKB2QOr8OA3cCedY/UBuov6jhz7oip eBTrZGJsn9TScQjEQmoXYuYtQgFvE6wCMMq9wF+ub6BdXNTPaIxO4tGchTMFVNgDB9iOCfTYqPmW mJMuDuKrlJIMlDOfvxVM5XB1qWqX5GOBEXvkcXkc5d50MNFHOiKf4yn4g/fXTxs95C3aV8b3xdYW S/nxvJDKxk25nCrIx25wLObr7CzX19EK/kSGoXMIaTtcEI19nUA1qLfXiQlWBhl7IQExKRfbJikz 6C+lP+11JtG80PkDPFl4LbcTCl7CXdsYr6hGrmnzTV+YPj8kuBmpUtMYD7+FVk4+pIp4QEI/3sTY jQ5C8m8xu959k5LBD2WCQOaalSXSYcVmCf6hJiQKmLE/kGIGLEwxdscU6d/HC7uhQi2/kCHTOw6F iBtLn/FA/NBN/blo/GRl83vGhV4j0RA2nlVe9FavEtel4ASnrG5QaHueHdT+RqA7XiB/r4ChwvAQ urtqwaXoenSasrVtr/MhkpQtFYOFWBZwOInlyhy4q4J0Olx/Yin1kUuOlu52WRHFNM6kxFQfo0Xv 1bRmzOi80BuhIpkKxjJq8Hxc2PshDeyMN6ZM5Mia8/Gm4W0ix6XxF2qqqRKVnlLP5Bvdh6SkoKn2 +6cSUwqxLIxvB+IOSMzsGIxIn/gcUJ7TMzGoRGWYNtw8UA8YRSexEQ8NvCz2zXaMgnPTcrK1aUya x1Klh1ax4nYIyRjppj0luYK/Jiuyj0zd5jjL1EKd96Hp9ELgfr8rXsA8CozeTZLOltsWGPoOkXvF x6Q5X4e74zo5RLgKU5t0cnTkDP31RWmqL8y2E+g8Hq4NToIGkNla0wfwGlE1OWGoAIo9JOlQ0T8A +G41u2VefG56HDmjTioyC+J50VPJ3DKojtVbXUm4S8f56xucoT4pE3hju2ZOlo2BHoabPj6Hdq2v gr43nZF8+mayEtix9hQi8zGv7T0TLIjgFdlxvXlW/ktRoe4yUPosL/9SrPSRNP2z09TjBhEhsbZq 4YtKdm64HM9Nx+YsneU52eytfWRwi2M10KN+Bs/+1qWSoN5NtyCuRficzpJ29K7fHLGMvdrUXmGi t9ER+U5A235ztgXgTLIb49RpaiBmUwwuNVojOuVTo+ToTbw21lmDEnMPMIu9iW0TX7tjKgH5pP3V u46ImoP6BaKsgclxH/WErc7EGRzdi2DNxYXFpPNBR1+Q1oDCPMJE/k1bSp6Ot0GhiidYNJFEA5ed P+oncPJ7QlfC5dI+fB6cbWlH/vxbc3PvIOsh0E/KWTXIh5cj3vQ5jnmnCGPTDvLw9RNknO/oTUeq yol6VC1K8Z/Y/MzAONy8G5vZY0o9YUpdL8v801efErtf7xuRNWYNnDvL7xU5U/t2pvV/w6v6GU0E fVByTbQQDjojkmUvkvvoU23JMMVpy2Z1zcncjRoNk3j923dygrj8EqfU4MvbCRnM6r87OYnEX83R hgT43p2G5kMK7HcClgnnTKw8PsygR5gvSYk4qT45sJzExk+e7gVNv65GW2ex9zreW+7MxnyXKl7P DiZzcyG57LZuB7V+Ag9ZOPrV9c+kyqnlV+izSRS+VshQ9XMU+sMC7OBsxIl+Y6WTvmoQ5M33IdVy ubNCfwYSIe8n+DodQOrb1xhOzO7+kUB34Wp5KluxUg0iLeSmOEep5N1mH0nopt6msLtUDSvmaBy/ gv2xPDxAvSGBdHD82Y/xWbsttWPRoJU8/phfcaji7dfK3/P8Kcz/TgPk0H0YE13W933uYUrI0HUh ePIK4yc3zt2d59MxU+8jhNEJAYf+h+3ojbEy6HsN8dHb4XI2IlMbvhqFxSfvHk0Mtz0/5Ae3bOQD kXekxsflH1s2WZ2eW6wxkva+pGxhJGVCIirMKJfuQinH7MNsJSm7adxybIGFdHQIQ8T5xjnYyGCE eXMvzcIFWReZkUcMC35XtztcOUrFmk1sf19qhIRfTG/N5T4YeTpzODX7ykZKHVcNPC3R0jvb8Isg wobK3C3DHezZETJNCMYk7O/y68hOV5uRfagkRcd/DtDesAOGlr6TfT7/Tqu146vQ3aF/hvaVrILf XGOrKVi1nZnseZ701cey946AFRL/hPyr6XMk/MDz0vxxUwMkNEULIl1CFr5FkBvyZdh510+GO0Pi tafkd737CJE1xbhS+BIPbvg+1WiCOAVhTuPCOwn6Fxwa34iuvDVcnMSI5VA0poi9AhvWIqIAKleY wsPT6NoE8SuKpVi/CRrD16bBQYHPtR8FnHbJ9WkfSYic6cY2p6ubkiw9qG7oyjKF4upM5sSjCFrO r2IzYOoduV0pSB/IqFVH1/rrWAip9+iDa1CFQevL9x5oBKQk3g4U4S7crN/+lt4W1WCmytA38Ch8 VlHPTDsYnJtdWUjKGSTIoSWnJqo8OTH+2dY2kRAvJkWgY4ylZKt9ap8IWvksPQH1I5QIDycZRyWQ V7AdyjXm+ZY8NkJvwaZufyjzmwiJR++t0LV1exVH4bqQcaBA4dscloH3PD8FCu04ciz1gIBItiE8 XkEiyfGTpwq03ypfDAA8OT7K+OnTs/5OkctB5g8smYjZ/nVYki9mKJW5WIKdZ0pKUadF9h+Aq1jh 6I8YQ/6e/Cb4OXyJSB5E+sia+oqMeFb1CfY1VVA1S2PXU0AcvgSSht1+NmytNilLQiVkzyYC4Pt2 D10XkKJrOwRYYQExFhvUZTKg5awr6ewdoRaXdI4PycQ2yyGrU2DkOoq9+lXGEnTxg75jImbZRhsP iYtMm4uywJ3il+PX6mny8kPeghtyF5GfR3z92ywXfupBSG/M6MjpAKi/ftpJIlIW3BGEYZ21Rmei DHRqcUP909A5MUkFWMxjkmLT+rEwcazJGc1g1Vchw0Hm+wSVvm3I7AGE2uacQfiFQaCQXP676ZsO uz/nJqn9keo/193Ybn71NsW9x7re1MOcQfKSWZPMuwdUtLCLdG9jmxuFmtGZET8x9YX39WT3g8Q+ T2Bw2WAx2QPGqn85VNge2WLmog7sYW/hE37fBq2zrN9uIeKocprFBEspXpy9zAIxKd7Uf8v1aI1p jCW1ShK7f/01BvGgEPIhULQAjwt0ggu2trV2GXiqS8mm07icpFihayAHx4k1ruGwMhoIwLAvHeXr sCmQZoJ75Oyao2cAK1jumTXlMZbz5GwceBWZXVO+qsclh2XHVfxyBbu0bmPt0uux+o4t7jPXC0Jy VcFE0m5Y+rJPqaOI10usd2pEw8dOgfaZ9EA/dbwuW5zvkneR9II1PNX0GhZQ8uv6I4ZmT3SvX4J2 iDAUJz+E8zoHekike0ho3zBFuoKT1h0eOfBVYzbOU/d3ktbe70kq3UtCAPR4aih3Zs2oDvA7MAi9 3+RS9AwlsWeMdt9cxY0c88Di250eioeVGE8yhY9FOcKB7AfscWECBSJVBVnWe39MQ3F6hCuLtou8 ErnfTzwF64ZKN14c69aM9OujBSY0083DhqUt+YUsVlG4SaiF7AnzRMj9UAXCPQWte/nhndEC2WoN ueF+7mnrKOT3nxQS4zvmM+IHJs4SYXEHkRrmKsSy7nYmDD2eQ0sMaEjlomH0M9hx6C5F3JzY5dtT I8bZMzzldqKO5H+q9Pz8JB/LMZE3q7N17M83ooK6I3aofgEskA8jW+YUIUbS6XKtBJUOjdEZtHS0 VdyVGb0FLTOcnoj6/bYnx1xK+QbjTfPkmLpe8jG9/pMoZiGymuj77EZRGWKDNwK2791xDQoL3yYZ XeNqEESH+BxkqMoSide5tBSHlzr8GwAFIPrf0xmRTuAWYlEsuPBnLppRyK2ZxTRRcV5rVR7qMrgm ogX4uPU52cnHAf8YDHvrKvP9aoGnYpxfLIYL/PtfGjdxZo0JuEZyovWGUJ8rJOeLg/4xGYs5nJ0l 8NB9Kbdi/byJXpVsDiiuQyq9qN/jd150MTvinLQwKM1DWjqNnA2izknXxktvhiTuIKQsiMI8QSQG 0qYvKWnp+UEOA6IIsBFpVo7bPuBzzWn1eWI+kmOX+0LqZgStsgoofBmJM8ClBQ9iHv6EnLHegGLG 1+CjgXjJ3DGqzdQ3EC6Py0C0mtnQeRQAlL3026PY+kXLfe60BRYe3c299Bcd5jBlX1WNzx6Kkrhn +sGAWXZMXYmLhwEwzh50hwIUMqP2bMZFy+wAUEqwZcjrN9xUAZ0x5AllNBGVw6vxLKjDw+EX8F3Y w/4V9rD/uhnwogM5lQueA2+HkcsRhJtD3yLz299gAsXLh8TAvkADmm4JtchTiDyNm5SSOO+Y4cIr IClp6EAonPzmouTSQCgMFg2Ewh/p61ktPbcGQqGO3fQajnu5E3lXCzpKk2hvQL8vz7wX0P+QUwhp iyBfbzCBmuk8IsyWS4f4JTq/GuU+Z/OQPT4+ipMtpLS1c4dor+B3CbOJ+dLY1nVAdIIHAT7Wlwdi yUkC+Iw7nRuJYXuFRj7eY0/02E+gHRNO5tNjmZOEE8hZJp5Fj72lO7Kz+mBmb9FRPIcean7TVxvv 841k85iG3e7fSAb85v2j7lvGWqbJ7zg+vzXSTtQuzsWLJ/4HN2ce18S19/9zZiYbi8kkYVOUkEBY 3CYRECuaBcQFqAQM4squoiiyanu1LIKCYhVFa1WEKtGKbam2tm4VbGur17Yq1UqrCBXXYCVBcMXM cybB6r23z33d3/M8f/18veIkITOTSd7f7/fzPeeTQ29EX9YZpg+bVLGfuPvwgspLFRTEGmQ68Zug DGA8wAxWOPETlXWV3O3LfJ85SbDvecxIhT0zUrHYwoaDEhUpIAMsSwI5X6GAT5kNCpZYrY1ps4E+ +Sy1fDbIPUXlHqXqf1KkHKeW/qrM/J4aVn+cWvJ9QFJncMpZavEUvjrteyrXQlpHGIqtQwxVrEJe odPt3lXijifXRfoZcGKPvHPxSxWQgFRABb2gHZX8JpzvxPfhj+FH8GdwvkKlvKcijJhK01d6Kugs e3Y2pHsKSsJK3uROpdfgpWtLCct21vv8A/yvAO+dBpw28VeBki84JyrBZXwVgKbrXId3f2YBvqmV 18SXDl71MGzNMofwgWFw6kFIvzj0Pxo3OMCMG+SJsMW9ptx6P5DSa8qYCt6CWHoEeJs2pTKDBPP8 wODcp91pYPlz0xtwGs/hGR3cb9VkxLV1pCqEftB4xPpVdt5gxHVfT2N7AY0tS333QSPXqTHK/cvR HUhbqyzuROOPa9+dcVFBuzX5m0awrhueC5sCcKemae1zPOxORDg26Sdag4dnDR42Ch6OrWQ/Mns4 Xmp/Poq3YDw3hAmbCGupZsbR2HOx6QAwtbrThKJKT7AJpIJ3dDxxQ9qFqdTMKemLChe1Gp2TRicV MAFEM2/cogo/WmAr3qqLROuDX1k3VNEdTyB+FTi/LLzX7z5EhddCCFl5l6rAADcUPexetsUuDpXc 5HFO3HBnXjjp/d0WiG2DFRDuBN1mUMaqgEsHbkR362CZ2yPzheVudc7rxdugfafJhLNgpjN/LtyG /oxKqJu6Dv33yIzukC1uW7eg/izVuVWc61wBlg6sAu1OYLzfTHmsV5VzrFcduqnJI+P9vh3cQmJ4 dgkGO5ssx6RYkwy1ujGodJSjiGGGNG48fdYudfi71DqmEXNFuocJpUv3mOrZLFNYfAO6hg5fj/1F 8Yx+WTwDQMEYVEEDwegQ8kX5egiZ8Y/MRtv4xxRq/slo6/CHbxzl98kaSgmozVTQGirKOIVKWUll RlKoltaVKvMV2W9RhxRJpVS6cRm1ZBolWUOhWlr/IyVZGZxzUZkWSaWtXUnld1Cp06hxAqP55LZK 4nPsngxidazH3GDsTo+1umpGPfACinGCLygljxg52qR66CMpHhFauwX9LRXeH9bmDQ0SvqiUSV+y FaEUbXO7lKgMg15gKJNthFibHFQ3sVHDsXHFpAqopvttB6pNPVFnWfFX8WaX+N43c1j6cbpbY+Ou 0XMS1k0ymp1Wf8AdtyJ0IKU4FnpMy94UA8Cc8DnhvbwZ2nYvv7RyYhscNpcjbuvbBjfmTHjsvZE1 cgLqENRCwNKXwUm3Hg1Javf2T+VBELhIHOifWgcDF9Fo+8gsCVw0coJ/qpoMnL/0u/C3QqOTiF8z haNfluUPplXAM+QZsl1a3+p7bRgn5yJxUtUUHn67tyn8V04ZkClgQBiGsRclgTMyGC4o1HAVdce8 zpC87yRql9AIYWKse9Qy6r5CUkplrqH8pyuSvqHm78qe10GdUOTl/a6URKKs+Db63LuVFIlfI78X 8vBL2anvYeysbnaYIj9b2JUd0cS6Ik2tJCqYzBc9csJDv9z4e927kOZYERp2kc8XgzVUzoYe+ZD1 2Fu59qSaRBo3+0FOWxMLv2l5rxjmqj3J3Rt+Xv6m7OayMidQRIHtnPOZvz+7NuHRYpnGbulOqGZn sbPapUQRUSRWimZXRdNKoACK3drPW30/HbpC0zcz64pwX2FB9mXJplv5RAn+6VY4U87Fxstmyvna sOWiKmdY5VLnUucMP3cp3C73Sx4vU5MlrGWbxYG5Yk4OX2yqqorYuTmhklu4iy9uUjnWEuQCQ3ID F/AqkU4ZXFQ7x/FUEQR7WsjNCwycjZaBt/J3b1aTQGFeVfJWJR04Jqph28aPP9hRqBM7CCbtjumt Y/+c8x5GrKLytuyesGNzjMFXvWVTu7RoyRbiXGZrpqwGFoiW78dafW+WfuYzZtXqiWFDVb2+fyi0 o0QxHcp0IK/7e/YHefOmUKsVuR3U8vyI3ZZ5x6X5AO71HlImakq0i61RnlBMV4weAeLvHCp8h0t5 /PgxTp0HM8K+x1UiQhjuzApHJUlbM4kiUcaPwZ+PPV3dEUavmRC00On0DmlR+geE24ahG9r64otu 967IXjGR2Bpbe8oHKMfFLNKfjpjrGRfWSN3u9b6nDORd/O58uJNG6PaLfWFHbj6WmbW0eebB/tYJ t7ZOb1jbfBywunpIR9KufyCYjY3lGM2XkZRBnVEAMw6s7TS5/9k6aYkqFrSHbCYTP9UAjAZ6m2qh Qx6gpItybsO5WzdUxwnLN6zuaT+wvubqguw91mO5G0Fvoj2UWJNuYZu1WwJCmPvhI5Odh7vAbT3E 2M7JERCMdsO9naNcUH+UQuRxSP7gpShBy8kp/MFMU2Rmu4n46+E5TvJnA7mnnFE24W09JbAI2BCr hRqINHCHEL/nbA9B6RTuiziUMJVMwuhiMsZSEkB1nTVlROJ7hWCgvNC740tnLEoQ6YufIqOkzUbz aiadzhLLXpvF8naXSQd2mzpNqtu9u+RRVhWmATFe7jP9trDm+5douYPFskBHMNxBJSyMzPCuZUZr S5ViGRxOqaFy1FiCP58HBlYI2c6FsYMEkwuBYIlsD5P7Dollk1HezldY/hYQaF8uEdLWVIwycQEz FG1tZlbmDhBYB6IHCKajXHyUChogiDJQc1L2oEScU03NO6CM2anIrqFaFEkHqPRq6vESMGKAQAI0 QJ/xkJLsCc55rEw7R21J20Pl89SpnVS7wD4GVQg3DepvqrnDH450Lh7FI4pHm3bJNXCI0s863EuN ZzqSBbCQGe2tZZXx00ZXKW73DnkwJgwC3ofaJGCZclkLr07Arqqt/clSmeYI0rmcOAicP9SK8922 A8ugGFjpNlzXIRxWg9lDO9AhhFFxUVjRujxfP88jnEuATNjsYoKqkQlDY+frJ7CWzb3C2pgAdif0 Tp+vHxK4TM+Na0uQJdTimfP18wPlAZwE+I0M6LI1UAaOiWB1CpSHwvQPwzQwA33xQwLH8IKDFlpd UivGTCSATHqy0yRA0aF3yz5dtUuOeoyjXo0rNPe67xWXBvIuzAsOivFa4L1XyAGu+Qt9/k1s8P4l NtidJoqJDXWniRkR/zM4PmSCw2hGKmXsPwbHSVW4WiLgdhGYWfUl8ZMq/NLt3mY+ig13RH7yFQws tYcko9zpJpZtLOFjFBN47iMTippk8XYgFDH8/8EWihbAKnyQUCRFpXuIM8uN+GWoq1XR+Liz8qo8 SB8XFCAcH0GdK3fhp8526yHPxxogszDOeAISzUK8xdm4E0PxYQ2PVyaYTeP6C2okrhCCRzx5Ycde ZywZAulYX/xTMkSKgGHC495wXHbjqaUbyWLeDKJYZjSjfpgjIbChoFbLVeIyeEyihicaZYh8BP5W YW7GGtIeFsaKBYUes7z99jABcghnJAuuuFvsudZnLKs8gZmGoUH/NEyDDf7cGolvAwN/jUSZCKgD IKhGEqWkUigqMwLk+FPzgpV+iuxhlDFNkRRMpftTiP2TNRIG/oxCSlJPBeeUKNPiqTSKyo/ZSqUu p84L7BH7BZ7+KNTf587CZQNXeQplkULpD0oAtsi3yFF4hzLxrRm5TRDnj5pzJy9rKDi09TG9eXQZ z2j2ZCLhc28gg20YSIKWEi1MMoCKUGyzLRbeCMZlV9muchQK67HVwi2S272si0LMxWeudF1iqm/D hL+zGqdenGRSXZ+KGc3p6wkN7EMA93iP4U07LbcBvNSHuDDKYuPX/fusGEP0iS0Mwe96NSZBO2bW IpA3O+60nBc23RtTCDl1cTP+rwme8DrBzPjslxxmaq+GEdXhVnpnBtnLEb4otyNIG5LZLyGmQROL YCgerbb0U8wWIYbd+xl2RwyfxRwHTnGFcR5jhUReJE4qEL1+pIKBdz9HwdBrg/cLhcAyEKV3LoJ3 BiGD14QYgvk/YHgsYlj0iuEJDMPhrxh2fI3hin9m2FEGv0UMXztrY7iZxFhfYCh9D0EEp3nvEVsJ dmQIdlRUePZUMQSn/+NE4hUbwfslvuAKIni/lWBwOWi/JCqESnkDZW/vnABqnlY5SpEdRGUq8pK0 VHoAQ/B+SYKV4LWU5I1gfc67yrRkKu0NKr+W8kst7ie43JORsIhgR9nA9Z7uMnfp3l8QwTXyGoZg 0weI4AhEcCJDsJfd6wSX8T40mocyBJ9kCMa6GILfRQSDmK2hWHU/wY6ynVfZ0pcES7Yigi33SczT ZwFCeInvUYTw2alXEcJ3pwr7EXZP5lgYgs/3E/y2D/HbqJcZuCHmdFUNw+82hl8mA7sH8ubFnZeL wpK8x6IM/Elcyv81v9P6+VW+jzoC+myPykpy43ImF1d8jV2P7ac4yF6xHnb2U4yEbu/LVNzEeoYJ uWx4k2E5E/zJsi9btB349LPsIyqXr8cwF5bjILl4AcTehwPc1Cgh42SIO8svL4AMsebjEMFXrpe5 Z61Ih6B8fAghLWMUC9EpxC+ZnV/BTL/ZD3PUIKOZ95Lm38KFQIpobkQ0r+OBab74WVLP0OzF4Dzc 3UbzCMkMYsc/w+wugz8jmENa+hNygxBznlUY64dYzvVGydgOsezOsOyu2OG5x+cZYrnYynIm3c9y eqeV5SOI5ZRO4HfExnKQ8YgkKoJKmcwokU2h1DydUqvInkC9o0g6pqPSQxmWj0gkDQzL71OSycE5 9dXKtCwqbTKV30ClVlVSd60sb0Msr56CWHaXDdzpOVQKh0r33kIwfyL/xArzfgTzTC+Y7MfK9M/w Rzy/wrmW4dlofoPB+UdvcBLxzOBcrYURScAQin1kwznrDXeUkBU2nBfWCJmEbBRiUCEvXiZdt9L3 DMK5Zapxkmmy6vHUVzhHOyJJcb0f53Kfp8S9Uf0JOeL7rJPRJz5hgN7n5WcjemggLy/uupw702up d7iQ81Vc9kugOa8Bzf4noG2+i2brZIXM5rtAeturrU8GR/E0EOs06XAtYZXcnaZ+28WCftuFbbTw pIq2SgukLGhVePWb+36+lzv2meob4gHD93X2YQT4YJSls41m9nOsaYAIMAqjwTZdgQ8Q4WudBtvm GzxQWsY6/1QiTTM9rCIjt4oJjN/muBEhNqGRnLELhLiy8vLJZLjLycDgvVNw2BXpcbuFCO+dAksG xJHii3cR/UoyiP9KOoyHetwqzeFDZ9YLZ2PUXyXvGX8mby1K3lqEO5LnyTwgzWUEet7L5D15eIgN 91mAOC775U/cwZpcxjsxO8QLVcweScdHqocjWUF3H6qOzqatPz9RSUCE9ecnEsHNx/e+81r7Bsvj Ts9OjEiSfoVPttwdoL5af7Gt9gL9WKUud43qDpjo+4dqXlBR0FMHf57wQF7k+2TqbJEwRcQ6W7QR fihRe4giPDHc4aDyPWHhiB+C0mTzgjxE7GQSgx8J17k9Uu0n5VQJf/LEwQO50hfOEukwkWDSTWFS eK20hDFoDN0/svBet07rLIXSpVqIAnePmJk3OBTChOMlzXHPnm+Y0rL0L0tLCwrHZai0tEhQY+AS fTmoRRKFR6fAaKa0PFfP48U802S/UAfp8pJ40enP1SgcW/pLiy5aAuP1OfqYNL/oNBidPz/aL3Vy dLs1HI8wpYXJGyEyWB2thlGs/HEYH+7WYqzcbWQ4I+R+UERQW2WrDVzvWSGygSc8I6QwQno7ZsEg 1Hz+JO/vkPzf9oLFfqwNqAQRVXBABoQAhS30vPG0CkpuejNx261BcfuefjZm01G7khkdtTcF+zjR GrYBLSGyO2wdCttFGgxMec/ZcjMZ6uTvSddV+xZRf8+4zr6RCT15Ye9JB1yo9h3ryXhAwp6r88CW ZF102j5Jii5aqltU3yJZsCgmrUWSNDE6FT3IpdVLy7PtJkZnevGiF+hGdAs+yVtYiSJeg0J+Oop4 wwyjeUvHk4N/q5j4IuEnuecoefHDg43iLH7+5/7A83uvRsFP8tGqCyt13ukY0VTQXODf1sdkiIqJ hDG20+SCMgQr4ETMWs/iKaXEiNVjg3g7Vxvi3vba6B2i5XFurt7ks6iaWL+hBvXxZFnHk0fmj4am fkDMqllcs7Ctb1fHk+Ff2f2k0smHySmj2V3tUCcQG+z2DlRBl/ghyZg58YG5gdoeQSU6OxWO9xTs FNhH7VZ+UOvYadop2PMrmbf5oGDj1Hp24ThPAQuftAdXaKc1zGtYvnvbft9yw6KJj4VYvg7vdrm+ D8Rp+aKkyDjtiz0LixLCbdaEbqs1IZGZapkbemWLaghKYMxkC31y7bfHB2XtibsDGG+CAETCqSPF VHDgjaf2d3rRi+p2GXCtBwCtD/udCVV7C/bggZ4AFKmwlXadpgzjZvyLOeBFVhJ7J9eA+0iXAas1 AQztNCXcLKnDhxaBaeilEztNPTUGvKAIPFzDiobdZoftBryR7QuAO17P+mjkTgMuXQu+tpg+wunZ Owz4zeEAvGj6kZ3xngGvox4DcPFH9oltBjwhbxQA9SXgl2vd///ZOIP+ysbJ43vSgxILwlDvlE0D q+0BDGsAqSApVpKkl+TUx0oyo6Speml6kmSRUS/NjpDkT5UMA8nGGZKcCEmKXjIPZNSnSZbpJAtm SLJjpemxYEmlZJ7n4hnS9DTJnCUbfIeBpVGSTJ1kS1qSJEcvWZgm2euZVh8lGbZGmnNOmn7QPzkU 5JVLr3s2y84Mj42QXF6ulwQNDpjfIB0G8iZ7UFP1jLlTo/R63dzZ6ngz9pW5k1Xykdjq7WS8w219 H2pf93aWgZ9feTt5fuGbR/w7c+fscHZMv7lzdjhvtmag1k4yFSi1QrLT/uXEzgvLve5quhioC5hf eKv6APB4kgkA38THOe0u/JLBkIQeSjgA8CCLWYBhK11WBjesLqChqQzAsihAc9bQOIe7ocTyJlhD EybaVLYiAcQDgkPT3ATQxl9D8/jZYAPa11SwmuaZCq7Q9NJCuOZNsIrezDKt59c4suuwEsASl2F5 OLEC8BdyLsFkcBSfB/Q4xuFH4TSHLqVfnPyfzwVJek05HlhSzHNTEsTEMJs2pToSRglMx8EiDyId 5H9Nm3LGENH8ZH4u59Us0H9rsRK/tFgtp4fbLFZ19IGt3atH31CtyH9ptGoKYLFtRiv9S/+pKfLu Q6cw2y9fbRNAJMcmhDBGCBnNTNQRd3qQGEIpY7h6itW54dvWlwSjk+Dt3iikmPE3GRtqltWHykJv FgmiF6VRVkXU3tVoM6Kec+yibUbUc7fybvzMarvFalZFl9rrBeMh1sq2CIT4bfZKC/owGKOph2g/ OIfUD1S7OI+HxB95GpsnVcUKnyFi5W0DqW6UkBNE1lNCboUzL4iM2wKxYbUwCkmbWugwBat3gpwa TAO/Ex0R7hfq0PYQEls12DbIAXVCfG29M+tzZ/i5M416JQ4QSb8WiqQ96NaObkbR10bzzinEOOy0 3SNu+CFVPDMvbLzFfVt29rfH/MmEGylMFCZjz0F2FLRjGmv/GSI838202AkkekSSH+UP/khKZP8i An3DWULHUbh4jEDIThOPFn8o0h4REpOVtPCI8LawdjxRazRnwDOg/Xm8DKZiQARKmFmWwW+r4qVH yC8xrPCZyWqTnfIm95f9o5AC6VBY7gY8Kx5bHvGv/UA8yBVTqB84DvzEzCyRXB1kFFNRQnWKQM30 A3bqea5anibbQT1Bk3TMVZ1uxwgQMWXrBxKRYp2UU5+qTQtWpwnU+fnq1Nx49WjByPGMS1aopvtd sqBXG69OiWdcsmCZDATKtQoQMEEhZMYumdmj/WPiZV2jrvKIrtEmVRlHArYQlHBAhTM/iDSa9z2I kAMgah3NWGnXhULq8IRGA2OT3bhfNV2OD0FtB2Z1xUbGQpOCccWuD1SbRnWFd4VDt0vSeK/Sj7kv ZJGxr7liJ2NbR40nsBtzp2dMIepgkI5xxWbADNSB1kE3fQW/cSLU+N7ubVK+QzGu2DfV55SGtXrf rMjY28ShWxzYckDWLgsSsLKNoiY8YLI4X5h8QmDx2oLVMiPYdhc9EsFkpUj6S3K81HPdkuAg3RnO TS5MTf1dKj6+xGiuqA6eTK683bshLaJR418A5+d7iLBDaZWic0oiS8caVb54zHy+ZDx2zHv1OxPz bjtFlGfeI3yzljWvaM6Gx2SwLXfnCjhgSXASTAfLOWVJ22AtLB02j5noak4bkzmV835xx5MpkbHd cVXy7rjuOLAK9JmUx2UqGOR8KhXDAfucsrEo3vuZOXXkfUDd3PCo/A3RIW+2pUn5SAYGbc0KPFcy Xz6h5s2axJqRoovQUd9YVBs4Ays50eqx5Murf5g2+3xY86gc7Ek/ITiUKa7WsYbtuMnmNICedX8r CD9gl6SD2+APSQNTwRHyxlP07gL3lesz18YungfhsiWFRakN8ndyqiOysgK5D8yzChYvV71VsO6t 5uyd+cJzytRqIgq6z+PoWHvK7RLmICm1CavojlMFeZz/SRUEgfSa7JtkLjjLPiTTNRVpYBJqgWDw j/M02H7hL8n7hdtgwffEdyJLKTCod+M69K2mE9OOnr90/GzHk6GoM9sGC1moCsRLeTAzZSW3VvkF 0PtCaGxSjb4Z0KF4UiQDNTwCQEka8IzB1iUSPE2OK4J6RAwOE80x55SuF7MCuzS+beN/bn9SpAET L9/XxV7ghgGYFzklo6U28Gxoadt7l9lw+aQLqfBDJSpxMflaVuZnzSn52i/Cmi4yAwbBDecDBjSf B4C8800U9H1kfmSOl+7X+y66880d1dIRVzZ3lQVfi0108P4yulQeoF36tlancb7ZnI0nWI23ZwK1 K+P7BGQ6+Hul2/kddbRGU2h3KGbyC879p/PZxDY4vOviJ9FdgmTjETItpdP0+ZLg5pyrl2W+6idF jp92mtITV59tnHa1Mceu6uqZ+MjpxP7md9jdtkFKDPid6Ar/udTzoldjkG7+IcW97sCJF+ITAHjd yPPYqi6PfrZB1cvrV5cbP6N9ZxaOr5mJyo7V+frF41vqqV3bWtk3ng5nMeqtr8iA9wUjeSm02OTl isNIXg4YC8DnNnl5KbEE/xrJy0VJbC/SgA8P+VNezocjC+twRRGIVGHd5oSqKgO+sgjA4QAy0nDg ve4/V2JwQsdBNcqB+fkP849ZP8SQ22kK6OpB6RzJQQvjUCjI+eqtaNpZPcyNl5R3JdRV3fEEgxjS E2hXmpDsw11CAeh16TSFDsdya3bj+hGjGZuR5l43vNbzamG1vzgF9rwH0rbjO6tp2/Fd1Xc7nlh6 rUev2rW7EV+Djs4cbvxwLKxiN145mm00Q3Rk5kqYN99pQs27k7DTJOo0Of8vriRsWzX++6sr8foA XcmT166EOV//AhbofLYzu/wvzldSXo3rwv4838330PkWvHY+ZnGS7/5plQ5e/1aNbiFbDHgwer/M gm0x4F//Ma8hjPX4jlDbamV/9Zq/3mtFVz2Ohf33R/7rve6jvbL/YS8WioCQa7T1J0QD/sMH/+6q mSXsCHTVqybYqPqr98a8Jgy9k43/5jV/vdfnaK/q/+e9vEz1eP0/7JWAEi/wRQh0maY9pW8+RkFp f6eH6StXVBjwEhcU0/s6TbHgLEoPgQXb8KGuAEg6TSu1nljuHgN+WAp+Xz8Sm85P50uhwwcGFe7B pIFY/na+ZTD7260G/B0t6ATvj8RUKNobDI34KfShI6kc/QL8iD6fNQb8y/0TfmKh6LLaiLiglhD/ 28v4zxaIYQUgXWr9lhz0TlZ1iy4p8e7Dvmc95m4AdroCio0awcZrdPvzbjMPj+THAsB0muF3etBH UG1bQeYtBD9eqGVvdGRx6jjtz/OYJWQeFLHRB/nnCjIObX0tsIXxEF5qxe4+RA3p7VJMH/4qUYT3 Z4rX/YPBTq/5B6c4c8gEj3MgWuSgSvL4/RmkG3FAhABtKXSczSFbIAS8IhY8RhZ/KoQd8KSoA55x sSfxHVBQClmMn5Ds9gb3hQADIPzfRDdqT3cQYtS6VUpE6tu9suEmVeBwd3/fHDd4Hr8vtBdyyC8h 4dwKiTx7QeJ6iXXaQPgcy5aywpdLWXktoNjPaG7iupo3SkRrJSwRs0ZIgtWtc2n42Vu+/Y7r5se+ zpdH5OgHK24NCqr0GKeqwEX2TiCTcF3l2U5wo9v67Mm4INKX+QmARHQRKdWDioM45AggXHFQgQv7 7AEY3Iq1JfLCQcZcahlYmXLeus4SSklzLOcpgMFnZkuzEtq1qIzK7YGznepVJ1Q/jdGHzqWWzFSn /U7lzqU8sztVL5TTp4rD0rjiDgiXt3Ig63ZvB/zJCXdrgcPy4I8SwBjIcwKOkTpmhENzB9pW8dnP 7zTdJ1EeFj4Ui8WdPcs9Xe70oP72oUYmwDjkpFuPRupmO42dZk+GzwL26E4LDJ/1nDV2Wh7agm/R nTZN+Kw2zej4DrQFHejOHXTnDtrmK9AT+YFjpz1ETxxDux5jjvEQ/SUDPZHBvJI5xh10DI4ufBaN nqCZY+C60fE4eoKDtveZXe6To+P56Ak+ekKEtmEidMctdG43en5g6NyyQehhNzlx4swH5tHxg7ih c5d7jo53D53rox87rVlhDJ9+9gl3LUeAgeiNHfCO5o6GQ5KNE+xJsozW0JoWSFZlVWXlQbLscNbh rDYN+TjrcVaHhixzLXItuqMhmxXNinwFSXp0mr4rOkaSjI55qFGQqzxXeWZoSM9O0x9F4XcgiUr9 syJaQ16DFdcgriOlnSZxJUdHkt6dJs9K+xh5p2lEJV8nI306TWMrRTpyuedyz++6SRKlHH1lVRbp V9ZpSq48nEX66Hx0j7NIhT8SD5WuReTQTlN5JWhWpObtrPmkpqmm1RKu45CgIm0lkQfv4LOdus15 cCNfMsHx7pYm3gVWh2ZYK+f7PHWJ/FE87nRlsoP37d4Jg73o+Z6K+yuW96poteumhXvOZxlpldrW ODd0qdTHnklvHDO0yb8xNKtm+EtzSkjfP4rUZ6QVIe/KCovfhruS9z3henWTQ8OgRfsLBYXwM6mh 7hR3HL1/tshih/EmEzmfvTMILlTcFw7+1Nk4W7j6cvwxich104XGaDDo09ZCkRdsasCHBg0NyhnC ERxGKoxO3gSSL4Dk6OPg7ZHR6sIOf4lFH7tYm8ePTgSadFydkgEKNIRmvubtq/6SRYl2HueV1OnC Nt6polbed/eFRXt3f6avnO0U7NCKz/YA4IThtGHQxxzyLq6zd7ohmna7dypY+slc1M/FSpoWd6vT 1QedP1nVTnzLWyK3DoXeiqf3EbuLhYeQLnRBwnDqhRNDx/9RNAQzCtn3DrLE37Ih6JIUBeHqHLxD I4TY0U+bIjdONeR//HOU0Vx+fwBxeO1G0neQTjLy1qN1XNcBHTpwfJ9H13PWmAenDT53vmWNuSXx kud1tegHdP3+LOtaWB4s1Fe2E6F5J3jf8i78ajS/DzqeCOFJ4xXDqa6sw7d7JWZQcXpY74mPQmk9 LTHbO+U8B5dqvUZupQc+fs46Zjm99xKN3e5bnFB24dtPW98dF1o6Sj+gvBIHKDbzEakVX6uPkcdI e+FDzdhY9+gl67hgEn8mP4M/IGYVuLslQ1PxNZxvCjvKP8dv5Xc5Ptc814AT0nDdCc/7NSdTT3g7 Nng0AEVDiz6iYU5DZkNRw+YGw4GCjGWR1T8e6DvWMOmHhusNpgN/oxsqvl7ocrzIYXtxnfRzdHuo +f13yMK+kuNX0aO7xZ6HODrilOyWHHffVCeVNwY3Tmlseufib1mpjfmNZUcPZ+GDm3+eAJv/i6nz DGsie8P+mSQgAm4SmrqWSWiCq4bq2tYZQMFKqIp1EpqiwtCiyCIJIIqohKioi0gEBLFgAMW2qwNI saABBAERQxBUbCEIigXmTfT/vtf7ZT7MxzPXuZ/fc5957uOeT8ht3NhOQsEjYB58vKOGMHlKvLnN 8VqyilW5yWXGYzjQDoiej5dPkc+WsxC5tzyoNmnhbrlf+fAxeWWRvNi0XF1zf4vx0zpf4B+0FA3r roy1ZEUYMC70O7LMXcO7K/G3DhEXelHWq8qQpejOqWgQpacy5r18TM5QmCucFO4KEKDYpkhQZLR3 KMFwn+qLCownp5CzyX2kNT2IFJCzcHQxfpG8TcrJffin74codJoJ/SE+x8ThNueLRf9sy2gImilc JHzEzmodNtVGgYBh7FcWyG2VhYqn8lCBdarFnD0qsSpPNSikiRfQwVR4DhxJ107rFdEfir2lQCX+ SAcwIr0oDZIKpOunAyl7mBkzNTdIys7lZzKHmSAXLjZ+vtbVm2k14P/YFGeCzJhuo1PC/yYu9r+X ZCSBJQOzJKazO5S2Mxd1i66T6weHEG3ZIjRl6z6CPvdt/3i/8CaCGkkAuHeZ/wcApjbelAdFogoX fZeJNt5UAcuOt1qAM3g0wysXvE/vXFZRbj17wd18NTJrxuLBu/lfhkpxbwoQhD7/vexYJk8QYobG R1rqu4SWQzuIxArKoStp5a67/qPmE4G1ueauPlS+K5oY/fwK1fleEh1hO9nbOgMB+1VBa9b+mfk7 7e1hyQXvaUrqXT0KBZTmBnnZKyn+yF9+j7xG8w1iPVeZoa7e8TH6LqP5hhnVxbn8E3ctow3GW0F6 1hAjMbrK4kadd4zhDfkDuedOif4r+Yg8QZCTXWxl5fX5RYlD9N8+2gGii0PL8UZ5cGtTeCsB+DPP +ZWXng7M5Z+R5sanLec9lCYfqXSpdNEs6YWdy+wU9gaZvm3Pfe8hvophJsPLPjGm0YcWssjGlxYi 3V1yMypwEAnuJaxlJJuUsvdGPfKWsi0lu5KNGa17yoRyIa0airD4IPRpBwvW0AIniX3aWwoTY2KY j7wBDieZDPhnwvnwVbgObocH3sI/4N84rJkmlXzye3bFWlZi7toZxvt36KFrxF6cQE7szE2Ws+Vr A1dlm5+3Nqh0qbJITtKlVroUWLRJJj2RanSpTaKwoCI0+f+NdunGnTP7Uqr3IsfnT7v3FHkF4Dbl e22gE5AjSse53K+IAbcA5nBduEa+XOqCqQKun8Omk9wL3O5H3pXLA70blw27hQP+hbd2weF2kSQD /80n+I6+TwywYdlEAt8VkWBWuB33GXrbam3hgBW/Fw35zcvA23YSNhMDizBPjIdFY3ux41gxdgsD DdgLbACj4Ca4NT5BuAIHG/EInMrVhkW5cldyn+G89/gYfpRrLkiiQ1QpnQpBPjFDXF3MxXSv8LgQ FAtvCe+pXggHhM1cBmktBvPE/dhGcYRYJD4irsauicE9cQH+n3RMzNDOIEtP4aAEJ/AEaYaULmQL HYVPpeDNyUfD36VcPxOZSjjvYtMwzbPklcRpcIaaHbbuCL+gv/uw7NgX9deSylmuOyTjyUsvQz4g 6O8fyLFvP3hUFK0hA8sCZpm9Q9Cu4EUu0X3Eyb2dyCmUV5DcSny8ZFROmSB4pdkEn3nsCiPCkvgm sGseG33dHHV13Re6Lupz3XPcIRf6mXKAagXvL2k2sewSESNtvEp5pDZ0oEyxAMU5OynPb947MUjI 6WZyGzltgXyVnIrJTeCURyfsT8jB+YZH6klPiovajozdLS5S1Ii0kSz6bU9lb2TzFCvaPihUWZtX O1uDs9OQm7OV1jVEiGKXwuyAAhBHR6xnz+0fHmIBxl/JVSaFOYpIYaXimLBXAT4r9LqX3PlTPkeF fsi/tk4FtqsK7j1SH1LlqkpV1aoWVebVjSv5Mfhbc7M/j25FeU42jPqhsb+aIUE7z+OpgUjnFeVu yLIlZ0/uv5pC9hHUxN27jviVNW8MnjoxqLA/fesSaPWivxQDiLfi0ZO4QTapm77gzo0ptXUFL5F2 XlBNtGPjQtfqZYfKDvzuZYnoqSZNHpihAhNNXlHK1cVZOH+YdXs0dc9w07YA0acjXslQo36MQ2W0 o/uAgqJyUlmrwDzVsOp35kq1wNuDXDfUNAy2kvHkITKXLCWryRbyFTk28g1ErBW6d5HjEDSBTmfT HelL6VHGlpvo75dQj/D/phr9uSZcF4LCoev0j9JO+gc6Sd8sAxZTBN79FqTuEngNvBWOh8EhOBcu havhCPgVPALrc/RyKOOncDh+t796cngcPzVL4B1ve8pJ+aWTHfGUVcCBYno4QxxdZBIyE1mEeCKA h0Qjmu2IFCO3kAbkBQIGkDauCdeaO4+bh2zkRnBBN9KPnOXGsW5yH3KdPL9SwM5xO/W+UkSUqAkr sI1YBAZE2BHsLHYNm6F4hk3El2OAgZvjTrg7HoA7Ye5YBg46iVRVDf4Uf4N/wyfgMA7scVehnzAJ P4oX4jnCywlAj18l1Fmix38hDBFSxCbiyl+5atrtdM/pqoeipkJ54VtGmsM/Qu1EQi+BdjgsOpdE T2kh0IAKcb2Y0SF+Jx4Vq0b6pkhnS9dLgbemRGVK90v/ydELKc2angMCKQ3/LD7RIz1N/xUkBBbJ PGVKevTldy77Zf9c0uMDvSvTi1Yf+VgwvUh+drrMTtb97dwq2WaZDfH6S47pGDn5rfIZgbZdgWes PDWu0Y8IJeIIkE7kECq8kujCewlIqCcHv8tn3b91uYTYIA9/xMtKlYMT8sn39fg35Q/lXXKVHFJU GiveYH8qsLYnihAFAMyqe070fTNT+r6pChQVioF6RUfXA/aHxjDqfezPS/1PqrshaNtNYxK8otJT ExXrVTtUajxTlcsAharrylBFnCJdkaOw+OrDB45kZWx6lh8ZSsaR6WQOOXCZrCSbyd5vmYlie/rU P/TRr6QBfRqdQ890oftO2MFPpU4ucS/4DIECdSo9WHqe/i/9Eb1FqjYAPvz9Fs66RrAlPBdeBq+H wQ44Ec6Ez9J/lYbmQRpiMAr7pWdN4szk5Pf58G8ss9VlBtj4gqD67pCZcSwBCcLieFt2cBI5IJOT z7nKqeO0c95yfnB+QwALcUCWIGuQrUg8cgiJ4YJSZDy3BVFwRhAqMpU7AwEo14cbzMWRNI8C8uzS ZgTc4TZye7inObqYVsxPyYEndvCnmM8jtWLegIFo7l4uBecSHYp5+Ap8Iw4i8JVYE4Zj1/B7OIH9 gYOX2DBmnij1DlNllpeeSFeBHNVlVcaeZd4Mt2c9U7ibT4x8V832MCb90ZYzLDIevW2Aojt2kT+p EkHvjwbTk2go+mxbBb6+ZM3r5YIhxDe2qm0DGf59IVtIJltQqWAX/99B9+paso3sJ7+TE+goTLeH pN71xrb7SPP9eiOTN9bFmFvmIH7i0H2kxdPfanoQv8bukzyVSxq8fLV1rwn5d8wqyqe+J2N1MdYf Hj0EMwYLnnWE0f+mH57g+CTGQOCSzQi6xYgAsd10aqBfJb2Z3kv/TNeDf59EczzoCPtlhnjCPLg0 ROqdnzhZ390uY5KhJDafwb+wLZN1hxEUkRl2mRE7dIlhJNlSZBSiqZtrbVhuBmciLhmFZTMObL/E cMjbfYnxD9OscOlMdjEr9Ej4ZQY+I99EsnTWJYbgDoOXJ2OGXWXY8k0zeXlBu/NjQ/Iz8xaElsQI 8kNAXFh+QkFemCw/V3av4GQea0dmbH6OUTRdxi4uL4zNZswxv+ilL2acZjYURNCPjBV44CAUyR+S BZzftfTYMtey0DyzsrDw8gd5gVj+uvAdR3h501iPz8XU5nuHbc+fd5MhiTbN5BcZZbqWmZXNq1hx nuUvK7g8DWJNLbtr6m7v1/TExH2auz1rWj9pNTZ5iff9SNNoczmTt4YPc+w5bhx/21Eyw/vvOEpA FQUKBHtK992oik9xlHwzJa28a96brKufaun/sboiSp7y2K8FnJKXyIl6mouAbcidzrXjoq5cP24o 1xKr4Oas9F+xCzxR1K/81O4neMOtfmGrmqYhCsU2S5VSwNnP2a24yLnNofj0tZUgccgPDvzhi2o8 CVyRT61BkRiygkxBIsb8du5NI7N/bItqeQh3wSHPs3hh7auh3yxfiIfr2I6bKZM/pdcfrINAQxS1 Y/jB+5xD4w3JxYIgih4PdAqWYNb4PDweO4TlYqUYq4n+kj5MH8H0t2xnmYyQNH16yPO0sPYGSCIY czTBARfmwzHwRjw+0I4Z2/T3DuDuaMd0tz/JlyiL8NKgs68ZBDOu9XF4IN+pcGJPbdtkcDX6xqQG yIxpwbRj1oVY7R6NOe6UP67FtySGpKAaBtEgCKllkJudH3Yq/u0aI9BzDtF9t4k/nD5qNHmuQ2sX EREPwMRCJkWwM5DHE9hpoF0kFnWiY5sdqILmSJ6geBcv3NlEeVp68qNDbCapUSmtSKFkn5ZQNIBC ov/zA0gE1aLKmXIFQCEwpdBIw/eh9mqGhu+RzPjIs46S+w6QHHHKtMUcIm+ktTYAHQ8IiHbx0APx tMxRJ6oOd6JnYTSlaNgUoqQfXbuKutadmlwYDe3yqBBAglphW6S9Zk2ToqbVGhgfjTfusUje6Zqc pYTWuH5wnWf0MiozpDAj303TBPDtQj9RkiiR48S3TLK6nZo1TQCSud6MGW9kh445NRt6+KSFqr18 LZIN+t05Rh9coSMWyYZRWIqf/kHsnTFBm21iorTuNjvWeo5xd5qU0WcyrTbn7lZ7wUrSgLQ9HKQm 0D+/ks/gCUPVhEN04rZqbYMwtNyW94ccgYObZoQQ4fG/twCF3ay6UZj1mMVxmNkv6ZeYEUzmBelJ jqHxBLwGZ0mUlCSx28mehr5FhcZV/le3dghTBhP3DhIpHJJJ2jFXtxoxLde3vbA92zbpluqkosAV gkqSr3U8Vp+NVp02MnvgGDrAm9QqmqIz9iAaEhgxWnabKGvvBo0orw3Nmuvh2EcI2TBxd35B74be HQ5rZ/n3p4cOQYseCJ8MIC+E61PiCpm66eSEgw8G474NIbbUt4yo3Y3ODtW3vYfSoRuIU5Z4ju8s 5wrN86ADNCujl2BGKIsZEUoFtq1tuCmsXZTv+hOrjHsqjV667xGLxXniK2JQK06W2nkHsA8yJcoA TpoJiOJ8lGb9caxVu9fkHCVn4BNHZ8Fh5Zk/gUa4yV3/E26CNpZIKFSLB1Z9tz66c0DTZg6M6mfn 1UsLb7pu24CEOzs1N1HPFO1DTJTl14awaQRn+6KAUSTjXCQSsX/27xegw+fqkbQOZAGx6ipl3RX/ 8iX/UQFOeLqLTbGlhdcl3AJuBRckTGzijq7W3WuCWWPzMGyd3poAC6aX75wdPgeZYt/UOjaUWne2 /IubsNowVX5CTjlfp39FXis/vPQ21mcc99TmBVbw+hvmf/4cevXsT0Byw/3xLfhu/CB+GpfhoIq/ +YWJSgNQ4dsKjYSWQiDqP8h0FwYItwkThBnCMwmWY0lX4r2unhW7HQwaIfvAySLG9xqJm2a1anJW FKwoBN8k2UqR6tvRu++2FdIL4UIwpB5MKjbROf05yerpaRMj5kC2kl6oO183ZMlt93YyPNUIRRNy 15IzjDUdH9qtIrU2nNaFW+Ps0IOwaAobneZbF0W50Xdcdfo8qkb/0+kRVlMNc6Oc2JBBqrfY96Du Xh9WKpWoWNknJ5Sldn0VkDdFZuoRPF7n5aK7C+T/GrdGGqX6THNjIy7QYnO2kU7P8D7DYvktqqY5 fIX9bA5pvRBJTfOo86g7+nzArtSwp7t0/Bd3EJbVvQO4gU14VjcOogO9Oy1RxU8PxhIVvTxi6eLL T3Fi8Q7Cp814FfpVsEOuqUhxkdnFumjGd5sxxUOp0zfvypOSD6ACYuvM1BGNBqsT88zVmvXxUF5r yZrBPDex8H7/yr5/wLM3j6Er8Yt0rgmHdLr6SthAp++mFduwkdPDKWGbD4OFrPngeqI5UmSzsi94 2V8zdVl8JGZeqs+xcccMqXt95H+JKqCRppV9wqprjV19Wcxwv8LGu8yQdwxWYWP0cYb/zmpGsIVr TLxXWNGaM04F11okttE6c7qOPXsTMNg7juZQXgFpf5LeGdUc9d+cQwCw+/aeJx5DVyn9kmETiTVE BaqGtuPKtuHHUFHvzS5g1dQ5mmel+tqhIis+qSqEtHLadNKbNS4CW9mXtnmmDti5dmJhmn/VrAfr 6IWbsNK3VeE1V+2Y5QpD6VMF+AO8ffJOrS5Tl9kZTa6aXGU+qMdsYjZNHozYtfUX0Ou96fhPUlgB DpYymgvx6zi4j/d2BauD1eaDNZLnZd4kWH72eVkEeUB4hDxLXiPvkSPPyPfk2JjWRMgerZgPnmZL dO8aJTE0ZER3o/sbXGVuoWs+pWsCZaTJ1e3gPs1yMVKpUJ6r2/l9EJRXQK+gg3p6B/0dfZROn/K8 jG288PgPO7g9xebj4BdgO25w+Ks3HAQL4P3wP1Mgv2L4FtwAv4AHYIrN0lOUKRy/WMFczjJOuuB5 WSgHxHHSOTmcy5xKDgOPRqivQcbC35Avssp558VdzhuI1UfBwvkZiwMQF+Ku80HNq6cE2H99ZZ/H YinyH9GUMjq/LvZCV9+qHaJVxgyX+ejutzm8IGNG+HFGMBAAtusC7iruZm4kN5l7jFvEBTe4D7jP uR+5ADPCBoVzMbAM08V3YIlYJpaPXcXqMNCOvcV+YOUKFk4RFsmthWArHo8fwnPxg6rTKo7wFQ5G cFLFJC1IVLg5urtsPhNgCY1Pussamzaw5zPThRss0FPnPCXzTb+m3hLMYTv5fwHZVefvJyjn2HpK EpR1yifK7m7lBYHOgb15pulm2/4isxuWGaLoKmvy6C/TbeTpBvM2Ipl2M12nnrjsmQ6Aqb+akqwr qnBh5030V1MFvSLeagEywKPVUJ8knc5vF7w1Omz6N3RvAhppSNzT15Rk22uUyMgO++GohG7LiZrK iwzMQOMd2XnTjajaFsLVfzCyN8XPeJdZEAzthBlp08eZpydXVFPHmecmNxgz6lMTlE/EfXvtP6Ty k+qUaHJW1CGa+wHxqdQOB0r3tcY3PcNJT5QfmWs/GetRmJQboPHJVAllsnT8sQ67xxUUTRF+ltmb FB+zl51XQTG8ZN5hX2HxkUns7er9yLSexrkuL937wSin91wcM9XruM5743uEw2j0x/8V1zWonRyZ 69S02JlYnU55ZxL5qKWxyY8sftDY+jc56fDn7rJ7pswL+e0FEqJbZIl0IqNRh9ndxuJ8w9pFW+Md u8s+z74Zlj+IOC85TDwjSbK7bF6Tp6klurTNeby4LUSRohgygtanZOQp/NFl1gtfmDYo/HWPTWgj uo2xqA1JfVEyEjD97pHu2PvvfQJtEK01vXsefQWdln6NZZKcq+NLGh9+OQ79/3yfFrI/dsFpT/1K 9GNYfnQfofL7RqAhAd98WgsnPKBQBNkDKTxBd3eHzgP6c/rjyI9jRnu1mq6RdBJFf9EVqYv+oisy bvgXXb0+Uw6mMHqqKEBwM9SFv2xAQ1fPMuOPh2vI5nAgdBRfYkphRxKFa5gPQg/B1Pt4GXzkE5Oy IamimmJVMCWBCqbsbDJZuKsHHoJ1Oddfm3NYePmCaB+Lkp38OYXazGfRCc55q2x1xZzGpgoLvNxg WclOY5+wG4bO4vCr+lxx5eqjLZxxEmFrgt0wB5j8MLFiIv6o7oSW22T/4HcCXV5+nx7Fe13tjHgg 65DtCNiDiJE85ApSi7Q5NGekSQGJMFdXuGrNi6GcCpdNXIBzk7hHuYXc66t4yk2qiz4dZhlBjY08 1uZYkc7hsYx8SLCr8eR5ftTdnkftym20gTUGQX1EC3K08qtbhnq45vOuawOC/vTGFmhRhmygH8mX Tb8SN0Oim67ZjuMt5xRDKNVkR6nz+Ubr6uqkpM8XKCGG64jtN/UrdxODMXLzDVUiYZObep1yZuY6 ZYH4QFtTvGexKDRaCze8aJ1KLMbdhfAlUoldxAECuMuHoqZ6v1dPwuQt79XOmE25fB22HQNR0fNm nPinUHSwtU55iVmE3diQ7/8A8yfRPZf/Pau3FtJ80vcBxfC/F0gGio4NnNF/R3ZrCL2yus0cp5LN CNYyiGxtcanWzYZxLVb8u+zGNhrxre3SnlXZzO6nip96vKnxhzVpODOxXsPfFHIiMe+KKxOFIMPI Sb+3UF8r8FxjPdV4IXivhnf7v18S3TBZ8NpfuEVI2y08pXTOFGb3mOXFvPRN0Xv9am/PQTWU7xNq G0Zrj4YgrT+a013EufHHe7VtGjTtdK1FzJ5BA587Samp05wJ6MxRvaSRuEYrJGepZZbOzaHUt2Lw Q9x0Mymp2v/wgUk1Z8TlB4ZTpQFdZ15qg71VxOPV27/EMNzFwp/H8y+Q6UeHofg8/oVmPhD1Pmtg 5XsNgDP3lTymQjv+HZEAQrSDHbHxIBr4xIPTggQQDMISwD88sCG+s4FVMDmn++gqXUFSAL+jgZUp etnAHr8ONgrVccchV8aWgd10fy8MxO4FIWkgIlt3ulR5NJAByiaYSW2kYIF0lXSzNFLa6lQ4dgi+ JAXM1bX17dK30n8f6sumyubIACrzkQXLdsrSZLOtzIl8i5FbsoYU3oul69beiUq58vyt7IfsCIdF OPx3Q2hQPW/TC42MWAlXMpUhf6y9+nnW2OiMhNqV5f7Rz0lk+9i1K7PfVo99nvPqn7HgJuseEpnQ 5H9ygXEX+nlOGXGXaCVeE18J96UI+JkUjRxGpEhcLancKwfLTEhlnvwat1beJu+Xf5cPTFDACnvF k4AVxOwMMstY01/9ftv8C/e15aZGd67/4+9zrHu94rSDUNdpn5Egvy/IDr9X3cmKY4oixQ3Fg05t Mdf+soygZttUf2U33BtoXLbfhZzTM9UARW1rYWvvrX1G39qMrL7zaXqhk1XQOHyxyquH7GHFUdbt oK4LXRK7e4v2oOmKCtSq2j6QSt+Ud6FpgdpKByxIZ9Lj264kkwxqVPjXvKVqKCBwP1l3YGa6m4y8 MH0UQVWnF9JPifRrKsh6soN8R9Ik4iaEZk53orvTA+jb6CCBnkE/Qy+n19Cf0t/Qv9GBITwdtoNd YT84FI6D0xkACSD23+B8Yqa0FK6eRo16Cr+Bf5wG1KjfOJp2irOEs4azlRPPaTzEyeWUcqo5/kHY UATs2vfs9cePHIAcl/2wROYuMvm28MHIlK/AuHLhRds7nXHVjrv+/Xb5rpsC4RMLdkMDIuIyUok0 I73IZ0RvqWg5sYEIJ4SEhPCUJyw1AqncEx5pVYXcW/L73E7uB243yWViFpgz5hHg9aCX5J9J0kHR rW9VJ6No9q8b0dW9X9KGVsZ4DV1osjBWB8d4bX3yCm9NxU5gIz/ztzf+dJOHuwK8TF75n+matvf7 aZMhr3rY+Hi+y+hoQGeVc4jhq2k4ZKBiueJ+gWlVm8I2vaduepUcDPa81nqw1/H7eGd4WpUqCKhe HeqhCrUXV8wXrozvrGJsTEyritpdWAtt7DkoPL2bNJYKHzk/GkBI9EXM/rLepS3gpvChsEuoEkLi VsJK/KcYLBdvEIeLhWKJuECsdWfBL3eWLmVLHaVLpWulIEz6t/SwpGTsGHxVWnc6rQo8k76Xgtlp VUYyS9lc2TKZaL1shyxR9vMOCFmdzH9siyLUfWPNGrsX3YMyGpHNsSEW/NcQdUMeR3dQT3R3tlIf kh4uuSOq85Xn93RDSAiy+WEqcoWoJdqIfgJ8JybUrEYwRIKkIFmID5eCqj3O9s6ETlQdq/mttfAl KKstkxMeNIWz1bva6TPmGXXP5iAcb1PXjjzBUKnNl0TXO0Ne9vdtmsliHVPU/WLrNkXF+hJd1I82 hpj5+n1G/Ggf0zurjGuVaIN/mHHb2/65DpC3qQVC+38hO+wp05v3WW+ivawNgVsMIFBtP9ek9S8D yEB3hU0I+2UtlLLexqHpeeNj+8wq+y2NrcAteHWU53ZvU7dgO3vP7axazYuyJs/tL2vdgh2Ynlus TUFjkwP8HFkDb538Vf1V3dgM8qBPL1/hI7i+cKgmnMHhg3HqcYN5tYW1RT3nXpJLDNWgsxow65zd hFr1ni583DI+uL2msWlq3S5OyPPdZhN0cvFEf1+s0DpWTHlezwTSvh71/chzypY9m/w/mhJcKkme Uz6291bb2Zc1PQ6hPXbMeEzL3VmxtLOqTfxwNVht29j6rtYA+sIdv35i2B9hrDkYP3VHQKD4jtS7 Q1irZLFqj2PFGzghd/wc6rB2jGZi0VZrZzGjYU9nVWetpvEdP24dp60vxvaxPZak799XRMl7edBz 0ovCpuMqGat2/B3wLOvLOU7Ii8tLCQOdF7K2eEZmlbe6senYKuq0XKlynhQ85L5e+K7Wm7nQ/n6s Yvmac0OfiYtSfz/aHcTdjPiVRxnu/zgJkRDJdUNSe0pj68JCT+TX3OQKmWI9KOP/7mggnZY7E+om lkjXSEWG8ulyO7mr3E8e7h9SiSI/B0ShSdcrFOCYvEiuPd8NvjCdo4NlycAVWahlgyz99j7rL7L0 ipJW1vH3ZfwSvlagSVP1JIXoPTFGrFJsVkQqkhU3ju2RLpbKX3+60ojVZYI1tDuKekWH4p1iVPFE XhtFy0/60GAwLbeeP460VJzZD44Vbs1SuIxg+tsUy49KjuUN5CdtIyWKLfXasWwNz9NQ7cwq/Ul/ 7DfpSL/Ov+QjElWQajJ1zdEsY9mC1/slxV0bF52dWh91iHEJ8dL2x2uMh016YpK6y9HtKpcpX/sb V0JkhPk5AHKkaQv8lg/+hpLhrW/w9hEKSqJLDlnvrl78NQ8ZM5tsTZ3sb/KbTC/3xuaB+5EOa/kg aEsm61/gG8KKBmGdvNgL870i5kaGvfOKSBW5cbQXxnby8BuRIvam2FRRGIhJFfFTRcNzjEU7tp6Z A2xYtjbbWWnskFRR0P45OWz/8CDW7lRRzJZMPs7Kv8GOCWJdszg74/+U9x1gURzv/7O3dIGjWwJy ICgQpagUjQqo2KmCkMQEjo4iRxWwHdhQgwI2DBaKkFiiKGosMSFEYzRqiMYW24EalRBzJ2j4Ytvf OztwHifNROHv83+fub3Zd9+ZeT/zvtP2bmctd/F8fSKywy6a3jQPvciLuWdaEhXG439peskkOoPH 36GbFqabNnCzaYxuGs9iF6/KZJ5JwmlemIC3waRgoUm0ja/dIZOlNrztafE+Sbaz43jWdvE7TdUC eL8iu6p+hnYLTYIPms5CfkmRBYlxptEHTWOXjzi/ySQ8ydbLLizEzIK37ajNtiFT7CJEg1O38tTm nAiaOsxrDOrN22Sil21ia8c7zRP8NMphiM+Qw1HfDu5rF4XmuA8Nv3XYNiaM953dKhMLXqLCNdP1 A5I28qwmTvEcPebkENeolbZKY3yGTLJzsgs5aJouuGE7ym626yGbtSZ6rlF7Crcl5n8gdhejtfz7 s24dWnNtYDAvfVWc1gB0frPe0eT9+v4m03Ql5YlJhb+8p/f+Uuo5E109N4Wzay++xb3XNm+39xzH IJcXjn5lijkFs+75BIYGzg5cvEx1rX/qlfzAvf53tDmcr7zSbisc9LYKVr49bUKIo9+nj0/7UoLf Av8IbAhM/2xNAP41bzGs/qNnGPp+wLgzCsbox3X8+0sn+K8JDxOaDIlPj69P80+fRqHnHvSe4vA1 M34z7P2MGaW4iLNIJehDrSM+HnFlih8lxqKZwkThUqG/zmYh/35W5ikh59r8mbbFV6rT+Cq+a6f5 qowd0BigvYx/X6x9soQq4xSGZq/NzirKijTcwr/vFP6T2i/OTgZfh/Z3+TqUMpy4zm9VVOHaQnOx TqBZIPpYPEssFOeIt4pXHalR5ChTvXOKH5wZnmBaODxuMjVIUdOnlGG0cnesLdH/Y8hjSsN8rYqv /8o8amXhVI08quB5tT11PW7huiOqcfb7wNXzHAuYrWoQuT170LIGF62nLi63KHa9zJzUnH1l+Z1/ nIdT+w+rHrjr7JW78XzwAQ71ddoJLZcXF6o51+iklQVBSddjgxQujNkXoL25VGVDTXH2AjG+wf1P gd6MkQ0wZ/qnQHJApMncxnOmo04jmGPLjHRdKHXLH0brxOZRR3LEWlsPUmhz2vVYWEof9N5cRm3Y Wn7gu4hCmjYtVFlN64jLqMcHA7S//KuXJdVf68nwdCqziIOCKDuV20le2nmK9p8Y++sk59Tv88pc FHFC4Yfp2tTC1cU/Fnvc2abC4VwMGp7wwgOlcwyCtlWk+q4JL+OcD+6xL9HDe08eNSehLlx9W+UP poVXjvWxzDFyLqEqOI0n1q+u1banflBx+ZNx/OvJKsdjUBupBTbhc3fedX46OH6dDrui9pvo8mul /cVzoy6Wmx3h+OmVny0eu3rSCV997erQVVuRQp6igfbCdTcs19gK8at6YEK/W9ddy2btTWfNO07a /EllpXgqfyu76Nfv0aCCiRVB2ol2MVmmM1x9qux8ztqGu4ZOHRxxsWKah5fLVtPCNWcupV+p1v/9 Vna2JOTD+8F3L5Y9/KSgYg8K0moUeSmOrpsyJKbPXUsKT9uR3YMA7RdxDkkLclR894ud5i4/Vbph uq5vTfp4k/Hm2oo7SlVsbt02E6kzvtrbKgw0jiGLNRtGKE41LYw0uvq1bt0BvbpyP3AjZFo4M2d+ YUL+kvzc/O3536ytpu7onPzcSfuvwrQgY3HNg/eLHXMpZPBktE7S8Ngg3qWNN4T7bbecclZ8ocPZ SSUdyQ76OlzxiM+xJ44p1TXFPI/JnlFPBxxXPZg3e7FGWEif33brHflp/481K4YnPqVG6Kg+3XDy fELChhpz7sEfFF+kjNZmlFb09Zq0nLKv/8P5wOO+ig9qlmtlJJz7ZbbmFsUbXHGPEc4jtYOtr96e rXnEJ33grWVMjj+PyckS7Ww4N+f8/9Is2b8tXL9FfU+Z/ci9zFU1fsrVMDY2RocqrArrK/qXDkus rxhT6mCDIkpTSz8r3VxaWlpR+lvpzapnf39fW7Te1dK/r+oCpuBZP6fpKY5MARN7o1Zl3q36cqFL dvLplOwN2nuC7/S7XWve77uJZZykEnw7Yjcv4ACeBt+sOvSiprjpdsQC4aFfP+v51ebe2Xuc/17t PXOF2ueHSh4uO3dgmcPhcirD+Wa5ZQ5nbH2FymqOuIw2veFE/+6AXuxvdORWmlQOqXSr9D9bX4Ey F80cpzJaWJlTubXyQOVPP/NKHl75pb7iwSkTc+rKYGXRi96/Fz9QzTxCSZhylwqTSdyfLaiL9qLx og9FM0XzRd7GhSK0T0ReE/RUpCE2FtuJ0RixnzhCnCrGN+JKxRVi9JsY/+9O9aHlp1pCW2b0c1Rf MY2JZObNr69YBVVQxqDjzCXmPlNbdH2LVo94/S+4/3PiTlK9Y11pP2bSA/ry1RhuGtcg6wg1MOuI inD4XrfpX/8jztV6Th2dkxu5sTL5sknFnFX/mFdn1S+vR/nWxsjF2Mc41Hi28TL9U1nXsjTyvZgs 7fxf8p/pv/cgdIrGALRqgErhhQpLmw92Hpsp4VfzUZllhPkOk1E5ZaHemzO8c9yqDiT5mxSZX9ll dPG9M7eZ5CRKz8Xl+FYm2GKNZpWzSxUjbrqlf/HIzPhbN0tE90rOOzNesQmDnHwqqpTKXSnPqmBX 12+T/giZOom3elpPV3/zfp72LrbD3HZ7P3nPrV/f39jH+bh4xwmVwptTT4bf8JVo+7m5GV2s2+1S FjDQEz9+eW/byX1XG7ctnJo/y9dsXM5uQUD+eQGi3r8bskH7QsWFCnHdDpMdJuhs/G6T3Sbfxs/j v+eqVNmrssCqsmpWkneSt7gu1P2koVbaT4Hmky1Xf7LlUkqCSdleTs3WMiVlx6XWogUDjfiQfm7l ysp8SLI9bnvc2fgxcWm9/SY/WlzmN6WqpKbkg1KGYlQKV8clefubBO4tSpx5A/mb+Jv/mLpBO9Ak w++icKobT5w6Kaf31ZoSUchnP6ck37b0FpWKQjKPpBht/WsqH9XVG12I815zJ9C86A+jizfuom/u ZfidvT1ffK/kwR+r4/baoy3CPcIfhF7iu7Fh4iLx/r9R1uOBjy+KjS6uGS8wyfCeW6q1ckfGNAdx VfDnG/4XuJeZg8q/plftGBPX8DFVnxShWPcVEhekc9dwV/2zW5Ne9SvXV+WZ8HGE4tEb+HE/SvLt Ia6xifGn/Xf3uPvFVGMUZqxucrUiw1vd5vKJ90uH2WhNtszwCxy0w2Ro2OWrFaEfVr3nmrd9i+Vk je9s/Fz6iCyeDX5verCtg7Fo77jCq38/4g3tw6wct/VcucuE/oH4XvDvm8wrSsxdTzX/PUgUEg4r rW8bQyPsa4Jtixm/KXoqq+5Dlz972poXqFIbBsfQRytGbF5Tl+FMcX8bcrXixjDXEXSBqwNnLN9x uVvWY/+88RQq8TzoeWrK1YrrHj87avsJH6PdB/ZYDw+cElhbHutjZD7fn6Pcn8oJ3Bowam/0gUnl 0/dQdkEHDPaWlbgeszhSFdwwWj1o8B98qsfVcTPrigQzROiEYJXoT8EzgWbsHuugwKFCNG7+iEHh whQhB6pjtTCcQfj/L1eFu5kXwuyFGsHrxcp+LkH5g1KH/Kx9tvqEMTIMPVt92/i0QNkGv1JvpI2E vJSuVOEc/ed25tIwXRcXvTOzxYN7eT80+3XJ6EJnL4sL5S5e28yTEtKPz0sqtzlnc9vmsY3yiEZR z0fWva9Fxa79hVk2ONfvL2eX7SKxyGzthtW8m7bG20+HJj9ycjhb7TaM0yuT7rV0xlCnDHJjBu11 Pjb0bPUvowozapzdQ5fNRzqeZp4OnhM8P/KM9lzgme2Jijz3e57wdFh0c8ze9Q88GU/UdIcg8EO/ jAWOpYsD0fpPzlbvCDwauHXX2epbgY8CkZIAv61yhMBDECToe2T2fOS1CL8fnYNevrBe229FTR2n +ZXJfuSRM/LEmR954AI/agEn+JG3WknPWkkvOOldK+lTK3mvVmIIJ0a1+Pkc41oJD05MaiWmtZJ+ tRIzODGvlfSvlQyolVjUSvQtayVWtZL3W32MzbRTj7GFbllKfzsHIfy6iTGDOAqfF9GBNnNR83Ns TQ+yGcg9TUQ1fbvAx7eshB4GKbxRqw+OtZccP4F1Z28JfXSu7BNYOMV0Oenm18Prw6d4Xwn98Xgo cAhCv6FTwBm7PZP+CkBosyo5w3HtnhJ6BeRqDXEvhF9wbwhqnpJymsnPrnmrDYv79fqG+GFKBuFn O+4+btpQw9NUZWx/Dt/PlbpfX/fQj8swHorZM1SrnlriZ59MVSiK05PdhUNhPvcztT8fHjh6+3/v G3D8OIMo1emlGvM0jZVUaupOLVdZ0rc/x3sQVa7WW3EQZwKyUhjJtUAB3Cjdfx4mG+3lemVzi7j7 udVP8E52BhwT7ydcFZs+NgNt0PPwWkkYVIIrYvAmm3wUjUQ85IdiGiUhSCRAofj1E+4oaup1RvSM caBrnG0UGyjnoKEUp4eSgiLHh1Iwo3AmipDJVMSkolkoGNaKhdHXGR2uGdeBm/bnQ0VGEXxCWYmj SCk7SqX9kTAKxaAIFNrwqDDhOtOLa8W91YjFkaMaFnJj9RI26XWdeabFNeUixgpVjRGnoO9VbSAX lwVDEYNVAU2aVSlhVUmOQrMeS5JQzHUmUYd74wVdU5dloXTvUQOFFKAFUUqIpqmp1MskXogBoKxG P05plPhdZwygxhiOEBU8eVZpYXDvUTKFtCApR9FMpTmRO2KmIh6kHY+3JEpkX/fxMOQ604f7xz8M B1WJnj7/aYbOvUf5oCU49GURpwejhJQ5iiocBfSy7LFIiFMnoVnNMEs5aM9T8bzLUbY4sQrTlFhJ GXy2WWs3FmhDKop+IOGjMPQQsOpxRc8ylJDCzVuN+Qjx/nxIqTGKHEVaiaZpKPABm0wiQQmISWQ3 0IjBW2iEgd0FyI/3WBJKo4QGCf8607f6yRgeAnMMg97GsF5SU0erKBHguNxpxGFiwEPs+NjWUMOo XnL7f5pOihSl5I58WijJREJhSQAxLqpZWKH6yTycbZP1kBOnWdwdBWK9IhokYPVMVjqt6ikryygo 0oocmoZO5mX2vkiYxNoNFBnB1h6NXKqf1OMmpkBUHs9qIQrDCjdKUtFDPqkq8KZqEfSt36uAN1EM DyELHijUQ+GlZ+MSfJARv0EyG4HyOP8sKICDCwCNaKT4sgiwYyTChSTJuGs1R9xcAI9pKkC26eAC piBjPnafBgnDaHO39OPSSCvtVmO9hPfdnw+baqjZYbD8eCTi4/pskMxCD6MIFhrx0pxwGtCqWSks y+6WFY9/NkEMH5zVA7tKMvFRGqH0uluNlBvCxdCyao1/6d7jwE+M48FnopoaBYsKQD0nqABUOU9O yxJWSzBMNJT72m7tixhIhd++iC6Dxk8lyYzEB20WNIKjg5ffeCHG/YAr7gZu3nvEQEcwFloYw1Gi FQEDjTHgJ1e1OOgVavuJ1svwmfd9Nt1jPhk+RrMcsyfZtNd80rkTzibgLACOuZSj9zSb3gocJykn EzjXgDNEylF4lk1rLkDIXsqZB5wxC3A1NXMeAWcFcIZLOWuX7qSPA8dRyjEEztMFuGts5hQv2UmP ECI0SMoZCJwo4NhIOfsX76Q3AMdWyhkBnJPAGSDlHF+0kxYD5wMpZwpwrNLAvFLOhYU7aR/gDJNy pgPnszTZnO+k76S/Ac5AKScaOPfSZHN+lLaTNk1H7IDaVBvA4afLYlcAzkbgTGY5zcP1ePD7KDww QfwxzHQo8polYRi0PgEKuS5pYnqB0wpx1zYI2QHTlGWOh3NhAtvVxjdIRNi1BQy0IQ3+UwnJfjQk A0dHITh7QzbROPBh6J+TcdtplIjiwTGhN4DLvdjL+HfK+TBgsrtMNUioeChNrxa/HAW/RRQSsm8R ZSTQ1vBbJbA41gDSG7AvdBgLyjC4K06EYpUF4N8SnDNc8YGETALIg7ZII6ShjkxWfBBWJhDZ4Tz6 sFspQteEcU2DBPGNEuMoRLKxYNUYi1Lxy7b5oHcU3oCVRyFoSDFIH0b+RGWE9e3LCvri8lJADy9I 7w+18FQSxUhimqeApL5Bzh1XbTx0uFHNygLTFQ8lGMJUAGyMZxJh1yW4/eFz9hRnYMVW2WjIX4S7 pLBGCQ+JsKkinkNM6IHHQBT8vA5q6nH/VmT9IqALeCpJUkaJzyVUKJTeny3dA6SEiVAGDwU3SJ6n PJfgF6PwkX2CBopSbrIlWxdRuLLJjmCBPLwjGAPDnaTJli0tpmyNBrd9aShcGsheaquCHzdVMPQd lH3bGTm8VkaObWfkBJes283oYlNGDyR2iLJtO6dhHebk9zKn3tivsSO+kpOxNTjp4NfTCldUm3kN eb28hr6euMPriTu+nvjrWGcwqYfXEH8d3Qe/tjLgD3jcTIHuhyszYg5s+mDCI51vfiZ9ZBGMuwiP oJhzZlsm/fMisrgaz3LuAEfUgmO4Lpd+tIiMp4SjB4uu3otl81l8MY+2BI6xVKb4Sh49ATh9pBx1 yDl4MRnhCefRl5n0nMVkkxmSj8KJPHpZi1Sht/LoohacM/sz6aMtSj8OMmeAYySVuVBXRNcAx1LK Gbsvl9ZZAnNuKWe6cgk9eAnps0k+vr1LaIcWnDtQ1vAlsrVx/I882hM4hlLOM5CZuURWn9D6Inru ElL3RGYtcL4ETv+X+QDn7BIydjchvZ9HP14iW4djZ2+j9ZYi9N7LWo3cRtu04Ay9UkRPWkrmP02p QrbRKS1k1t4sote0lAnfRle0kMms3UFfX0rmJISjADI9MmRljoNM/wxZmbEzt9F+GbI1P/SvHXR8 Sxn3bXRhC5likPmuhcx14DxowdF7sIM2XCbLmQKcyS04i4EzpwXnKHC2t+Bc+HsHfaUFR128g1Ze 3szB1HwXB4//2PaK8FGCDx6YVBDZxga/n7oHTo1eboyE2xq2Or75oAMfXURuYWBvwTc+eiLi7b0R 8V9ck9hvcE30RcTS2B9N4GMKn37wMUOkpWFPwXM/7B/Yi63g8z4i5Nfnj38U2D1ilOAIkxn9/7IP 1NLNtOlKGCH02NtAvuuLaD+HFvtAUU1VA4pJ93/Ck/xHLx6+eAxZFOM7R1kryZ2jQZz8R4ol9OeO 6MVDVw7koMVuYjOp+cZPE3HR2yYX+MwrLaFdVr7OfkhdSS7weTaziN4IGjqgjvde6p56xEut4q9K aGbV6+yw1JWENbwOGqpnyWo49yoH+z76pV7iUfWUQjBhV1OEVjNftVaSTOEt9pgq8pe2xhd3Gjb1 Qg9tl1KR3Pv1FnNVHzAlnIDbLhYa624bfbGT86XSl5oqul6bFRueqezJVaNq6vTn3HtkoEup5NBp tZIbEXga3BPG6m3+BfQ99s6tVw8dY9/DBXSPekkvXRvjHa7GMGnK7KdlUy/5pxyUPI9G1EqimZJM 2hxMqPY3XsaMgaZUUDSTthFoKWloIyNonMfLSujUcQjdWIOXG2a1kin7hQAUui3D942taupMaiV6 hVoDS7R66c63rJVc31dCe5VoXeyRqzOgVvIsS+vpXFipRfbWsauVJO71LKEj5s3RqpWc3238FF2p lfwFzeOuGJZwv9bDbG7wk1rJfmOeA3SN9/9WgzW+c63kwu6Scvoc+KfVANOxH9VK1I15vbMmmDO1 kp5Hd5XUKAWpmL5xc+LdbZXQq7cGsOdXLcmva/SM1NqZo4LeH7Dvd1vgGXqRnhlfD0KkJ49EpMvC 6zjcJ6Yh0quvRaRnL0Ckd/8KkR7+ECI9+BlEXOgOIr26pCm/Owqkx26+GS0fx6OCb1hoKG8CPyYh LKZd2Y7SacHHPSokXpAgCE/kTYtKiBKwXUXB2f2N6r+epPCYZQY9GgOk2YQ7U6aepsDHT+Z8Lgxd +6CCeG7u47C0oSepG5wOdx/RTXLZUDF9QDlvABwv18306aGKJF8owgp2IiwYJ7IdKtnhN7nppuzL sud5tK2LO8L3JvGod0aGm+bcWhzgsd+hiIyCGCOsbdl4cz5U0/0izP//lZh3n8rLyxsaGtqXeedx xsbGuri48Hi8L7/8sh2xdxsngBQKhRC5d+9eQECAk5PTTz/91KrkO4yztLTUy8tLlgMgASoABthy wu8qTmiQ4Kuv4gECB4ZLYGfZRvuu4nzVmLIECAGnbKN9V3FGRkbm5ua2LyNttEePHu0YJ0g7u422 HzmswzDBY3KH/fubIltbWxhOOhQDfYYPH25qatoxTsiup6XJiE2zOgya+joikei/Y+gMgd++2gjl CC7BkBMSEgLG7xROY8eBXr+u7jDoGPbsMpxMa41QjmDUycrKIh7+DuMktGvXLnd3d2iElZWVsnw4 Bd+GRgcVATXybuOE4gCMWCyGkRMiYDrpSEOMGRQUlJ+fz3Smv5XD6ZQdZp3qN2TJJxCHI4l0F07Z CRBxUQsLi4yMDDBgr169Fi5cCBxy9d/bc8LRxd1rTyFLUiWhy4EI2DYlJcXMzExFRUUKkvkvOLvX b8kUj8Sl3iu9euXKFUArK98xTmjQaprqAFU26PfvC0GO2YOr0epE7G3QBx98AGAYttd9tRN6lTo1 H4JcyltSIEtyzMuXL/93AJ0k6bA5efJkGEs7lP+X8z7ZttGNVFVVJeefbdG7jbPz9C9xCgSCOXPm tC8ze3byyJHObzu4uY3vTKfQqXm8m+vIkY5DZMPgQVb2tgPlmO4Tx8nONo36Gi9ZunFDXtmcuasg zJg5D47LPyuUxiHEJyyBkL4oF+JwBD6cQjzgwwg4hTjhkAgwySmRh5whWFpad2ZC36lxxdJINy9g QIdBX0tddlwBnGX7Kk+ffbBr98+g0Oq1Ozdt/vrg4UvLPytY8VkRRIq/+H5pxubde87MmDEP4isy i9iKKAAmyB86cjln9XZIBacQydt0QPYI2ZLg4DjyjeF07N/nbNLQDoOhvlarOCHMTl4BAbRfuCgX IitXlUCk4tgtqAISByYcIQ4WI5Gi4u8WshYmV+GUyJBTqKa3ixPstmiySfGnVhBJHtv3mGBwhzgB j1StTgZIAc8KMPXSScm3hVMWmFxQV1WGIduFJWtra32DntA+iR3APmBMsB64HERkOSAA8Vc5ECBO TsGGcISrYF7ChIoDDvj2W8EJZlzlbQb2JEewJxylOHvpaMJSkMwZKioqwJ65G/aQ3gLgEVcECyxc mAscrP3CXFAXGi00QsLBjr0wF2QgTuBBKhAg+KUyBCqEt2XPdozZlt/KWgxUJIYiDZUYh1hy+ifR xM7AJEdiT9J6IRBjklOp/d8KTmiQu0MHQgCrHp5hA6eklUJov30SM8oG4ngkQszSqliXtk+Y3Gr2 UAWossHG1ACCHFNTXU12yJbtb99eeGM4mdbm8erq6rDAa38eD5OVrvkprMPFSmdxvkr29vYURf2X u5j19fWtxt8S/UucDg4OgHPhwoVvVpu3R/8GJ5hRS0srKipKVVU1Ly/vjev0Nujf4MzKyoqNjQW0 tra2mpqaRkZG+fn5XXYn4d/R6+GEYQNAwnRHejPm448/pmnawMBAQ0Ojb9++n376KaxLoU9q63fI 7qI2cYKukZGRLs0EEzro2Xg8HlhS9o4T0O+//z569GgwbO/evQEt6QM5nFaeqgFSU1PTYgkqBXKz srKSThXbogkTJgibCWoZFOtMB9spnCkpKVBAbm6udMzo0D7gtxkZGdJfAcCry1ujwsLCLJbCwsIC AwOhgnr16jVixIjDhw+3Kg908OBBKU7yKz20F6gyLy+vzt9eROvXrx81coRcUO/Rw8nRQY4JknKJ AfyoUSNlZUZ8MFxTQ8PBfqhc2ojwcJIE8Ht6uMtdNeHxIMgxnUeNlIXxqp7vW1lCWa8q/6qeGGfg p59Eh336VcF62fDlxhw5DsiApFxi6H5GjxreYdrczEXGfY1IElC9p4G+nECrqQZZWchOdP6Lnk04 s5bMv3vpJAnXzpSvWZ4Wxf+4YN1nEJHyQaZVnAE+HlKZtsKpb0plcfY1MuwwCYQPnBzkcMrq2VZo Vc8WOCsr9h/aWfBa6d9JnP8i/X/ESVwGjlDF4HIQh0iHOI9/vQOSEC+F05TYSOC8Hk5pMRAhoZM4 ocgl8xKJrkQJSAsconpn7AntpYvsCSWB30LdgGagK4QO64nglK2OVlVvCyfUAgSoFCgIAildWmg7 OCEJCBOTgp4Ql5b1/6Lfdmn7FMTEmPczhUzth9gNtLKAo5P9ED1dnSG21hABDlyCADIgKZe4tLTU QF+fCEgDQJKmImGonY2N9SCSBKYTXK6mXBLrgVb9THhyTBCTnfdI9ZSGYQ5DdXW05VK1qifG2erE BZbRSkpKsPiCKcvy5cth+rJr165WV5swVZBLSyY6ckzZWT4sx+WuJicnw+ROjik3uXtVz7i4OJg2 vqp8q3q2Pu+DWRXJF6ZaQUFBZJ4JE7TOLOcBEkxfYYK2f/9+2QkqGL+tHw7hUkBAQKuXGHamLUsw r4TcyH80O79aaBNnJ9O3StAIoXYgE5isw1zUx8fH2dnZwsICakpFRWXo0KEbN26UxQxx6Y/ThKCy oKZAHqpMbloPc2/ASf5d0Xl6KzilBOoSI4BaZCKekJAwZswYQKusrLx06VIiRhbuUn+D9RDYClZL b/BfACg3d73zKwSN81UmSL6pUhm2rwZzSc0C9pT+LA2A/8XKq31CQYGBifGxhw+UyYZ9pV/JcUAG JN9s2eCu5G8wDPtn0nb+f/nfCePMy13bUPd3+wFk3jhOhnVscFGwHom88fyl1M04GbazJd4LjfZt 5E+oBc4tGzeAi4quXoZjVuaKEz98J8WZsTgdmpNc1wedKuldwPfaGbs6SeSPeG8Qmyy9hj0nT5ok N5RJe1HpMAvtDfpqGEvaf/qgVQKcb+9vVi1wnv/lNNiw9t5tOBKrwvFf+C2oK3evTJZa7Utzc3N1 dXW7CGcXtE/wAnIXCwYS4vYHDx6EjhdaqZqa2tGjR/97Ea0Sio0VDBjQH9/OajeADEh2MlOCpIup /X+FtT6Pb5U630lAqZs3b545c+bsN00CgSA+Pl6OCSsNDw+P9v+39VaedwCcsGTR1ta2eNMEE2ZT U1M55kcffQRzjO7BGR4ePnLkyK1dRd7e3t2DE2bho0aN+qKraOrUqd2DMyoqCqb+C1iCdUlSUhI0 V3IMDg6G47Y3Sr6+vt2DE5DAtGFnV5Gfn1/34Jw1a5a9vf2iRYvWrVu3ZcsWmB5BhJwCZbIEERgM UlNTCRNkFrEE8kRYKkMSEk5pa+Tv7989OGEAgPV0WVfRhx9+2D044+Lihg8fnpOTs2zZMugPDxw4 sIylvLw8aLGETyJwFSLAhzgcgf8VSyQOl0CAJIRMiMyBVwiGlu7BmZCQ4ObmdqiraPr06d2DMzEx cdy4cUe6ij755JPuwQnTsfHjx3/bGsHSBHoU6H5iYmIgAsdp06ZBJJclcol0SIWFha3m8CqR/0V0 A86UlJQJEyZ831VElj7dgHPOnDkTJ0481kwwDYSeadOmTXv27Jk/fz5w4DQjIwPiq1evhggcgQOn JC4VAJ8kTDgFPiQ/1hrx+fzuwTl37tzJkyefOHFi37594FcnWpIsh8RflWmV2hILCQnpHpwwHkyZ MuXnrqKwsLDuwQmluru7n3k79MMPP8hxoF10D8709PRJkyZ98803P/74Y2VlJRy/YQkiGzduhGYm jf/YTMCROyVHSJ6dnS2bD4nLUkRERPfghFHB09PzfFcRLI+6B+eSJUtgjX+xmdaydPr0aXIKIwHE CwoKICI9hQhwyCkcd+zYAREpB04vtk0zZszoHpwwEsAa/wpL69evh7EBBoZdu3ZBfMWKFXBKmLAW hUhRUZGUScYJiIA8RCCJ9NKVtik6Orp7cC5fvtzHx+fatWswAEK/f+11CJK0c+ncuXOv8mEZ2D04 wQiwxr/J0oULF7744ouTJ09CHNZQq1iCOIlAj0VOpZdAGI4wQ5bygW62S7AM7B6c+fn5CgpNe5/B 4rC6uvrSpUvSI4lI41JOdbvUjoB0I6KuxhnftTRs2LBuwCn7+1KXUfu/zbA7suo13brXaopHIh77 0o8E+I5F8Qi/xgPvWoe3Fw9DocDlw1HAbn+ewG5lHcMereHKFLiGX5YSjwbCWTgb48G1FHYz5lg2 zUA2fz6bP85pNt7jnt0rnuQeBhycJw9S4PR4A/QQvPs7qwculwdHLBPfpGEUWz7ONxilsrkGs3IY Q2TTXntYmzB26/xYuJ4q5caye6qzG3LLaOyKktgd7ePZbd6j2JeK8BDZZT+U1S4RzqyRBlJD41hN ItgUgiY5PrufP9YomdU/md3xPprFh3PhQ4pEVlOMLZ6tjUhpfUewnFlwnghnuB74aCabD5afzeob wiIgte7P2k92n0Sy9aw6u8cjpra++2qRPR7xfo5e/IiwQXbIg43HC0LCEhJYfxibGsOfFRXCCxHE xISFJAriQVPM9xAkhvGCBSm8kGh+QkJUCPYcvDfj2Kh4EOOF8hP5SF2L6NRXpowE9HIvxWa+Oz8h MSw+QbqbcJoMFgvU9j6Vze+Rwn4c6DVxbOCUiR6TR7tOdWMl8J7CgdMw23WKr5uPh6uvm4eru9vU l/tTuqKX76GSrT/sDcSfwljfxLYNY+2BX4aCfQy/XUbAWoW0iETpVWIh8o6fYDhi/0lk0+DcElmP IP4dwl6JavI9PvvqmWZfx3v9E18LbcpZtoz4Jq8irSgB/R9uw6O9AwBz/gLpvg== ------_=_NextPart_001_01C8D00D.200DC7A3 Content-Type: application/octet-stream; name="image003.emz" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image003.emz Content-Location: image003.emz H4sIAAAAAAACC9xdCWAURdbuZDLJHD3TPTMdCOFwkENEjogRUCAZGAIBwn2qCImA3BAgXALrsCDi LkI4FFZRuWQRRcSsXCKOXKKABEEOdSGIQlxBkUNRQf7vVU1NhgnTsAFW/Mt8fFX1qqqrXl2vu6vH KEmSBgHkooDEaEnqBAjXuKUkjesgSe601s0oxaDTkmSKlaQYkSDAuYhLRGR75B1OBYW4RKtZOr3U KKEAqQbgBlDcPVGeKKkc/CoQrfq/oGyZAVDabKA3QGmTPNEsHb+uL/UOT4wkQ0augscY9Jf3SJKG OBNAzeiCfyweyVcZ/gSgXf6sy3Sdo9WWNsmOPu89/8uGJrlbH2tSEXGU5zGAyqU0lIcgSb5GjML8 VP5dAJVL6cnNym/HuAr+FeUIP8r3dUF8EtAR+A8yvQ2uhIKM4DrGhRXqGGvcmWglkH9hBZE3DnmF H0lZewJ1a4xwwPmCfqob6XAZMB8gHZo8UrQH/mSA9A2SPqF/4CwHFqdQnlBQvEgH72WTJ8qQDk/D QDzVmRzpcuYKU9OBM+/1CibdCh0LuRQVFTUR6ePR7yo4BiBH7Qi0JaKeeyJNfYDqR0xOMGlf1IVL iv4VOqN8wo+0wX7ogPhC9EMeuDISUTnhfUBhkbck/VANZdJYoDpQnxQA+wDqk+oe3vYEhCXJ34RR wC/0Z/JExyYhjnTE+mP6sRA98To3ljpILaTGUgbS1PVE+8aDswE4Nt7RRAl1l9oito80BOOvvzRY 8j3+VIovdVmKb+kqxlLLPTx86jTndFMqyT2NyzKWZlfkLPlSqWjuQv1ORFFb6XrUJvKTKwWQn+I6 ANlIQPo4f/nyZVDQ5VJGuDiMjsbScNQyK7g+ccl/8+/6gZS6cKSMbh0VUyFKuoPCmQ6zkXBhs8mI OHI+kpPnwtflpSPn149OihoVc//P60c3eHdlH4on+WmUkwTfeKTp/i+rcU6e1TgG/i7SuwOpvH53 joopHMWvlY78lKvOaiuLR1ujE2o27fRbRbPn1A+vj3RDlv5NeTYPfn9l/cBU1KOrga+FT4KTIZOk N0aWUd8YaYKPXI3j5aV7EH6ydCA89d2BzdpWrL3h7VExaxFF9aN6kJ63A71HsSUtOO5J352AMcAg gAbGc2AZAlLD5iRbk91n5SYksyCOxksGEOrQXcx1R+SVY4mvn7GIF6D8dE1yYv7YoGuaAx4gGaA5 cA8CMvzkLJ6itXrXyOTgWv3+a9vYWj0Va3U1pKP0VOfKAaDYkDlR5Kfr3wUkAJSeXPLIXYxFnShe +E0oqAvCSQCt0c9C+Db4Q7ARXMe4P6GOMatcopVA/v0JIi/a6xN+JPWF1K0xwgH3x63R2dHHvLRG Cyad0hojmOJvxhqN4Rtcm+uLZkP7pL+rOaEzyif8SBvshw6Inwb954G3B/vhyj6gPhF5S9IPYkxR HWh8ngQKgOtZo0l/tOauRfo3ALjgmovxjnHUi61k2VKOlIa1ty9WtSFYhd0wN+5PkX5qnuJb5OOs vcQ59i3G0vINPNz6S85lTwbk5lTK5zmYwFhaXo2x/7dajH27Urj8lTZcfkPrtdArzSVaP+YDvYHn 0BcLwIvA+AuuHyRbgAhqewYQ6sT60Q+RkfXyF7b2YAxIMQBdl9YU6hv0bXB9EfEkIyfqieuyNeYg 4nYC4WtMdY/+niv6cx7yTgPggv1pQcArDcXemY1/qReHoFfd2NDbp0i0k16eyVhavIqHY4/ycGcp leT+qipj34U7GHs+rs1Ymp/KeVJzzhF6zInrywDpOyHgB12xvwo9iP6aCnlfgPrpFfBKMOUX6z3J ViCC2hapvzIhu1q7TYgn/ZsDTP5QUJ+RE3USfbMFcWuBkvbNZOQdA8AF+4bq0hE9MlwahRnWC74R knR8eoo06WSK78C/GEvj9nEefILH/xCVSnJPYxPnJ0oxljKqcr6J/TAe9RsCkP6fA28I6weSrUcc tSNSP3SHLLyNYk7QXDEC1O/EkebFPMimAeG617s/OPjp9d0f1EC5boDsVKoHue87RGPPOe8l9j94 nO0xN3IPQGOqPiu5iGlEU5uv5qogUgYon/Ajra8rwpWBicAO6J3G1Ekw1buqaWGFqqbtN3VPob5r B5De6V6qIfxJAOmK+o7c6haXmkx66zjTFd+PY70UFvHYnydqniifirSBPJerwU/tQ9VLZA8hG3NC N1SOCxBliniMS7Yn14DsL8A2JHwa/AmY6vJd3IFyVU1Z5bJMB8qRX+TD+PRdrTxkuW4bKRmJqZ2k O4unyEY8vn87m/+bzxemvlP5b94zuJ+/GTbi9v3HcbWi8UI6Ee0RekhCHMVr+CcL3BpsBFeQ0hwV pHzNGEsgf5pD5CVdCD+SXnf7lyHxfICPHSnaAz/phMYO6Kbcx5MOH5+w1LvjJX8TwaRToVshvx1t RNKBC/p/DNw22A9X9gH1idB9SfqBxh/NCVpHmgFrgTcA6pPqnsg2hdAf2YiTkX4MAHfFvsX31sEY R0NgW7kl6alhKdLbhhTp4ELGvnEf8PCR04w9FWFHkPws7AiwfwvsCLDvedgRFH+T960EVLgU9NoS XAmMv6D9QLKKiDCBM4BQJ+y97ogMbyOlpz2KbIdw+wFRwfkmbIZ8xG0BSN+h94zVPden+1zkJf3D BXVP182GxTCU2Qy9mfUwQpJ+m5IilZ+S4nt5KefcdYyl5EOcl55n7K8M64HS/YTeAHu2uzk3rs44 Ui9IkhPXpbFEeiT9kZ9cKYD8FCfGKu1HnQCqe1ngTmSi8VcbTPmFHUeymoigNmUAoU70QyYii7e3 PuuHGMioP4wAXZP8BIonJ+oj+sOHuBygpP3hQd5kAC7YH9SeajCP6qdIWR9HHMUl018nlE37EOkt HtwQTNcT+iPZg4G4SPprhzTVyK6EC9fHHMRNBUqqD6pfOgAX1IcBgQxYfKjP2B5cJwWwaKEb3x5Y tDddR5m4XmmAdIR+KKYjkpGOeL0QCHFijFE7AnUuoPGDtZa5cH2RrsYDJdUX6aohK7lIXzRua0hu SRoJO5+04/1aV0slmYfdcI3qAOmoJjh8HJGMdER10RtHVE/SI7lw3cxHXC5QUt10R952AFxwLMUg 0BZjiY0mxzk+iqph5YKePBUrMZYS63K+iftHb1w3CSB90f4Rri+Skb6ofpH0RWNK1N0EP42pP2Jc +b9LY/rxf9r6puuJxhW1n/TUFhyuJ5Ld6LjagjLWAiUdV5ORdwwAFxxX1B9dpX6wXXKwf45ie6g0 bViKr0Ncqm/0m4ylsp/w8MZTnKdd4vHz7KmUTtpTjrF/UQ0evonjbzzqR+sW6bMpuAUYf8F1PwH+ 5oigdkQaf90hC2+jBXFij6R5TH5jgEHF5rQPcTlASXXvQd5kAC6oe2rH3ZK/bF1drZV8v2yG8klv 6eBwvZGM9EZ1iKS3dpDdLVXFv8X1sQVxa4FwfZg8UrQH8dTW8Pub630O0Q15qU6UX6wTixo3Zfc1 xLNnr/A+9dHTjB8YvoJxbsIBxiN6Sl6Sn7g32vuPYZu9koG5G3pvSeOjPkBOMGmOxsvVnNgPKJ/w I62vM8KUvzbQCoqfDH4GTG10GPI1hyEvPjUmL36QMS9+XWxefKwpL76yaegNvaOohrJlgOpCfU5z oR1A/RbpOYbjC6N38JlN7DkGPU994feLTVobN3tF/O30HOMp6G8K2jMdHAPuYeqZUNW0P6EwLiuB /EL/0PEtf45RfZjDS/fc5/7HzzFmot30HOM0WDzHSDCnORLM+dplO4H8f47nGKRDen5R+fuhQSad Ct0KOXuOYTDcFvO6C/SeBOQC9BzjDLgtGHNeCu8DCoeOSeFH0ut6nhQ+n2kBP4fMNJ+reyLfSwv9 0XOMnUjvB+CCe5GCQBrb//k7keL3mVLmoUZ0nkCaXZ+fNxgNK4HCPefx8wbRaznnf8j55QNc3uRn zolGdv7A/53GuXIlxr5RdzP2pD/AWEpswXl2B84RrImS7YvL0M75wN3Q2zfgumD8Be0JkiUjgvSR AYQ6cY80CJHX0FUBrenU/7EB0PpLoDCtU8Qkp/sMkYbiyYkxIe7VRZ1vxV7bENdLAmivFdf/50oP m3vEU5qs8E7cGuc9N2OF9/WV0d73hvM99XZ4B9AZ9a4BTARoP90Epv2U2mGV8zWr/Fr8BNPb8ff8 AXuor3+sd3npzcE9dIX79yavf7XJK+Jvlz30SeiK9tCnwWIP7WvqxfbQH+MeTSC/GI//iz10YKUp f8geKkMHtIcOBMQeulVNc2xV87UVpQjk/3PsoaRD2kMLs94JMu2hQrdCfjvuoVbon/bQQYDYQ8P7 gMKhY1L4MYRLtIceRMadwLX2UKE/2kOXIP08AC64h1oRoHMR/XAX3VsaiXNadFakr+TGY9seKT56 1nz3c5xfxJk9hKVUnNmj+K9wZo/CXpzZA/u1BMa+xysw9qytzFj6WzKXP9KUh2/q3piL+tO7AHpG 3RmoDeAvuDeSjJ5RUzszgFAn9sbeiLy6Dpqx+xwj5GK/E0x7YOg+SOWKPhV7YD7itgDhe2B1T2Sb J7S/cpF3MgAX7K/I7w989IwW7w8Y4/0BMb0/YIz3B8T0/oDJ8f6AmN4fMMb7A2IMxlR+Qfo31O9E WAZItwkBP+ia7w+qIgP1SXuA7uvxF+wbktHzpf/+/cEI1h8xKOu/sUmoL9YC4f1xq+7/X9v0ElvL iOn+fvHFKYwbDM5k/MYT9zEuPzWWcZkXor3JAVsFTwBui/uEztBXfWAiQPZKI0Dc/69z5WvrXHnx BWpefJw9L76+NS++P+7/q/8Btsuo9rHeY2qR7VL1+0tN6hdu8or429l2eTxgu5yG7UJ+sY7cSttl x65TbE15cGxnb6nOm73zdgzzqqZpN3zW9dSuHRgpRWshhktwXTRhSemCcBLwGTAFQjpfuQswItzN NjChm21HuZHlCOQfeIUuhF6Q9Lr2zGZIuAyYD9Cc15vnN/I9Aukwsetxb/9Fx4JMOhW6FfLb0XbZ B92QLf0RQOdqeD9c2QfUJ0L3NCaFH1mvqx+qISHtHeJ5Xiau0wm4lu0i9BfpewQUwRzVOfx7hIuI O82kRXunxtL1wjPxkXh3MEhy471q0UlZNyygorOy/lEPpkqrtzfyRbVl7Nnbg3NGP85vjGUsvT+Z se/tqTy8dBrjgulzGPtHz2e8QFrE2H3uVc5L3uTxmXk83GkNY6nR+5xPfcj5pXzGvtx9nD3/5vFX 7M5FO/X17NOiP8h+6QBkQ5HkD/82YgNFwt3MbyMKyvPvFbBv09Yt+VePiiEsOzkqhkWwW+GrfxtB 6SWpljRm1f1SIcpph5BTWi2R/d1ppRz8NqLg9fuZnZGNdJn4XmLQmfWjJel+KbWt5VkqYRni5iZ0 RlwtCkor4F/8pHUbyalsv3THKNKRCtC3ETlIj9Oqz7q/Ly+t+Lbn6HcneVf9DuOR8s0oV3YU5ck9 2iuGvo2gU63kL0CeJveVHUVlkdUT6dsIskkSUX+ag5OBWQD+gjZSWQRyARq7GUCoE/ZrDiIbYyRf z7g2IS3pOQbAXGb+0Oc8QkZxJKd05Kd4ChOEDN7g2i5s3hiMmQuob7iNVd0T2eaNOM+XL29E1xDu avN8Dq41FYAL2siVEPBihg+R3Dh7QidzB8JH4bFgsvTpO5/ip+OLnzeWztVK8R2cnyLNGcTYFzOd h99/lYf/gXsiknf6iIc/+ZSHKxfy8Fi8dST58phUYs/TsLvBvt54+0hh5S4evoi3kJSuXgPG/qNp gfgMHl7XnsvnPsrYM7kXj984jMfPn8B4wYbJXF72acYF5mcZ+y7MYuz+4TnOi19i7J+5mHFmzhuM pV5vM17Qfi1jj2cj44JaWxj7yn/MGAv/DdwnRFp/LmBAs54M/EPjntzNXH8W1LJhGI2KceGW3Y1J vL2W2UiY+oRsRBx7Jxvp2yxWmcD6swzlNEQErT/0HGZJyLdZOuvPdCpDZ/2ZLtaf6kinAiHrz/Rb sf64UffjuM58cD/gVQB/wfWHZEsQQXMq0vozB7KbNN+CaxOtO7T9hHK4X4RpXSC/ISyPiBfpiIVf rHNijRMywUhabG2birjxQEnWNnr+ko68NGbggmsVtbGG5Jbc2i42s/yWfN0Z5kR6GaA+Sgj4Qbr3 4d0gH4oM1MfDgPA+Jhn1MdUlUh+3g4zqSWnIVQGoHmLdT0b+akBJdXMOZRUCcEHd0HwcCRutD65L 73b6410PP/PhxhpOkhz2ZYxbyozay7V2+iDjzLTDPJz8NeMF1U8w9pQ5xcNLT/Ow8SwPP3yBh1v8 zvj0K5KHrc9zDYxznUYefi+Oh/9l4eGeNh7+3M64YI+DcZK3FOMbWyeFjknnnQA/kAMdUz/+Cwjv R5ItAUhvkfoxB7Lr0ymfK2I+UB3IHzrHKCziBYenp/lFTrRFjJeDiNsJlHS8zEPeaQBccLxYEOhV 7FupEZJ0eGYjSc7H07ATnJVKKSxceQBj385pPPz0Eh5uvIGHL+7l4dXf8fDMnzlH2P2cuD7NCXTB dc/NqUj7JbAUmQzASoDyizOiJHsTEdS2DCDUCfsvE5FXa7foi0hrHPUZufC+oTqNB0raN+nI2xCA C/YNXYvWD8+I2FTSvS9TZhxphpREl91wDRN0Rbq0AOG6JBnpkuoSSZftAvWMpJv6ENQASqqbC7j+ SQAuqJuaCPTBKTf6wo+vdv2xso2QaJUL//KPYmnVcwM57Kn9cPgj38eOkPytnVzT91Rg7P8M327S bMhLZuzJ9fBwg1Y8nNCVsc/4KGP/piwuf6svDz88nIfTxzDOHDuRh/s9zXhBy1zGngeeZ1xwF+6A qcdL4Q4Y7DYuY+w/u4Jx5n/e4uHU1Txcdx1jqeYGxgvKbmLscW5lXCDtYOz7eRdj9/G9jP37DvHw Y7hDxnX83Qp4+M1vGPsM3zEuyP2eh384zeWHf2Ls3/cL48wdFxlLj0Z5qJx2nWIYL2gVx/j0E3iO hHjPcCvj3P52xpFGcsne+XePkphdSWN5MRA+lmXE0VimsRNpLC+7pePqyv1BrDViT6D5QxBhIddb i0Ta8HwiTPLw/Sc0HHpNcb3QvMj+v13rNAcfITOcuiPEiXrJALrzuvcNWutoTND4WAWEjw8K3+ha NwfXmAqUdK3rhLzpANxlVIe1j/qrD1auXlKBRWNaSYouzdg3IUFXSyWbR5m4HtlKpKf3gHA9kYz0 RPWKNI+oHbzOReMZUcXGkg9xOUBJ9eVB3mQALqgvVA13nEnVyt4C3VC7NuICpJv3gXDdkIx0g7+I umnH6od/4MLtiFxMvslASfXRDnmbAnBBfdRFoBPb9/juOAQjqQ97lkM74uMSPefR2w/d0mjcRwwK PP2l3ZV6ln6bhr7eduN7PrrbGIyyhjOfVOevKb76ZVOlJnhqA/ZdzOPhNTt4eCZOjJH8xEnG/nbR qSxcy87Yj19MYOHVlRl7Zicx9vlwghr5/IMbcnmrdC6v34bLq3Ti8uhMLj/dh4dfyObytHGM3UkT efz0SYwzJzzDWMqZxnjBgBmMPQ/hyQ+uV9D8Rca+ugsZu5/DEyCqx6TXGGcOX8lY6o8nQdSu8usZ Lxi3gbHn842MC+p/wNhXG0+GqNzJH/HwiN2M3V1wJ0blNj3MOLPBUcbSC8cYLxh/krFn4Bke9v/M w2t+ZXy6A+7AkN/TEndg4NytMYwL6poZJ9WSefgc7sAgTzqpMo60Czsxbv7bNTY3Ct+SI986MM2R TQD+grY5yT5ABI3JSGvHWsj+l+PViOvFBEBTR/jDmWRCHu4Xaf+bvZXKiA2UKcoT5VN5Yt8XMhEm WWg68gsZXZ/k5MLXlrVI+AZQ0rVlDPIOoouFrC0PIlDeXWRzj8C6QGsD/e5G6OpCK85wSLIgIwnZ 7DnBFKHPl91hv7/iRVlX/pLHCFxRuqNSiudTWON/S+V8/wDOn01j7Ov5Fg8nbufhfUd4uPp5Hl7y O+dUYyqV479oZix9Hs/Ys6YiY9+Su7h84n1cPvQBLu+eyuUPtOLyqu15eM8jPPxmXx7+aAgPr85h LLX0MV6w7K+MPXOnMi549u88fCyXh/c8z9i3/R+M3e/PZ+xfsYhx5pJXGUsvLmPsWbuS8QLbO4H4 tTz8y3ouL/QzLji8mbHvs22M/Wd2Mc48upexlH+I8YJaXzL2lP+KcYG1kLEv+jvOq88wdr96gcs3 Sx7SY9K7Bsa+t2MZ579mZuxeKDPOnqcw9rscPLzRxfhmrkHLsL58g3FJa89rwA4Af8E1iGQfI4LG bqQ1yA/ZHzGuxfwNnf/kF3Oeph8hNC5UJvxCHr4ehctDyxN+sR6G5yW5kF2tHFrLKF6sRaIOgkW9 kaTY2uRDXA5Q0rXJg7zJAFzQ7qE+ryW5n4rXHWEls5E7oezVuACNsTVA+BgjGY0x/EUcY+1Y/fAP XBWA9lrxrG8e/NOAcH3gPjrag3hqa0m/u6qBvO5AfuoTcvSbYwn793lfMLVlTOcuboez311Rt8rA WwDN6z3g18FU70Tri4k/yi8mCt1h3PmEH+ISnbPojoztANJ7pO+m4su38SqXP2VnVUhnFK64Yj9j ir9dzk19gnaQDbYfTPckMeCv5MzEbrYXE7+S9wOZV+jOBTmNQSQNjkd4r0uPzZCQxmQ1gHRn8fB8 CQiL338pzPrwDznzPR0N0oDvgdYArWGnEtIcpxLytc8qEMj/5zjzTTqkM999FvwUZDrzLXQr5Lfj ualnoXsX8APQNtgPV/YB9YmYwzdjPp9DXxcCNCareyKfpxD6i3RuCkUwR2Mn/NxULuImM2nR3kPn c4XlSvfOZP26Jd/dfwucB8cdMTsPjrMPdB68UhQ/731OZexrVpqxZ155fv57QE3Ox3AHTOkjvE25 vr2sGupG85zW0A5ANvqC/OFnmXIRT+7mnCWwkuqkqYHzChuWWo1U/NRf149ezH6/lZ9fmka/yUoL FZwJdwo0FjwLrMYlr/D84iwTJTFDr3SWwEEFzYsxJoyKNcb8I8aoc5ZgBlLqnSWYIc4SFKCeKtKG nCWYcSvOEtC4IRv1TmAfUBvAX9BWJVlN4FrnvYuPNX4ug2wyyktMfUwgf0DFwXVe2B35kG0Bwu2O 65k79L4+F3mpTXBBO4yuf5XvDPH7Pexc/W13/p7sDOqHvUBDAH/B/iDZg8C1+uMq7Q3qnfRPk0H0 hV5/UF+sBcL742bYgd1QbgbVI+T7+6pRR9i+Qkzn76tsXcO40jO5jGc06sz4UD8z45kfR3tfHHF7 fn8/EW1rhb7yA88AdF9ytGy+drRsXvwvpfLinc68+E62vPi5OH9f8w84f5/6dKy3q7vo/H2lzN+b /PrFJq+Iv13syCeht6egv6fBZEvR2tHf1Id9O3g2rnsC+Wmdpj2F9uxbZUf+fOZ7tqbQb7XFzavH fkdw2k34renvz/yMmhfZvGhicF00oT1dEE4CKH4NkAX8CNAcriA9Ya0gGRVjLIH8T1hDdSH8SHrd dvQyJJ4P0JzXm+c3cv6edDigRTb7HUHBpFOhWyG/He1IqAa7Pv8dwTNg3g9X9gH1idA9jUnhR/Lr 6odqSEjjmZ6BNAN2An7gWnak0B/thfOQfhoAF9wLLQjw391yw44cgdO19DbGLUm/9+UW4aLZ3CKc g6/RyEKsh6/RiI3fch4XxyxA37/iOZ+qxNjz/n2cLzRmjGZe9bSpE9endtFYTgj4Qbpn4aYG0m4D twT2ApRfnLehcvYAvG3whLjQ8zZXa3cs0qJ/2N5IuiY/9SeBZMTkRP8JO2UD4t4CwvfF6p7INn5o 34xH3mwALtg3dG16i8W/6aR3W76cXP4t4MH3ua0y7ggP33GZsSdL4d8A4gddyJbxT65yC74JHIN6 lQdI702BAiBU/yQ7DFD9M4BQJ/TfHZFXtq3ILiQ9E4Q9QvnD9T0PcdOAcH3rrU/X+ztANVCuGyA7 hOpAjn7/h9Yl4j4np9x2v0dcG3X8AbgPUNAZVG+Hwag4DIdVoTv0xw2vO9Rv7QC+F1z994hP/tKh yeJRU5iu6FlAt2fuZ2ERf7vYETXRDjqDcz84Hkx2RIZht+owpDkORO9WyR+qOxelB5A0OB7hva71 uxkShtrONE4zEOcBgs9NqWC4iOOUSX2NQY1FHvjZ/2OnGzxUHsXTvCO3A7/Ju/Z0R+ypXzOu8IHD u6dLB+9z3ru9w+PbebfPbut9ql+G98TuTO9nvzfznh+0EN+u1rt1v13l5P8PH167K/8VeqY1V/hJ HULnNJ4bACagLKACRiwS9bEAPwR/ZUA4scZQnidi69nOxybbSD/JIgFYpKF15lfILyHdpdiGtt9j PbZfY5vafgL0yh0X29wWG5uuW25UbAvb78Y02yVjY6ChLSr2AZsxtr6tEa4Z2o6n0GG1A+2odpU6 kk5mxdWy1TDdZRtpqqR7zbGQTzBVBaoDtW1PmO6zjQKoLZHKrmmqZ5sdl2KbEpeqW/ZEyCfENQTq AffZJsbVtj0FhLcnBjejidfol35ml+2s2ax7vQtmk+2iWQZUQLP9Yk6wnTeX0e2X/uZKNqO5um65 UZBfgi4vme60XTRVsEnmRFsMEN6OSTAgLmLCk+5qXKVfaL14zvKbHGM9LQ+2HpOHWb+S9cbZSOtR eaz1G/kJ67fyOOspeYz1R3mE9YysV/5QyI3Wy/LzFottskXWbZcP8vEWM2C0jbNItr9YLsqTgPB2 0SK2O9CuSGPiQflDeaG8Rj4lv67bph/l5fJ5eYX8k7xK/lleLZ+T18s/AHrjbYm8TW4k75ej5cO6 ZV+yHpF/sX4JHJQvWPfKv1lRa3l3sfaMw1ibdY32PGmbJf9qmyD3tffXveZAez852z4QyJaH2XPk IfYx8gD7WN32XLJNk/9qWyhPsC3SLXusbbE80rZAzrHNl0fY5sqjbLPlcahXeP+ct2OPvUZ7NKWV vEapJR9Vqupe8zjk/1HuBmrK3yn3yoXK/fLXSl3d9qxXGsmllYflC/ZM3bLP2rPkH+w95O/tDwGd 5R/t7eXz9nbF2jNUlSR7oD2R1un6jpPW7o7jVr35k+n4xtrbUWjtg7SPO3609nKct/Zw/GSlsRap 3AaO36zD1Qq67Rii3iH3V8sBpeV+qkseqCryUNVerB3/ceD7avwIid7YTnR+aJ3jzLMecC7TbcsX zn9ajziXWwucb1qPIv1h5xrrIeda1pZIc3Kuc5O1vHO/9ZTjsG7ZhY4j1q8dX1qPOQ4Ce63HHbut /3F8Yg0fZ32wuc4MtCeS/l52TbXW1IbpXq+Olm2tq40ARlvraeOtyZrPmgTo9ctC11xrP9dC3XJ7 Qd7T9bK1h+sF4HlrlmuWtY9rZrAdDdHvJoBuLBOAHsA7QBoMhwNgYTuQHSFsCnh9wk/2MLWbt53Z VQiRK/KTDUH9geEbvPfeAv9agNvAt96Oo3sOsqOJn7FP8sY9eoLxyxl1vRSeP/svjFsPXhzkB+5V /zR2nAUGTlPMrbrQqQrYEK6NcDf4SffCCZsNYqSp7bAZagE1HSJfKQgSr5GvtKGMo7QhwZEAiHwN ke+8qn+9hoZzaiMgxXBWFflGI99n18g32vCZOiYAvfmwzfCuut2wXqU2JwPCiTbHImKnYZ2ab9ig 7jH41U8NW9Xdho/UHYaPVSq3qcgAFnno+QfJJxi+Vv8CpBmiHc0NkqOSoZKjiqGio5whGajjKGNo 7tC7bhlDK0e8oY1DNbR2yIDZ0MJhMTR1hK8nnWMk6SVVf338R8wstZxxktrU+KRuW9MhzzD+FZii tjb+XW1hnKGmAXprb3njLHV+zEK1W8wK3bI7xrypto15XW0TsxRYpLaPeVntHPOSGt6evUacAQq0 pzJ0KZzQL60NzWMHq5tj++lebzvkO2IHqTtjs4EcdXvsGHULoDce0mMnqPuMk3XLzYd8p3EiMAEY o+425qh7gfB2dMRC11vVv096OS5L9Zp66F4vHfJWpizgcTXDNEBNNw1RmwJ67XglbpjaKS5Ht9y2 kGfEZQOD1FZxfdW2cb3VjkB4O/aa8DvC12iHZn5E3QzojeftkO8w9wB6AX3V7eaByDNQtx3xkO8z DdItdzfkO0z9gd5Aprrb1F3dC4S3oyMm5sNoh1hHvNiDKaxX53Trw2orK/RvfQzoq6ZbB6heQJRB ZQ64RhltLQPUVpa+AMqw9FDbWh5WOwLh9dtLNkFI/TZj8+t6jbK3y13VHTL0KvcEeqvb5b7qFkDU bx/K7H+NMnZboTvr48BjwKPqbutD6l4gvH4dbTiPjbL0xl2hrY3axN5ct7+aQ97K3hJoA3RU0+1d 1aaAXrnf2nqonWy9dcttC3mGDfPE1h3opra1dVI7AuHt2AM7/8FrtGOCUlF9T3HpXm+T4lS3KfHq h0oZdbtSXt2q3Kl+AOi1w6ckqXvtLXTL3Q3d7ICOPrZ7gRR1l/1BdQ8Q3o4WaMNZRb8/TqMVdzsW KXpjvKZjgVIHaZIdS5W6juXglUqSY5Wi147z6k6ljWrQbUdLNUZNU6PVpuolpYn6i5KmnldaqGeV 8Ha8Dtuhd6Ad1aQiJ9Z7sjtOOBor9zllZYjzS7teW4Y5D9lHAWOd/7aPdxbYxzm/sY9xFtqpLZHK bugso5x2tFHyHMN19bTSkaMsd4xQljmGKq86Bir/dPRVXnf0LtaefU78fxcwxvSuecmZbn/A9Yst y7VW99lCL9c7tn6uPNsg12pbNtIOc71nG+r6QPe5UjNXtN3s6mgvcE7S1dW/nVPsB4F9SLfH6QPG wT/GHt4/S1yYLzb99uxyfSmfdw2Sf3U9onvP95urq3zZ1Vk2aF1kk9ZVtmiPyGYtU/e+OEYbJn/p OibnuRrr6mqVK832hqu5bRl4ictrW+RKAT9Y7PlSBQ3vqQL3XzWKhlvQfoM5Jd2nDbe20L6xCOiN uRbaUUtr7bClPdBFO2J5SDtm6aadsOj1fzet0NJEG2mtpe3TvRerqR203q19Ya2sfW51a4es5bXP rBW0PcF7sbKoqwo8hDZ1wV6kd82HtXaWXtpKcx+tr1mvPX20XuZ+Wk/zYC3TPAwYifBIrZ9Zr+wR 2lvm/lp7S3+tm0Wv7H5ad0tvLdOSqfW0PAJ00x6BvrpYxJgLv7esjbbNAVpE4f8LAmAosntCeP/U 95b0W9t0b0l8z/Lx3j7WHowr9x3HeNHoXMarGiwO8ubvbH+ae0sDbJc0rOvCDjEhHI0wjY1qgHCh a7xZjnJwSMF7xDLIt03Vz1dG3qaWkbcyiOvVQb7Z18h3nzxL5ZgZtJe6IF+fa+TrKvdROXoH83VD PrL19cb+I3KWmik/pvZC/sfxxKuPPFh9TM5m9oJHKnJCJ2ZEPSYPQ/qhqkd+UW0sv6BWk3cCO9QE 2ehIkA0Ol9xM9x7SJbd0KHIbh1Vu7YgFDHILIK3YPeQe1F9T9dePH+Q4tbbtrPKu7aDuPvm+7YCy 2fa5ssV2RNlqO6Zssp1QNtoKmT0Rqe+TbdHqT3Ip9aBcSdem2CtXUXcjzS75Dti7ZcGl1D2yVsw2 aoX9d8c1bIoe9o8Uk7JFaQDo9ZsHcq+yHdgJ7FE8yj7k2afbHjPkPe2HlAz7F7plp0Pe1H4Q2Kd4 7buVZvadSiv7jmI2BbVlc6A9lYuGSnDPonviuapfeVfdqHu992EPbka6zbBWt6gfKX51l7JB/UTX 1pun5is7lL265X4I+WYlH9gBfIj/uE+s62KfaoE1YMU1+mWoY5my3zFdqekcqHvNe50DlLrOQUo9 Z7bygDMHPBY24hO6/XLI8ZIy3LFGaeV4T7fs5o6NitfxrtLEsRp4W0lzvKm0cKwo1i9LYetVCrSn xlX6hWyJk7A/v3N+a2/g+ru9hWu0rk3WypVjb+caYe/kGmnv5hpjf8g1wd7F5WP2a6R+T3c9b7/g PMfKjTS/foac47xdrJFvoe61UXe9sb/CWUdZ5rxXedVZS1nkvEdZ7KyqLHVWKqaHXGzMFwM2YiQ9 LHHttW12TbUVuOrZTrgq6Npyha5E2ylXaduPLrx7hP8C0v/supPZvZHK/8HV0Papa4Ytz/W57RWX QVfPL7ni7PNcJvsccK7LaJ/hksAXi9mKVg37CNZGPdvHoU2Qq2qaXFf7p64tV1dbbG2gLbCmagut XqCZ9iqwXPfdw/1aadmt+eSy2lxduzpRe1Eupb0sO7SXZJs2H3b1XNmqzS72LqU52lMmYPtGGk8d tCWwy6rr2nEPaVUs3bU7LVlAH60S7L6qln7aPczmjVRulvaqpauWqKujLtod1g7andY2QEutIvRT 3tpcK1PM3u2BdryADZL6JdL1emg+c6Z2xKQ3vrO0L0y9tQOm/sBg7aBpGMLZWoFJr9wh2kTzEO1F XRt6sPaKeYC2GLb2InMW8CjCPbQXzGI9bIh6m4BUIAHYCPwd+P9m59Lvt5OdS9ys3givqd0Cxu41 C73DF/fzdsC7k7vefYTxemcq49rfW/40du4qrHtk5+qtD2+7CtV3XM+r61yddW2bda726nuu1uom Vxt1G/CRqwPQhdmH1TA2hBP2oQERW11zkf5b9QOXvh34gaulY6OrjWOdq7XjHWAVwrhfLmYHfoT2 bA3sZ8nigmBxzVj4P3G9rhxwTVIKXD2Vc64qilk7Y3doR3TXW5f2hT1BO2QvB3Zr/9fdtYBHUV7t CQkYctndkNkEsoEsFytipKBIqSIZ2YCItyioeEEWEyJXCRBSQJRBqEVFBbFoESWApUgREAGRAi6I CBQBFQGRSyQIKFqkYrVq5X/fM/uNa5Jd9llDq/88z5v3fNdz5sz5LjOb3dnvaKZ/CD4i61o4PQ31 fzvi9VbOE+mFziPpDzr3py9yvp++KeK6vSd9q3Nn+nbnjvRtzr8Dm9K3ODenv1FtvboM80ev4DOa NjWcJz6C0DrrbRzd9W9SC/TXUnvqY1Nv1gdGXLNu1otTb9PvSr1TL0wtBIr1u4FBsmaF01Gk35fa Rw+k3qr/J/UG/WLH1fptEf3YXe/j6Krf5eis93Vcrvsdl+p3OC7Te1V7ZtMb5/fBGdatPvqklL76 +SmF+vGIc3KhfiS5WK9MHgQMBUboR4HjEdetYXqrlKH6QylD9A8irltD9IqUAXplShHgB3rrB4EP qq1bRTif24PrVrixUKT3SO6n70+CzyOuXbguSQP1wqR7gBFAGdJlaBNpDI/Es51SvWdyqX57RF+V 6n2Sh+mFyYOB/kAR0kVoo+Z9tQ8u5vWpH3neKNZ31y/WrwSOR1zDivWjiQP1ysR7gBFAGdJlaBPp fMrQbxn6L9M/iLiOlekH66NPrHeVWM8qYctB4IOw69hv46z/D/7/to7xe1Bcx8jbXzJ9B8a8Izz9 1BvCLf6yTHjprXNtPmdFyi9mHduLwOwaXMe61TAfYuhp73nS0t7zpKdt8hx2bfJ85FrqWeN62fOa a7pnpuspz7OuER7TNRIoBXqhfrsa+uH6UeK53zXUM9o1zDMSbYa5RnlKXGM9w+1nKWNhy3BX5Gc+ 93lGuBTU/cxstJtyhnZzPFNdxFxAtQug3bIztAt4lrssrLDb7UK7A2dot9tzwLXbc1Cg9B1GOwd8 TR+Fm8sOe5xpFlz2s7CP0Y57jUi+/cRzVdpRz7Vph4ADnuvS9nquBrpWW+dPZuE7HLCdc0S4+6nD WV1cHwGDs37tqpd1XsRrGofy7xs1d51u1ATIcsVnZbrOAdh/C0Adah/B5xVDs7yuY1ntpd9wfmD5 x0Eo//0LtvPzu0h++Caro+u7LMP1Lez/d9ZVri+zrnadzOpe7TlRWSNNa4q+Is2VNzXyul5rmON6 sGGTiD54AOXjGnqADKCB64GGDtcfgEh9Bxo6XTc3crl+1ygtYt/3NmrgGtfIDWS57oeP723UzFXW qGm18/kqU9Oyg+cT7rp+nulxPZKZ7jovs47rnMx/R9xPxWd+7YzL/MJZJ/OEMz7zuDMx85gzJfMT ecYSrv9WqD85M951MjPZ9VVmSsTz+hblpzOdgA40dH2bmY022dXOy8zAc2DsS1UMDER6TfDZRbjY GZixxjkgY7VAtUtHuwfO0C494wFnA8H4iM/F1rnbOQPuiyP6b43718617lbOde6Wzg3uc52bga3u 86XfDhgD6lDjAv8yorGcaJxR5szOGOkcnrHYOSxjkfPBjJURdT2csco5OWOt8+GM9c6HMjY6J2Zs cprgqnuPgW7cbwb3vuGuYQ/3k4627h6OdHeyo667MuK+N959MLWu+4PU+u73Ux3u3akN3HtTdfeB iM9qmrkTHIb7GoffPdkxyr0i4p53jHuVY7R7rWOke51jmPt1xxD3esdApKue1/vYU92aGnksb9Dr pi7WZ6XM0++JuC+dpw9Mma8Xp7yo90t5SS9KWa7fnbJCHxTxc8q1eO7yrl4n9Zh+U0R/fazflnpU vzO1Uu+TekD3p+6F/L5+a7VnT1NwPhXJkc/nEX1l8v36Jcmj9M8j7nlH6Z8m3YvPHMcBE/HZ5CT9 OHAi4p73Ub1d8gx9eXK5vj/inne2fij5Odwj/An4I+4NpuqHk6foFdX2vENxPn3P8BnlQD0D+/ff YY9ZEnFfWqwPxn60P/al/bE/7Y997GCgJOJnlGV6Wf0xujvpfnz+GGntGKcXwVf9k34HoO+koXo/ oK/9GSWWYfnMtR+vT+IPcxLvUd5COlLfRfqmxP76G4mD9Q141rQhsRTpUn1ropqfRgb7jNTHSP0j tD2G51XH0NexxH5I98MzKzUeOsI+mGE/W8rHnvxhpPl7i2frM9Rm6D8F4DzWFZwNuAD+r26CYZUh Kd+h5Re5TgXL+NtK3SDTZn6HivfdPL6/ravv6Yrf+GZdftzm50saG8xXzHL1veSLjbg46ufRyrD2 HA0lFegsZMnrVb+JRnxcT+RRN/UmkKUOfldqQavVxAWB9sbwx07lzZgx4/SRI0dOK/782pdfTul+ QV7va197rcd/6i4ZknGJ0e6jvn9LMn7Qy2czOM1qfTVFXiJwF0B7WUflNYFMm98E2H43CleCzwVY F+3M88Csw3IesElY1WG+kln/ZqTbSA3rj1pn6Oc3oP0NnPWeOIJy3I/aqn5Q1WyJP7SB/Ve1Ab5B 7g96w9mgzmsXzov6LRvqQG9d6Cco14nJhsOHD0dtA/XSBkxFQRvqQm8S9BOU68Zkw6FDh6K2gbpp A7YiQRuSoNcJ/QTlpJhsqKioiNoG6qYNbtsGJ/S6oZ+g7IzJhgMHDkRtA3XThizbBjf0ZkE/Qdkd kw379u2L2gbqpg05tg1Z0JsD/QTlrJhs2Lt3b9Q2UDdtaG7bkAO9zaGfoJwTkw179uyJ2gbqpg0c 69bYbA69LaGfoNw8Jht27doVtQ3UTRtybRtaQm8u9BOUW8Zkw86dO6O2gbppQ1vbhlzobQv9BOXc mGx45513oraBumlDe9uGttDbHvoJym1jsmHHjh1R20DdtOFS24b20Hsp9BOU28dkw7Zt26K2gbpp g2HbcCn0GtBPUL40Jhu2bt0atQ3UTRu62DYY0NsF+gnKRkw2bNmyJWobqJs2dLdt6AK93aGfoNwl Jhs2bdoUtQ3UTRuut23oDr3XQz9BuXtMNmzcuDFqG6ibNvSwbbgeentAP0H5+phs2LBhQ9Q2UDdt 6GXb0AN6e0E/QblHTDasX78+ahuomzb0tm3oBb29oZ+g3CsmGwKBQNQ2UDdt6Gvb0Bt6+0I/Qbl3 TDasXbs2ahuomzYU2zb0hd5i6Cco943JhtWrV0dtA3XThkG2DcXQOwj6CcrFMdmwatWqqG2gbtpQ YtswCHpLoJ+gPCgmG1auXBm1DdRNG8psG0qgtwz6CcolMdmwYsWKqG2gbtowxrahDHrHQD9BuSwm G5YtWxa1DdRNG8bZNoyB3nHQT1AeE5MNS5cujdoG6qYNE2wbxkHvBOgnKI+LyYYlS5ZEbQN104ZJ tg0ToHcS9BOUJ8Rkw6JFi6K2gbppw6O2DZOg91HoJyhPismGhQsXRm0DddOGqbYNj0LvVOgnKD8a kw0LFiyI2gbqpg3TbRumQu906CcoT43Jhvnz50dtA3XThmdsG6ZD7zPQT1CeHpMN8+bNi9oG6qYN s20bnoHe2dBPUH4mJhuef/75qG2gbtpAq637rNnQOw/6CcqzY7Jhzpw5UdtA3bSBEWTZMA96F0A/ QXleTDaUl5dHbQN104bFtg0LoHcx9BOUF8Rkw3PPPRe1DdRNGzi7W35YDL3LoJ+gvDgmG2bOnBm1 DdRNG16xbVgGvSuhn6C8LCYbftqzwZXQ+yr0E5RXRmXDuTiHFOAcPDNsFpTVM+EpSE8Eqv92XEJC w2BdPouFyOeMrnZGgvTFdKKh1THA7QBVx7qL1LTH14/Mq8P8EEC060E8fTbeYeCkkhoO5QOcg+0z xJZ5M9JtgA0ALjf8qmmrwIy74pRxyf0bEy0hE+N+0u+HtkSfvA60oSswGTAB9dsZBuSafBntb4nm or0X4LWg33n89aUbfKc33nFFvT79hfls/mz4nf6q6Qjn91tQuQWwA6BPPgF47Wh3dup+7UHHfvs6 MW5VPyg22Y6AeIVQFZl9/K98ffyhXN8/Dm/zkX+Ovv4rfDMLMc7dmuXrzUn7G21OUv79pfha+bjb Ex/9LH09Ez6mr98K8TX9/HL2L8/XnEMYz2ou+TnGNeeQd4HQuOY8UptxvQzXkr8xz/m6lfHD54qa 9qPPMzsrP/F3hk3ULwVw2L9l2xSJLngGUoj3PnrxXKpQ3gVfgncsdcEvDt+Nt7D1k/ewqfcG8H1t zClF7QH45Vsv2nrx8zKFnbTuOZ20wFPCZuErFr+Ht3wzf/QXVnpuXB7Txkzd4veaWXxdrrBWfpFw YFhni3t1FzZvwPuS2a75EGHty7HC/rnjrfzJDwl7R04VLu//R2Ft0Szhiul/EQ4Mfdkq7/U3YfOK 14X9rf4ubKS/K+z9bq9w+YkDVrrykLCWckTYbPmZlc4+KVyRgPcb8zzD/JpydO/bUPHBubAnoMfh dw3ADYDJkHPAIPv3lFnWGGgKXAOEHupz3CnIrIXrK78ZXA991QXI3DdgfpZ0Apg2h+ZTJlS+KksM 5tcPsqqnmP0SbEddlFnGQ/knFW7uirQJlAJV94vRjgcDbdsBOOzxQP+21vxf4z3VtX49e6Lvx6GA 13MKuOr1ZBmvJ20Idz0LUNYa4FHVH08ibxIQqz9oXzcAh+0P+r8I708ZrH0+UjPoE//ABOEd39cV rt2Y90PfE0EfzajBRyyjj2hXOB/xPCybf4hBZFXzl4m8UiBWfxlo2w7AYfuL1661Zkw75yz4huf1 bNA3z9XgG5b9lPgx0f/Z8EdLfDWjaSft42m1PD/SHx8CHEeVQC4AF9jzI8taBfPCxUoBymGfHFXH 00J0Vg7EGh+D0dYP4LDjg7b20Kx3I1tvWa76zlK+Ibkvfu+f7z7tD8l6V/IISHyPshf/tnWl5cup Dwmb7V6w0k/vsdKXfS0cSEjIo88DlzcQNp3NhI11vxXWpl1llRfdapW3H2CVJ462yodMtPL9k6z0 fY9b6ZJpwv6rsLaif+MirK3Uc90iK915qZW+81Xh8ivXCZttNgtrn70lXPHee8L+ze9b6Y8qhAPb jgmX/+WUsDkFc3Gtx04irsthXAteD867VWOHZYwdloeLncko+4nX0l5X1XrIea0uwDVP5VEOhapD VnXYRuWrugnBdqH5qj6K/ovzodYZa0etX0OOf64HvEbTariGLItm/P9v1tPAZXXEJ23a1BMu34A1 o9Z95Idv/hj0EdeHqnHOMvqIMRIuzunnaNZT7j3GArHOl9x7dARw2PMl94GttfM11631xTs7bkyO 6CXurVIAnJb8HyRlHhkA5YaAmufZN8+tF8B5nnH05xp8xDL6iPWvAUIPtc8uQCbtpB95KB1qrzoR fYwCYvVNPtp2AHDYvvEgYb3/nKuFWimK5F0xXC0G4G6ur+zdWD4Yq05fXMd+gLlxeSftwj2dzAex ZoC1VlgzwIEjyXnCOVkW18OawXp72lp8w2XCRvOrLU7qIaztu8ti9zBh/wjTKr8Dawfaey950iq/ 8ylhc8xzwv7CecLG5BeEvcsXCpe//bKVfuMVYe0fq4Qrdq0XDry2Rbh8/jvC5lTcr/E8avX+63P4 9xRwATCa/gfzEqj32bCsPcDrEC4uJqIstmtk3V+puVzN70wnAGTGGpllqh7nd8apyqOs0qxPWdVV jKxq8ToJeWOBWOO1G9p2BHDY8UrduYhE/5hDcrUqhuBuOsJVa4D6KQB93jAog844lseiAa/ZOHDV a8ay9iijLeGuWQHKaGe4sTwT5VOAWH1zB9oWADhs3/Ca9sVzlSLo9ff9RPxidP+nsPfibyw/OeKM 2vZXEfSOh0/or2ngqv5iGf1F+8L5qyfKlO0qpsg8qs6DLeD4hkCsvjsMe/YAOGzf0Xbukvm0agTu YKx3qA6Q51Y1PdHiEyyv/dbV0CdaBehnKP4DZIDMk8Px7zJTLzc7OPK0Dvstrrywk6RbDRE2O0yw eMEsi0cttsqzt1vsOGTxvpNW+bjvLU7D+6DQr/l1hrBx8nyLW3WweC7ezkW9X14pHNh4i8Uv9hE2 5w0X9nYcL6yd+5BwxbWThQPtnxQuz5kp7E0vFzZ7LRD2X7FU2Mhaa5XHbxTWPn1LuGLne8KBNfuF y+d9JOyd8bGVfvQzYS3pK2Fz47fCS3bHGbT78351hf3f1BPe8Y8kYaPSIVy783QB4uF9xABjl+/8 7gJmiKh5mmU+gHESLoafR9lZiiF7vuaY4LzDuZlzC9McV5SZzzTls/lcjX1TJ3XRDqWXaR5Vx6uJ vFIg1vFqoG07AIc9XnltWuPzsrSzEAs90fdCKGAsvFhDLLCMsUAbwsVCAcrC3RMkwGFfs188d7/A sNYnVNdaQW4BbshEhGfwG9B2JZWH+KMlEtYewbrX567tHs2L7wBxnhqijcTerRRzUgmYOSVVZqkR yCvGvDUc3A9t+Sxfq5ffSbvvxjzt9YnCZvHzVjppg8Xf7bLyZ/1LONA+Po/1A0PThM0rmgob6dj5 Id/4poOwtrWbcODZXhZP9Aub7UcJexPw1IB6L/yDle99RNh/1WPCxkXThb23/0lYy58tbP7mz8J+ 74vCFfteEg688aqwcSgg7E3eIKyd+rtwxb53hf1/2mOllx+00i9UWumZR4UDvz8hbHTGUwWe5yVf Cxc4NUPS8QnCeKGTxWF2kg1wrVKAOIDXmjKPDIAy89QY4thiPHZE5cPgG4E5kPuA2V7NTyzrDTAO wsXkTJTVdoxwLuC4JxKCzPmH84LKZzpU5v6SaZ4by8gqTVb1VX/sS9VhOfOZx3qhdZXMOizncS5A n6p7qJZwWjYQ69g7hr72ATjsuagBEoXyPK4Ef3/4bItjkDuJu2Vcjda01a3ytFmlWJE7CAc2dhM2 RyH+kW90L7HKHaZwxb8Q/8gPHMRTM3D5pqeEvaufsdKL8fQM+d6tuAMCa8sXCZvzlwr7p64SNsas F/YWbhEuz9kurNVifK6EDxoE43I4eDDSIDs+WTaQdYBrgNBD3f+WIDMaP/La8hqrOKIcChUXql5o XLAe44dH1dgwkVcKxBobBtq2A3DYsUEftNa8HXdF9LjlF8Yp63P8U+aRAVBmnrKXY6FnEPQ154IR 4MFgtldzAsvoc+ZdA4QeyucFyAy3TnWAolwgVn9wjfuUykP8cSESPbC78mmNvFxzOFr4NMELzw/F 3x+vS3wiwVWM+/ABsn7xWcQA/G+ztT8vxrrGd9pyZePI06YUXl4+bGae9mZCJ+EFBcLmwKlW2vGc xeYqi6/bYpWf/NjiLQl5bGfM1IW1e1pYfFOuxR3bCQdS8y0+dbWwufF2i/P6CRtpI4W9fx4vrG2b KFyxYrJwYNaTwsa0p4W9Y8uFtX7zhc1eC4X94xcLGwNfEfZOWyVc/uBaYXPxOmH/05uFjXVbhb2f bBcur7db2MRn0OKPhZVWetZRKz3tuHDFvV8IB4q+FS434gzW918aL7xjW4Kw8XqicLiZI7Y4viPO eqfTKMTGbMi/B4PsON4NeQLA2AkXx/NRdhbjSvbTXOsSAY4/zi1V5xXOLWruUbKab8hsw7aUQ8uV rMrI7Cc0TZntWZfzV6ge5il7VBtk2fOFWvv8KOwJxDqevWirU0HIeG6LRKl8xlSqqf/mGIk76NAx XdPo5ci2RvsA3Ctb66Q1znn3zVFfiD68GNXF+Cvj+gHs6rSXLi8nv5nZSdhxi8ULyixu/oiwufEp izsss7jeBqt8QaXFDi2P7QMHncLmSzkWP32exeN+LWzckGdxhyuFtYevFQ7c3lvYfLHQ4icHCRtH hglr+0zhCuxkRQ92smSj+2PC3ounC5f/aoaw6ZwjrMXPE644/qKwHyu5tHt7uXDgs9XC5bs2CHu3 bBLWXt4hbM7bKezfvlvYWHlQOLDziJXe9Imw96V/CmszvrHyP9AM6lmyHeMcXLK5nnDFmiTh8ldS hGt33JfG4X+SET+/B+ZAfgIM+tG4n4J0WyDcuF+Csv9C/P1orKuxx6Ggxp0ag2RC1VEy61ImRxrb LFNtyBzrSk9ofmgfoTawDtNV6yKr2nzwNfI+BWKdD1ai7UIAh73fwVwj14Njt/peTsbxtLXWOCZz HJM5jskcx5KP8Qs2B75ipbcdEQ50iM+T/KR0YWNfM2Ft0UXCgXGdrXSYnW1s69NMnNMu4AmA9w6z wFXj9Fnk8dzDxWl/lDFOw/ilWnypaxhuj4vuql1PU3TEfj0NtK95/xoo7n4W/Mo9bBM4kn7NqcGv LKNf6etwfi1AWbj9aznKngSqxjd/D6YU+bwm/N/yJDCPd2/Z41vjS8wvbvO9780Xv/Htui0+/9R3 p32/iq+X//bTCfl9WtfLb/ps/Xx/kHMnHvF9+5Cef/T7/b6iQ2n5XRbt8aV2S81X/Whx8fHxcfgz IV7TjTjTBR0JAPfeLcEpAM+tRRCYXS+HGDx+kDn+zwMaAqzPA10In4u/qp/0EPkyyImAB3AByRDS mlnP4Zl+MwfvcgF6QaYt6lD3BZxfdns17/im5zWd3LR/s1uRpp3qUPVoG8vfzm5+bqS+Ap7RLTI8 NzZP9qQ140nSto5B7gRuCCzByX0JNEKnPYDQ81HniWpmiL+uQDp4mLZMm7oCO4FNAK9/oqHVMSC3 A6p+tyPa7yOUom3/YPv/Rsz8HL7X8EuKIwPXhnG0GDF0CshCIHC/q2IH+3dTyagWVRy1REWOL44H xtRMYApQWzHFMdAGYEwmgHmo+WfPg9/7Lr69Tv6a43H5D39Zz553NEwrP4fYuAm25gLfhvi7JfzN 83gz5+act3Oe8t7rXSvzh/J7bVyDyejfBM50Dfa8M7cT54JQIGmPf4inuRbwHLzBfNblMX5Rpe/S OvH566/Z4/tq3Zf47svPw+e3wLYWAGP8E2Az4IDRtLsse503yfNqk9r09R3otwCwfB0X3xFyGyA0 Xu927PY91uYrX0rpLt8LTb7wXdhgr69A/9Kn8vH9ivGh6x+a/+T1D33Ioc4VbqhxvUhEqNyMMl7j hah0BFgOnAAYp4eyjjbZnlXUxOeZ24Sy6o9x+lPXn8no3wTOZpy2rnvC93iull/58Yc+7asT/I7W +J/D3KDidD38fACoAOoE4/TDxineTtmnG4f6Wsl0GeObgHiFUBWZsV51Xo4mTue8XuFrP/qk759H DvpuHPGZr8vcSt+y3BM+lV9TnIbYEnZvpmzHKZ4xBl9Dpb3AJqASSECbRtltmvzHs7jxyOwjjSmr /n5qDF6DvosAqJH5gesh91Wh6RuRPl++oY1KcuCzB/sIle3MHwnNkEoBuB/k+pgNuADGfB3DKkNS cwA6BRwugPL/AUsR14ds8AAA ------_=_NextPart_001_01C8D00D.200DC7A3 Content-Type: image/png; name="image004.png" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image004.png Content-Location: image004.png iVBORw0KGgoAAAANSUhEUgAAAhsAAAJXCAYAAAA6vZaqAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAHugSURBVHja 7b0JuFxXeabrdG7C6djGx5ZkC8eG0yHpKEDSSsig0KQjBtPiCdfIDEY02MjGgPAAB2NsObZBsbEF eBAx2HI8ybM8YAubQTaDBZggZoUhcQJJlIG07g1NCwLBaXL7VtdX2d/h19LaVbvOqWlXvfU871O7 1l7zWrX/b6+99loH/MEf/MEBAAAAAP2CSgAAAADEBsDA/xgHHLC8yQYAgHmwlusoYgOgitjYcfzx xzfOPPNMAICuaF4/9jaZ4VqK2ADoKDbe9773Nf7hH/4BAKArmteP3YgNxAZAJbFxzz33NL71rW8B AHQFYgOxAYDYAADEBmIDALEBAIgNxAbABIiNu+++u/H3f//3AABdgdhAbAAgNgAAsYHYABgNsXHX XXc1/u7v/g4AoCsQG4gNAMQGACA2EBsAoyM2/vZv/xYAoCsQG4gNAMQGACA2EBsA9RIbxfLEfWHJ kiWNb3zjG1zAARAbiA2AcRQbd955Z+Nv/uZvOjI7O9uiil8AGH8QG4gNAMQGACA2EBsAiA0AQGwg NgAmQGxs3bq1sXv37o688Y1vbFHFLwCMP4gNxAYAYgMAEBuIDQDEBgAgNhAbABMgNu64447GX//1 X3fEYqOK324466yzGjMzM/vxwAMPdB2XwnXyc8UVVzR+/dd/fS4dpV81fuXpv/7X/9rWz7XXXrtP flI6hV9I2aqg/MXyv+Y1r+l5mw6Kj3/8442vf/3r+7mrjufTf7rF6cR+0at2qgOIDcQGQK3Ehoxf L+LqdKH/7Gc/2/Kjb/2WoVLaEiDdGLhOBijmp1dGrxfxqK2Vp1iG448/vivBNUoo37l66dRGvUJ9 x2LDfRixgdgAgBKx8Vd/9VcdecMb3tCiit9uePOb39y6ULc7/7znPa+F7sJz7h/72Mdabr5Tt3sa l/zJz9e+9rU5N5Xf4fXtsIpfbjLGGzZsaOVR5/Xb7k7Lbpdffnkrfqet4/vvvz9bLoWJZbC7/Mc8 OO7oR25pOLkpfbkpr7l0dU5+otvOnTsbf/RHf9Q61rfjVZldJ86Hwzsdp28/ad2l7eS+prhjXmOe on+XIVc2t6XbJa1bucX2dD1W7V9lKO/277wI92Hlqdf/kVEFsYHYAKiV2NAFWt8RC4FoUH1xj0Y4 vdDbcMlwRKNn5G5BIMMhY+tzURzYwCluHeeMSkwrJwosfmK5XN8xvIVHLKPjSo1YFAISBz7vfNog 5gRcO/GjfCmMhJjQseKXf4eTu46dvoVY9BNFTdpO8qP6tsBUfHZ3X7B/+ZMff+fKJv+58rgOlQ8L KflNhVZZ/yrrq7GOYpkRG1xLERsANRYbwhd2GRlf3MuMQrzQ63zZ3awMmAyPziuMjWrOQMe02hkV u3cjNqIR87mYZxu36D+tKxvwtE5yIzvtxIbyaRERDXFaLzHfzoMNewyrcqSjDk4jbeNUMMWyWfDl ytZJbCg9HSvNdPSjXf9q11djvstEKGIDsQEAidi4/fbbG3/5l3/ZEYuNKn67wXe5uXPKmy7ep5xy ypzRef/73z/3nfqXXx/bXxpfWl6PDuT8i5hW9JP6ddoyhNEtl89cXn3n/dKXvjRbBvvPCbOvfvWr +9VJzEcsS1r+z3zmM600hdJP007rJebb6cuP2ijWs0dlFH/q36R5lX/FE/0orrKyOe12babwitP9 qEr/atdXY76dfq6dJgHEBmIDYCzEhs5FA2HjLcOoO1G5ydBGQ9xJbKQGUPEoPrlF/067TGwoLcfj +QQ2hMrTfMSG8+DwyldqxGJ+5C8a6k5iw8LK8TsN12cUOnarKjaiu8P6kU8UAR/96EdLxUZsV/+W /3ZiQ2UqExtu17L+UNa/yvpqKgadDmKDayliA6CD2Ljtttsa3/zmNztyxhlntKjitxu0m2zuFVG5 K2+eXyF0oZe7wuni7rvnyy67rOUmv45327ZtrfNl6Smc4/A5xRPjlZuOFVcaZ8yXBYzcLRA+8pGP ZMvlPKZ5dbliHmQIRfQvv857LHvMp3+X1XcMr/z6nPMe6yWtx5hvxSXkJ1enFk+uI5fF4XJ5zfkv K9vb3va2Vrqug3he/q+55pp94tPv6K9d/4rEMruOHEbppP0iV8ZxBLGB2ACojdgYFhYH8yUaoF7x la98pWVA/VvHZQZLfheSlsRQr/JtATTOhhUQG4gNAMTGwOmH2PCdvUc04ojJKIPYQGwAYgOgrdi4 9dZbG9/4xjc6YrFRxe8kcN999/U17n7G3w80UkK/mCwQG4gNAMQGACA2EBsAoyM2/uIv/qIjp59+ eosqftvx0EMPzR1/+tOfbt3BRzcYD9Suk1Re9+HYl3P9epz6OmIDsQEwkmLjrW99a+PSSy9tHb/k JS9pPP3pT5/jmGOOwUh3gYSa63IUedKTnjRRwkp9WMf69mMwu0XU79V2iA3EBsBEiY1bbrml8ed/ /ucdsdio4rcMXXz1/eCDD7aMUTyni/AFF1ywoPgniXvvvbfxpje9aWTzl7bvuLeF+7a+9Tu6RR55 5JGWsB6HciM2EBsAIyc2JCRsHHXBlTGKaX/5y1+eO37Xu941N9qhb/n3hVxudlecOlZcV199dcvP ySefPDdaIgGTy0v0o+OFpCmjEkdpoiHJ5cX+HV80SDEd5UduqjPFY3fH4zzIn/IR8y4xlxrDmKaO HafiUFkVJsbhdGJdRMEYjWcM53wrXpdHx86T6yR1j6NcZXURKStzDOe4qpS/SpoR9d2YflWxkatT xAZiA2DsxcbNN9/cePTRRzty2mmntajiN8dzn/vcxvve976531dddVXroquLvc69853vbLl/6lOf arnbn4y7zutYfh2HhUKMS3HYr3jxi1/cCh/zkfOzkDR1Tn7SNJWOjlP31L/j0PnZ2dk5d/nZvn17 y83xfOlLX5oLqzD2rziUHx2rPdM2TdPUsf2rPIpH2M1+4nnXXSyT0DnXierR9R3rTW7yp/zHune6 qf+yuojp5sosnJdYt1XKXyXNNP1YPvefmGbsUxGl6f5eZxAbiA2AkRMb8eIckYHShVfndbHPGTQb ipyRtjF1ePnxnaaFTGoco1EpM6JV07RQiIZdacotGpToPxoh5cVuEaVrIx3z6/JEsaF0XNZUXMW0 07Kl9aF4dKx47CcKMbmn/UUG2XWusPKfpuE6cXw27vITxUas51xdpG2WK7PyF8uQM/y58ldJM9c/ 0napIjZyfRCxgdgAQGz0WGzYqOUMovKTCoRuxIbuGn2xF+ndaXqhl/FbSJqp2LBwUT5SI+jRnTKx obAx7xoJqCI2YhpKOy1LFWOrcMLpRj8WGWXG02mozLl6c/qqa7mrnB61KRMbubrIpRvLbNEqN4uk bsRG1TQRG4gNxAZAl2LjpptuavzZn/1ZRyw2qvjNoYux0/rkJz85Z3T828PYPnfPPfe0zp100kmt czqWu+P7tV/7tTk/+tZvxa/vL37xiy13hTv//PP3yUf0I3T84Q9/eN5p6lt+lG+XU0P0IubFxtDh HKfKLDcbfLnFfNkwxXp0+vbvNHWsb/sxaZqxTI5f52Mc0Y/yrfMxHzG86sv5drgYPtZVzIfy6bBp nnJ1kfantMwxL+5Hau8q5a+SprCb21PH6mOO3+WMaabxKJ2q/7tRBrGB2AAYObGhC7MNgY2+Lti6 IKeGzOf8OCI1tL5g+yKub/vznIwy4xj9RIMx3zRtVBw2pikjlLrHvNqP41T9OC4bUp2PgikaROdV 4Z2OSI1bmmYsk+OP5bfhjfFEQZXikYWY75hGTD/69ShQ6r+sLtIypWVW/mIbqhyu307lr5pmGk+s r9hH0jLHuozCB7GB2ACYGLHxp3/6px059dRTW1TxW4YusgsJP4rcfffdY1muiIXIOJdxkHUp8TEO ZUFsIDYARlJsvPe972284x3vGDuxMc6G2BM5P/ShDyEWelSfX/jCFxAbiA2AyRIbW7ZsaXz961/v iMVGFb8AMP4gNhAbAIgNAEBsIDYAEBvz4fOf/3zjjW98YxadO++880b+Ij2MfCo9pTvffHYTXm2x 0PyqX1btm/PxP4j6Q2wgNgCgEBs33nhj42tf+1pHXv/617eo4reffO5zn2u84Q1vaKG5BM95znPm ft91112tyZrDzmMnhpHPF73oRY0PfvCD886nvvW7Sji1y0Lz6zbtl/9u6ab8kwJiA7EBMLZiIzUA 0cDYOD788MOtY32nxjMajNR4lBljh4vnJXr0O6aRxp8i/zqvOrcRT9PUecUd/cfzLlt0dxwxj2nY XDo5t+ieExtV6iyKDec39ef8pfHZLRUP9l/WplXFhv3HeFTf7fqM0kZsIDYQGwALEBs33HBD46tf /WpHLDaq+B0Uv/qrv9oyMP595513Np74xCe27uLXrl3bOv74xz8+51duQqMhdvvABz6wT3y5NBRG 6Si+K6+8spWO3H1OcTgvSluk8eic/Tis3BWn/agtFNZ+FLd+26/SjunYXd8e4dGxy6/vWFblO82r /HUqZwxfpc5cpksuuWSfMrutnDf9Vv6cBx3HtrN/16njUT7a+c+hfuA8xL7hMrXrMzond6cL/wZi A7EBMLFiIxo/GQm5/f7v//4+AsBGNbrr2EbPfPazn225R8Eg0nRk9GRYY75SwyRjpfiiaEjD6ljt YYOYGm+Fi4be7opL55xHC4zUj/KU5lX+q5TT4TvVWUwzllnfdo9pRQET69RtJPcoyFx3Zf7L+or8 u45ieXJt6XLGsuXaFLGB2EBsAHQhNr7yla90ZN26dS2q+B0UMgBnnHHG3O+tW7e23Pxb54wMVuTZ z352y4+OHZfuaNM0ZJjlV+flV3Gl6fhcJOYrpmOcvurfx47TeU79Kn/HHXfcPvlxOOUpFzb1E/12 U84YrlOd6fwDDzywTx3FOFxmj/DEvMW2dB6a/XS/+i3z366/6Hwso8Lk+ozjivHZfZT6/7BBbCA2 ABAbidh41ateNecuA2kjKePt4f40fhlMD6vH+HJiI9ZjzihFseEh/Rj+3HPPnctjmdjQt/yVCYn5 iA3FV6WcMVy7OotppgLL4kTurq+Ypxif4s/VtcOU+S/rKyqn8p0Kn6piQ2ERG4gNxAbAPMXG9ddf 3/iTP/mTjlhsVPE7KGQkTj/99Lnfd9xxR8vNv3VOfOxjH2u5v/vd757zo2P5Ufll/C6++OL94r// /vtb5xRG/hRORidNR3Hpt9x1rDBKM8YlIeGwOo7h9TuGcb59XiLD3zKajsNhnHYurPy4rpw/Hysu HVcpZ0yjXZ3FNBVHLLPLofNuC52PeXT55NfliO7yr7ja+ZfbZz7zmX3yZLEhv8q385/rM3KLfcZt 6vLDv4HYQGwATITYkAGJ+ZeBkZt/65zPy6DKkMhQpWW2scshg6Rwildx2JDFdCw4FLfFTVl+dV7p R0OdGryYb+dB34rXYkLnY15sXNOwOQOsvKaipFM5UwPers5ivC5z2i5RCEb/drfwie6q31Tg5Pz7 d1n9Kw7XU67PuJzuMzqvOksFDGIDsYHYAJgAsbFQbFR1xzusPPhuvWyUgDrrnnaCDxAbiA2AIYiN 6667rrFr166OvO51r2tRxW9dkFHS8Psw87B69erGiSeeSJ1B7UBsIDYAEBsAgNhAbACMhti49tpr G1/+8pc7YrFRxS8AjD+IDcQGQK3Exvr161uUnf/IRz7St7hTtm3b1nq0sXz58saznvWsRtX6iWHb +YllUfxKJ9IpfBmKqxdtofzpsY7Lv2nTprEzkm5fobKedtpprbZbaLxlbdCrtkFsIDYAEBsLQHlo l4+FXKw7xZ2ityze/va3N26//faWodXvquE//elPdxQ2sSwxLTNfoyeD2QuhoTypDMqLyi2DXFfB oTpROVJ3iwzXufyp3AsRte3aQHEjNhAbABMvNr70pS915LWvfW2LsvMXXXRR44orrmicc845rd+K VxdfEf3Jj9zkX34feeSROUHgeHQ+xqOLdYxH5/RbcZWlb9K4na/Un7jttttahii6yZ/Teeihh+bK pGPHqXByU1kcr/PjsubKomOFLavPsrw6Dwrrc45T4WI+0zjLyi50x5+GUR5OOOGE/cp/3333tdzc fo5b7iKmYz9ut9jnYj+RP7spDvt3WmX9KldmxSVhp7w7XqM2TsspN9VnbM+yMrvfxj6i3zHO2PZq 5075j2nWBcQGYgNg4GJDF1QZKxvnePG2AY/uMgJahtoXWV+YFYeNqIyFLuIOY6Ogc/qt8zbkMf2c YY5+LCpyRtePD3QuGjkZHYVXGVyO6N/G3+4xLZ9PyyI/NjTGRqwsrz72qENML+ZH4RRex3JXfTs+ H+fasEz8qPyK2+WXX9WP/OvY7a5jxe98u3z2Y8Gl79gfdM5lUV05Lbm7bGX9ql2Z3T/aiQ3VucsT 27OszKlYSNvAeXN+quYfsYHYABhbsfFHf/RHjS9+8YsdsdgoO68Lqo918Tz77LMbt956awv9Vjr6 1sU6htH5U089tYXC2G+MWxdifTsux3vhhRe2fqfpRxx36kdh7Z6icy984Qtb/p1n+ZXxsh+Xw/mJ +UvTevDBB+fcXRb7SedsqA7K8qr4Y/hc+WN+Yro6r3p13eXqy+3RqR5jHcUyOw6lG8OkfhRWdRnz KhSfyxrTcth2/SpXZqedlkXn071W3LYxrrIyxzTsVtYGqXun/NcJxAZiA2DoYiNnRFMD54tsvKhb cEQDEMVGaqB9rlux4XSj30996lMtopvyozRSw5OWIRUbURTEtFOxUWZkcnlVXqLgyYmb1HDF+knb JAq/XNhoZBWP7szTtHNiI617+cnlO20z+0/r2mUo61dlZW4nNsqEZoyrrMw+p/rTt/9Dndqgav4R G4gNAMRGBbGRXqR1QZURj+76nY5s6JwNoM/Hi7WHueOIQW4kYL5iw0Y1uilPcksNvY7Tu9KykQ37 W6jYSMsvt27ERhRSOWMrN9+l58RWLL9/VxUb0Y/COe+xn9hwl4mNsn7VL7FRVuY4opEre5rPMvey /CM2EBsAYyc2rrnmmsYXvvCFjrzmNa9pUXb+6KOPnju+99575y7or3zlK1vH0V1uK1eubIXZvn37 nHFRXmI4+VE4fevC/slPfrL1LWysdNFP04847tTPLbfcMuceUVrOg42J8q1zznssk74Vl+O0u9JS XM6n6zmWRX7SO12XuSyvCis/zoN+R/8xP05P337k4nI5XK78zncsv/Iby++2i2VO8+26lx+5Kz7n W/GpTuQe00rbLJahrF+VlTmte+M4cuWPcZWVOZY1xuOyx3yqXDn3KvkfdRAbiA2AgYuNeLEUuigr 7uhuoyU3X8h9URcOp/NpfPG3ji+//PJ9LvypfxPjTv3YPUX5lHHO1U2aNwuR9Hc0xjGfMR+OK6Vd XhW/8fyG6L8sPz5WvaV+cuXXXXeuTnNtE+OL51z3FiTyl+snaZyxzdL4y/pVu/yk7ex+WFb2KmXO +Y1+Ytt3m/+yvozYQGwATLzYqILv9HynXpc7uPlQNtKyUGS0JRg8ClS1/YZJOvoB4wFiA7EBUFls bN68ufH5z3++IxYbVfy2o5lu4/Wvf33jLW95y4LjGmVUxn7E++EPf7gVt6jadsPmE5/4xNi39ySC 2EBsAIys2AAAxAZiAwCxgdgAAMQGYgOgt2Ljc5/7XEdOOeWUFlX8AsD4g9hAbAAgNgAAsYHYABgN sXH11Vc3PvvZz3bEYqOKXwAYfxAbiA0AxAYAIDYQGwCjITauuuqqxs6dOzvy6le/ukUVvwAw/iA2 EBsAiA0AQGwgNgAQGwCA2EBsAEyA2Hjve9/b+MxnPtMRi40qfgFg/EFsIDYAEBsAgNhAbACMjtj4 4z/+446cfPLJLar4BYDxB7GB2ABAbAAAYgOxATAaYuM973lP49Of/nRHLDaq+AWA8QexgdgAGGmx ccMNN2TxuTpdcD/60Y+2GHS6uXqqkpetW7cOtb5y6ferDlVHw2ibUahnxAZiA2CkxMaVV17ZeOSR Rzpy0kkntajitxP/5b/8l8av/MqvNI466qgWOhZ33HFH63cv0hgUr33ta1sMOl3X0/vf//7GBRdc UCkv119/faueh1VXSl9tP4g6dJ+q2r97jdJWeevUl7sFsYHYABhpsRGNTGr8EBvdiQ0ZtKrpD1ts DLIOh92PEBuIDQAYcbGhu1+hY412yF137/LrUZH0DtZuDqvfvuPPGVz7cfwxnONS/l7+8pfPub/g BS8oLYOR/ziC0y4vOqc4ox8fOx79ttGKIwM2pq4nhbXRlj/F6zw5TBQbZfWZGsxYBtdVuzq3aEiN vX7H/Kf15nBV2nnjxo3ZNoz12uzbc2mpLh3Wbeg6Ur7Sdk37iOvf8bTrm04z/nb7IDYQGwATKzb+ 8A//sPGpT32qIxYbVfxW5TWveU3rohzddGG+7rrrWsdvetObWn62bdvWcn/ooYda7ueff37rIp76 /73f+72W/xjX7bffvk/8Ss9l1veaNWvmvqMfxam4FKfclLbiy5XBfmKaVfOiMqZ1EdNyXnSsb/vx eefTcQi5xbwqL0rH4dvVZ1lbtKtzl8H5VTlVn3ZXWP2O6cd2d11VbWcLDrdhrg+7/Iojtk+si5hW WR+JeYp15LpO8yw3iyGXP7bbOIHYQGwA1Fps+FgXaV3gbRji3a39Rf/xvP1EQ5j6j6gelB/fidqI R8GQM8g6L4Pm3zayVfIShUSa1kLFRjSwsR4dX1l9pvnL1V1a5zK4qRGW4HB4C5CYfozbdV+1nVXf HgFL6zTNq+ohtk9ZHtKwMQ8aJVH+VU6LS/lxnnPxxHZr1+8QG4gNgIkRG5/85Cc7snbt2hZV/FZF F+tf/uVf3sdNF2UfX3vtta3z8TuS+pef8847bx8/Dz74YGn8TkNhFFZ1cd99982lZcNpv7/zO7+T LcPs7Ozcbxkix9cpL07H8cS0nM/ox/UQzzufMQ65KR+OS/nQ7yr1mebPx66XXJ3fdtttc78ltlwf Ma1cezqMxUbVdo7hVK5cu9h/zI/DyH+ahzRsmgeVX+6qS5U31nUaj87HdivLf91BbCA2AMZKbKRG V8bDBib6912njmXYU0NowSCDEeNROBklG1XFaQNYRWzY3WH1XSUvVcSG4raxVB5zYsPpRAPofDiO Sy65pFJ9pm2hcE7bdRTrXG5OP5bfIkfpOP9l6fsxStV2dnl0rO92YkPnFaeFntu/ndiIfcR1mfqX H9dHWhblG7GB2ACAIDbe/e53Nz7xiU90xGKjit+qvPGNb2xdnKObLuI+vvXWW+fO68Ktc7qIxzDR v3jZy17W8iP3iy++OJuuzhn9vvfee+d+K+5TTjmllTfjcGleXQYZJoePaXbKi+JTGR1PTMt503nH EevL57dv3z6Xb8dhw+g8qTxV6zMiA+mRg051nit/lfZ0uVz2Ku2seGIbug7L0lXc7eqirI+4Dh2/ 68JiJFcW1UXatrk6GwcQG4gNgFqIDegPFhsLjUdig/oExAZiAwCxAVmx0Ys7acQGIDYQGwA9ERub Nm1q7NixoyOvetWrWlTxCwDjD2IDsQGA2AAAxAZiA2A0xMYVV1zRePjhhztisVHFLwCMP4gNxAYA YgNKeeYznzkScQBiA7EBMEFi4+Mf/3hHTjzxxBZV/I4zd999d2Pz5s2t7+guN+HfH/zgB1vfN998 85x7GlbnHNbHaTrRPfqPacV0Yr5y8StfT3va0/YLX1aOGLfdc3Hk0k/jS8uS+le8cnfZ0zxMet8b NRAbiA0AxEYfOPfcc1tG9tWvfnXr+6KLLmoZQbs9//nPb93xy6/9HH/88XPu+tbvn/3Zn2350Xm5 y6++dS6Xjr5T/45b7opX2N2GWunYv46VX7W3jh1nxHEKHcvN+Y95TOMoS9/uLrPjjP7lrvgURued B31HgeGwgNhAbADUUGxcfvnljY997GMdsdio4ndckWHUXbeO9b1+/fqWAb7wwgvn/Oi36vTkk09u GU25XX311a2w9iPDKTd9x7D2o+8PfOADrWN92z36v+mmm1q/9R3j1nm5p/GcccYZrTw5j2nZdF4C IP5WWH3bzXmOcZSl7/zZXWnn3FVXsT5y+dGx6xJGB8QGYgMAsdEnsdHJTUY1khrpKDZSo58zuqm7 vqOw0W9tFKZ8RNK8yV87sRHzG1H/kH+POqRioyz9VCA4/znhIP+5ckeRZZEHiA3EBgBiY6LEhgxn KgB0N64Rjypiw3f6uZGNVGzI2JaJjdRI289CxIZGKDxq4T6SG9koSz91V53kxFQsVxqP6zJ1B8QG YgOgZmLjsssua3z0ox/tyAknnNCiit9x5aUvfWnLAMow6lu/o+CQYZRxll8bbx3bkDqeaFz/83/+ z61jx63zntNgd/mJ4RxPdFc+Yr7k7rw4D86P/cey3XXXXXOPaYTCyk3f+u24HWeMoyx9uStNP1rJ 5Vdu8pPWkVDfVHqqV7u5DDB8EBuIDQDERp/w3IdorGVMLS5koG0oXbcPPPDAPv51LDcZV4+CpMY/ l47D+XdqhGXkywyzwjk/+ta5GJfYsmXLXDl0HP26bI4zjSOXvsstXEd2d5z2n9aRiYIJsYHYQGwA 1FRsXHrppY2PfOQjHbHYqOIXqiGxcdVVV41l2e68885W+e6///7W71WrVjXOOeecyuFvvPHGxumn n94KR18ZTRAbiA0AxEYNkCGVUR3X8jX7WOsxiTjppJO6Civ/Ckc/QWwgNgAQGwCA2OB6itgA6Cw2 HnrooY688pWvbFHFLwCMP4gNxAYAYgMAEBuIDQDEBgAgNhAbABMgNt71rnc1HnzwwY5YbFTxCwDj D2IDsQGA2AAAxAZiAwCxAQCIDcQGwASIjXe+852N7du3d+QVr3hFiyp+AWD8QWwgNgAQGwCA2EBs AIyG2HjHO97R+PCHP9wRi40qfgFg/EFsIDYAEBsAgNhAbAAgNgAAsYHYAJgQsfGhD32oI//tv/23 FlX8AsD4g9hAbAAgNgAAsYHYABgNsbFx48bGBz/4wY5YbFTxCwDjD2IDsQEwULHxohe9qHHkkUe2 eMpTntK44IILWu7vfve759wjJ5544lzY5z3vefuEVRi5y0/0N2jK0nfZhsVv//Zvz9VRFfdBpW90 Tn7SulL7Vom3H+2uuJX+m9/85p7EF/u3y4rYAMQGQBuxcckllzQ+8IEPdOTlL395i9T9zDPPbF1w /XvTpk2tC/vNN988d1wWp8Idd9xxc7+VF/tX2HXr1lXKWz844YQTWuTyPKw8iWuuuSbrLqGmOhtW +jk/ab9oF8b5v+eee1r0Ms/t+uB8iOWqUh/jCmIDsQEwMLEhQXDMMcfsJ0Ci8CgzSLlzMazdFL8u 8CJ3cdd5CQP7iWnYLYqaMnfVhd0dZ5qO8uzynn/++XP+c8JIbhZjQv6juwys3HL50fkYp8MobdeB 3Bwuio2YL9dnrs4czn5ifqN7Gk7pC9WP43G+5S43hVVduT38Hcsa8+xj5UFEf/brcsf+EPOlcPIn oRuFQbOfz/Wd2Fc7lcWiM/a9WK5cfPbrPLgu0vIiNhAbAIiNLsSGL+g2wtFAWWx4lMDozlXfuvh2 SlcGxBd/5TUVNr5zdbpRJMjdF3fF4Xg6uSt/ylu7kQ3lRX58J27hkI6O2I+Mj0d87J4aWudf+ZG/ WD82ovYb03c9p+7Ob5ovxe+yOV9pfsuEotOPacq/j4XzHcWA49I59zkLrhhvbkTJIsJxWoSpXDG8 6i5nzONoWVqn7cpiAZKGdblSN/fBtFyOI5YDsYHYAJgosXHxxRc3HnjggY5YbJSd37x5c+N1r3vd nPCQEbviiiuyYuPuu++eM2yd0pVBURwykIov50fnfazyKO40bYXX73buMT8yGDqfpqXy6VvhVN6Y rs8ZhY9+FMbxOu5cOJdH+VG9CudN38prjEPIoNld8fm8R2nScrh95MfppXHm2sfpp/Xl9onusVyx jVQelVthOpXL8anPOJ7Yl9zXHL5d/0jz3KksZXG6XDFcLF9suzSOtK3rDGIDsQEwMLEhY6qLfXTz nbMNey6+9AIfw6Z50kXb4iQXJqZhg1UmdNq5x7gdT5mh8ShOu/IofCyLBUo0qH40kiuPznnkxWmV GWWXIRUbqeCxX4/cWMzlxEbOMJYZaKffSWz4MYP8ewSgrFw5EVEmXnspNmJ/qCI2nM9cPSE2EBsA /DEKsXH//fd3ZM2aNS1Sd207L2MZ3fT7TW9605xhL4tTF2L582/7v+mmm/aJ/7zzzpv7nYsvuikO hVEcit/uKqfyVdVdBl7x5PKsbxnwWG4dy61d3SifEk5yd9z6HfOv+lixYsU+6cV82XjJX4y7zF3p xDqOfnWscjv9mC8R85GGtSGN6aTuCn/XXXft00ZpWe3X8cY8yC22fZp3xe08Rvey/pHm2SNaZWWJ baq0HI/LFcM5rrRO03zl6rSuIDYQGwADExs2tH511Y88onhI8QVXhlbHNqg6lxoXiwD7c9ydxEY0 ZsYX/U7uSktlKhMbzr/8OI6cEVH4mI7znhp1+3MZVS+xbqN4kB/n1+nLrZ17Wb58Pmfoywyj0xHx fBQbaf1EQeX09O1HWDFe50G4rxgL2FinFlKx/O36RwzrR09lZYntHdNyuWI4/Y9yftN8ITYQGwAT KTbe/va3N97//vd3xGKjnZ+rr766Ulw5tmzZMu+wnbjzzju7cu8VNpr9TGNS6XfbQWcQG4gNgKGI DUBsAGIDsQEAiI0B331zBw6IDcQGwMSLjYsuuqixbdu2jrzsZS9rUcUvAIw/iA3EBsBQxMbWrVtb LPQidtVVVw3tAjqoMuTOV0nb4S677LKRMTqDyEuv2mUU6mqY/RuxgdgAGIrYuPDCCxv33XdfRyw2 Uvcbbrih8cY3vrF1/IpXvKJFlfjEueee23jve9+7n/tv/dZvNS699NLK8fSSsjJ0Uy7lXWVo58dl 7Kb+5P+XfumXWsdPeMIThlI/Oeablxe+8IULbpf59rFh8NznPrfVfvMpxyiC2EBsAAxMbMgA+uLZ rUGQ32GJim6NWifxMF9i/VXxa7ExDvSrTke1j6ntRq2/IzYQGwADExv33ntvR44//vgWqbsMhu5s dXeuLeh1QZWbvp/znOe0/LznPe/Zz11uCqffOk7jfNe73tW4/vrr9wmnNNL0FYePlb4oC6c4o7t+ O5x+G/2OaSi80lE4/47xKL3oX/Har75V3lhPsYxp/TltuTt+EfMfy+24HY/T1aiBw7odcm2XphFR XmI8Oo7uzrfzEtsi/s6lozzpvPPWKb+xblz3LrP6T67N0z7mNGK4svjSdna9lvWhtP2jH/3HXN5c f68riA3EBsDAxIYurDYC+o6GwsZG7uvXr8+65y7WvojbqMlNxuSUU06pJDbKwvnCb3eFtZFyHMp/ KjZsMB0u+lfcPpcaG6fp9FUH0V3+0voTyqPzn/pNxYZxvuRHRjLmSWVK664sjdTAx/a0oSxrZ8Xn dJQH/W6XThRvnfIbxYbScxyKu12bu4/dfvvt+6TRKT73D4WLfTjXh8r6r/uC/ZSJE8QGYgNg7MVG 87vxvve9ryMWG6m7jaWOfQH3uWXLljWuvPLK1vEb3vCG1jnfPdq/wqdxKpzcFVZ+9Vt+r7vuuv38 Oq6Yflk4uxltPa50dOw4VB+xDEb5djlkDMvy4DpxnC5LGo/dy+rP+XB92a/jTdOU+znnnDMXTyyr RzzSMuXSiOd1TuWNv2XE03Z2XlTvsdxu+7J0nKcq+Y1pxrK7/sraPPYxuVkoyW+7+NJ+Ecua9iGX 02mk4dzWaV+oO4gNxAbAyIgNndfFXej4tttuqyw2YhrHHnvsfga2TGyUhYtGO9KN2ND51BD2WmzI wOu80rLxaic2FGcqClTuWMZoEC2acmm0ExtqQ4vGnNhIDWundKLY6JTfTmKjrM3dx5S23JQfxd0p vpzYsKBJ+0+7PhmFF2IDsQGA2FiA2PCdfpnYiHfd+o6GQHfKZWLDRkhuUaSkF/ZovJyHXLholD28 nQoCP0Ypy5ONlv0rnXSko1uxkdZfzL/TUzvlxIaFXDpiIX8qu/2k9VyWRurH+bUfjw6UiQ2LC6fX Lh3nsWp+24mDsjZ3H0vFg8pl/2XiJe0XfmSW60NpX7Ef9feyvoDYQGwATIzY2LBhQ+Oee+7pyEtf +tIWqfutt97a+M3f/M3Gs5/97MarX/3qFj4nN93RKQ35EdqmPrrrAnzGGWfsE6fP+9hhdeFO01dY xaHzOnb6ZeH02/6dxjvf+c45v2kZjPLtO9RYHqWT+pUfu8ey+Hd0z9Xftddeu0/8SlvuMV6d83eK 68VlVfg0j2VppGXO1WNaR04z97tdOo67Sn5jmjF+1Um7No99LJ7373bxxX4hYdKuD5XVbfST9oW6 g9hAbAAMTGzA+CKjnzP8AIgNxAZAV2LjbW97W+Puu+/uiMVGFb8wHlhsUBeQA7GB2ABAbAAAYgOx ATA6YuOuu+7qyEte8pIWVfwCwPiD2EBsAAxFbNx8880tuBADIDYQGwDQM7FxzTXXNE4//fTW8Zo1 a1pM8gV40ssPiA3EBgDsJzbe+ta3Nu68886OWGyk7pdccknLwOrYYqNKfOPKb/zGb0x0+WFyQGwg NgAGJjZkXJcuXdo47bTTWkJD6w/ITd/Petaz9vFnd/nNiZYYdtOmTS33F7zgBXNLQzs+pSN3+z35 5JPnjkX0Yzcd59Jx+fVb8cfy5Pzrd5l/oWMEByA2EBsAEMTGBRdc0Ni6dWtHXvziF7dI3WV8tfW8 jvUtA+xzMrz6lpv92P2KK67YJ55f/MVfbDgv+pY4kPGO8en4pJNO2icdpa/4tmzZMheP8xTDyl1p +nwM6/OKW8dnnXVW63ear82bN3f0L6FRpT4B6g5iA7EBMDSxEUVFNPARGWwb6lSYRCQWJDhiWgof 07FbTNN5imH1W2lGv9F/FCFRNChfMe/aeCsVLdE/YgMQG4gNABiw2LAhl+HXsfFIRJnYkB+NbkRR orzKmM9HbFi4pOnkRjxSsRHzbT+IDUBsIDYQGwAVxcb555/fuOOOOzpisZG6X3zxxY2VK1e2ji0C fE4GWeflZj833nhjy/3yyy/fJx4Z6VNPPbV1vHbt2tbvN7/5zS2/ChP9xHQUv/zk0pR/uV199dUt 0aBvnXc6jj+Gi/lJ86Xziqed/+ielhFgnEBsIDYABiY2JARkaCUmJBKEz8nNBlejFDLEFhG5NDyJ 1IY7Cg+PaNjN6Sh+C5mYpgWOwzpNCY6YjvMX8+rfMV/Oeyf/StdiKvUDgNhAbAAgNuYhNkaVdJQF ABAbiA2AIYqN22+/vSMvetGLWlTxOwocf/zxLeqSX4C6gdhAbABMvNgAAMQGYgMAsQEAiA3EBsAk iI3zzjuvcdttt3XEYqOKXwAYfxAbiA0AxAYAIDYQGwCjITZ+//d/v3Hrrbd25LjjjmtRxS8AjD+I DcQGAGIDABAbiA0AxAYAIDYQGwATIDbOPffcxi233NIRi40qfgFg/EFsIDYAEBsAgNhAbACMjti4 +eabO7J69eoWVfwCwPiD2EBsACA2AACxgdgAGA2xsX79+sZNN93UEYuNKn4BYPxBbCA2ABAbAIDY QGwAjIbYOOeccxpbtmzpyMqVKxuLFy9uLFu2DAA6MDMz06Ju+X71q19d6XogEBuIDYCei43LLrus MTs725B/AGiP/it1/L9ceumliA3EBsDwxAYAAGIDsQEwL7Fx9tlnN2688UYAgK5AbCA2ABAbAIDY QGwAjI7YuOGGGwAAugKxgdgAQGwAAGIDsQEwGmLjLW95S+P6668HAOgKxAZiAwCxAQCIDcQGAGID ABAbiA2ACRAbZ511VuO6664DAOgKxEaJ2Gh+ppYsOfy+ww5bvAsGy6JFix5u1v80nXH0xMbLXvay hgQHAEA3NK8fexAbebExc8ghh/zwgQ891IDB8vM//wvfb9b/SjrjyImNWQkOGAu+0OQrxd2mjMDe JjII/9zkO4X7o01+UPiNYb9ZnKceoRu26Caea2lGbCxevPj7//OfHmvAYFn+q7+6F7EB0HOxuLoQ EBIVu5psa7KhcF+e8T/d5LGM+xoZDuoUALGB2ACYHBExpf9Lp7vGwt/yLuJdWYiSdRn37dQ9AGID sQEwvqJiXZONxdC0HoE8Vhyv6HF6GvX4vL4T9xmJENoEALGB2ACor6iYLhEVe4vjTcX8GflZ2sd8 6DHLI3pskhE9j9FWAIgNxAZA/UTG0mKUwqJiYyE4Vg5jYl0xl+OrJfM5dvdT6AAgNgCxAdCd0dZj h1V17NOF8JkujlWGZcUx/08AxAZiA2AIhtmPP9Y32VyMTjxWvAGi49U1HGnZE37r1cW1tDUAYgOx AdB/Ixwnam4qhMTesPaEJlau7fWEzSGUc0V86wSxAYDYQGwADMYA7xqVORUDKKvKthmxAYDYQGwA 9O4uvtYjEX2ok01xjY3mZ2v6ZgoAIDYQGwD7G9ClxUjEhsJ47ipW1NxZvOrJcso/rqud8U2UYjSH /yUAYgOxAVD8f3PzKjxZc3tYpnsZ9VVah3uj+EJsACA2EBsAfzC3NsTu3LwK6qdS/U0XQmx5ukoo YgMAsYHYgEkwhMu95kOHEQ0Wm1qYWNtevE2zuZ3Y0KgQ81wAEBuIDairwUvnVews5lXoEcgq6qiv db8lPHpa10FsaPfXbdQbwIiKjXddtqnx93u+nT33hS9/tXH+W/+gxQMfeqhSmBSFk3/EBtTAuK0o 7qI3jut6FTVqi6mi/pcWE2eXJ+d3xrYoRjbYkA1gVMXGit9+RuPhT31mP/fb77yn8eQn//yc2JC/ 098w2zZMWfyKB7EBI2jQpoth+l1ht9K4sRhvgwyvbdZ4Ea+iTaaS8xKBM4nbXuoOoGZiQ+4SHP6t kQyLhqpiQyMj8vvKE9c2rrnuxn3OKXyMI41PYeO3zvs4+qkqehAbUGLUVqZGC0aiXba3W7SrRGzs ym3UBgAjLDY8mhEfn3QKk2KRYdFh9xf838e2RkmcxqPf2N36jmLC/iVw5F9+dWwBpLhFjAOxMbGG aXkxmXBDsT6F16vYSP3Usj2Xpq+6VhQbm1lVFKBmYkNIKPgxSBzpqCo24uMTHVtM6Ngixm6a1yHx 4GM/spFfzw+Ru8SFwsS4FVdOFCE2xsoAzYS1KjYUjzweLUTFjmLy5oa4GyjUtq3Vxls7+MmJjf3e WgGAGoiNVHjIwHsUolMY+9eohNCxxYTP+RFLKk7iSEUUFUpTYkPfcaSExyhjbXh2hLc/vFaF51Tw Wul4tvnOTrvSFmJjaWaEi0miAHUSGxYWOb9VxIYERpzzobgsHDyaITc/ComPXaKQqCI2FF9MC7Ex skZkRdj2XKMQW6gXyAiGPZ0m55YJzU6PXwBgiGLD8yeMHlt4LoSMv4y7/NjAl4XJCYtUgOhRSIw3 Th7VoxCFi5NJc2LDeVBcFh6IjZEQEZ43saFYI2FHWJrbq2huK87P8hopZPrS5oXMtUlfiQWAEREb ngeREw4y/vptkVAljEcacmtrKD4JCYkRh0vfUklFisWF34iJczMcR7+ExqSKjbCXx4oKfjcWEzLj vAnPnVjJ/Anoot95YujSBcTRenWZ+gQYMbExKligxDkcrLPRswv4ymRy5YawcJXZU8yNiPMjtnda khugh311vSeGFmugrJhHHKtZSRQAsVGKR1BY1Gs/gRBZH8SCWdohrnVBUGxJwsa4ERUw7NG0PV4n o3jMtnke8UyzuBcAYqN2PPVpT/teePuhqgCITFe4m2sk7E1GHXaE1S1j3OuZDAdjIjZWxjdJilG1 1fOMi8W9ABAb9eKoo476YZiTkGPjQsQGAMyNbEzH0Yn5CmnmbQBMoNjo9GhEczTSZciZswEw0cJj badFvSqMkmygLgEmSGx02oStm03dEBsAEyE2NGK4ps157fC6iroCqLnY0OulfjvEr57q9dL0NVO/ Gpu++mq/XinUr8vaj779amwUGzG+3Ou56WuyiA2AsRMaS4t1Wdrti7KefW8AxkBseEEviQYZegkG fXvbea2ToWMLBS/UFfdT8YJduZ1i4wqgdo/xxVVEFYcX7/IxYgNgbMXGbIV9UVqTo6kvgDEQGx5d kJGPj0LKliyPS41H96piI64I6t8a6dCcj2HO60BsAAxUbOzq9IikeIV7LfUFMGZiI+5DYnGQW+nT IyJRbHiCaBWxkeJRDC+Vni5ljtgAGCuhoYmduyv42zLf12IBoGZiI92PRKLCIxHRPTeyIX+p2EjD eY5HfGziRy2IDYDaC4s16Qqhxb45sxXC7uA/CTAhYsObpsmfHnPYjx536NjuFhse9fBKoanYiOHi pm/27/jSyaOIDYDaCY1l6R4o3eyLUmy2NkNdAtRcbGhEId1YLXesiaKeYxHD213f0X/0a/c0PomY ND75sSBhzgZA7cWGRibWJW6tnYIrht9ddbG8Qtgspd4BRlBsAGIDoE9CQ3v17Ezc9tkXpUIcj3WR 3vr57LECgNgAxAZAPYXG0pyoKATIti7i2N1lmnvZQwgAsYHYAJgMsbEjt4y4xEfVRx2aVKpN2uaR 7hraAACxgdgAGG+hoTkZO3oQz9puH4voNdn00Q0AIDYQGwDjJTRWFo9PlvYgro3d7uja7ZwQAMQG xh+xAVAvoTFTzJlY2aP4ts1nE7ZiZIWJogCIDcQGwJgJjaliTYwNPYzzUb3OOo9wnig6TdsAIDYQ GwDjIza2Vn3LpIs49yxwVGSWtgFAbCA2AMZDaGwoNlWb6nG8UwsIu7yYu8FrsACIDcQGQM2FxvJi lc+lmXMzw3wNtdjEjdENAMQGYgOg5mJjuuzNk2IOx/oh5m1pIYQY3QBAbCA2AMZQhGwehfUump9N gjYBQGwgNgDGS2jMdrOB2oBGN5bTNgCIDcQGwHgIjdXFa6fLRihPs4xuACA2EBsA4yE0VvRyUS8A QGwgNgAmS0gs73B+pnjVdO0C02EyJwBiA7EBMIFCQ5MsH21zfrpY7XNDD9LaPUqPYAAQG4DYAOiv yJgutmzfVjbZM6yzsbkH6Wm+xy7qHmAwYmP6Zw488P9tfjdgsPzkT/7kj7irAmhdh5YVoxWb2vhZ VTw6WdejNLf1Ki4A6CA2xuAipbucGRoUoLb/4bXFRM81bfzMFkJjRY/SnGF5cQDEBmIDYPxFhh6b bC9W/lzWxt/KYi+UmR6mvXHQr6dqFIWdYQGxgdgAgMH9b/1IZOMQrxvLBpymN5BDcABiA7EBAH38 vy4tNizb3atHIvPIw4p2b7sgOAAQG4gNgPr+V9d7NGOYxrZIf/2Q64HrFiA2EBsA0OP/6a5ifsay kvNLJ+maUUyK5doFiA3EBgD08H86nXGbKUYZ9vRi3YyK+VCau0ekTtYO83ESAGIDsQEwzsJjTTHK sbsQGzMDTFsGfssI1cWq8GiJ13ABsYHYAIB5/keXF+tkbCvW09gqIzukvGwatYW8ileAtxSLmjHK AYgNxAYAJP+/pcVd+Ybi90yxLkYUFzsLP6uGffdezB1ZPqJ1ySgHIDYQGwAQ/nczxd34nmK0YGlh LHcX+5tsGAVxkeR5SuJnxOvVoxx7WUodEBuIDYB+9eeVgdnCaJexqTDsZlWHuJcl/quwK+znc1qR p12FyFhfp/UiCkO+rSZ5XcYmjYDYQGwAdGvkVnZ6vbMYLYiGfnMHsbE+ESed4p9K/FdhdZHWo95t FSMIAIgNgOH2Rz9O2BDeuHisEA9ralKG5cW8AQuMTaM6z2HC+9oMu0YDYgOxAZNzwZ8thMXe4vGC 5yysrpMxKITS7kJkbEBgjHx7eZ2O3cUbPp4ngwABxAZiA8agzy0Njxb2FBP6Vo/DfhcYqtoKXj/u 2hbm2ewshO+W8Ohttng8RjsDYgOxASPc39YXIxi1mLsQ5mlsGNYOqzC0tl9RtP3aIDY2FwJka4Xw 28Lk4G7ZVSF+58vzg1hjBLGB2AAId5EjtwZCWN9iXXKHu7d4xMNjERi1PrsuzG3ypOi9hVh5tOjD fjTENR6xgdgAGLCoWF9M4Iyvpnp9i03hbpGhcqhzP18VhPOjYaL1JkZBEBuIDYDuRyNWFhfW9Z1G TYpn7lFQMFoBk/Sf8ejdLPWB2EBsjPeffXoeazWsrGoYi8mX841/RYX4ZzrE0W4hrdkK8a8tWRxr Z+a59p7EzwaWqe5bv11eZZ4CACA2JkZstDOIFcKuq7gy5O6M8XuswsJQ6+exCmVkaY/yn2N7pzdC 2ogB80CT97cRHEvn2XYM+w7/jngHdQGA2JgIsVFsr93pjnd3iSHcVsGYzlQcBeB5/v51t6yYoLaS +hi7tl1dl6XKoSftrUeNq6kLxEZtxYb3LAivbW1KZlLPdCkGuOMdjX40XfSlWepjLNtX/9ct1MXE tPeK4jHlBuoDsTGSYiOsS7AmzISOr2RZWGwMq0Su5G649v1oM8ZorNu3NbGWupioNl9avK21mfpA bIyi2FjtRW/CO96MPoz/RWlvp/kYUOs23sBd7kS2OyOWiI3Bi43iEcY0jQ9Jv9jEXS9iA8a27T0X azn1gdjom9gIG2XtKp7hrabxIbnzYVRj/Nt5I2Jjott/lgnCiI35dJxdJevxz726WUwIs8CoxT4W MJS+tIaL0ES0szYjW0tdTGz7TxX2YBX1gdjopuOsLhEbm4pzuwpW09BQwQitoy4QG8CNBSA2ch0n Hd34lyZfLB6rIDKgaj9iBVrEBkxGH5guRr9ZpRex0VXHSUc3/pEttKHLPqT5PHuoC8QGTEw/2MEj dcTGfDqORzf+d5PLaFTosv9ofZSd1AViAyamH2zksSliYz4dx6Mbf0mDwjz6j9ZQ2U5dIDZgYvrB LG8lDVFshCW468g/NbmopnlfPgZ/3qka9513FJu31TX/0wNu66U1rqvtRXvXMv/853vGhTX/z9fy Ff25C8hP//TjHvulp/7K3jqyaNGSf/mPv/jU79Yx74+bmvqXuguOgw859NonHHnUP9ex/o964swP Dj/iCT+sY96PftKTvz996KEPD7StD378Xz35F5Z9r471teTwpY8d/aSf+34d8754yRGPjdIKmHX+ z6v/1vU/r7zrP1hnsTFz6GGLvv/ZP/vvDRgs6kB1n6x08CHT91xw8Sbac8BcfdP7GtOHHrZrkG39 Mwce9O1tH/0c9T9gTjntzY1RGvrnPz8c9N/TfxCxAYgNQGwAYgMQG4gNxAYXHsQGYgOxwX8esTGW YuODn9zVeMVJr2/8p1/7zcbK5z6/celVN9WicZVXxAYXHsQGYgOxwX8esTHiYkNC4+gn/YfGWedf 3LjpngdbF0mJjjoIDuUbscGFB7GB2EBs8J9HbIy42Dj2xS9vrJtdv9+FUiMdFiM6L+7+8Kdbbju+ +M2Wnw3vfM+cu9CxREtVP8LnY/wKp2P5i+5CIkhuCofY4MKD2EBsIDb4zyM2aiA2ZLA1olE26uFR DiG/Mvzy79EQu0ucyF3+JQSq+NE5iR25RfEgMeF05cfu8iN3+Vc4xAYXHsQGYgOxwX8esVFzseER hzgKYXEgox/jkDCJYar4iSMWFie5dB2PhQaPUbjwIDYQG4gN/vOIjRqJjdSAR2GRTha1gMgJiVSg VPHj+SFKR6MeZWLDE0HTvDJBlAsPYgOxgdjgP4/YqIHYkFHXaEV006MLGXKd89wN+42PQhYqNtKJ qJ3ERip+GNngwoPYQGwgNvjPIzZqIDZsxC0uJDwkAvSIQ5M8dSyB4ZEHPQrpldhQWp6gqvQ9J6RM bOic4nRYxAYXHsQGYgOxwX8esVETsWFD7tdf03NyS93T+RY+lkARVf3EuOPbLj6fxmOxo+/ojtjg woPYQGwgNvjPIzZGXGwAYgMQG4DYAMQGDYrY4MKD2EBsIDb4zyM2EBuIDcQGIDYQG/znERuIDUBs AGIDEBuA2BgPsZG+VdLJHbHBhQexMXpiw2+iiSr7Ji3kLTG9eVa2yKDQOb+d1u+30RAb1a/z6hfu H1qjqd82JfYDxAZiY7+3ShAbiA3ERr3Ehhf3i8Y+rgbca7FRtshgTN+v1Lfzh9gYzH/eyxb4Ou8t LtT/+2lT0qUVEBs1Ehte3yKuuZG6e4EvrXFhf34FNS4M5t96ldabrqnzOUzc/E13SXa3Ik7TjH4G KVIQGzDpYsP7F6UCxMfxv+kRD++DZPd4XbBbXCzQiwgKi430mqJj78tkI+O4Fd6iKL2zjun16054 ksVGTnh6I820f9gWxPbySJbbx/0i9eO+ZZuSio1ok6JbP9sdsTFPfMfiuwUbf7ursdWpoijwxmi+ I3GnUwPH3VzdKRWXFwqLy5VbFbtTpWnq2H580UFsIDYQG4N5jOIF9/Tfi4Y8/n/9v/b/1f50LUiv AXYXMY54DUqNiUVIdE83boxxxGtYfBSE2Oi9zWj3H0j7h3fttrs36bRtiAs72o/7VNyBPBWdFjKK L/YPuQ/KXiA2uug4UQGqo5RtupYOe6ox9Wd2g6fLjqdxRCHi0Qof59L0/ikK1274FrGB2EBs9GeC qBf9s/CIF/52j1G8Q7MNk8PY+Kdx2G+3YqNs48ZePd5BbHQvNqJNiKPbsb3K2lnnY9j0BjbtB3YX 7p+DntOD2Oii48ShTXeM2Kh+Hpd7xhqf1Xn4s0xsuDOlYsMdLPc8zjvOesQDsYHYQGwM5jFKKvA9 WlFVbPgakRqFXBy+XixEbPjxLmJjMI9RUjePXqQjYW67qmIjzvuwcKkiNoRHSRAbI/wYJd5h5Ax/ HApN1aOfmbmTuOHTP74vVhYQ8ULjRzf2r04TR1zisCxio7cXnvhnbmdM6oDKUjY5GbFRndxGjTYi 6f/X//2c2EivAb4pSePIiYp43akqNmJc7g+Ijd6j63FsPz8uUbum831sU6qKjRg23TcrhovtHO0F YmPExYYazo8tyh6v+Hw6GSvO4UgvAj6XThD1xm9xck+apjp0THNQj1ImTWy4jvslNnyxGETblc3t GdQFaJweo3hE0a83xhFQ/3+FjUMqNvxf9jXA2ECk1wC7R7/x8UpqTMrEhg2Srzn9enth0l99jX3A owy5c26XVGzEa73b33M2jPtc7tVXt7OxTUJsjLDYGLVXiYbNJIqNMjGQGu50k710oz37ie66COii kY445Dbli2mkbn5s1y5fZZv3pRegKmnmNiKcJLFR1gfmS27EqR/EvuwdoxEb/33k+0dOQI5Sv0Js IDYQG30SG+kQeBz69l1HfMXMdyUeYnVY+0nfwS/zH+9WlAed86iYREMcio9lcH7Vpz2s7/lBFhs2 Ph6ujeWJadqPR9cmWWzUDfcn969+zfVCbPRHKNbtES5iY0jKFLFRT7HhlSKNBUQUCTr22wnxuWqc OBiH2m3gPTyau7BE/3Fisg1Eemfqx3nR3ZOaXRYPtTqOOGksvhYZ/cc00wWsuhndQGyMBulIGGKj HpQtCInYGBOxAYiNsrsJj2bEUQ6PMKTipN0z9DKxEUc7HD6d4BcFSRQxceTDAiKKhygSohhJ856m aQHl+Qrd3GkhNiYHxAYgNjKUPevOPVZJ7+QWoja9KmC3dx9+3t5uzgBio/9iI573++/piITaKrf+ QhWxEd+p9yhKNPzpY74oejzDPTerPRUP8RFNFDhxUmKc2R7/L/FNLMRG/0dV63J3i9joHWX/r1FZ mh6x0QW518LSP318KyWuBjif52i++83NQnc+crOORZzJnL4hM4j5JbyN8uN31uNdvg2wDb5XfY0r BLZ7OyA1LBYKMtDpqrRpX/Hr2OnS9V7hMhUbXlFQx/H1x+juVQzjXI9YPuUrvsKJ2Oi9gcktKV2X 5/aIjd5R9gbJqGy6h9jowvCnw8w5MZIuxFL2ilknbDji3Ykv7L4jTd/h9/vUFj3xXNnaH4iN3lx4 ytbZiJssxREIi1OPcHikQN9x1CD2p7hfTuyXcb6HDXq6VoaO7SfdWTJdfCqGtQDy2hCxLzrdsjRV DqfZzeZSiI3eXK8QGzxGQWzUUGzEBisTG3FmfjrE2e2fv2z3Pwsai5FoJJyWX1OM4eMrkoiN8bnw 1HnxsEkUG3FNjDhSFUch/T+3n7g/SnpNiiMb6foKuXV60sdlxqNVab4QG/3B65ekay7Z3aOFfpMr rsWSvpXm9nL/8Kii484tHtkuzbK1oBAbAxAb6Wz+dls5x0V81FEsBro1CmVbUcd44iRDpRs7oC8e nnjoToPYGC+xkRvtQGyMrtiIc1fiFvTR3aOQqTGJ+2V43ZWyVUb92mq6GWNZmvFNonR0DbHRH9Hp toxr2ET3dIVY94v45lhsd8cR+08cXY8LQsaR8JhmnEuWG41FbPRZbJQtC9spjIXHfMVG7u4it+S4 h+PT0Qx3GN/Z5PZaQWwwMx2xMdiRjdyIaTpyGm80fO2INz0WIHEib/p6s//v6byvXJq6RvjGZJDi dZLFRmzj+Cp6FJ25/VFi2+U28Ww3sTvtBwob/cd5h/ERKWJjxMRGbqJWXK++G7FR9qePCzLlFnjy 8/U0rbKLEmIDsYHYGI7YyN2VRsMTbzB8LUj/w1XERtwzJb4pl3uW72tL7lqG2Oiv2EgnWZft/Opz 6RYXVcSG988y3o8ltWfeXHRQ8z0QG20eo6SNZiXq9RTio4w4PJU2dNkralaYUdnGi4A7mgWH86jf HpZzWK+jUHbxyS0zjdhAbCA2+vMYxY8rvHpsavjjBl3+L/ua4v99HCbPvYEUh8zTNVdym23FBdz0 jdjov9hw20c7EdvK7rYP8XG4+0VspziK7v6TvqRgd4uMdDQlPkYZ5O6viI2SO5L0tdJ4J+JJWu4I dvdwVcTP29vtqeGJOrl1HHzh8bBXXFLYKjgN686VbtSUG+JFbCA2EBu9Fxu+aUh3fU0fl3oyX7pU ePSr/3M0LA4T5/LYPf7Xc/E4bLxuITb6KzbS+k43QbQ4TF9Xt984up1uwOk+lq5U7Amg7ldpmu6f ub6H2BiA2PC2v72uZC9dPQoX+fRNGsQGYgOx0XuxQRsjNqrM+5skEBt9NMZmlFb56+VkIMQGIDYQ G4iNPN7DiD6A2ADEBmIDsQGIDUBsIDYQG1x4EBuIDcQG/3nExhiLDT3+yC0dHSfaeFGUdBnnYaJ8 DGLSD2IDEBuA2ADExgKJq77F33Feh18j6nYyUL9fO1P8/RY/iA1AbABiAxAbPSAuzFJlq+7c1vNe BTBuzZ2Kk3Qb+XRtjvg7t618uo6GF+5BbHDhQWwgNhAb/OcRGyMuNuJysn5XOgqQuKKb17qQPy+a 4sV7orsutArnd6r9nrSFjARDbs38uDmb44u71Jo0b4gNLjyIDcQGYoP/PGJjhMVGHCGIK4V6K3c/ DokLbsUliuOcj7gSoMOlW8XHlebS5Y3t5lGMuPpbuuCX3fq5cA9iAxAbgNgAxEYPH6VE0WGRYdER H6c4jEVAuspnKjYUplmGuZ1dTTqa4bRTf97VMTdnpN+LyiA2ALEBiA1AbPRQbKTLxqaPLMrERtyl NTeykds0Le7Oly51mz4aidtHIza48CA2EBuIDf7ziI2aio3czngerSgz7FFs6PFGuh193GjJx/bj +R5R1MS8yI/8ei+WMmHBnA0uPIgNxAZig/88YqMmYiO3t4kultEtXWfDkz+9DbTQKEjq7jB+hTbu AGt/6TbzSivdmjhN36MiiA0uPIgNxAZig/88YqMGYqOOpI99EBtceBAbiA3EBv95xAZio2dohCM+ ikFscOFBbCA2EBv85xEbiI1agtgAxAYgNgCxAYgNLjyIDcQGYoP/PGIDsYHY4MKD2EBsIDb4zyM2 Rl5sTE39+/+lDl1Hjnn+C2uZb7F4yRGPjYPY+N3nrKpl/b/sxNc0jnvZCbXM++8d97KhiI01zTqr ZX2tPr5x4imn1zLvv/abzxg5sVHX/7z6gPpCHfOu/16txUYhONaqM9eUbzd5b03zvr7JVJ3FRvOz vMZ9Z2eTB2uc/5UDbuvVNa6rPU2uqXH+p0foPz9T43p8sPjf858fhtioubHbUffRARha39mtCyd1 MfbtPNVkb92FPfSkL2yTaKYuEBvz6Txbm6yhQaHLfrNSQpW6mIi2XtVkO3VBP6AfIDYW0oH0CGgL DQpd9BkNA+8apaFp6FtbTxdtPUN9THQ/WF+MajC6hdhY0MVkD50IKvaXFYXxWUZ9TITQ2M6w+UT3 gZXFHI2N2AjERi861KYmszQqdOgns8UcH4TG+Lf18sLIIDQmU2SuK9pf//cV1Atio1eda2nRsWZo WMj0jxXFRWcTdzdj39Z6RLaF0auJa/dlxc3E9mIy8GZEBmKj33cy0zQuhAvQtqJfrKROxrqtlxci Q28YraVOJuK/vaYQFWrzR4ubiVXUD2JjEB1wVdHpMCwYni1FX1hNnYx1O28qjM0uRMZYt/PaYt6F RigfK/7bW4vHJTPUE2JjGB1zadEhmRA0eRelVUXbY3jG1+jMFkZmT9HOsxibsWjbmWIy52yxeJX/ x43ie0vxRslKruuIjVHrvOsL9buei9FYt/NUcdfzaPG8diX1MhbturK4a/Xd7N7C6Gwqhs+XUk+1 Eokri5sBr4S5NREUu8O8qg2F/+XUH2KjTmp5YxhmXcdFauzadk9x18NkwHq137IgKDYUbbij+K82 iuPN4W52mnobiXZbUbTHyszy9duKdosiwiMTO4qbAftdg6BAbIyzut5cGKe9QUWv4264dne8Wwuj tB4jNPT2WBqMT84AbQkGaE8wQI8GQbGhGJ1ayShkz0RcjnVt9tzYkeGx0F5mZzi/LYljdUgLEQGT KTaSP+R0eD64ufjjNDJKPF4Mu2V1mz99BGPZub38qMTtsmYIeVhRsT27YVAbm72jyU1teKSo23b8 bcbwiO8k/h5J4n5H8T8TL+rSAI4LG0uMeTc8VlL/KY+2iaPdtSzXP5kbAYiNAYyCLPRiuK3iRWRv m+HGNZP8rnghCjcUoxhbur1bCqIyfV5cdif3aJuL+M4eGIwdiWGPhvkTGR4tyl7G9ysaoMc6xPO1 CmLjcz0qfzcGcFxY3wNhiuEHxAb0XOSsCpOodhbGYltxdz/2c06K+RibimH3DWVlLkY84gjB5uS5 /95g1LZXuJNb1mU+l7YZpSi7K91bYnTnMzrG/CMAQGxAz4zvVGF4thQGePsBY7jTbfG82Qszzca7 ueLc6mDI9xRGPD47Xter5/5B+K0t4t6UEQ972jy/5q4UAACxUWujvOqAH681MDsmImNb8dhgbSjj xjCf5tFg0Bd8Vx9GRdYFAbMz80hrS3F+FvEAAIDYmETRsbS4467lqqlF/r3S55sO+PHeBo3ie/1C y3XAjxcLWh9GJ/aGUZHNQcCwlwIAAGID2owM2HCO/F13EEnfavLQAT9eDXJBexsU8a4KIxWeGOkV ZWd5AwgAALEBCzPi6wrDOrITB5ufCwpxIaHx54UAWDrPuFYc8OPlq3eH+SwbeNwBAIDYgP4Z8xXF 3IOZEcvXCU2+2+QHTW48YB6L/hSTNuM8jp0H/Hj56pEqLwAAIDbGXXDMFAZ56Aa4+fmdJn9diIw3 dRk2fQtnVy/mcQAAAGIDeic4dg7rkUoxCvHZJv9Lc0m6zPe64nHIRK0vAgCA2IA6Co7lxQjH9ADT 1KqdtzT5diE2piuGWRdWzNy8kImiAACA2IDBCg6NCmwZUFp6E+SvmvylxENFMeRHJJsPYOdWAADE BtRWcGzv50hBMbdCEzW/2uSL7SZ/HvDjTdV2FnMw1vLWCAAAYgPqLzaWFo8opvsQ94pCNPxxMUox XeIv7neyhQW0AAAQGzB+gkPrUWzqcZyrijkh95U9NinmY3iV01kW1AIAQGzA+IqNqWLy5dIexSeh 8UCxAujakvRmc5uqAQAAYgPGV3D0ZHSjmGfxsUJsrMqcX12MZGxiJAMAALEBkyU2Fjy6UQiN24vH J6uScyvCdusz1DkAAFAJkyk45j26UYS9pRAUK5JzG4o3TFZSzwAAgNiYbLGhN1P2zCOcRy1uiXM0 igmgGsnYQP0CAABiAywQdnQzAlEICr3eemEcFSkW5dJoxmrqFQAAEBsQxcO6Lvcr0cjF+cXiYFOF 25pCaLDqJwAAIDZgP/FQ+VFKMU/jhmJkY7pw01smW3mdFQAAEBvQTkR0fJQSHpN8zhNCi1GOWeoQ AAAQG9BJbGzoNKmzEBY3eJ5G87OxyXrqDwAAEBtQRWxoBdDtbc5rVOPr3lOl23keAAAAiA3EhgTE 3jbnNarxYCEyVsbJoQAAAIgNqCo4duW2gy9GNf68OL+smLcxTZ0BAABiA7oVG5tykz2LUY2/bvI7 heCYob4AAACxAfMRG1orY2vippGMbxWCY2e6LDkAAABiA7oRG1qCfGfiprdUvlm8ebKVegIAAMQG LERs7DdJtPn5YpPvLHR3WAAAAMQGWFzssajQ3Iwm/7PJ51m4CwAAEBvQK7GxM6wOqqXJ9xZzNnjN FQAAEBvQE7GxWWtpFMdfKkY6NlE3AACA2IBeiY31xWRQbc72z03+B3M1AAAAsQG9FBtrm2xpsrrJ j/TKK/UCAACIDeil2FhZ7AB7cZN/1dob1AsAACA2oJdiY0UxSVSC4/9jYigAACA2oNdiY6ZYU0Nr a/wVdQIAAIgN6LXYmGryWJP/rbkb1AkAACA2oB+Co1HwXOoDAAAQG9ArgfHSJnc0ua3JvxRi43nF hNFp6ggAABAbsFCx8WgY0Uj5AXU0Pw4+8MB3tKlXAKgBjz/44C9wPUNsQG/ExvI2f7bnU0fzY/qQ g+9574a3Nb7zpS9ACeefdmrjXeecPZC0Hrj2mlZ6vY5X+a9ahr975JN9LWM3eYHO7PrAA42DDjzw 21zPEBvQO8HxzYzQ+BvqBrHRT+OvfvZzTzy68WcPbe/o//P33dtYsXx54+Hbbpm3sFFavS7H7z1r ZYsq/vohduaTF0BsIDZglEY3nkTdIDb6xStXv7Bl/EXOCEtURGFx+gmvbPXLzRddOHc+jhREvxIv afh2YsN+JWiiey4e+YnE83ZzOIdRnpV3lSE3umH/UXSlcaWCzPlVfE6rXV5y4ecr3BAbgNiAhQiO PUFoPEydIDb6iQy/jK/uxKMIkFG0CDEyqPr2SIiMZBQp+q1z+r79istb5zQK4vDtxIbTl38LArk7 HuMRgxiv3PRbpOeMDL78Oe+psJIQifm1mPLvGKdGg8rSsXual07h7R8QG4gNGJTY+I+F0Pj/qQ/E Rr/nFvjxie/6bQg94iGBIWSoPd/CgsJiJSc2hOctOG65lYkNiwaJAqXj+GWELTDkrnwpPzbUzl/O wPuc43b+ciM4Fl2pIIpxWYB5jkuuvsrERi58mkfmeSA2EBv1NNrLitdG68j3m7yvxvkfmSXWERvl 2BDK+MnQpiMHubvtqmLDIwlxtKKd2HD66chD2eOdNH+pgc+dKxMbyqvT9SiJR0PSuJyftBypQCnL i8N7lMXzO2LdA2IDsVEjfuIn/t2PDjziKXtryaJf+G5d8/5TBy7W6qfrERujjQ2sjWEc0tcdePpY RXfunUY24ghGNLKehNpObHg+g/zGtPWttJ1nz7foJDZiGp3ERjqyEed6lImFOCrUaWQjF97iKpa/ 32/JIDYAsdGfkY3Gr7/lSzBgjnzGa3VB34DYqMfE0JwAkTHUXIl45+1HBhYOMqC+87ehjiMYFgyK q8rIhkdA7N8G2hNSld8oIjqJDedd4XSs8jid3CML14dFQCexEONK56VUERuqOwupNI+A2EBsIDYA sTEWlK2tEd09kiE8N8F+hO7EZTT928een2B3H3s+Rm5kIfp3HHHyZozL801i/uNvG3iHi0ZcftLy pOfK4nXZHdbldToWGzFMu/Bl9QuIDcQGYgMQG1CDuSj9frvDb+Jo9ERiZhBpIjawa4gNxAYgNmCE HhF5nke/R4csMvwmDfWP2EBsIDYAsQEAiA3sI5WA2EBsIDYAALGB2EBsAGIDABAbiA1AbCA2EBsA iA1AbCA2EBuIDQBAbCA2EBv/xn/4vYsaP/s7pzWe+Nxzugr3a298pKswSiOl2zRjXIgNxAYAYgMQ GzUQGwcdtbyx+JdXt4z30t84oTF16BMb/+nUhyqFfdop97XCtvNz6C88a+5YcSuNXoiNGC9iA7EB gNgAxMaIio2nnHhbS2xEN4mBKADkR0SBYff4W98SKXK3WNHIh+K3X4mNGFcqXByvj3N5KEs/zadw ftL4EBsAgNhAbMAARzYkADTCkDPIEgoSH8KiRN8mihXFo9EGxSW3nz/uisYvrrl2Lv5OYiOG17HC y10jJ8KjLjE95yemK39+NKTfctd5/UZsAABiA7EBQxAbuvuXMZfxFn4sotGN+IhEvz1SYSGQig2d 17FEht3TxygpUYg4vNKyAIojLxYUqdhwfqJ/nbeAUrz2j9gAAMQGYgOGMEE0FR6ew5GbhBkfi0Sx kT6OsXFPxUa7kY342MTzOTxSkRM3aX5iejlhU5Y2YgMAEBuIDeiT2EhHL6JBT8WGRg88cpATG1Es xBGGhYiNdE6JH41UFRtpuRjZKEe7jWrzrV7tfxF3NY30a3+NbvJflrc0n4rPVM3HfMvX6/qvM5NW B4gNxMbEzNmQ4JAxtjGXsNAoh4+F31JpJzY0CiE3GXxPMtV5H+feRomPUVKx4fA6Vh48P6OK2FA6 LpfST0deEBs/RluIa2MvGTt96/dCL6DaUjxn1LWhVz+Mk3cnPf2EV2a3eK+SNxG3cS/bEr5TXY5C /feKuH38oKha/n7kzSITsYHYgD48RvEIhwy05lvEEQoLAs9/8NyNdJ0NGX+v1xEnYyo+uclvbp0N i4o4iiK/zofTEBIcqf+YH49+xHKlb9cgNvYn3TrcF3sZbxk/CwQdy5jndgD1TqQ6b0MgPyLuUuq4 lEZ6UXfcOqdw/u04406nUVDIfzQ8zr/82HjHfDhvzq++9Vv+tK26xUtaT7nyO7y+HWesjxiP3VSv Verf+XdZY/puG/tN6z9NL1efsU7cVqkf5S23w6z8us5dn86T/afxd+ovLqu/NdrjOpbY87lc3srq Nu1/sSzOl88rvdhm3dQ/YgOxgdgYEL2agJnOIdGIhMWEBFGv3ipBbHQebYiiQ8ZAF3ddkHXhT8PY YNqvLtASE/In/wqnc/qt8+lFWqMNNi7y47t8G5soABRe/mN4b4duIaDzNhLOi+Pz71x5HMZxGbtF /1HkeGQi+o31oTI4z2nd5eo/xq08qUxO3yM4MWyanvPTqT4VnyjzUzZKJL9p/Tp/HjlK4+/UX9wn 3IbRyCs+11+at051m/a/eE5xu+/p24/Nuq1/xAZiA7ExIPq1yJZGMxS3X29lufLBjWzEu1xdcNML dZnB9KOHaHxjWh5dSMWG7zDlJ2fM5Ed5S+OMd80yBn4EEkdOcvGlow5RbOSMSFr+mEYap7+dbvpY plP9x7gdRxpnTCet//R3mThwftQeOT/diA21j8VZbAfHX6W/pGVSXYg46mBhFIVhWd2266fOp+OV iLDY6Lb+ERuIDcQGIDY6IDERh8R95+i7N1/E24kNXfB1B+lRizia4MmPMQ5f6HN3oHqUkTNm0bCk xtl5tcGL+fddfs7Y2rikw+w2aCYdzdGxBZLOOa4yseE7d/lNH0vk6l9xx/zHkZ2cscvVv4xnzFtO bLl8SqtMbLid4ryVWL+Ox789WpHGX6W/xDJ5NM3HfkQSxYby1q5uc/1P/hSX+5JHq9xPFFe39Y/Y QGwgNgCxUXFSXnoH6uFtXZg9qlA2ic8XboePkzCju8P5GX80XvZnw+Gh8RiXjUdZ/qMQUfz67fBp fH6kE8N4/oHdTVn5nYYFmt39HdN1nLm3LXL177hdT7k47ZbWf5peWX3GOsv5cV3YqKcTNKOoiW2Y jlrkRtPK+ktZP3NcMb0o0srqNqbjPCqOODcm5tETgrupf8QGYgOx0eUcCa8WqscWXiyrrsSJo4iN /tKPt0xybx/0Mp2FxuXJhemozzjWv8RGL19JHXZ98eorYgOGJDYkNDTJU29u6HVRrwJaV8ERX5+t u9hofqZGXWwMglFdf2HQr0oCYgMQG7UVG141NLpJcMQVPL2MeBQgejvEr7faPb7S6tdYHTa+WiuB k75aa/9+jTamlfMvvzqOS5x7nQ2NzsT0aiw2NjTZ1mT5JIsNAMQGIDZqLjY6Leftxbm8kFdcX8OL Z3kzNR172XO7y783ZtN3btEwCYXoP7p75MUbvCms1wFxPArjV3AlViQ4ev0oZYhio1Eg0bGizmJj VEcCvB5HXVewrFKvVRcny40o5dbb6Ef992tUq138w+zXiA3EBmLjLfmt6C0U0vU15OZ1MBwmt+R4 XEU0ulucRP92k18fW8zk4nHYMXuMEsWG2dFkZSex4Zn4Zb9tXD3pMp6TYUovoPod306Yjx+/wVHl Ap3Lf/xO81+lzGXpxkWkfL6d+GgXp/PksJ3qNU3HfmK5op8q9ZpOpPVrpJ2MY6wvHce3TtJ8lvWn dm2Ypu16im0a6y7moazO2vVFn0vj79QncnXYrlyx/rsRrYgNxMZEiY102e8oAtIN0aLISMVGupS5 vnObqaUTUMvEifdI8dbzcYv73IZxXu+jX2LjsGXPa2QM/9D491NTXygTG3GVQ12s429P0NNrpvod 3w6Ir4bGhZC87oEXQvIKi3HiZic/fhXTr42mCy2V5T/GH19DdP79umgaxq8w2o8XmMqt1xFfCY0L TTl8NDIxjlycrk+vHeJzuXr1OiZxvQn5ifWa+qlar9FY+q2ZdnWQqz/Hr7p2unHF0LQ/xeXdO9V/ ut5H/O02iHlwPjvVR+yLXhMlxh/D5+qjrA7L6inWv+P2fw6xgdhAbAQ8cpAuY+7HIlEAxC3kq4iN GDaORkQR4t9lYiMVPMqD54oMUmyM0MjGliYz7UY2oiFJ14mIF/5oaB0uriXgpcXj64F+CyOG8SqL vtCWLdYUl5uOowi5/DsOr7egNLykeIzTr2amZdTF34ZbfuKy2C5nKjbiWhM2QjFfcQVTL6PteNKF x9I1GXL1mq7f0WkBrnRBsbRevTJmauhyC1alr/Tm+ki6pkRcsyJtn1S85Oo/1l2nxdbSlV1Np/qI 8ca1TnLx5/pEWR2265vzXVUUsYHYmCixYUPtlTolPDwvwuc8khDfUqkiNjyvw6/Vah6F0LHchDd6 KxMbjt9iJc7ZKBMbnvsxZmKjJTKqzNmIz9jTu1ivV1FFbHh1SV9MvepiTmzYj4et2xlFD0OX3T3G u1nH4XJ43QTH6fUTcmX0uggOZwOSppmKDQ+3e6Qm1mVcjyIaUD+qqCI2XK9VxEb0kwqGtF7jPifp YxORy29ObLj+2omNtH1SQ+tHGK7/tO7mKzY61Ufsi14vo53YSPtEWR2265s5scHIBmIDsVGC3+zI PVLxfAmJgtzW7RYm8bfFg4/L4kzDla2V4ddy4/noJ4bVcZqnGouNfURGFbHhxw0eZYi/043RcmLD d4/RmMWNyHIGL92srGwZag9Re/g7Xqxz+U/FkQWKRjmcnp/zxzD+7dGWeFda9hglPkJxeVKDk+Y9 jbOd2Ejr1el4WD5ngFM/7erV7ZRugBYfP5XVQa6PKL+5FTTb9ac0vlz9t1vZNd1YzXmIgq9TfcS+ 2E5s5OojrcN0cmlZ2b1YmPPmkaN28zcQG4iNiRQb/Vjvolfbu7OC6P70622Udvti9Iv5pFe3xaGG Ua91o1dtaqGS27hvPnH1600WxAZiA7HRo1U8e/0oA7HRf7ERl2QeFPN5LbMXy0UPuoyDrte60as2 jZNDh9E3ERuIDcQGIDYAYCRAbCA2EBuA2AAAxAZiA7ExKPzGiNe66MWeKembJIgNxAYAYgMQGxMq NrSwl18pja+VxrdS5jufox87syI2AACxgdiAmokNTfBMF/zysuQeofAaHX6NVWHkx0uYx0miPqdv u2ukxHF41ESvrdotXQAs9YvY4KINgNgAxEbNH6PIsHtxrlRoWIh4zxTvzupFveJeKl6cK+7g6hVJ 42Jf3njN4sWLf0mAOC75jSMuiA0AQGwAlVDzCaJe8MvCwyIi7lEid28Pn26Q5kW2LBbsJzd3w49q 4tLmTtOip9fbxyM2AACxgdiAIT5GSednxGXD434nHqnI7erq0QmPjHQjNqIf5SUVPYgNLtoAiA1A bNRYbOQ2afPjFH3H+Rj6nduzxKMb6b4nwvHERzZxszdvvObRjDh/o2y3WsQGACA2EBtQs8coMvR+ 7VXfqcGXQPAoR9lrrYojioroxxu/+bGMR0PilvIWFU7Lk0R5jILYAEBsAGJjTOZs5DZbG9SS57z6 itgAQGwAYmNCxAYriE6W2NCeEN4x08htFPckqbJ/hTbl6nXetddJWdq92FOjXfzd4rLre1D7tPQy /72MC7GB2ADEBmJjhEY2tFOpt1lPt/EeJdIt6nNoq/Jep6ut7cvO9WITsHbxz6ct3X793oHWcfcy /3ErecQGIDYQG4iNMXuMkl7kf+6JRzdeufqFLeMtY6Ltt2XA5JYaff2WuwVK/K2witu/HbZqGLkL pa88xVEL7/optEW4/Of8KLz9RAMv/8JGM5ZPdaGye1dR/Xb+5UdxKW6lF7cmT/PkcEZ+nK7jjvHb 3XmNbrHOY725vC5nmdhoV+YYzvHENsj5Vf04rlg/ubC59o35jf3QeSwLG4VVzJPjk59cO7g92/Vl xAZiA7EBiI0Big2PEMhNjyZsYH3RTg2YjnURF76A65yOFbeH820MYhj9tnGUkbABjmFyIxvRUEVj Gf04fhumKAqUB+dZv220la5He2Ld5NJLRw5UN/Jr/7l4/Fv1mYqNGL+Fks4pr7F95O560zn5Vb7b iY20zGpXi5o0fAxblhefT/Ofhs21r+pJx1GoOa60r6Rh0xG52B5OO63L6LesLyM2EBuIDUBsDFhs 5C7eNqLRn4xFagDi7zgy4N+5MDZgwne+DmNhMh+x4TtvGZf0nIya74ZleJ2e5gy0M6ZVxYZJ4/Fv H5fFL3c/2kofLbgO46hRWg+5xyixzLGO5a46KBMMubxUFRu59lUdO704ryRt91zYXF+rIjbSPOXq FbGB2EBsAGJjiGLDjylyRtsGI95t67f9p2KjLExMw8PsMb10GN2PEGS00jvcnKGJd7GK13fqcbSl 3Z27wistkRq5mCf7cfw5o+xytRMb8a4+LXsUNhYcncRGuzLH9DqNTsRHIbF9y8L6O7avvi1w4uOt snaPYauIjbRvRL/t+jJiA7GB2ADExgDf9IjD2z4nt7I7wdxdp+OIccd424WxIYvpee5Imm460pJO vnQ66bm0PPabltvf8Y44xpHWXeonjcfpet5HdE/LEfOf1nlZG8XvXLvmyuz428WZy4t+5/Kfc4vt m/vtcLl+lvNblo7dytqhU19GbCA2EBuA2JgQdEeaMy7DxKMHvXirJk4YBdbZAMQGYgOxgdgAAMQG YgOxAYgNAEBsIDYAsYHYGLjY8BsLvRr+7zZtzUfwXAn/Xmi8ca2OXhInHubK0a/4Yzqa8BnfzPDj ltw6G2WPZ6qmrfVB0vU/qj4C6rbsXvMit67GsClrW6/1gdhAbIw9P/ET/+5HBx7xlL215PBl361r 3n/qwMWPNcXG+nEQG5oQJ0Oj+Q/6LUMm8eG5EP5tA+fZ+17/wLP3HU/063kVjtvh5cevNjp+GZm4 dHbqz3HnjGL0q/AykjHN6Cc3OTTG699xPQ0d+60Exxvjc77b5TONN60br1+RTtaMfmyIo59omGP5 4noTsQyebJq2VSxbLu5Yj2mb+ne6DHquLtKwrpuYlvObtu1C+5/c7SdOaE3bO/pRvBZ4qd+47gpi A7Ex7iMby5qsrCn3NDmlxvmfGrfHKLq46k5NF1i/dhh/62IrQ+7XIb3uRHw10nd88fVWx2ND4YW8 /KqhL9pxTQn7i69SOn/xTYfUr41DfItAxkOkRk149VO/XuvfNmgWQl6IzG+IxPic73b5dN5sONO6 cR5SY5/WX+onjgjYyNrAxgXTXIZYn7GtXLa0bmJ7eLTDi7i5frzYl84537m6SMvjdMqWTE/b1unP t/+5LK6H2P6xPKkf/wfSNuQxCmIDRl8kLW2i0YFt1MfoiI10HY342wYmLlRVtsdGXII7Gk4bgLg8 tOOJi1uld+u5dSja3dmngsLGVO42iDkj53UyvPS118pIF6hK44vlKMun1/CwWFA4L7Nuw5sa3HaL TsWRKefdxjW3vHentsoZ+7j4mEcCOi2MlUvD6efKXCY2UmGYtu18+l8uTLv2TlelTdsQsYHYgNEX G5s036RgOXUyGmIjDl/HEQf/joYsd+GO+1REw+C7Qg9FpwZC317+2/NHcv5yRjz1mxv+j48e0qWn bfTSO27l3494UrGRxldFbMSh9yja4rmy1U9dfzmjHOPx3blHaRxnlbbKiY3cY5RUbMQl0l23ZW2W K3MUNq5TG/12bTuf/peGSZfET9s7jmzk2hCxgdiAeoxqWGwwujEiYsMXahuo+DvuGWGD4LtdGxzf 9dmvh7ijQfLGVn7m7mFy78fhi7jDRX9puulEPRuDdNKeV4PMTejzXiDOs3/nyunVNdP4nL92+Uzj zdWNjWa8449+YvyxbLkNwxzOK3B2aiuXLRUWET8SsXFO28piI21Lp58rc/oIr6wcadvOp/+lYTq1 d1wC38K7bFLoQkc7EBuIDejvqAajGyMmNuZLv7cqh9FsK088tQCj/yE2EBswiqMajG70SGzMrl07 9yhgWNz9nj8ceh5g8G115sknNV738jX0vwVw3SUXIzYQG9DnUQ1GNxbI1NTUGYdNT+8CgPry+IMP vpnrGWIDei88dugVUuoCAAAQG4DYAAAAxAYgNgAAABAbgNgAAADEBiA2AAAAsQGIDQAAAMQGIDYA AACxAYgNAABAbABiAwAAALEBiA0AAEBsAGIDAAAQG4DYAAAAQGwAYgMAABAbgNgAABjd694M9YDY AMQGAEA/r3u7m2xtspz6QGwAYgMAoB/XPQmNRoGugauoF8QGIDYAAHp53ZsNYsPsarKW+kFsAGID AKAX170VGbEhdjZZSh0hNgCxAQCw0OveVJPHEqGxWe7UD2IDEBsAAL269u0sRIZEx19otIN6QWwA YgMAoJfXvk1N9hSPVJYWczZ4hILYAMQGAEDPrn3Lo7goRMcOHqUgNgCxAQDQz+vhOs3doC4QG4DY AADo5zVRE0XXUReIDUBsAAD065o4VVwXmTCK2ADEBgBM2LVKq36uHlBaTBhFbABiAwAm8Fq1PSwv vmIA6TFhFLEBiA0AmLBr1aZkEa5tTZb1OU0mjCI2RoefOeSn7zlw+qd31ZGf/L/+3XenDvqpb9Q1 /wglgIkRG+tKlhjf0mS6j+kyYRSxMTJ/gsYZ1z+zlpy6+Rm1zftvHftEXWg20AcBJuI6uyojNPb2 e/O0YsLodm5sEBsjITau/JPVMGCev24ZYgNgcq6zM4nQ+Jt+P0YJaS8tljefoS0QG4gNxAYAjPe1 1punnV8Y/+UDTJsJo4gNxAZiAwAm4Fq7zW+iaFSjeD11aoDpr9UcEdoCsYHYQGwAwORce2f1lsqA 09RbMbPUP2IDsYHYAIDJuf4O9PV9JowiNhAbiA0AmLzr78BX+2TCKGIDsYHYAIDJuwav1nyOAafJ hFHEBmIDsQEAE3Yd3tLvNTcyaTJhFLGB2EBsAMAEXYc1l+LRQT/aYMIoYgOxgdgAgMm6FuvRxs4h iJyRnTCqpdybXIjYQGwAYgMAenc93jDo68KoThg96KCDzliyZMk/ykYtXrx4oJNoERuIDcQGAIzz 9XhqUNvQZ0ZVRmLCqPKyaNGiR9euXftPe/bsaSxdurRx7733No444oj/8fjHP/6liA3EBiA2AGDh 1+SBry5apDvUCaMauVi8ePGHnvrUp+7duXNnw59ly5Y1Hn300cbevXsbz3nOc75z+OGH3zeouqFD IjYQGwAwztdlbUm/eQjpDnzCqITDIYcc8o5FixZ9b+vWrY30s3LlysaOHTvmft9www0/aoqSvx3E 6A+dEbGB2ACAcb82a+LmqkEb/kFOGG1+1jSFxnfOO++8x5qfRu6zdu3axpYtW/Zx00jH8uXLv71k yZJjERuIDUBsAMD8r80DX100pNvXCaPa8VaTPo899tjvaV5Gu8/s7Gxj06ZN+7lLnDzjGc/4zhOe 8IRTERuIDUBsAMD8r88DX120SLcvE0aLeRm3PfnJT/5ufDTS7rNx48bG+vXrS8+/5CUvkeC4GLGB 2ADEBgDM/xo98NVFi3R7NmFUomV6enqD3ii56qqrftTo4qN5HGvWrOk0+vHdZtw3IDYQG4DYAIB5 GuphrC5apL3gCaOad6IJnWeeeeYP9EZJt5/du3c3ZmZmOvq79NJLf3jkkUfej9hAbABiAwDmd50e +OqiQejMa8KoXuFdsmTJzmc+85l7NaFzIR+ttdFpboc+11133T/3UnDQ+RAbiA0AmLRr9YZhXDO6 nTCqJcYPO+ywa4866qjvbd++vdGLz+rVqxvbtm2r5LeZh396whOecDViY8LFxvn3P7fxljtW9jWN t39sVSsNpRXd+50uYgMA+jzKMPDVRYu0l1eZNzI1NXXWoYceuvfyyy//10YPP3obRW+lVP0Uk0YX /JYKHa+GYkOG/+d+ddE+PPtVP9/zdH77uCftk8avPPsJc+eWPPEgxAYA1Pl6PZTVRSvka2VTZPz1 qaeeOq95GZ0+enNFi3tV/ei12BUrVnx7oeuF0OlqKDZk+E+4+On7uEkIvOD0p/RU0KSCQuLjpef+ Co9RAGBcrtlDXVY8ycvM4sWLH37605++d9euXY1+fSQepqenG2ULf+U+Ej1HH330Py5kYi0drmZi 44zrn9kSG+3EgUchhI79CEQCxecchx6HSETYze56fKL4lJ7TuPQzL9hvZEPhYnil4eN+jLYgNgCg x9ftbVqDY4jpTy9atOjKI488cm/VuRQL/aTLlld9k+WII474lvKL2JgAsaHRCxn33DkLAH17ToWN v8WDBYPd5S+OYEgkOOxr3r2i9Vvn5TeOpkRh49EO5c1iRekM6lELYgMAFnDdHsrqokXaa7T1+0UX XfRYNyMNg5634c/tt9/+o6VLlz6I2JgAsSHDHudO5MRGOvJh8aHvOAfD7tG/BEM6+VNCxaMiflQT 07J/nYuPchAbAFCTa/cqvZY6wPRaW79XWWK8Hx+lqfU25iNwjjnmmO/OZySIjlYzsZGbSxFHKlKx IaFgQeDvlJzYUHzpHJDoF7EBAGN2/d6sHWL7PYqS2/p9GJ9Vq1Y15vM6rYSKRmO6fZxCJ6uZ2PBE TSEh4XkccX6FjvUIRMeaN+G5E1EYeISkTGz4sYsfnei30mRkAwDG9Po9VTxOWdaPuNtt/T6MT5Wl y8s+2pr+8MMPvw+xMeZiI86P8HyKOJFTbp60Ged3SBR48qbdNVIS/UiEeEKp4owTR6OQ8CiKwtq/ wsa3Vcoe9yA2AGBEr+E93zRNjxwOO+ywPe22fh/GR3nRaqLzfb1Wq5nq8RNiY8zFRjtGaQ0MxAYA 1Ow63pPVRb31u+Y46E2OUfysXbu2sWXLlnmFVZkkoqoKMzoXYgOxAQCw77V853xXF53P1u/D+nS7 wFf60eqmWk4dsTGhYoO9UQAAFnQtn9HjlG7DaYnx+Wz9PszP8uXLG/NdREyPYjQPpcprw3QsxAZi AwBgYdf+VdPT0//QryXG+/nRQmLanK3foxt0FMQGYgMAYH7X/J5t/T7uoxt0GMQGYgMAoLtrfc+3 fh/30Q06DmIDsQEAUJGDDjroDC1q1eut38d9dIPOg9hAbAAAdL6+t7Z+X7t27T8NY4nxuo9u0IkQ G4gNAIDy6/pAtn4fhY9WFJ3vCqcSYAceeOD3EBuIDcQGAED163lrifFBbv0+7I8Ew7Jly/qyqiid CrGB2AAA2PdavqYpNL4zakuMD+KjFUW1suh8wx522GH3IDYQG4gNAIDya/hQt34flc98d4TViMhB Bx30T7klzOlgiA3EBgBM+rV7ZLZ+H5XHKTMzM435jOpIqGlkCLGB2EBsAAD82zV7anp6eoOWGB+V rd9H5bN58+bGunXrug6n+S2aUIvYQGwgNgCA63Wx9fuZZ55ZuyXGB/XRq7DdTo7VaMjU1NRj6aMU Oh1iA7EBAJN0nR75rd9H5SPhoF1hu320pNeEtS4JYgOxgdgAgEm7PreWGK/D1u+j9NH8jRUrVjS6 EWYXXHDBv05NTb0dsYHYQGwAwMSgrd8PPfTQveO2xPigPlrMTCMcVR835eZt0BERG4gNABjXa3Jt t34ftY9ehdUrsVU+quvHPe5xP0RsIDYQGwAwztfisdj6fdQ+ekOl6oJf2hFX7YDYQGwgNgBg3K7B 04sWLbpyZmbmO+Ow9fuoCg7todJpDY6mn+8322MtYgOxgdgAgLHBW79fdNFFE7fE+KA/WpNEr8W2 ezQlUTI9PX0zYgOxgdgAgHG47o711u+j+tHIUbtJozqvR1mIDcQGYgMAas2iRYvOfdrTnva9cd/6 fVQ/qvfly5dnX4vVOYlAxEafxMYZ1z8TBsxvHftExAbABPK4xz3u0o0bN2L1h/iR0NA6HOkcGbkf fPDB30Zs9IGfOeSn7zlw+qd3weBJV6sDgIm4wVt/9tlns3bGkD96fKXXYmdnZ/eZOKobcMQGAADU XWys1VsPmPvR+GzatKn1WMWvGx9yyCH/rB11ERsAAFBnsbFS+3Bg5kfnI6EhwSHhEdfaoMMCAEBd xcYyGTRM/Gh99ChFj1QOPvjgf2220fMQGwAAUGexsVRD9Zj30froTRSNOE1PT39eC60hNgAAoO6C A+s+Ih+tuaH1TvTKK1vMAwDA2CDDxjobw/9oR13trKuVXLOikM4KAAB15bDDDrtny5YtWPshfbS+ hubNNNvhWj8yQWwAAMBYweuvw/norRPtqqslyePurogNAAAYR7Gx/MlPfvJ3Mf+D+WhexplnnvmD 6enpf2jW/arK7URnBQCAOvO4xz3uh+12IOXTm89VV131oyOOOOJ/NIXGhq5FIR0VAADqzOLFix/e tm0baqBPnx07djQ0etSs59u8IihiAwAAJoqpqam3X3DBBeyR0uOPNlM75phjJDK0/9TyhbQRHRUA AGpN87PiqU996l7kQW8+WgH0vPPOe+ywww7b06zb1T1pIzoqAADUHW1nrjtxPgv7bN26tbFo0aLv HXLIIe9oCo2pnglCOikAANQdHqUs7LNz586GRocWL178ofnOy0BsAADAWMOmbPP77Nmzp3Hsscd+ b9GiRY/qcVTf2odOCgAA4wBLl1f/aF7GRRdd9NiSJUv+sSky1vRdDNJBAQBgHJiamjr/rLPOegwp 0f6j14SPPPLIvYsWLbqy3RLjiA0AAIDUoLHlfNuPt37XuiTNupoZaNvQQQEAYFxgga/9P+22fkds AAAAdD+6wV4p4dNp63fEBgAAAKMb8/pU3fodsQEAAMDoRlefbrd+R2wAAAAwulF5XsZ8tn5HbAAA ADC60fGzkK3fERsAAACMbpR+erH1O2IDAABgYaMbS3XHr0cM4/Tp5dbviA0AAIAFolc+tcbEOIiM fmz9jtgAAADoARoB0COHOn/6tfU7YgMAAKAXhu6AA2a0F4hGBur26ffW74gNAACAHjE1NXXWqaee +oO6iIxBbf2O2AAAAOghMtwaKRj1eRmD3PodsQEAANBLg3fAAUuPPvrov9XbHKP4GcbW74gNAACA 3guO5U972tP2jNLrsMPc+h2xAQAA0AeWLFly7DOe8YzvDFtkjMLW74gNAACAPrFo0aJz161b971h CY1R2fodsQEAANBHjjjiiBsuvfTSHw5SZIza1u+IDQAAgD6jeRLXXXfdP/dbZIzq1u+IDQAAgAFw 5JFH3n/22Wf3ZcboqG/9jtgAAAAYEEcdddS7TzzxxJ4Kjjps/Y7YAAAAGCBLlix50wte8IL/udBl zeu09TtiAwAAYMA8/vGPP+F3f/d3/5/5rMNRx63fERsAAABDQOtwHH300f9YdWnzOm/9jtgAAAAY lnE84IAZ7aVy7rnnfr+d0Kj71u+IDQAAgCFz+OGHX6Yt3tP9VMZl63fEBgAAwCgYygMOWHHEEUd8 64YbbvjRuG39jtgAAAAYHcExffjhh9934IEHfm+ctn5HbAAAAABiAwAAAACxAQAAAIgNAAAAQGwA AAAAzIv/A4Qxox0rNs/LAAAAAElFTkSuQmCC ------_=_NextPart_001_01C8D00D.200DC7A3-- From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: Best regards,Stefan AnderssonTribal Media AB Join the 3d web revolution : h= ttp://tribalnet.se/=20 > Date: Thu, 19 Jun 2008 20:16:06 +0200> From: olish at newworldgrid.com> To: = opensim-dev at lists.berlios.de> Subject: [Opensim-dev] A software to connect = its own region and TP in from locally...> > Hello !> > I started to develop= a software that creates a region automatically for> a given grid. Clicking= on "Create" creates automatically the region file> as the software gets au= tomatically the local IP + public IP + domain > name and you just have to f= ill the region name and its grid coordinates, > then when all regions are c= reated and configured, the user clicks "Start> Simulator" and the sim start= s up after the software configured its> firewall and forwarded its router p= orts correctly. So people can host> their region for free and at home.> > T= he aim of this software is offer people the ability to attach their own> re= gions on the grid they choose with the minimum manipulations possible,> and= without the need to rent a server or have another computer on the> LAN. Bu= t there's a but...> > I experimented this last week to TP into my locally h= osted regions> (viewer and opensim on the same computer) on OSGrid and my o= wn grid :> anybody outside the LAN can TP in, but anybody inside the LAN ca= n't> sadly, while I heard that some people could. I followed all instructio= ns> on the OSWiki here : http://opensimulator.org/wiki/Network_Settings . I= > run under Windows Vista, and there's no equivalent to iptables to route> = the traffic...> > It would be really great I think if people could host the= ir regions on > their own computer without such issues.> > Is this issue an= OpenSim related issue or may I use another software in> order to route cor= rectly the packets to the region from the local viewer> ? Any help would be= greatly appreciated. I would be happy to offer such> a tool to the OpenSim= community.> > Looking forward your reactions.> > Kind regards,> > Olish Ne= wman.> > _______________________________________________> Opensim-dev maili= ng list> Opensim-dev at lists.berlios.de> https://lists.berlios.de/mailman/lis= tinfo/opensim-dev= --_db30f500-2ec5-4860-a84b-2507af6b6e54_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Olish,
 
we are doing something similar to what you are describing with
 
http://tribalnet.se/
 
- there you can download an windows application that gives you the ability = to build locally, and either publish your local pc region or upload yo= ur build on our servers.
 
The issue you're seeing is known as the 'NAT bounce' or 'NAT loopback'=  issue - your router only translates and/or forwards traffic cros= sing the LAN-WAN border, which means that if you access your computer = with the _external_ IP from _within_ the LAN, the traffic isn't 'bounced' b= ack into the LAN, but is lost.
 
Normally, you would solve this by simply address the computer with your _in= ternal_ IP from the inside (typically, you have host file settings or an in= ternal dns that serves internal ip's within the LAN)
 
now, things are getting complicated with the Second Life viewer, as the vie= wer demands regions be addressed with _IP_, not host name, so the viewer ne= ver resolves anything, so host magic won't work.
 
so, on login and teleports, when the grid tells the viewer where to st= art, it would have to serve you your _internal_ IP - but your _externa= l_ ip to the rest of the world.
 
Which gets complex.

The solution is either to configuring routing/translation manually (which i= s complex for an end-user) or to get a router that supports it out of the b= ox.
 
From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: R>
Best regards,
Stefan Andersson
Tribal Media AB
 
Join = the 3d web revolution : http://tribalnet.se/
 




> Date: Thu, 19 Jun 2008 20:16:06 +0200
> From: olish at newworldgrid= .com
> To: opensim-dev at lists.berlios.de
> Subject: [Opensim-dev= ] A software to connect its own region and TP in from locally...
> > Hello !
>
> I started to develop a software that create= s a region automatically for
> a given grid. Clicking on "Create" cre= ates automatically the region file
> as the software gets automatical= ly the local IP + public IP + domain
> name and you just have to fil= l the region name and its grid coordinates,
> then when all regions = are created and configured, the user clicks "Start
> Simulator" and t= he sim starts up after the software configured its
> firewall and for= warded its router ports correctly. So people can host
> their region = for free and at home.
>
> The aim of this software is offer pe= ople the ability to attach their own
> regions on the grid they choos= e with the minimum manipulations possible,
> and without the need to = rent a server or have another computer on the
> LAN. But there's a bu= t...
>
> I experimented this last week to TP into my locally h= osted regions
> (viewer and opensim on the same computer) on OSGrid a= nd my own grid :
> anybody outside the LAN can TP in, but anybody ins= ide the LAN can't
> sadly, while I heard that some people could. I fo= llowed all instructions
> on the OSWiki here : http://opensimulator.o= rg/wiki/Network_Settings . I
> run under Windows Vista, and there's n= o equivalent to iptables to route
> the traffic...
>
> I= t would be really great I think if people could host their regions on
&= gt; their own computer without such issues.
>
> Is this issue = an OpenSim related issue or may I use another software in
> order to = route correctly the packets to the region from the local viewer
> ? A= ny help would be greatly appreciated. I would be happy to offer such
>= ; a tool to the OpenSim community.
>
> Looking forward your re= actions.
>
> Kind regards,
>
> Olish Newman.
&= gt;
> _______________________________________________
> Opensi= m-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lis= ts.berlios.de/mailman/listinfo/opensim-dev

= --_db30f500-2ec5-4860-a84b-2507af6b6e54_-- From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: in an unobfuscated form in at least one place where the garbage collection process can read it, or it risks deletion. This would apply to scripts which used offsite storage via email/http/XML-RPC as there would be no way for the process to know the references existed. On Mon, Jun 23, 2008 at 9:36 AM, Justin Clark-Casey < jjustincc at googlemail.com> wrote: > Dahlia Trimble wrote: > > Thanks for the great explantion Melanie. > > > > There was recently a discussion in sldev about asset garbage collection > > in Linden Lab's servers. Apparently they search for references for all > > assets in inventories, scripts, prim inventories, notecards, and > > probably a few places I cant think of offhand. If an asset is found to > > be unreferenced, the process will delete it. This was discussed as some > > people were talking about obfuscating scripts to prevent copying, and a > > linden was asking them not to do this as it could fool the asset garbage > > collector into thinking an asset was unreferenced if the only reference > > was in an obfuscated script. > > From this, it sounds like it isn't valid within the Second Life system > to take asset uuids as input to a script (or obfuscate them within the > script) and expect those assets to always exist. Is this correct? > > I always vaguely thought that asset reaping wasn't possible because of > the possibility of external input of uuids. But if Linden Labs doesn't > make this guarantee, then it must also be possible for OpenSim to do > some asset reaping. This would depend on the nature of the grid in > question (e.g. it would be easier to reap assets on a grid which only > allows its own region servers to connect). > > -- > justincc > Justin Clark-Casey > http://justincc.wordpress.com > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > ------=_Part_91_26316382.1214239826722 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
From how I understood the conversation in sldev, all asset UUIDs must exist in an unobfuscated form in at least one place where the garbage collection process can read it, or it risks deletion. This would apply to scripts which used offsite storage via email/http/XML-RPC as there would be no way for the process to know the references existed.
On Mon, Jun 23, 2008 at 9:36 AM, Justin Clark-Casey <jjustincc at googlemail.com> wrote:
Dahlia Trimble wrote:
> Thanks for the great explantion Melanie.
>
> There was recently a discussion in sldev about asset garbage collection
> in Linden Lab's servers. Apparently they search for references for all
> assets in inventories, scripts, prim inventories, notecards, and
> probably a few places I cant think of offhand. If an asset is found to
> be unreferenced, the process will delete it. This was discussed as some
> people were talking about obfuscating scripts to prevent copying, and a
> linden was asking them not to do this as it could fool the asset garbage
> collector into thinking an asset was unreferenced if the only reference
> was in an obfuscated script.

 From this, it sounds like it isn't valid within the Second Life system
to take asset uuids as input to a script (or obfuscate them within the
script) and expect those assets to always exist.  Is this correct?

I always vaguely thought that asset reaping wasn't possible because of
the possibility of external input of uuids.  But if Linden Labs doesn't
make this guarantee, then it must also be possible for OpenSim to do
some asset reaping.  This would depend on the nature of the grid in
question (e.g. it would be easier to reap assets on a grid which only
allows its own region servers to connect).

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

------=_Part_91_26316382.1214239826722-- From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: ting, physics) until we reach the inter-connectedness of users, avatars, wo= rlds and content that we call the 'metaverse'. Best regards,Stefan AnderssonTribal Media AB Join the 3d web revolution : h= ttp://tribalnet.se/=20 > Date: Fri, 27 Jun 2008 12:08:54 +0100> From: melanie at t-data.com> To: open= sim-dev at lists.berlios.de> Subject: Re: [Opensim-dev] Proposal to subdivide = the assets table> > Hi,> > Dr Scofield wrote:> > Stefan Andersson wrote:> >= > a) Provided the scenario allows pushing local prims across boundaries.> >= > b) The Prim can have a 'home asset server' which is the first region.> > = exactly.> > That is where the problem starts with home hosted regions. Home= DSL > is not suitable for asset serving. With hosted systems, it would be = > absolutely beautiful, truly spreading the load, but that darn home > DSL = makes it a pain.> > Also, that would lead to issues if that server goes dow= n. So, if > that were to be adopted, it would have to be combined with > pe= rsistent caching, so the resources needed are present on the > server curre= ntly hosting the object, as well as on the creation server.> > We should tr= y to avoid allowing grey prims by design. I agree they > will happen eventu= ally, but i believe they should not be a design > feature, we should do our= utmost to prevent them.> > Melanie> Melanie> > ___________________________= ____________________> Opensim-dev mailing list> Opensim-dev at lists.berlios.d= e> https://lists.berlios.de/mailman/listinfo/opensim-dev= --_0105e7e1-9539-40b5-beea-f51b03be7437_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes, I actually think we're (kind of) in total ag= reement. When I say 'base case' I don't mean 'the only thing the core shoul= d do', merely that I think of the application scenarios as being in differe= nt 'rings' where each ring contains various constellations of services.
=
We have gone in on something akin to the SL 'ring', and slowly, we are work= ing our ways outwards to something like a 'metaverse', but the metavarse wo= n't consist of one homogenous architecture.
 
Again, look at the web. The loose coupling that gives us 404's is also the = loose coupling that give us mash-ups.
 
The base scenario for me, something I think would be very useful from a bus= iness perspective, is the standalone prim serving content to anonymous avat= ars. It's like a campaign web page.
 
From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: ting, physics) until we reach the inter-connectedness of users, avatars, wo= rlds and content that we call the 'metaverse'.

Best regards,
Stefan Andersson
Tribal Media AB
 
Join = the 3d web revolution : http://tribalnet.se/
 




> Date: Fri, 27 Jun 2008 12:08:54 +0100
> From: melanie at t-data.com=
> To: opensim-dev at lists.berlios.de
> Subject: Re: [Opensim-dev= ] Proposal to subdivide the assets table
>
> Hi,
>
&= gt; Dr Scofield wrote:
> > Stefan Andersson wrote:
> >>= ; a) Provided the scenario allows pushing local prims across boundaries.> >> b) The Prim can have a 'home asset server' which is the firs= t region.
> > exactly.
>
> That is where the problem = starts with home hosted regions. Home DSL
> is not suitable for asse= t serving. With hosted systems, it would be
> absolutely beautiful, = truly spreading the load, but that darn home
> DSL makes it a pain.<= BR>>
> Also, that would lead to issues if that server goes down. = So, if
> that were to be adopted, it would have to be combined with =
> persistent caching, so the resources needed are present on the > server currently hosting the object, as well as on the creation serve= r.
>
> We should try to avoid allowing grey prims by design. I= agree they
> will happen eventually, but i believe they should not = be a design
> feature, we should do our utmost to prevent them.
&= gt;
> Melanie
> Melanie
>
> _____________________= __________________________
> Opensim-dev mailing list
> Opensim= -dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/ope= nsim-dev

= --_0105e7e1-9539-40b5-beea-f51b03be7437_-- From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: Charles ----- Original Message ---- From: krtaylor To: opensim-dev at lists.berlios.de Sent: Monday, June 30, 2008 1:41:10 PM Subject: [Opensim-dev] LSL test suite ideas I have been putting together a few ideas on how to include more tests for LSL. I am thinking of putting together a set of scripts that would systematically test all the script functionality that is currently implemented. I would start slow with a few functions and grow over time, hopefully with others contributions as well. I was thinking I would divide the functionality up into logical groups so that it wouldn't be too huge and would allow a developer to beat on a specific area if desired. I know we have used the Kan-Ed scripts in the past but as far as I can tell, the Kan-Ed scripts are no more - the Kansas Board of Regents closed down the URL for some reason. We could probably piece together most of it, but that is not really what I had in mind. The Kan-Ed scripts were good for showing a large set worked in world, but I am thinking more systematic coverage and reporting. The Kan-Ed scripts still required interpretation by someone in world as to whether they were working properly or not. I have had some irc discussions and I think the best approach for now is to have a set of scripts that are checked in and exist in inventory that can be run in world and would report the success or failure of the functions tested. Maybe this report could be pushed out to a webpage for on-line status of the current state of the LSL. This would be a supplemental help to me as I have been manually testing and updating the function list and status for several months now. Additionally, it would be nice for putting a load on the script engine for scalability and performance testing. There are a few helper os functions that may need to be implemented, but the core of what would be tested would be done via LSL. Comments? -- Kurt R Taylor (Kurt Stringer) Open Virtual Worlds Development http://opensimulator.org http://opensim.ibm.com International Business Machines, Corp. (512) 838-2496 T/L: 678 _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev --0-857153825-1214861126=:76701 Content-Type: text/html; charset=us-ascii
Dear Kr:

I think that is a capital idea. I see that we have some scripts in our library. If we had scripts similar to the notion that kan-ed originally used, that is about 10 scripts covering the range from very simple to complex, then we have a series of scripts we can use for testing.

From time to time, we can then encourage others to add to the test script library as we have additional functionality. The important thing is, I believe, that having such a standard set of scripts again allows is to guide our users to a common level of functionality.

Charles

----- Original Message ----
From: krtaylor <krtaylor at linux.vnet.ibm.com>
To: opensim-dev at lists.berlios.de
Sent: Monday, June 30, 2008 1:41:10 PM
Subject: [Opensim-dev] LSL test suite ideas


I have been putting together a few ideas on how to include more tests
for LSL. I am thinking of putting together a set of scripts that would
systematically test all the script functionality that is currently
implemented. I would start slow with a few functions and grow over time,
hopefully with others contributions as well. I was thinking I would
divide the functionality up into logical groups so that it wouldn't be
too huge and would allow a developer to beat on a specific area if desired.

I know we have used the Kan-Ed scripts in the past but as far as I can
tell, the Kan-Ed scripts are no more - the Kansas Board of Regents
closed down the URL for some reason. We could probably piece together
most of it, but that is not really what I had in mind. The Kan-Ed
scripts were good for showing a large set worked in world, but I am
thinking more systematic coverage and reporting. The Kan-Ed scripts
still required interpretation by someone in world as to whether they
were working properly or not.

I have had some irc discussions and I think the best approach for now is
to have a set of scripts that are checked in and exist in inventory that
can be run in world and would report the success or failure of the
functions tested. Maybe this report could be pushed out to a webpage for
on-line status of the current state of the LSL. This would be a
supplemental  help to me as I  have been manually testing and updating
the function list and status for several months now.  Additionally, it
would be nice for putting a load on the script engine for scalability
and performance testing. There are a few helper os functions that may
need to be implemented, but the core of what would be tested would be
done via LSL.

Comments?

--
Kurt R Taylor (Kurt Stringer)

Open Virtual Worlds Development
http://opensimulator.org  http://opensim.ibm.com
International Business Machines, Corp.
(512) 838-2496    T/L:  678


_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
--0-857153825-1214861126=:76701-- From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: seriously evaluate whether it is worth it. Creating new Packet classes is something that can be solved in managed code with an object pool that is aware of packet types. libomv had a huge success by using an object pool for incoming udp buffers and zero(en/de)coding buffers. The Packet class has already been re-factored in such a way that would allow object reuse. This is from my own personal testing, and more data on the topic would be greatly appreciated. Do you think it will be possible to empirically compare performance of funsl vs. the libomv wrapper? John -----Original Message----- From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Mike Mazur Sent: Thursday, August 14, 2008 2:39 PM To: opensim-dev at lists.berlios.de Subject: [Opensim-dev] Upcoming work on alternative client stack Hello, (Could it be? Are the mailing lists working again? I wanted to send this message last weekend.) Some of you may already know, I've started working on an alternative client stack. This alternative stack does not use libomv's Packet class to move packets around. The buffers which are written to by socket functions are passed around instead, with functions available for extracting or writing data to the buffers. These functions are provided by a package currently codenamed "funsl". Johan has written a compiler[1] which generates C# and C/C++ code from LL's message_template.msg file[2]. We're doing this because we believe the creation of a Packet object for each transferred packet impacts performance, particularly when GC events occur. As I'm working on this I found that libomv's Packet class is used outside the client stack, namely in OpenSim/Framework/ClientManager.cs and OpenSim/Framework/IClientAPI.cs (among other places). Since our client stack needs to implement these interfaces too, and needs to call ClientManager methods, those libomv Packet references get in the way. I would like to factor them out. Please allow me to give you an example, inspired by changeset r5785. ClientManager had a method, InPacket(), defined as below: public void InPacket(uint circuitCode, Packet packet) { IClientAPI client; bool tryGetRet =3D false; lock (m_clients) tryGetRet =3D m_clients.TryGetValue(circuitCode, out client); if (tryGetRet) { client.InPacket(packet); } } This method receives a circuit code and passes the packet to the IClientAPI instance associated with said circuit code. Why should the ClientManager have knowledge of Packet? It's not in the client stack, it only provides access to the clients. Therefore I changed the method as follows: public void InPacket(uint circuitCode, object packet) { IClientAPI client; bool tryGetRet =3D false; lock (m_clients) tryGetRet =3D m_clients.TryGetValue(circuitCode, out client); if (tryGetRet) { client.InPacket(packet); } } Instead of expecting a Packet object for the second argument, we expect any object. Naturally the signature of the InPacket() method in the IClientAPI interface has also changed. The cast from object to Packet (or byte[] in my case) is done in the class which implements IClientAPI, namely OpenSim/Region/ClientStack/LindenUDP/LLClientView.cs, where InPacket() has been changed as follows: - public virtual void InPacket(Packet NewPack) + public virtual void InPacket(object NewPack) { - m_PacketHandler.InPacket(NewPack); + // Cast NewPack to Packet. + m_PacketHandler.InPacket((Packet) NewPack); } InPacket() is the first method that has been changed so far, but others will need to follow (OutPacket(), SendSimStats(), ProcessInPacket(), etc). Please rest assured these changes don't break existing functionality, just factoring out some libomv Packet references which currently live outside the client stack. Any thoughts or concerns? Thank you, Mike [1] If you are interested in the source for the compiler, written in LISP, just ask ;) [2] http://svn.secondlife.com/trac/linden/browser/release/scripts/messages _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: seriously evaluate whether it is worth it. Creating new Packet classes
is something that can be solved in managed code with an object pool that
is aware of packet types. libomv had a huge success by using an object
pool for incoming udp buffers and zero(en/de)coding buffers. The Packet
class has already been re-factored in such a way that would allow object
reuse.

This is from my own personal testing, and more data on the topic would
be greatly appreciated. Do you think it will be possible to empirically
compare performance of funsl vs. the libomv wrapper?

John


-----Original Message-----
From: opensim-dev-bounces at lists.berlios.de
[mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Mike Mazur
Sent: Thursday, August 14, 2008 2:39 PM
To: opensim-dev at lists.berlios.de
Subject: [Opensim-dev] Upcoming work on alternative client stack

Hello,

(Could it be? Are the mailing lists working again? I wanted to send
this message last weekend.)

Some of you may already know, I've started working on an alternative
client stack. This alternative stack does not use libomv's Packet
class to move packets around. The buffers which are written to by
socket functions are passed around instead, with functions available
for extracting or writing data to the buffers.

These functions are provided by a package currently codenamed "funsl".
Johan has written a compiler[1] which generates C# and C/C++ code from
LL's message_template.msg file[2].

We're doing this because we believe the creation of a Packet object
for each transferred packet impacts performance, particularly when GC
events occur.

As I'm working on this I found that libomv's Packet class is used
outside the client stack, namely in OpenSim/Framework/ClientManager.cs
and OpenSim/Framework/IClientAPI.cs (among other places). Since our
client stack needs to implement these interfaces too, and needs to
call ClientManager methods, those libomv Packet references get in the
way. I would like to factor them out.

Please allow me to give you an example, inspired by changeset r5785.
ClientManager had a method, InPacket(), defined as below:

    public void InPacket(uint circuitCode, Packet packet)
    {
        IClientAPI client;
        bool tryGetRet = false;
        lock (m_clients)
            tryGetRet = m_clients.TryGetValue(circuitCode, out
client); if (tryGetRet)
        {
            client.InPacket(packet);
        }
    }

This method receives a circuit code and passes the packet to the
IClientAPI instance associated with said circuit code.

Why should the ClientManager have knowledge of Packet? It's not in the
client stack, it only provides access to the clients. Therefore I
changed the method as follows:

    public void InPacket(uint circuitCode, object packet)
    {
        IClientAPI client;
        bool tryGetRet = false;
        lock (m_clients)
            tryGetRet = m_clients.TryGetValue(circuitCode, out
client); if (tryGetRet)
        {
            client.InPacket(packet);
        }
    }

Instead of expecting a Packet object for the second argument, we
expect any object. Naturally the signature of the InPacket() method in
the IClientAPI interface has also changed. The cast from object to
Packet (or byte[] in my case) is done in the class which implements
IClientAPI, namely
OpenSim/Region/ClientStack/LindenUDP/LLClientView.cs, where InPacket()
has been changed as follows:

-        public virtual void InPacket(Packet NewPack)
+        public virtual void InPacket(object NewPack)
    {
-            m_PacketHandler.InPacket(NewPack);
+            // Cast NewPack to Packet.
+            m_PacketHandler.InPacket((Packet) NewPack);
    }

InPacket() is the first method that has been changed so far, but
others will need to follow (OutPacket(), SendSimStats(),
ProcessInPacket(), etc).

Please rest assured these changes don't break existing functionality,
just factoring out some libomv Packet references which currently live
outside the client stack.

Any thoughts or concerns?

Thank you,
Mike


[1] If you are interested in the source for the compiler, written in
LISP, just ask ;)
[2]
http://svn.secondlife.com/trac/linden/browser/release/scripts/messages
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

------=_Part_202769_7029875.1219103441814-- From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: We'll have to exchange some ideas.
It's too bad that the client is so attached to the one-mamma model. We need to constantly trick it on the server side.

--------------030102050901010402010203-- From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: We'll have to exchange some ideas. It's too bad that the client is so attached to the one-mamma model. We need to constantly trick it on the server side. --0-134747981-1225388983=:37208 Content-Type: text/html; charset=us-ascii

Dear Crista:

I have no problem supporting and committing patches to core from your efforts. Please move forward as you see appropriate.

Charles


----- Original Message ----
From: Cristina Videira Lopes <lopes at ics.uci.edu>
To: opensim-dev at lists.berlios.de
Sent: Thursday, October 30, 2008 9:19:28 AM
Subject: Re: [Opensim-dev] OSGrid <-> UCIGrid

Mircea Filipescu wrote:
Me too. I would be curious to ask two questions now, one of them related to that. First question is, how do you set that up on your own opensim so far? Is the inter-grid teleporting system in the core yet or just an experimental separate application? Will there be a way from opensim.ini to do that experimentally soon?
It's not in the core. It would be great if it makes it there :-) It will be really easy to merge.
Since the architecture of OpenSim is so good (I've said this many times before!), the extension I made is really modular and simple. The only weirdness is having to subclass OpenSim.cs, so that I can instantiate the hypergrid comms instead of the default comms.

My second question is something on longer term related to the technical part; I'm curious what will be done with the assets in this situation and with fetching them, and here I mean how one can sit on one grid and use assets and inventory from both that grid and another one. There are two problems here; First of them (smallest one) is the possibility of UUID conflicts. Lets say for example that someone uploads a texture on OSGrid and uses it in their inventory. Now they cross-grid TP to the LL grid, and in order for stuff to work correctly both the OSGrid asset server and LL grid asset server must be used. However, if the UUID of that texture he just uploaded on OSGrid is the same as the UUID of another texture / asset already on the LL grid, there will be a UUID conflict.
For this issue, I'm relying on probabilities & statistics! I hope the math delivers :-)
But I confess I feel a bit nervous about this too. I would feel a lot more comfortable if UUIDs would be suffixed with a domain name, or if they encoded domain names, so that ambiguity would be impossible, not just improbable.

Second problem as the devs have been discussing is that the SL client can only support one asset server at a time. So if you go into another grid like that normally you must have both the assets of the grid you come from and the ones of the grid you go to at the same time. So yeah I was curious if anything is intended or known about these problems so far... one way or another I guess they will be gotten through so yeah.
From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: We'll have to exchange some ideas.
It's too bad that the client is so attached to the one-mamma model. We need to constantly trick it on the server side.

--0-134747981-1225388983=:37208-- From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: ve concluded that we have a process that doesn't allow for rapid change unl= ess it's either =20 a) really easy=2C and shows immediate value for the percieved audience or b) has been labouriously discussed and dismissed=2C taken up again=2C re-ev= aluated=2C and then been dismissed again=2C just to be suddenly accepted be= cause some technology had matured enough=2C threshold reputation has been e= arned or a good tool was found. What I'm saying is that from what I can see our mindset is 'refactoring' ra= ther than 'rewriting'. Babysteps rather than big restructuring. Always thin= ing of the job that should be done in the light of the job that has been do= ne so far. =20 Good and Bad=2C it has worked well so far. Best regards=2CStefan AnderssonT= ribal Media AB Join the 3d web revolution : http://tribalnet.se/=20 Date: Sun=2C 7 Dec 2008 06:41:07 -0600From: james.stallings at gmail.comTo: op= ensim-dev at lists.berlios.deSubject: Re: [Opensim-dev] future rexviewer merge= rCommunication is a good thing Toni=2C and you have done a fair enough job = of it here.Clearly there are some cultural (think national=2C not corporate= ) differences here. You have laid out in bold relief many of the reasons be= hind the things that have frustrated me about the rexx project.One thing I = am always harping on with my employer is the notion of managing expectation= s. Typically I am talking in a sales context=2C but I'll say it here: manag= ement of expectations is everything! and of course=2C communication is key = to effective management of expectations.IMNSHO=2C this is the 'big fail' on= rexx's part - they were oft invited to drop in and discuss things on IRC o= r participate in the mailing lists. I dont think anyone really expected the= m to be there chatting in IRC everytime=2C but they could have been followi= ng and commenting on key work there and in the lists as well=2C and comment= ing about things that may have impacted their work=2C whether in a positive= or negative way. While it may seem we burn a lot of time in IRC goofing of= f=2C this is generally users or opensim devs that are finished with dev for= a time socializing. Nothing wrong with that=2C we are a community=2C and c= ommunities interact at many levels. No particular commitment to such trivia= lities is needful from the genuinely busy - opensim devs are all business w= hen working hard=2C and dont involve themselves very deeply in the lighter = side of the community (if at all) at such times. As a result of this mode o= f working=2C oportunities to avoid duplicated effort were missed=2C and dir= ections were taken that are not consonant with the general direction of the= broader community=2C leaving as much work to get re-integrated post-fork= =2C as it were=2C as perhaps was done to demonstrate a proof of concept in = the first place. Additionally=2C such communications as we did have were ty= pically in response to complaints about the cross platform issues=2C and we= were continually reassured the commitment was there=2C in spite of over a = year of work and still not a single line of rexx code that will run on any = of the alternate platforms. It simply appears as a result of this that ther= e is anything but a commitment to our cross-platform ideals. Worse=2C it se= ems to suggest that rexx's commitments are not to be trusted.Now=2C as I am= an equal opportunity offender=2C it is time for me to level my critical ey= e on the opensim team too. You see=2C they have contributed to this mess in= a subtle way=2C through a slavish adherence to an old toolchain: SVN *simp= ly does not do as good a job of supporting collaboration as modern tools li= ke Hg and GIT*. Hg is probably to be preferred over GIT as I believe Hg wor= ks cross-platform - but the key point is=2C these more modern repository ma= nagement toolchains would have offered rexx the flexibility to both do 'cle= an room' work outside and parallel to the broader community=2C and facilita= ted a much smoother integration of their clean-room work post-fork. Indeed= =2C these tools facillitate this asynch workflow so thoroughly that the ter= m 'fork' really loses most of it's meaning.Enough of hindsight. Time to mov= e forward=2C with lessons learned. Ryan seems very commited personally to c= orrecting such of these misteps as are perhaps of chief concern=3B I dont w= ant to be offensive and suggest he isnt sincere=2C because at this juncture= that is all I would be doing is offending=2C and that is honestly not my g= oal.It is clear from the 38 messages plus in this and related side threads = that rexx is getting the message about communication - and I will say it ag= ain just to reenforce the notion: to be a part of the community=2C one must= communicate with one's peers.I *wish* I could say that OpenSim's core dev = team is getting the message about the toolchains - this is something that h= obbles many innovators. Some have quietly adopted these newer toolchains fo= r themselves=2C but much of the benefits of this are lost because core stil= l sits in an SVN repo (yes=2C I am aware that Hg and GIT can work with SVN = repos=2C but to do things this way rather dilutes their strengths).Oh well= =2C one thing about us human beings is=2C we learn=2C grow=2C adapt. I dont= think anyone in this community of ours is less than intelligent (or less t= han human for that matter =3B) and I hold out hope that the OpenSim team wi= ll see how remaining bound to SVN is holding us back. Coming to this point in this discussion I am hopefull and optimistic that g= ood things are going to come out of this=2C in spite of the pain. C'mon=2C = Ryan=2C I cant *wait* another year to see this stuff =3B)CheersJamesOn Sun= =2C Dec 7=2C 2008 at 2:03 AM=2C Melanie wrote: Hello=2C Toni Alatalo wrote:> yep like i mentioned in the previous post they are ort= hogonal and> should be separate. was thinking of that earlier this week but= didn't> have time to bring up with the Rex people yet.That sounds good.Mel= anie _______________________________________________Opensim-dev mailing listOpen= sim-dev at lists.berlios.dehttps://lists.berlios.de/mailman/listinfo/opensim-d= ev-- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DThe windscours the earth for prayersThe= night obscures themhttp://osgrid.orghttp://del.icio.us/SPQRhttp://twitter.= com/jstallings2http://www.linkedin.com/pub/5/770/a49= --_3501f0de-0900-4628-9a60-f857ce1b7deb_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: ve concluded that we have a process =3Bthat doesn't =3Ballow for ra= pid change unless =3Bit's either
 =3B
a) really easy=2C and shows immediate value for the percieved audience
or
b) has been labouriously discussed and dismissed=2C taken up again=2C re-ev= aluated=2C and then been dismissed again=2C just to be suddenly accepted be= cause some technology had matured enough=2C threshold reputation has been e= arned =3Bor a good tool was found.

What I'm saying is that =3Bfrom what I can see our mindset is 'refactor= ing' rather than 'rewriting'. Babysteps rather than big restructuring. Alwa= ys thining of the job that should be done in the light of the job that has = been done so far.
 =3B
Good and Bad=2C it has worked well so far.
 =3B
Best regards=2CStefan Andersson
Tribal Media AB
 =3B
Join the =3B3d web= revolution : http://tribalnet.se/
=  =3B






Date: Sun=2C 7 Dec 2008 06:41:07 -0600
From: james.stallings at gmail.comTo: opensim-dev at lists.berlios.de
Subject: Re: [Opensim-dev] future rex= viewer merger

Communication is a good thing Toni=2C and you have don= e a fair enough job of it here.

Clearly there are some cultural (thi= nk national=2C not corporate) differences here. You have laid out in bold r= elief many of the reasons behind the things that have frustrated me about t= he rexx project.

One thing I am always harping on with my employer i= s the notion of managing expectations. Typically I am talking in a sales co= ntext=2C but I'll say it here: management of expectations is everything! an= d of course=2C communication is key to effective management of expectations= .

IMNSHO=2C this is the 'big fail' on rexx's part - they were oft in= vited to drop in and discuss things on IRC or participate in the mailing li= sts. I dont think anyone really expected them to be there chatting in IRC e= verytime=2C but they could have been following and commenting on key work t= here and in the lists as well=2C and commenting about things that may have = impacted their work=2C whether in a positive or negative way. While it may = seem we burn a lot of time in IRC goofing off=2C this is generally users or= opensim devs that are finished with dev for a time socializing. Nothing wr= ong with that=2C we are a community=2C and communities interact at many lev= els. No particular commitment to such trivialities is needful from the genu= inely busy - opensim devs are all business when working hard=2C and dont in= volve themselves very deeply in the lighter side of the community (if at al= l) at such times. As a result of this mode of working=2C oportunities to av= oid duplicated effort were missed=2C and directions were taken that are not= consonant with the general direction of the broader community=2C leaving a= s much work to get re-integrated post-fork=2C as it were=2C as perhaps was = done to demonstrate a proof of concept in the first place. Additionally=2C = such communications as we did have were typically in response to complaints= about the cross platform issues=2C and we were continually reassured the c= ommitment was there=2C in spite of over a year of work and still not a sing= le line of rexx code that will run on any of the alternate platforms. It si= mply appears as a result of this that there is anything but a commitment to= our cross-platform ideals. Worse=2C it seems to suggest that rexx's commit= ments are not to be trusted.

Now=2C as I am an equal opportunity off= ender=2C it is time for me to level my critical eye on the opensim team too= . You see=2C they have contributed to this mess in a subtle way=2C through = a slavish adherence to an old toolchain: SVN *simply does not do as good a = job of supporting collaboration as modern tools like Hg and GIT*. Hg is pro= bably to be preferred over GIT as I believe Hg works cross-platform - but t= he key point is=2C these more modern repository management toolchains would= have offered rexx the flexibility to both do 'clean room' work outside and= parallel to the broader community=2C and facilitated a much smoother integ= ration of their clean-room work post-fork. Indeed=2C these tools facillitat= e this asynch workflow so thoroughly that the term 'fork' really loses most= of it's meaning.

Enough of hindsight. Time to move forward=2C with = lessons learned. Ryan seems very commited personally to correcting such of = these misteps as are perhaps of chief concern=3B I dont want to be offensiv= e and suggest he isnt sincere=2C because at this juncture that is all I wou= ld be doing is offending=2C and that is honestly not my goal.

It is = clear from the 38 messages plus in this and related side threads that rexx = is getting the message about communication - and I will say it again just t= o reenforce the notion: to be a part of the community=2C one must communica= te with one's peers.

I *wish* I could say that OpenSim's core dev te= am is getting the message about the toolchains - this is something that hob= bles many innovators. Some have quietly adopted these newer toolchains for = themselves=2C but much of the benefits of this are lost because core still = sits in an SVN repo (yes=2C I am aware that Hg and GIT can work with SVN re= pos=2C but to do things this way rather dilutes their strengths).

Oh= well=2C one thing about us human beings is=2C we learn=2C grow=2C adapt. I= dont think anyone in this community of ours is less than intelligent (or l= ess than human for that matter =3B) and I hold out hope that the OpenSim te= am will see how remaining bound to SVN is holding us back.


Coming to this point in this discussion I a= m hopefull and optimistic that good things are going to come out of this=2C= in spite of the pain. C'mon=2C Ryan=2C I cant *wait* another year to see t= his stuff =3B)

Cheers
James




On Sun=2C Dec 7=2C= 2008 at 2:03 AM=2C Melanie <=3Bmelanie at t-data.com>=3B wrote:
Hello=2C

Toni Alatalo wrote:
>=3B yep like i mention= ed in the previous post they are orthogonal and
>=3B should be separat= e. was thinking of that earlier this week but didn't
>=3B have time to= bring up with the Rex people yet.

That sounds good.

Melanie
_______________________________________________
O= pensim-dev mailing list
= Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensi= m-dev



--
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The wind
scours the earth for prayers<= BR>The night obscures them

http://osg= rid.org
http://del.icio.us/SPQR<= /A>
http://twitter.com/jstall= ings2
http://www.l= inkedin.com/pub/5/770/a49
= --_3501f0de-0900-4628-9a60-f857ce1b7deb_-- From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: you will have an 'isolated' software team working on your viewer and none of this team will be contributing code to Opensim. I also assume that any contributors to your viewer will not be able to contribute to Opensim. If this is the case then they will also not be able to contribute to the Idealist viewer as the people working on this are opensim contributors. Please feel free to correct me if I am wrong. The beauty (for me anyway) of the IdealistViewer is that it is possible to be involved in contributing patches to both Opensim and IdealistViewer. I think that it is important to clarify this issue to prevent problems in the future. Chris Down From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: packets (and possibly some others=2C like IM?) where the viewer can only ac= cept IP. That is why it is implicitly resolved in some places. (Or rather= =2C that's the rationale for why those places need it) =20 The remoting issue=2C I don't know what that actually means=2C but remoting= should be resolved thru hostname as well. =20 It pains me to admit that I'm probably the source of all this confusion=2C = as I=2C way back then=2C did the DNS resolve as a quick fix to fix some net= working issues - but at that time I was not aware of the DnsEndPoint class. =20 So=2C really=2C the endpoint info should be stored in _DnsEndPoint_ not _IP= Endpoint_ all thru core. =20 and =20 Unless anybody knows of a reason not to=2C I suggest moving any IP resolvin= g into the LL client stack=2C as close to the actual needed conversion as p= ossible=2C and let core use hostnames=2C via DnsEndPoint=2C all over. Best regards=2CStefan AnderssonTribal Media AB Join the 3d web revolution := http://tribalnet.se/=20 Date: Thu=2C 11 Dec 2008 17:38:04 -0800From: lopes at ics.uci.eduTo: opensim-d= ev at lists.berlios.deSubject: Re: [Opensim-dev] external host nameThe thing i= s that this can potentially create a RegionInfo data structure with = nRegionInfo.ExternalHostName =3D regionData.IPADDR=3BThis is inconsiste= nt with certain queries on the Grid server=2C like "give me all my neighbor= s" which may send host names.So=2C back to the point: someone needs to deci= de what is it that RegionInfo.ExternalHostName is supposed to hold.Teravus= Ovares wrote:=20 RegionUpData is my fault=2C and spawned from compatibility issues with .NET remoting and Mono remoting with complex types. It is only used to notify a neighbor region that 'this region is up' Best Regards Teravus On 12/11/08=2C Cristina Videira Lopes wrote: =20 Things are very messy right now. You can search for "sim_ip"=2C for example= =2C which is used in chatting with the grid server=2C and where it is being converted to an IP address in about half of the cases. To compensate=2C and before I noticed this inconsistency=2C Homer introduce= d another field called "sim_host"=2C so not to mess with what was already the= re=2C that is supposed to carry the external host name=2C but this only works up = to the point in which RegionInfo data structures are created. At that point=2C= we need to decide what to place in m_externalHostName=2C sim_ip or sim_host. Which means changes in OGS1. I also noticed that there is yet another data structure called RegionUpData that uses IP addresses. So=2C messy. Someone should decide what this field is supposed to be=2C and= make it a rule. Charles Krinke wrote: Dear Diva: You have a very good point and I would support harmonizing to one notion even at the expense of breaking some things for a while. In fact=2C if someone can identify what some of those things are=2C or come= up with a couple of search strings or grep expressions=2C I would like to look= at the anomalies myself. +1 on external_host_name Charles ________________________________ From: Cristina Videira Lopes To: opensim-dev at lists.berlios.de Sent: Thursday=2C December 11=2C 2008 2:42:05 PM Subject: [Opensim-dev] external host name It turns out that a lot of problems with CAPs have to do with inconsistencies surrounding the URL of the seed cap. Specifically=2C in some cases we're producing URLs with hostnames=2C other times we're producing URLs with IP addresses=2C for example: http://ucigrid03.nacs.uci.edu:9000/CAPS/4cfc94fa-09be-409b-b136-cda2cdde000= 0/ vs. MailScanner has detected a possible fraud attempt from "128.200.71.43:9000" claiming to be MailScanner warning: numerical links are often malicious: MailScanner warning: numerical links are often malicious: http://128.200.71= .43:9000/CAPS/4cfc94fa-09be-409b-b136-cda2cdde0000/ The client is not smart enough to test if this is the same host=2C it assumes it isn't=2C so it decides someone's trying to game it. The inconsistencies are all over the code in OpenSim=2C and they pertain to the use of ExternalHostName in several data s! tructures. In some cases=2C an explicit conversion to IP addresses is made. We should converge to one single thing. And I believe that thing should be whatever it is given in external_host_name config. Is this right? However=2C I am a bit afraid this is going to break 17 different things... Crista _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ________________________________ _______________________________________________ Opensim-dev =20 mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev =20 _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev = --_c138cece-0090-4e59-bc4e-3ff653ac7430_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: leport =3Bpackets (and possibly some others=2C like IM?) =3Bwhere t= he viewer can only accept IP. That is why it is implicitly resolved in some= places. (Or rather=2C that's the rationale for why those places need it)  =3B
The remoting issue=2C I don't know what that actually means=2C but remoting= should be resolved thru hostname as well.
 =3B
It pains me to admit that I'm probably the source of all this confusion=2C = as I=2C way back then=2C did the DNS resolve as a quick fix to fix some net= working issues - but at that time I was not aware of the DnsEndPoint class.=
 =3B
So=2C really=2C the endpoint info should be =3Bstored in =3B_DnsEnd= Point_ not _IPEndpoint_ all thru core.
 =3B
and
 =3B
Unless anybody knows of a reason not to=2C I suggest moving any =3BIP r= esolving into the =3BLL client stack=2C as close to the actual needed c= onversion as possible=2C and let core =3Buse hostnames=2C via DnsEndPoi= nt=2C =3Ball over.

Best regards=2C
Stefan Andersson
Tribal Media AB
 =3B
J= oin the =3B3d web revolution : http://= tribalnet.se/
 =3B






Date: Thu=2C 11 Dec 2008 17:38:04 -0800
From: lopes at ics.uci.edu
To: o= pensim-dev at lists.berlios.de
Subject: Re: [Opensim-dev] external host nam= e

The thing is that this can potentially create a RegionInfo data st= ructure with
 =3B =3B =3B =3B =3B =3B =3B&n= bsp=3B =3B =3B nRegionInfo.ExternalHostName =3D regionData.IPADDR= =3B

This is inconsistent with certain queries on the Grid server=2C = like "give me all my neighbors" which may send host names.

So=2C bac= k to the point: someone needs to decide what is it that RegionInfo.External= HostName =3B is supposed to hold.

Teravus Ovares wrote: 
RegionUpData is my fault=2C and spawned from compatibility iss=
ues with
.NET remoting and Mono remoting with complex types.  It is only used
to notify a neighbor region that 'this region is up'

Best Regards

Teravus

On 12/11/08=2C Cristina Videira Lopes <=3Blopes at ics.uci.edu>=3B wrote:
  
Things are very messy right now. You can search for "sim_i=
p"=2C for example=2C
which is used in chatting with the grid server=2C and where it is being
converted to an IP address in about half of the cases.

To compensate=2C and before I noticed this inconsistency=2C Homer introduce=
d
another field called "sim_host"=2C so not to mess with what was already the=
re=2C
that is supposed to carry the external host name=2C but this only works up =
to
the point in which RegionInfo data structures are created. At that point=2C=
 we
need to decide what to place in m_externalHostName=2C sim_ip or sim_host.
Which means changes in OGS1.

I also noticed that there is yet another data structure called RegionUpData
that uses IP addresses.

So=2C messy. Someone should decide what this field is supposed to be=2C and=
 make
it a rule.

Charles Krinke wrote:

Dear Diva:

You have a very good point and I would support harmonizing to one notion
even at the expense of breaking some things for a while.

In fact=2C if someone can identify what some of those things are=2C or come=
 up
with a couple of search strings or grep expressions=2C I would like to look=
 at
the anomalies myself.

+1 on external_host_name

Charles

________________________________


From: Cristina Videira Lopes <=3Blopes at ics.uci.edu>=3B
To: opensim-dev at lists.berlios.de
Sent: Thursday=2C December 11=2C 2008 2:42:05 PM
Subject: [Opensim-dev] external host name

It turns out that a lot of problems with CAPs have to do with
inconsistencies surrounding the URL of the seed cap. Specifically=2C in
some cases we're producing URLs with hostnames=2C other times we're
producing URLs with IP addresses=2C for example:

http://ucigrid03.nacs.uci.e=
du:9000/CAPS/4cfc94fa-09be-409b-b136-cda2cdde0000/
vs.
MailScanner has detected a possible fraud attempt from "128.200.71.43:9000"
claiming to be MailScanner warning: numerical links are often malicious:
MailScanner war=
ning: numerical links are often malicious: http://128.200.71.43:=
9000/CAPS/4cfc94fa-09be-409b-b136-cda2cdde0000/

The client is not smart enough to test if this is the same host=2C it
assumes it isn't=2C so it decides someone's trying to game it.

The inconsistencies are all over the code in OpenSim=2C and they pertain
to the use of ExternalHostName in several data s! tructures. In some
cases=2C an explicit conversion to IP addresses is made.

We should converge to one single thing. And I believe that thing should
be whatever it is given in external_host_name config. Is this right?
However=2C I am a bit afraid this is going to break 17 different things...

Crista

_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-d=
ev
________________________________

    
_______________________________________________
Opensim-dev
  
mailing
list
    
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-d=
ev
  
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-d=
ev


    
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-d=
ev

= --_c138cece-0090-4e59-bc4e-3ff653ac7430_-- From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: packets (and possibly some others=2C like IM?) where the viewer can only ac= cept IP. That is why it is implicitly resolved in some places. (Or rather= =2C that's the rationale for why those places need it) The remoting issue= =2C I don't know what that actually means=2C but remoting should be resolve= d thru hostname as well. It pains me to admit that I'm probably the source = of all this confusion=2C as I=2C way back then=2C did the DNS resolve as a = quick fix to fix some networking issues - but at that time I was not aware = of the DnsEndPoint class. So=2C really=2C the endpoint info should be store= d in _DnsEndPoint_ not _IPEndpoint_ all thru core. and Unless anybody knows= of a reason not to=2C I suggest moving any IP resolving into the LL client= stack=2C as close to the actual needed conversion as possible=2C and let c= ore use hostnames=2C via DnsEndPoint=2C all over.Best regards=2CStefan Ande= rssonTribal Media AB Join the 3d web revolution : http://tribalnet.se/=20 Date: Thu=2C 11 Dec 2008 17:38:04 -0800From: lopes at ics.uci.eduTo: opensim-d= ev at lists.berlios.deSubject: Re: [Opensim-dev] external host nameThe thing i= s that this can potentially create a RegionInfo data structure with = nRegionInfo.ExternalHostName =3D regionData.IPADDR=3BThis is inconsiste= nt with certain queries on the Grid server=2C like "give me all my neighbor= s" which may send host names.So=2C back to the point: someone needs to deci= de what is it that RegionInfo.ExternalHostName is supposed to hold.Teravus= Ovares wrote:=20 RegionUpData is my fault=2C and spawned from compatibility issues with .NET remoting and Mono remoting with complex types. It is only used to notify a neighbor region that 'this region is up' Best Regards Teravus On 12/11/08=2C Cristina Videira Lopes wrote: =20 Things are very messy right now. You can search for "sim_ip"=2C for example= =2C which is used in chatting with the grid server=2C and where it is being converted to an IP address in about half of the cases. To compensate=2C and before I noticed this inconsistency=2C Homer introduce= d another field called "sim_host"=2C so not to mess with what was already the= re=2C that is supposed to carry the external host name=2C but this only works up = to the point in which RegionInfo data structures are created. At that point=2C= we need to decide what to place in m_externalHostName=2C sim_ip or sim_host. Which means changes in OGS1. I also noticed that there is yet another data structure called RegionUpData that uses IP addresses. So=2C messy. Someone should decide what this field is supposed to be=2C and= make it a rule. Charles Krinke wrote: Dear Diva: You have a very good point and I would support harmonizing to one notion even at the expense of breaking some things for a while. In fact=2C if someone can identify what some of those things are=2C or come= up with a couple of search strings or grep expressions=2C I would like to look= at the anomalies myself. +1 on external_host_name Charles ________________________________ From: Cristina Videira Lopes To: opensim-dev at lists.berlios.de Sent: Thursday=2C December 11=2C 2008 2:42:05 PM Subject: [Opensim-dev] external host name It turns out that a lot of problems with CAPs have to do with inconsistencies surrounding the URL of the seed cap. Specifically=2C in some cases we're producing URLs with hostnames=2C other times we're producing URLs with IP addresses=2C for example: http://ucigrid03.nacs.uci.edu:9000/CAPS/4cfc94fa-09be-409b-b136-cda2cdde000= 0/ vs. MailScanner has detected a possible fraud attempt from "128.200.71.43:9000" claiming to be MailScanner warning: numerical links are often malicious: MailScanner warning: numerical links are often malicious: http://128.200.71= .43:9000/CAPS/4cfc94fa-09be-409b-b136-cda2cdde0000/ The client is not smart enough to test if this is the same host=2C it assumes it isn't=2C so it decides someone's trying to game it. The inconsistencies are all over the code in OpenSim=2C and they pertain to the use of ExternalHostName in several data s! tructures. In some cases=2C an explicit conversion to IP addresses is made. We should converge to one single thing. And I believe that thing should be whatever it is given in external_host_name config. Is this right? However=2C I am a bit afraid this is going to break 17 different things... Crista _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ________________________________ _______________________________________________ Opensim-dev =20 mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev =20 _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev = --_93cdcf36-e58e-41c7-9d0c-28c44b8d43ea_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Augh. That's what you get for =3Bassuming stuff. It seems the DnsEndpoi= nt class is only available in .Net for Silverlight... that explains why I d= idn't know about it then. :D
 =3B
So=2C read that as 'should be stored in _something_like_ DnsEndpoint'.
<= BR> *sigh*

At any rate=2C moving the resolving into the very cases where IP adress is = mandatory is a good thing. The resolving is =3Bmulti-level cached anywa= y.

Best regards=2C
Stefan Andersson
Tribal Media AB
 =3B
<= BR>

From: stefan at tribalmedia.se
To: opensim-dev at lists.berlios.de
Date: Fr= i=2C 12 Dec 2008 11:04:27 +0100
Subject: Re: [Opensim-dev] external host= name

From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: leport =3Bpackets (and possibly some others=2C like IM?) =3Bwhere t= he viewer can only accept IP. That is why it is implicitly resolved in some= places. (Or rather=2C that's the rationale for why those places need it) =3B
The remoting issue=2C I don't know what that actually means= =2C but remoting should be resolved thru hostname as well.
 =3B
I= t pains me to admit that I'm probably the source of all this confusion=2C a= s I=2C way back then=2C did the DNS resolve as a quick fix to fix some netw= orking issues - but at that time I was not aware of the DnsEndPoint class.<= BR> =3B
So=2C really=2C the endpoint info should be =3Bstored in=  =3B_DnsEndPoint_ not _IPEndpoint_ all thru core.
 =3B
and =3B
Unless anybody knows of a reason not to=2C I suggest moving an= y =3BIP resolving into the =3BLL client stack=2C as close to the ac= tual needed conversion as possible=2C and let core =3Buse hostnames=2C = via DnsEndPoint=2C =3Ball over.

Best regards=2C
Stefan Anders= son
Tribal Media AB
 =3B
Join the =3B3d web revolution : <= A href=3D"http://tribalnet.se/">http://tribalnet.se/
 =3B







Date: Thu=2C 11 Dec 2008 17:38:04 -0800
From: lopes at ics.uci.edu
T= o: opensim-dev at lists.berlios.de
Subject: Re: [Opensim-dev] external host= name

The thing is that this can potentially create a RegionInfo dat= a structure with
 =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B nRegionInfo.ExternalHostName =3D regionData.IPA= DDR=3B

This is inconsistent with certain queries on the Grid server= =2C like "give me all my neighbors" which may send host names.

So=2C= back to the point: someone needs to decide what is it that RegionInfo.Exte= rnalHostName =3B is supposed to hold.

Teravus Ovares wrote:
= 
RegionUpData is my fault=2C and spawned from compatibility iss=
ues with
.NET remoting and Mono remoting with complex types.  It is only used
to notify a neighbor region that 'this region is up'

Best Regards

Teravus

On 12/11/08=2C Cristina Videira Lopes <=3Blopes at ics.uci.edu>=3B wrote=
:
  
Things are very messy right now. You can search for "sim_i=
p"=2C for example=2C
which is used in chatting with the grid server=2C and where it is being
converted to an IP address in about half of the cases.

To compensate=2C and before I noticed this inconsistency=2C Homer introduce=
d
another field called "sim_host"=2C so not to mess with what was already the=
re=2C
that is supposed to carry the external host name=2C but this only works up =
to
the point in which RegionInfo data structures are created. At that point=2C=
 we
need to decide what to place in m_externalHostName=2C sim_ip or sim_host.
Which means changes in OGS1.

I also noticed that there is yet another data structure called RegionUpData
that uses IP addresses.

So=2C messy. Someone should decide what this field is supposed to be=2C and=
 make
it a rule.

Charles Krinke wrote:

Dear Diva:

You have a very good point and I would support harmonizing to one notion
even at the expense of breaking some things for a while.

In fact=2C if someone can identify what some of those things are=2C or come=
 up
with a couple of search strings or grep expressions=2C I would like to look=
 at
the anomalies myself.

+1 on external_host_name

Charles

________________________________


From: Cristina Videira Lopes <=3Blopes at ics.uci.edu>=3B
To: opensim-dev at lists.berlios.de
Sent: Thursday=2C December 11=2C 2008 2:42:05 PM
Subject: [Opensim-dev] external host name

It turns out that a lot of problems with CAPs have to do with
inconsistencies surrounding the URL of the seed cap. Specifically=2C in
some cases we're producing URLs with hostnames=2C other times we're
producing URLs with IP addresses=2C for example:

http://ucigrid03.nacs.uc=
i.edu:9000/CAPS/4cfc94fa-09be-409b-b136-cda2cdde0000/
vs.
MailScanner has detected a possible fraud attempt from "128.200.71.43:9000"
claiming to be MailScanner warning: numerical links are often malicious:
MailScanner =
warning: numerical links are often malicious: http://128.200.71.=
43:9000/CAPS/4cfc94fa-09be-409b-b136-cda2cdde0000/

The client is not smart enough to test if this is the same host=2C it
assumes it isn't=2C so it decides someone's trying to game it.

The inconsistencies are all over the code in OpenSim=2C and they pertain
to the use of ExternalHostName in several data s! tructures. In some
cases=2C an explicit conversion to IP addresses is made.

We should converge to one single thing. And I believe that thing should
be whatever it is given in external_host_name config. Is this right?
However=2C I am a bit afraid this is going to break 17 different things...

Crista

_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensi=
m-dev
________________________________

    
_______________________________________________
Opensim-dev
  
mailing
list
    
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensi=
m-dev
  
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensi=
m-dev


    
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensi=
m-dev

= --_93cdcf36-e58e-41c7-9d0c-28c44b8d43ea_-- From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: d=2C=20 * for the people wanting to do public beta grade services based on OpenSi= m * for developers that want to code on modules without sudden mysterious b= reaks * and for the devs that want to debug without new parameters being introd= uced. =20 Now of course=2C vendor branches is one other way to do this=2C but what we= at Tribal realized=2C was that since we're coding in modules=2C all we use= d the vendor branch for was for stabilizing fixes. =20 And since that work would otherwise be duplicated in a number of dev teams= =2C it makes sense to share that work. =20 > A better approach to stability than stable branches is> to help create un= it tests for trunk.=20 =20 Which of course not only is a totally untestable assertion=2C but also has = to be weighted against a pragmatical timescale. =20 > This helps contain behavior=2C and> drives towards code correctness for p= arts of the tree.=20 =20 +1 to extended testing. =20 > I'd encourage people> spend time on enhancing automated testing instead o= f doing point in time> stable branches. I'd encourage people to do both=2C as I believe compairing the efforts woul= d be like compairing apples to pears. One is about testing the correctness = of the code in a point of time=2C the other is to provide an aggregate of e= xperience to facilitate a work process. =20 At heart=2C I'm an agile coder. I do believe that trunk should always be in= a shippable state=2C but to think that that means you should always ship t= runk=2C is to over-simplify. /Stefan = --_8c91159c-18de-4961-9531-c53f449079b8_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >=3B >=3B I can see some people being hesitant to commit to supporting = this
>=3B >=3B because they don't want to worry about committing to = two branches each
>=3B >=3B time they have a fix=2C or they don't wa= nt to maintain two slightly
>=3B >=3B different code bases.
 =3B
This would be 100% optional=2C and probably done by a small group of devote= es (like me and Darren=2C as in the case of the last stable) whose only hum= bly wish is to get a heads-up from peple whenever =3Ba good=2C clean bu= g fix has been committed.
 =3B
>=3B >=3B =3BBug reports could also become more of a hassle as
&= gt=3B >=3B some users will report bugs against the trunk=2C while others = against the
>=3B >=3B stable branch.

My concept will not work if we don't re-branch new stables reasonably often= - the heart of the concept is that 'stable' should not deviate from trunk = very far at all=2C just minor bug fixes and changes deemed 'harmless'.
 =3B
The reason=2C of course=2C is exactly that we should be reasonably certain = a bug exists in both branches.
 =3B
Apart from that=2C we have that same problem on every revision. The user ne= eds to tell us what revision (or trunk) the error is on.

>=3B >=3B Having said that=2C I can see a benefit for having a stab= le branch.
>=3B >=3B Ideally it would follow trunk pretty closely=2C= and when it becomes
>=3B >=3B challenging to apply patches to both = trees without too much massaging=2C
>=3B >=3B it's time to do final = stabilization on that final branch and release.

That was the general idea. Bu tI would say=2C given the agile nature of the= project=2C that we just _define_ that=2C "when bug fixes does not apply cl= eanly=2C it's an indication we should bump the number".

>=3B >=3B I would like to encourage you to give this a try.
 =3B
We already are. At the moment=2C I'm just waiting for people to tell me we = have a reasonably stable revision that I can branch again.
 =3B
>=3B =3B>=3B In the meantime=2C don't expect too much
>=3B >= =3B commitment from all the devs=2C and be prepared to take responsibility<= BR>>=3B >=3B for this stable branch. After some time=2C we can all look= back at how
>=3B >=3B things went and decide what to do in the futu= re.

This is basically what happened with 0.6.0-stable. Only thing we need is he= lp with finding the revisions=2C and to get tipped about good stabilizing&n= bsp=3Bfixes in trunk.

>=3B The problem with stable branches... is they aren't. If you add c= ode to
>=3B a branch=2C you have the potential to break it=2C especial= ly on a source
>=3B base as complex as OpenSim.

True as that may be=2C =3Bof course it depends on what type of code you= add=2C and how much.
 =3B
If we were talking doing serious work on a 'real' branch=2C I would be much= more inclined to agree=2C but the point of this is to keep it ligth=2C agi= le and to a minimum of deviation.

>=3B Personally=2C I'm going to stay focused on trunk=2C that's where= my time and
>=3B interest lies.
 =3B
Then do. I'm not trying to rally resources devoted into this=2C I'm merely = trying to work out a process that would work given the nature of the OpenSi= m project.
 =3B
From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: d=2C
 =3B * for the people wanting to do public beta grade services based on= OpenSim
 =3B * =3Bfor developers that want to code on modules without sudde= n mysterious breaks
 =3B * =3Band for the devs that want to debug without new parameter= s being introduced.
 =3B
Now of course=2C vendor branches is one other way to do this=2C but what we= at Tribal realized=2C was that since we're coding in modules=2C all we use= d the vendor branch for was for stabilizing fixes.
 =3B
And since that work would otherwise be duplicated in a number of dev teams= =2C it makes sense to share that work.
 =3B
>=3B =3BA better approach to stability than stable branches is
>= =3B to help create unit tests for trunk.
 =3B
Which of course not only is a totally untestable assertion=2C but also has = to be weighted against a pragmatical timescale.
 =3B
>=3B This helps contain behavior=2C and
>=3B drives towards code cor= rectness for parts of the tree.
 =3B
+1 to extended testing.
 =3B
>=3B I'd encourage people
>=3B spend time on enhancing automated tes= ting instead of doing point in time
>=3B stable branches.

I'd encourage people to do both=2C as =3BI believe compairing the effor= ts would be like =3Bcompairing apples to pears. One is about testing th= e correctness of the code in a point of time=2C the other is to provide an = aggregate of experience to facilitate =3Ba work process.
 =3B
At heart=2C I'm an agile coder. I do believe that trunk should always be in= a shippable state=2C but to think that that means you should always ship t= runk=2C is to over-simplify.

/Stefan
 =3B
= --_8c91159c-18de-4961-9531-c53f449079b8_-- From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: Charles ________________________________ From: Frank Nichols To: opensim-dev at 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 at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > ------------------------------------------------------------------------ > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev --0-81887043-1233637195=:75638 Content-Type: text/html; charset=us-ascii
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 <frank at thenichols.net>
To: opensim-dev at 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 <frank at thenichols.net
> <mailto:frank at thenichols.net>> 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 at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
>    https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> 

_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
--0-81887043-1233637195=:75638-- From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: the RegionInfo class tree=2C or be used in explicit serialization (as in=2C= filling in hashtables) =20 Thru SVN BLAME I can see that the serializable attribute was introduced wit= h the NHibernate patches. =20 From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: bernate=2C and is thus safe to work with in local changes. If you can find any other places using implicit serialization=2C please let= me know. =20 Again=2C =20 thank you. Stefan Andersson Tribal Media AB =20 > Date: Thu=2C 12 Feb 2009 11:07:13 +0000 > From: melanie at t-data.com > To: opensim-dev at lists.berlios.de > Subject: Re: [Opensim-dev] Refactoring the backend codepaths >=20 > Hi=2C >=20 > it is used in a remoting call=2C InformReginOfNeighbors or somesuch.=20 > That implicitly serializes it. That code may have been=20 > changed/removed since I looked at it=2C but that is why it is=20 > serializable. >=20 > Melanie >=20 > Stefan Andersson wrote: > > Esteemed colleagues=2C friends=2C lovers=3B > >=20 > >=20 > >=20 > > I have taken upon me to embark on an long and arduous journey=3B to try= to refactor the mess that is called 'LoginService' - and in the process pr= obably touch on quite a lot of the backend codepath messiness. > >=20 > >=20 > >=20 > > The general idea is to eliminate duplication by abstracting the archite= cture into 'service proxies'=2C 'service implementations'=2C 'model manager= s' and 'service interfaces'. > >=20 > >=20 > >=20 > > This will be done in babysteps=2C over a long time - my goal is to neve= r do any big restructuring=2C but merely work with my trusty refactoring to= ols=2C and as fast as time permits. > >=20 > >=20 > >=20 > > This said=2C the current tangliness may cause me to break something in = some code path=3B if so=2C I beg your forgiveness and support in rectifying= the situation. > >=20 > >=20 > >=20 > > Now=2C at this very moment=2C I have but one question upon my mind=3B p= ray answer it if you are among the wise - > >=20 > >=20 > >=20 > > why is "RegionProfileData" marked as "Serializable" - what is serializi= ng it? > >=20 > >=20 > > Thank you for your time=2C effort=2C support and understanding. > >=20 > >=20 > > Best regards=2C > > Stefan Andersson > > Tribal Media AB > >=20 > >=20 > >=20 > >=20 > > -----------------------------------------------------------------------= - > >=20 > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev --_d113603a-d6d4-4f3a-ac7f-668c53010489_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Melanie=2C
 =3B
Thank you to you and Belsepubi for your swift replies.
 =3B
From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: =3Buse the RegionInfo class tree=2C or be used in explicit serialization (a= s in=2C filling in hashtables)
 =3B
Thru SVN =3BBLAME I can s= ee that the serializable attribute was introduced with the NHibernate patch= es.
 =3B
From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: bernate=2C and is thus safe to work with in local changes.

If you can find any other places using implicit serialization=2C please let= me know.
 =3B
Again=2C
 =3B
thank you.
Stefan Andersson
Tribal Media AB



 =3B>=3B Date: Thu=2C 12 Feb 2009 11:07:13 +0000
>=3B From: melanie at t-= data.com
>=3B To: opensim-dev at lists.berlios.de
>=3B Subject: Re: = [Opensim-dev] Refactoring the backend codepaths
>=3B
>=3B Hi=2C<= BR>>=3B
>=3B it is used in a remoting call=2C InformReginOfNeighbor= s or somesuch.
>=3B That implicitly serializes it. That code may have= been
>=3B changed/removed since I looked at it=2C but that is why it= is
>=3B serializable.
>=3B
>=3B Melanie
>=3B
>= =3B Stefan Andersson wrote:
>=3B >=3B Esteemed colleagues=2C friends= =2C lovers=3B
>=3B >=3B
>=3B >=3B
>=3B >=3B
>= =3B >=3B I have taken upon me to embark on an long and arduous journey=3B= to try to refactor the mess that is called 'LoginService' - and in the pro= cess probably touch on quite a lot of the backend codepath messiness.
&g= t=3B >=3B
>=3B >=3B
>=3B >=3B
>=3B >=3B The gener= al idea is to eliminate duplication by abstracting the architecture into 's= ervice proxies'=2C 'service implementations'=2C 'model managers' and 'servi= ce interfaces'.
>=3B >=3B
>=3B >=3B
>=3B >=3B
&g= t=3B >=3B This will be done in babysteps=2C over a long time - my goal is= to never do any big restructuring=2C but merely work with my trusty refact= oring tools=2C and as fast as time permits.
>=3B >=3B
>=3B >= =3B
>=3B >=3B
>=3B >=3B This said=2C the current tangliness= may cause me to break something in some code path=3B if so=2C I beg your f= orgiveness and support in rectifying the situation.
>=3B >=3B
&g= t=3B >=3B
>=3B >=3B
>=3B >=3B Now=2C at this very moment= =2C I have but one question upon my mind=3B pray answer it if you are among= the wise -
>=3B >=3B
>=3B >=3B
>=3B >=3B
>=3B= >=3B why is "RegionProfileData" marked as "Serializable" - what is seria= lizing it?
>=3B >=3B
>=3B >=3B
>=3B >=3B Thank you f= or your time=2C effort=2C support and understanding.
>=3B >=3B
&= gt=3B >=3B
>=3B >=3B Best regards=2C
>=3B >=3B Stefan Ande= rsson
>=3B >=3B Tribal Media AB
>=3B >=3B
>=3B >=3B <= BR>>=3B >=3B
>=3B >=3B
>=3B >=3B ----------------------= --------------------------------------------------
>=3B >=3B
>= =3B >=3B _______________________________________________
>=3B >=3B= Opensim-dev mailing list
>=3B >=3B Opensim-dev at lists.berlios.de
= >=3B >=3B https://lists.berlios.de/mailman/listinfo/opensim-dev
>= =3B _______________________________________________
>=3B Opensim-dev m= ailing list
>=3B Opensim-dev at lists.berlios.de
>=3B https://lists.= berlios.de/mailman/listinfo/opensim-dev

= --_d113603a-d6d4-4f3a-ac7f-668c53010489_-- From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: database growth, and a reaping strategy would enforce that, so that = would be ok. If there'd be another strategy that would make reaping unnecessary, I'd = welcome that. To me one solution involving different data = responsibilities and quotas smells like such a solution. -- Dirk/Bart -----Urspr=FCngliche Nachricht----- Von: opensim-dev-bounces at lists.berlios.de = [mailto:opensim-dev-bounces at lists.berlios.de] Im Auftrag von Melanie Gesendet: Donnerstag, 19. Februar 2009 03:27 An: opensim-dev at lists.berlios.de Betreff: Re: [Opensim-dev] oddities with asset storage Hi, i proposed a reaping strategy that is both type and time based.=20 There was no direct response to it, but current development on new=20 de-duping cable beach plugins may go a long way to curb asset=20 proliferation and the reaper can be developed on that basis.=20 Refcounting may be feasible as a positive indication, e.g. to=20 indicate something is _definitely_ safe to delete, but a reaper will=20 still be required. Melanie Buckaroo Mu wrote: > Melanie wrote: >> This is something i have though about. However, it would not work in=20 >> OSGrid. Regions may go away, and they may go away permanently.=20 >> Anything in a prim inventory at that time is refcounted and would=20 >> not be released. Ever. >> =20 > In what what in particular would this be worse than the current=20 > situation? Yes, some assets would end up staying around forever.=20 > However, unlike the current scheme, some... would not. >> So, you'd need a ref list, to purge invalid refs. That is where the=20 >> inpracticability begins. A redf list for each and every asset,=20 >> listing either avatar UUID or region UUID? >> >> =20 > Eep, no - wasn't considering suggesting this. >> If assets are 51 mio, how long will the reflist table be? >> >> Melanie >> >> Buckaroo Mu wrote: >> =20 >>> Here's my L$0.02, for what it's worth - why not maintain a = 'reference=20 >>> count' in the asset entry? >>> >>> Resident A creates a prim, takes it into inventory. Asset is = created,=20 >>> inventory item pointing to asset is created, asset->useagecount++. = User=20 >>> gives away 15 copies of item, asset->usagecount+=3D15. Resident A = deletes=20 >>> original item, inventory item goes away, asset->usagecount--. >>> >>> Resident B rezzes item on sim. If item is no-copy, = asset->usagecount--.=20 >>> If it's copy, and Resident B (or Resident C) takes it back into=20 >>> inventory, asset->usagecount++ (they would have two copies of it).=20 >>> Resident B deletes both copies from inventory, asset->usagecount = -=3D2. >>> >>> If asset->usagecount =3D=3D 0, asset gets deleted. >>> >>> Tell me why this wouldn't work. I'm sure there's a simple reason, = but I=20 >>> can't think of it. All of this is assuming that the asset is no-mod = -=20 >>> any change to the asset creates a new UUID, correct? But if the = asset is=20 >>> rezzed, then taken back into inventory, it should have the same = UUID,=20 >>> thus adding one to the usage count. >>> >>> -Buckaroo >>> >>> Melanie wrote: >>> =20 >>>> All you described is design behavior. >>>> >>>> >>>> Prim items in world are not assets. They are stored exclusively in >>>> the prims tables of the region. >>>> >>>> Once taken, they become an asset. The name is totally meaningless, >>>> it reflects whatever was the name at creation. Nothing else. It >>>> never changes from there on. >>>> >>>> On deleting the inventory item, assets remain. There is no easy or >>>> practicable way to conclusively say that an asset is trash, because >>>> we don't know. >>>> >>>> In your test case, your (human) mind could know this for a fact, >>>> however, the silicon mind of the asset server can't. >>>> >>>> This is because you may have given the object to another user, or >>>> put a copy into a prim. >>>> >>>> These copies would refer to the same asset, that is what = "implictily >>>> shared" means. >>>> >>>> So, any asset may, at any time, have any number of links to it, = even >>>> zero. >>>> >>>> Like a website, you don't know who linked to it. If you remove it, >>>> you leave dead links. Assets are the same. Except, you get "Asset >>>> missing from database". >>>> >>>> So, assetas are NOT 1-to-1 with inventory items, and they _never_ >>>> get deleted. >>>> >>>> They have to be reaped, and there is a big discussion over how to >>>> best do that, running right now. >>>> >>>> Melanie >>>> >>>> >>>> Dirk Krause wrote: >>>> =20 >>>> =20 >>>>> Hi, >>>>> >>>>> I did a little test with a fresh OpenSim installation (yes, thanks = for >>>>> the installer!), >>>>> to get a grip on what I learned from Melanie yesterday. >>>>> >>>>> I wrote a little python script to help me monitor these tables: >>>>> inventoryStore/inventoryItems >>>>> assetStorage/assets >>>>> http://pastebin.com/mc9e6574 , be warned: ugly code. >>>>> >>>>> I started OpenSim and logged in a 'Test User' with the SL viewer. >>>>> >>>>> (Just to mention it - first time log in in as test users creates >>>>> 4 'blank' entries in assets.) >>>>> >>>>> The inventoryItems table was initially empty. >>>>> >>>>> Now I rezzed a cube and renamed it to 'p1'. >>>>> inventoryStore/inventoryItems was still empty. >>>>> To my surprise no new entry shows up in assetStorage/assets. >>>>> >>>>> Picking up the cube ('take') created an entry named 'p1' in the >>>>> inventory and in the asset table. >>>>> >>>>> Now I renamed the cube in Test Users inventory to 'p2'. >>>>> The name in inventoryStore/inventoryItems changes to 'p2'. >>>>> The entry in assetStorage/assets stays 'p1'. As mentioned on the = list >>>>> before, >>>>> the asset name is useless, since the user only sees the name in = the >>>>> inventory. >>>>> >>>>> Now I deleted 'p2' in my inventory - 'p2's parentfolderID changes = to >>>>> 'Trash'. >>>>> Now I emptied the trash - the inventory table is empty again, = which is >>>>> fine, >>>>> but here's the big one: >>>>> the assetStorage/assets still holds the reference to 'p1'. >>>>> >>>>> Just to make sure I shut down the simulator and opened it again, = and it >>>>> was still there. >>>>> >>>>> Now, doesn't that mean, that the database increases over time with = no >>>>> hope to find >>>>> these assets that actually should be gone? or is there some magic >>>>> purging that happens, >>>>> and that I missed? >>>>> >>>>> This would mean that any grid runs into a severe problem over = time. >>>>> >>>>> Best, >>>>> Dirk/Bart >>>>> _______________________________________________ >>>>> Opensim-dev mailing list >>>>> Opensim-dev at lists.berlios.de >>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>>> >>>>> >>>>> =20 >>>>> =20 >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> Opensim-dev at lists.berlios.de >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> >>>> >>>> =20 >>>> =20 >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> >>> =20 >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> >> =20 >=20 > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev >=20 >=20 _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: this out there for real, with a 2.0 tag, without first understanding if/how people detect phishing in this particular context. There have been enough studies in the past about how normal people handle security (or not) in practice, and the fallacies of designing systems assuming that people choose security over convenience.

But hey -- I have no interest in the success or failure of the corporations that are pushing for this.
I'll just stay here on my academic Ivory tower watching the phishing artists unwrap this wonderful present that is falling on their laps...
http://marcoslot.net/apps/openid/


And that's my last email about OpenID; case closed afaic, I'm too old and too cranky for these Web 2.0 experiments. I'd rather continue trying to solve the problem for real :-)

Crista

Aldon Hynes wrote: 
It is worth noting that Microsoft is now adopting OpenID as well.  A while
ago it went into testing,  The idea is that you can use Microsoft Live as
your OpenID provider.  I've tested it and it works fairly well.  In fact, I
think it works better than the Google implementation.  However, I still
prefer XRI based OpenID

=aldon.hynes
@ahynes1

-----Original Message-----
From: opensim-dev-bounces at lists.berlios.de
[mailto:opensim-dev-bounces at lists.berlios.de]On Behalf Of Ralf Haifisch
Sent: Monday, March 02, 2009 6:39 PM
To: opensim-dev at lists.berlios.de
Subject: Re: [Opensim-dev] OpenID


Crista,

this is a upcomming standard and common sense. If I do an audit based in ISO
27.001, this is a perfect thing and would get some applause if implementet,
generally speaking.


It is based on the established ideas from LPAD+Kerberos combining systems,
that use this triangle of user/workstation - auth-provider and
auth-subscriber in principle , as well.


Microsoft did try to run this with .Net Passport (uhm... maybe they even had
a name before that) and had a set of criteria you have to fulfill before
joining the system.  People did not like this "closed source big brother -
alike" system.


openID and SAML are major topics for those devs, that are into security
systems right now. Claim based systems and rights management are often based
on this.


It is all about a "secure stack".

- hopefully, you did write your operating system - why could it be trusted
otherwise ?
- what about the keyboard ?  easy going to implement what I need
- is there a "nuble" on your monitors video cord ? is this for antiference
reasons... hmmm..
- you print out strategic papers or sources on the big laserpinter in the
floor (sure, only you in the building)..  I did fetch interesting stuff
unencrypted from these devices
- you had this all new USB harddisc for backups that came with some new
drivers ?

Unless the whole stack from hardware to service is secure and trusts are
build and verified against each other.... what you see is the best that is
realistic achievable:


--> warn the user, if something is maybe wrong.


Its you, chooses the opened provider (I guess verisign is somewhat secure
for me)

It´s you who uses a service - and would have done even without opened.

Its you who gets a warning about possible fraud, you would not have been
getting without opened.


Instead of opened the usual user has 2000 passwords and requests new
passwords via clear text email over the web, regularly.


So - in total a regular user gets more security.  That’s the basic idea.


In some years we will use at least 2-factor authentification.  E.g. the
Netherlands did start giving out passports with a digital ID (certificate).
Cheap reader will spread.


There is a common sense that, "exo-technical means" will better serve
security needs in future. The more business driven standards like ISO 27.001
and 38.500 repect this. Technical means will fulfill a task assingned
exo-technical.


Let say - this is a new and upcoming system.
Its not worse than what we have.
It has many option got get better on a standard architecture.


It´s a little bit like the 3D web story...


Cheers,
Ralf


------------------------------

Message: 6
Date: Mon, 02 Mar 2009 14:44:46 -0800
From: Diva Canto <diva at metaverseink.com>
Subject: Re: [Opensim-dev] OpenID
To: opensim-dev at lists.berlios.de
Message-ID: <49AC615E.5010904 at metaverseink.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

OMG!
Sorry for insisting on this, but I tend to get obsessive when I'm trying
to figure things out :-)
I just tried login to some random Brazilian site using my OpenID-ed
Yahoo account. Indeed, it... works... i guess.
I seem to have been redirected to a yahoo openid login page, which,
after I entered my password, proceeded to warn me that "Warning: this
web site has not confirmed its identity with Yahoo! and might be
fraudulent....".

I have no idea/guarantees that this site that the Brazilian site
redirected me that looks like Yahoo, where I entered my password, and
that is warning me of danger, is, indeed, a legitimate Yahoo site. It
might not be. And I have no idea what that potentially fraudulent
Brazilian site might do with the info it gets from Yahoo (assuming this
is Yahoo and not a phishing scam).

Sorry, this defies all common sense...

I can see the *mechanism* of OpenID working among a group of
organizations that trust each other by exo-technical means (read
lawyers). But this mechanism in decentralized, world-wide open systems?!
That's insane!

Crista

Diva Canto wrote:
  
The more I read about OpenID the more concerns I have that it's unsafe
-- not just for OpenSim but in general. It seems that OpenID is a
wonderful opportunity for phishing sites to get access to people's
passwords directly.

The flaw is that it assumes that the initial site is trustworthy. That's
a huge assumption! Try to use your OSGrid OpenID-ed account in a future
version of DNCH... it will direct you to a page that will look like
OSGrid's login page, and then it will steal your password as you type it.

Is this serious?! Maybe I'm missing something fundamental...

<puzzled>
Crista

_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev


    




_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

--------------000200020906030200060404-- From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: understanding of how the assest server works. Also, I don't think I will play with that, but I was thinking of writing this info up in a blog post. Do you have a link to any additional information on your cryptogrid assest provider? Couple questions about the assest servers... Could I now run an assest server localy, and allow connections to other grids securing my assest here? Even if I could do this wouldn't it all still boil down to the CIL reaching an unsecure sim? I ask these questions because ealier someone mentioned trusted asset/inventory servers as possible furture solutions. I tried to find more info from past emails, but could not. Thanks again for everyone time answering my questions on this topic. I do appreciate it. I fully understand its impossible to protect data in any format 100% if its ever going to be used outside of a controlled enviroment. -----Original Message----- From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Frisby, Adam Sent: Thursday, March 19, 2009 8:05 PM To: opensim-dev at lists.berlios.de Subject: Re: [Opensim-dev] Couple questions on scripts The short answers here are: - The sims need unencrypted copies of scripts for operations (to compile them, etc). You can pass them the assemblies (compiled results), however CIL (our bytecode language) can be decompiled back to source form with remarkable accuracy (it's at the very least human readable). - So anyone who has a region that is running your scripts could potentially intercept them. - The grid & asset servers don't need unencrypted copies. If you are uploading onto an untrusted grid for use in a trusted subsection, there is the cryptogrid asset provider I wrote a while ago -- however this only works if you trust the region operators who you give the decryption key to. (and of course, you won't be able to use the asset without them having it). It definitely won't be as convenient since you need to provide the keys before rezzing the object, but it might be useful if you want to say run some private scripts on a region you self-host on OSGrid.org, and don't want the osgrid team getting a copy. Adam > -----Original Message----- > From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev- > bounces at lists.berlios.de] On Behalf Of Skidz Tweak > Sent: Thursday, 19 March 2009 12:43 PM > To: opensim-dev at lists.berlios.de > Subject: Re: [Opensim-dev] Couple questions on scripts > > That's very interesting. I like the idea of trusted asset/inventory > servers. > I will look through the past emails for more information on that > project > aspect. Thanks. > > -----Original Message----- > From: opensim-dev-bounces at lists.berlios.de > [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Melanie > Sent: Thursday, March 19, 2009 2:23 PM > To: opensim-dev at lists.berlios.de > Subject: Re: [Opensim-dev] Couple questions on scripts > > Hi, > > basically, to answer "yes" to your question #1, ALL of the following > must be true: > > - The grid must be owned and operated by a single entity > - Said entity must have a TOS, statement and/or track record of > respecting content creators' rights > - No outside regions can connect > - No outside persons can access the shell or database of the grid > > It would be up to you to determine whether you trust the operator of > the grid. Currently a few such grids exist. > > Generally, if a grid allows outside connections or Hypergridding, it > is not safe. > > However, hypergrid is moving towards a safe way to distribute > content from authenticating asset/inventory servers. Eventually this > may lead to signed binary assemblies being passed around the > simulators, with the region operators trusting the certificates. > However, this will likely not prevent retention of copies of the > goods, so the above points about trusting the operators still apply. > Even though your script source code can't be stolen in this future > scenario, permissions as we know them today could easily be > circumvented. > > Melanie > > > Skidz Tweak wrote: > > Hi all, I finally set up a openSim of my own, and its working great. > The > > development community in this project has done an outstanding job so > far > > (based on my own experiences). > > The setup process was easy, so easy I over complicated it by creating > the > > database tables and such myself prior to running it causing some > problems > :) > > > > I just had a couple questions: > > 1. Are scripts safe on other grids? I get a number of request to move > my > > tools into other grids. > > And what I mean by safe is, people can't steal them. > > 2. I am guessing the real answer to question number 1 is no, so... > Has > there > > been any effort in the direction of maybe a different way to > distribute > > items on the new grids? > > For example, I could imagine an install package for a sim, or > grid > > that could ensure purchase in an encrypted maner with a cert or > something. > > > > Just some thoughts and thx for your time. > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: "The 3D Internet Focus Area will look at ways in which 3D visualization and immersive environments such as Second Life are changing the way we communicate, share information, educate students and explore scientific problems. "'The Internet changed the way we share information and the 3D Internet will change the way we relate to each other in fundamental ways,' said John Hengeveld, a business strategy manager at Intel and chair of the 3D Internet Focus Area. 'These graphically rich 3D worlds require a host of HPC resources, and they could forever change education and how people come to understand scientific concepts.' "Submissions for most areas of the SC09 technical program will be accepted beginning March 16. Technical paper abstracts are due April 3 and final papers as well as submissions for tutorials, workshops and panels are due April 6." SC09 will be November 14-20, 2009 in Portland, Oregon, USA. http://sc09.supercomputing.org/ -Coyle [1] -- What's SC09? "SC09, sponsored by the ACM (the Association for Computing Machinery) and the IEEE Computer Society, offers a complete technical education program and exhibition to showcase the many ways high performance computing, networking, storage and analysis lead to advances in scientific discovery, research, education and commerce. This premier international conference includes a globally attended technical program, workshops, tutorials, an exhibit area, demonstrations and hands-on learning. From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: Key benefits * Faster and cheaper accommodation of existing systems. * Increased flexibility; easier to change as requirements change. * Standards-based. * Scales from point solutions to enterprise-wide deployment (distributed bus). * Predefined ready-for-use service types. * More configuration rather than integration coding. * No central rules engine, no central broker. * Incremental changes can be applied with zero down-time; enterprise becomes "refactorable". Key disadvantages * Enterprise Message Model is usually required, resulting in additional management overhead. May not be a simple task to achieve many disparate systems collaborating on message standards. * Requires ongoing management of message versions to ensure the intended benefit of loose coupling. Incorrect, insufficient, or incomplete management of message versions can result in tight coupling instead of the intended loose coupling. * It normally requires more hardware than simple point to point messaging. New skills needed to configure, manage, and operate an ESB. * Extra overhead and increased latency caused by messages traversing the extra ESB layer, especially as compared to point to point communications. The increased latency also results from additional XML processing, as the ESB normally uses XML as the communication language. * Some critics remark that ESB require a significant effort to implement, but produces no value unless SOA services are subsequently created for the ESB.[1] -------------------------------- Regards Teravus On 3/24/09, doug.lundin at gmail.com wrote: > All, > Suspect the notion of using an ESB with OpenSim would be seen as a feature request. But, am curious if anyone has thought about such an infrastructure approach and pros/cons for this project. How might it relate to the Grid? > Would be interested in hearing your thoughts. > Doug > Sent via BlackBerry by AT&T > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: any point that a uuid isn't the right thing for an asset, we can handle schema changes on MSSQL without too much hassle. MSSQL has a native unique identifier data type, so it was daft not to use it when we use uuids throughout the code - faster indexing and more efficient data storage. Migrating most of a database didn't take long, but the assets took a very long time to migrate since we have a >5Gb database of mostly assets at ReactionGrid now. -----Original Message----- From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Justin Clark-Casey Sent: 27 March 2009 14:59 To: opensim-dev at lists.berlios.de Subject: Re: [Opensim-dev] RFC: Ways of creating profiles for creators who will never log in Oh, now that is a most excellent idea, Stefan - one that I think is much better than copying and inserting profiles. And I even think it could be made to work with the current architecture. I think that it will need user ID fields in the database to be made much larger than the current char(36) limits for=20 UUIDS (I'd like to know how this affects MSSQL), so I would probably need to do that unless there are any comments. I shall seriously think about this and take this approach rather than the profile copying I was suggesting unless there=20 are any major pragmatic obstacles. Thanks! Stefan Andersson wrote: > Justin, > =20 > whilst you're at it, could you have a look at the feasabilty of just=20 > adding the url to the user profile on the user service on the=20 > originating grid? > =20 > We should try to move from guid/local to url/global in everything we do,=20 > even if in babysteps. > =20 > If we could let the user server serve a controlled subset of the user=20 > profile to the world, that could be used for preserving a link to the=20 > original creator. >=20 > So, instead of having creator=3D and then have to re-create that=20 > profile locally, we could have=20 > creator=3Dhttp://users.osgrid.org/users/justincc/ >=20 > Best regards, > Stefan Andersson > Tribal Media AB >=20 >=20 >=20 > =20 > > Date: Thu, 26 Mar 2009 21:00:16 +0000 > > From: jjustincc at googlemail.com > > To: opensim-dev at lists.berlios.de > > Subject: [Opensim-dev] RFC: Ways of creating profiles for creators=20 > who will never log in > > > > Hello, > > > > For Inventory Archives I plan to preserve item creator information. > When the archive is loaded I would like to recreate > > these profiles where possible/necessary (grid operators can choose=20 > not to allow this and that will be the default, I > > expect). > > > > However, unless an item creator has an account on the OpenSim to=20 > which the archive is loaded, they shouldn't be able to > > login to that instance. > > > > So far I've thought of 3 ways to create a profile without=20 > automatically allowing login. > > > > > > (1) Create a normal user account but set the password to something=20 > random. > > > > PROS > > * Doesn't require any changes to what we have today > > > > CONS > > * Creates user accounts which are never intended to be used for login > > * No way to distinguish archive created accounts from legitimate accounts > > ~~~~~ > > > > (2) Add a 'ProfileOnly' flag to the Users table > > > > PROS > > * Minimal changes to what we have today > > * Makes it clear that an entries has been created for its profile=20 > only, which can be used as a flag to disallow logins > > > > CONS > > * Creates user accounts where many details will be irrelevant unless=20 > item creators then get accounts on the instance. > > * Complicates administration tasks (e.g. create user). > > ~~~~~ > > > > (3) Separate the current 'users' table into 'userprofiles' and=20 > 'users' tables. > > > > 'userprofiles' will largely contain all the metadata about a user=20 > that you can see in the profile on the Linden Labs > > Second Life client today (name, about, interests, 1st life, etc.). > > > > 'users' will contain the data associated with a particular account=20 > (passwordHash, passwordSalt, homeRegion, > > homeLocationX, etc.) > > > > PROS > > * Makes it possible to create user profiles without creating user=20 > accounts. > > * Makes it possible to have somewhat separate profile and=20 > authentication plugins allow mix & match. However, the reuse > > of avatar name as the login identifier makes things a bit awkward. > > * Simplifies database understandability - the only people in the=20 > 'users' table are those with actual accounts, though on > > the other hand this does create 2 tables instead of 1. > > > > CONS > > * Short term adjustment pain for systems accessing OpenSim's=20 > databases directly > > * Complicates administration tasks (e.g. create user). > > ~~~~ > > > > I suspect that archiving isn't the only potential use for this=20 > functionality. For instance, the Hypergrid may also find > > it useful to preserve user information when a user rezzes an object > on a foreign system. > > > > Of the above approaches, I prefer (3) over (2) since it seems to me > to be the better long term approach even if there is > > some short term pain. I'm don't think that (1) is a good option. > > > > I've reproduced most of text at=20 > http://opensimulator.org/wiki/Creating_profiles_not_used_for_login for > reference. > > > > Comments? > > > > -- > > justincc > > Justin Clark-Casey > > http://justincc.wordpress.com > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev >=20 >=20 > ------------------------------------------------------------------------ >=20 > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev --=20 justincc Justin Clark-Casey http://justincc.wordpress.com _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev No virus found in this incoming message. Checked by AVG - www.avg.com=20 Version: 8.0.238 / Virus Database: 270.11.29/2023 - Release Date: 03/26/09 20:05:00 From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: 395 was about the most recent quite stable revision. If there is agreement = on that or another revision then I'll tag/branch it as a 0.6.5RC.
> <= br>> --- On Fri, 15/5/09, diva at metaverseink.com <= ;diva at metaverseink.com&= gt; wrote:
>
> From: diva at metaverseink.com <diva at metaverseink.com>
> Subject: [Open= sim-dev] WARNING: r9562 may break things
> To: "opensim-dev at lists.berlios.de" <opensim-dev at lists.berlios.de>
> Date: Friday, 15 May, 2009= , 6:23 AM
>
> Everyone --
> Just a warning to please sta= y away from head, starting in r9562, for the
> next couple of days u= nless you really really really want to help test
> things. We starte= d replacing the services to the new service model that
> was discussed here a few w= eeks ago, staring with the asset service. For
> starters, there are = new configuration variables in OpenSim.ini that you
> need to get ac= quainted with -- see the OpenSim.ini.example at the
> bottom. But un= less you really need to be in head, don't; please wait at
> least 24= hours.
>
> Melanie --
> The transplant is mostly done. = See commit message for the things that
> are borked. Also note, I ch= anged the config var you had called "Modules"
> to "ServiceConnector= s", you probably need to change your local .ini.
> Talk to you tomorr= ow.
> _______________________________________________
> Opensim= -dev mailing list
> Opensim-dev at lists.= berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> >
>
>       
>
> <= br>> -------------------------------------------------------------------= -----
>
> _______________________________________________
&= gt; Opensim-dev mailing list
> Opensim= -dev at 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

=0A=0A=0A=0A --0-1048744743-1242395963=:66058-- From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: 2009/5/25 Stefan Andersson > All, > > as of fifteen minutes ago, I just back-tagged 0.6.5-release, and > subsequently turned 0.6.5-rc1 into 0.6.5-post-fixes. > > This release is essentially based on trunk rev 9561, which has gotten som= e > good review - plus version number bumping and some aplied minor fixes. > > This is the last release to support Visual Studio 2005. > > I will now upgrade trunk to reflect our current version as 0.6.5. (we don= 't > up trunk until we know we have a proper release) > > Tomorrow, I will also put into place a little mechanism to be able to > specify "trunk", "rc1" or "release" in the version info. > > Happy 0.6.5 everybody! > > Best regards, > Stefan Andersson > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > --001636c5b91ecbef89046abb6e98 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=BFPerhaps a Happy Release Party? ;-D
=A0
From one of the suffered testers, =A1 thanks a lot for your great work= !

2009/5/25 Stefan Andersson <= ;stefan at tribalmedia.se>
All,
=A0
as of fifteen minutes ago, I just back-tagged 0.6.5-rel= ease, and subsequently turned 0.6.5-rc1 into 0.6.5-post-fixes.
=A0
Th= is release is essentially based on trunk rev 9561, which has gotten some go= od review - plus version number bumping and some=A0aplied minor=A0fixes. =A0
This is the last release to support Visual Studio 2005.

I wil= l now upgrade trunk to reflect our current version as 0.6.5. (we don't = up trunk until we know we have a proper release)
=A0
Tomorrow, I will= also put into place a little mechanism to be able to specify "trunk&q= uot;, "rc1" or "release" in the version info.
=A0
Happy 0.6.5 everybody!

Best regards,
Stefan Andersson
<= br>


_______________________________________________
Ope= nsim-dev mailing list
Op= ensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

<= /blockquote>

--001636c5b91ecbef89046abb6e98-- From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: objects in memory and increasing memory usage. This may be causing portions of memory to swap out where they may not have before. When retrieving the asset, it would need to swap it back in and it may have to do it in several steps in order to locate the asset. This may cause further delay as it may have to swap other memory out to make space. It would seem likely that a file based cache may perform better as the filename might provide a more direct route to the actual cache data. I suspect that the operating system may also allow searching directories for a filename fairly quickly - modern file systems are quite efficient these days. This is really just a guess... I suspect some benchmarking and profiling of several systems of different configurations may be necessary to determine what the bottleneck really is. On Tue, May 26, 2009 at 3:52 PM, wrote: > I noticed we have GlynnTucker.Cache.dll in the distribution, and this > wasn't being used. I have no idea what the story is, but since it's > there, I did one alternative cache module implementation using it, just > to see what happens. Since everything is modularized now, replacing the > asset cache implementation is as simple as editing your XXXCommon.ini > and changing the name: > > ;AssetCaching = "CoreAssetCache" > AssetCaching = "GlynnTuckerAssetCache" > > I would still urge that someone figures out what's wrong with > OpenSim/Framework/Cache.cs, which is the one used in CoreAssetCache. > > The GlynnTuckerAssetCache has been tried in the UCI Grid and in some > sims in OSGrid and at least it's not being an anti-cache. Let's wait a > few more days to see if it's being a real cache; if so we should see > declines on the traffic to the asset servers :-) > > Arthur Valadares wrote: > > If we ran a profiling with this cache maybe we could see where the > > bottle neck is, couldn't we? > > > > Mono has simple statistical profiler that shouldn't be too intruding: > > > > $ mono --profile=default:stat program.exe > > > > If anyone who saw this performance loss could test this, would be > > interesting to see where it's spending all this extra time. > > > > On Tue, 2009-05-26 at 10:57 -0700, diva at metaverseink.com wrote: > >> Just a quick note to inform everyone that word from osgrid folks > >> indicates that the asset cache is still borked and still a mystery. When > >> it is on, CPU usage spikes to unsustainable values (150% with 4 avies in > >> WP). > >> > >> If anyone cares to take a look at it / replace it with something else, > >> please do. > >> > >> OpenSim/Framework/Cache.cs > >> _______________________________________________ > >> Opensim-dev mailing list > >> Opensim-dev at lists.berlios.de > >> https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > --0016364ee01c638db7046ae1d243 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: objects in memory and increasing memory usage. This may be causing portions= of memory to swap out where they may not have before. When retrieving the = asset, it would need to swap it back in and it may have to do it in several= steps in order to locate the asset. This may cause further delay as it may= have to swap other memory out to make space. It would seem likely that a f= ile based cache may perform better as the filename might provide a more dir= ect route to the actual cache data. I suspect that the operating system may= also allow searching directories for a filename fairly quickly - modern fi= le systems are quite efficient these days.

This is really just a guess... I suspect some benchmarking a= nd profiling of several systems of different configurations may be necessar= y to determine what the bottleneck really is.

On Tue, May 26, 2009 at 3:52 PM, <diva at metaverseink.com> wrote:
I noticed we have GlynnTucker.Cache.dll in the distribution, and this
wasn't being used. I have no idea what the story is, but since it's=
there, I did one alternative cache module implementation using it, just
to see what happens. Since everything is modularized now, replacing the
asset cache implementation is as simple as editing your XXXCommon.ini
and changing the name:

;AssetCaching =3D "CoreAssetCache"
AssetCaching =3D "GlynnTuckerAssetCache"

I would still urge that someone figures out what's wrong with
OpenSim/Framework/Cache.cs, which is the one used in CoreAssetCache.

The GlynnTuckerAssetCache has been tried in the UCI Grid and in some
sims in OSGrid and at least it's not being an anti-cache. Let's wai= t a
few more days to see if it's being a real cache; if so we should see declines on the traffic to the asset servers :-)

Arthur Valadares wrote:
> If we ran a profiling with this cache maybe we could see where the
> bottle neck is, couldn't we?
>
> Mono has simple statistical profiler that shouldn't be too intrudi= ng:
>
> $ mono --profile=3Ddefault:stat program.exe
>
> If anyone who saw this performance loss could test this, would be
> interesting to see where it's spending all this extra time.
>
> On Tue, 2009-05-26 at 10:57 -0700, diva at metaverseink.com wrote:
>> Just a quick note to inform everyone that word from osgrid folks >> indicates that the asset cache is still borked and still a mystery= . When
>> it is on, CPU usage spikes to unsustainable values (150% with 4 av= ies in
>> WP).
>>
>> If anyone cares to take a look at it / replace it with something e= lse,
>> please do.
>>
>> OpenSim/Framework/Cache.cs
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensi= m-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
>> https://lists.berlios.de/mailman/listin= fo/opensim-dev
>
> ----------------------------------------------------------------= --------
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berl= ios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.d= e
https://lists.berlios.de/mailman/listinfo/opensim-dev

--0016364ee01c638db7046ae1d243-- From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: say you have good chances to get things done nicely here. Although I = don't agree on all your opinions (read: OpenID, OAuth), sometimes = someone has to implement things *when and *how she thinks it is right = without political constraints to make an impact. After all someone could think about paying you for your work. At least a = bit more than a hippo and a missing free t-shirt. -----Urspr=FCngliche Nachricht----- Von: opensim-dev-bounces at lists.berlios.de im Auftrag von Cristina = Videira Lopes Gesendet: Mi 03.06.2009 21:37 An: opensim-dev at lists.berlios.de Betreff: [Opensim-dev] OGPX and IETF-ing things [text] =20 Inifinity sent me a very nice private message, which, because it was =20 private, I'm not going to forward here. But the bottom line of his =20 nice message could use some public discussion. Essentially Infinity =20 is suggesting that we move towards getting the Hypergrid work into =20 the IETF, through this newly created OGPX working group. Personally, I think this is all premature. IETF-ing the Hypergrid is =20 premature for different reasons than IETF-ing OGP is premature. The =20 Hypergrid is not really ready for prime time until we have the =20 Hypergrid2 in place, with its security model to protect users from =20 malicious simulators. OGP is not ready for prime time because no one =20 has seen it yet, at least not any reasonably complete implementation =20 of it. The right thing to do, I think, is to first have implementations of =20 both OGP and the Hypergrid2 in OpenSim. Once that is in place, we can =20 all see the similarities and differences, and try to standardize the =20 similar pieces. Alternatively, we can try to work together towards =20 one single interop protocol, but honestly I think that's not going to =20 happen, simply because there is space for many (not just 2, but 3 or 4) What I suspect will happen is that OGP and the Hypergrid will have =20 several pieces that are very much in sync, with small details that =20 are different, and then they will have a few really important pieces =20 that are substantially different. Things like posting/retrieving =20 agents to/from regions, for example, we already converged to using =20 REST; inventory access, we already converged to using capability =20 URLs, etc. Small details such as the format of the data on the wire =20 are different, but that doesn't really matter as long as we agree =20 that the Content-type can be set to different things. The thing that will be substantially different is the issue of =20 authority: what component has authority to do what. In OGP regions =20 are still the ones doing agent transfers, therefore implying a trust =20 relation between interacting grids that must be established in some =20 non-technical manner (i.e. the receiving region trusts that the =20 sending region is not stealing the user's identity). In the =20 Hypergrid, agent transfers between non-trusting regions are done on =20 the client side, so that the identity of the user can always be =20 verified, there is no region in the middle acting on behalf of anyone. So, that's the main difference, as far as I understand OGP. The Hypergrid2 is in place through a proof-of-concept prototype =20 client (Grider) and a couple of small but horrible hacks in OpenSim. =20 OGP implementations don't exist yet, or they are not available to us =20 which is the same. I think there's a lot of work to do before we go =20 and propose any of this as standards. But I thought I'd bring this up for discussion. Maybe other people =20 aren't as strict on working implementations as I am. Crista _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ------_=_NextPart_001_01C9E488.83096C2A Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IjUUAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAMgAAAEFXOiBbT3BlbnNpbS1kZXZd IE9HUFggYW5kIElFVEYtaW5nIHRoaW5ncyBbdGV4dF0AnxABBYADAA4AAADZBwYAAwAWABIAHwAD ADMBASCAAwAOAAAA2QcGAAMAFgASADQAAwBIAQEJgAEAIQAAADEyODAzQjcyMzQyQzhCNEM5RDIz RjMyRUU0NjBFNjk4ABMHAQOQBgDwEAAAOQAAAAMAJgAAAAAAAwA2AAAAAABAADkAhWppdojkyQEe AD0AAQAAAAUAAABBVzogAAAAAAIBRwABAAAALwAAAGM9REU7YT0gO3A9Yml0bGFiO2w9SEVSTUVT LTA5MDYwMzIwMTg1MlotMjUyODYAAB4ASQABAAAALgAAAFtPcGVuc2ltLWRldl0gT0dQWCBhbmQg SUVURi1pbmcgdGhpbmdzIFt0ZXh0XQAAAEAATgAAwgjLguTJAR4AWgABAAAAJQAAAG9wZW5zaW0t ZGV2LWJvdW5jZXNAbGlzdHMuYmVybGlvcy5kZQAAAAACAVsAAQAAAGcAAAAAAAAAgSsfpL6jEBmd bgDdAQ9UAgAAAABvcGVuc2ltLWRldi1ib3VuY2VzQGxpc3RzLmJlcmxpb3MuZGUAU01UUABvcGVu c2ltLWRldi1ib3VuY2VzQGxpc3RzLmJlcmxpb3MuZGUAAAIBXAABAAAAKgAAAFNNVFA6T1BFTlNJ TS1ERVYtQk9VTkNFU0BMSVNUUy5CRVJMSU9TLkRFAAAAHgBdAAEAAAAXAAAAQ3Jpc3RpbmEgVmlk ZWlyYSBMb3BlcwAAAgFeAAEAAABGAAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAAQ3Jpc3RpbmEg VmlkZWlyYSBMb3BlcwBTTVRQAGxvcGVzQGljcy51Y2kuZWR1AAAAAgFfAAEAAAAXAAAAU01UUDpM T1BFU0BJQ1MuVUNJLkVEVQAAHgBmAAEAAAAFAAAAU01UUAAAAAAeAGcAAQAAACUAAABvcGVuc2lt LWRldi1ib3VuY2VzQGxpc3RzLmJlcmxpb3MuZGUAAAAAHgBoAAEAAAAFAAAAU01UUAAAAAAeAGkA AQAAABIAAABsb3Blc0BpY3MudWNpLmVkdQAAAB4AcAABAAAALgAAAFtPcGVuc2ltLWRldl0gT0dQ WCBhbmQgSUVURi1pbmcgdGhpbmdzIFt0ZXh0XQAAAAIBcQABAAAAGwAAAAHJ5IOTZoUSPUKWfEUA s00+TXvO/dAAATjA8wAeAHQAAQAAAB0AAABvcGVuc2ltLWRldkBsaXN0cy5iZXJsaW9zLmRlAAAA AB4AGgwBAAAADAAAAERpcmsgS3JhdXNlAB4AHQ4BAAAALgAAAFtPcGVuc2ltLWRldl0gT0dQWCBh bmQgSUVURi1pbmcgdGhpbmdzIFt0ZXh0XQAAAAIBCRABAAAAfwkAAHsJAAAXEQAATFpGdRvKF18D AAoAcmNwZzEyNeIyA0N0ZXgFQQEDAfdPCoACpAPjAgBjaArAc/BldDAgBxMCgA/zAFB/BFYIVQey EcUOUQMBEMcy9wYABsMRxTMERhDJEtsR09sI7wn3Oxi/DjA1EcIMYM5jAFALCQFkMzYRUAumJCBG A2EgeQhhIHQycgDQayAYwAWhZCCCdgSQeSB3ZWwDIHBkb2N1B4ACMAmAIOsLgB4gaAQAIADAAxAL gARnICEAc3QsIEmyJx7gc2EfMB3hIBDwUR8AIGdvBHAgEOFu8mMHkXRvIrARMCByISC7BCAfoG4i oAMAI1BsHzDSaASQZS4RYGwggAhgrGdoIaAkYicFQGEJwp4gAiAmkB9xHeNvcAuAFmkCIAQgKBjA YWQ6SCBPcAnwSUQhkE/UQXUggCkhkHMDcBEwfwdzKcIkghDwI3MHcAtQZbMf4iP2KnclMCcRbh7g tiolwAfgcyUwI/NrBCD+aQVAIKEFECXwBUAD8CWy/QVAcAbwLgAN4AdAIwAoEdseMQuAdCNzAMBr IqADkXMrUQDQdC4KogqECoBBnwGAEyEnMipmBaB1bB7g/y2TJpAG4C8SIgAhEiIyAhDrBcAd43cF sGslcQVAK4DzKvAmgSBiLgEEYBjAIHF3A5E28CCQcC9ALLM28G1PBAEhEgNQJtF0LS1QaVcAIDG7 McQtO0JVERBw+HJcJxDQISAhABDgIqD6TgDQaAUQEOA5oDtCMcQ+VgIgKKAnwAnwAJBtLVkBAHYt NHEjQkAhUnPsLmIEkCEAbz+wAQArQV0RYHUBgB5AITB2JwFDzwUQIXALgDbwVmkBADng3TbwTD4x ELAx00cHkAnwBQEAdCigTWkgMDMQLjA2LgHQMDkg4DIxOjM3MiU+DD9vvTHEQhEwGMABICigWyjC RT51XSiwR1BYLLNJsEVURi0hEiQFWw6yrl0xxArjCoBJAwBmJ+H+dB8wQ1E3MTEBHvQkwi8weQUQ dmEOsEzRBBAmoGW/IZAscDxRIZA/0C+gdREgfS3ydyrxS4VN1SGSHcBu/m8FQCLAShMjoDVxUAAe 0f0lNEIvESCAIqAG4AJAHbH7IQEm4WY4AVAnTYNOVTOV90+SKcIvMHUCYA3gH5AEAO8fwDjxAiAl cEUEEB/xBzHfJQFL8EwlS4UgoXMl4CPA/0GiSjJOEB9BN0EikSOQUoJPBCAjwVqVIqBIeSjQcv8J wEIQNfMgQSORS4VTcknCvyGQIIADYCXiIIMkkHclAf8FAChwIBJJMzYCIRIJwAhg+nAxu1AEkCnA QdBYwSGR/zP1IIMgoScyO8ArkE4QCHD/JWFJyVzaVLhk5zVjV4ABIP8lQSvBKGFjESNxN7JJx0kx +y4iZOlULWFLhWZrUYIoYf9YwihiHzA1ck3RTOEqAlZw/1iBAyBbMSJzU3Jr7hTgIFH/C1EjUE7B LtEt8SpBBZAIcf9MYQRiAyAjkTvAUZAFkAVA/0+RERA5QR2xS4UAwDxBKAD/T5Ah4AdwM8BOEAWw P7Bqdv9tJW4PT0dRgCbxcCcq4hEg+yyRLgF5ETAhkFsBNpRRgv8AcG2zYxICYGBRA3ArcU4h/ytX ThAoAVA2VHEuADG7a6L/LmQkAyOCH6BjhyGQIKFSIv854DbBInN9fAQgVHFLhVOxvyYAaoIswly7 cUMowlMHcP92kSNBWtRkQnF4M4EDkUuF/zLjOXItYT5xAxAKwC9xB5H/LMJohiNRewGFQh8hI5Eh cPMswQsRaXpv64o1LzAIkP8jUSVzBJF+AR8AY2KIlYxV/12TI5AjwSUxW6d+ZiSROQL/K4Bd0gSQ J8Bzox+wBvBPMX8vESXAJJAhcFjSY7dOECf/bQRRx3mnODAJ8CmhK1IfMP9PVpGSQGEqQTFxaCQD gR8wWihRgmpPkAVAMpSEM9Mm8AXANCkxylda8iYg/1owO7Bz8gPwH3GXpIHjWvL/hP9dRJ3UIpGN xj7ABJAvsf+OtFrUCsAioB8DdhAQ4CBC7HN5I0Bx5XN1UR+BETD/IOGelYkGN3Foh4v1LIJTcf8f MaB3NvBosAfgbWUrURhhvwBwLyGiBF43ooVaMGKMwv9YlWiHa4IkIyEAMPEvQFqD7i8YwB4wCJB2 IRKJBiPA7TBkL3STGMBnKAIhkDVy/Q7AYStiiHMHQHdkL+EfAR8jwDPhI6BPkK6pUkVT/FQ7IEEf AF3xHyEA0CNR/4vhsa+yuy+gCrA3EC9hWXdYVVJMi+ERMGMlcFP/pItaMKNhKvItYTVxZRFUYv9T co0AAZAm8lNyA/A3caWv/6azlKJa4x+gB5AmYm1lZRH/MqOtQQIgITAq8bVyJrOqau9TcghQIAEC MC1MYCjQiLP/P9BMgSPhgQFolyQEfy+Alf9a853Sw1Krf2jEnoOZUlow/1RTiQYpYQWwTFEooCxw WwH/fOIkgSvBKuLKJ4DkysNlcf+GcWqRsEW8qkGhH3FTcpTy/x+RIRKvUx4iAIBosYvhmRP/NXF9 VDTjNvAeMJryS4UYwPd2MX4iP9B0H1B6cpOSMYH/YYRCEJ6VdhA2wcNRWnF8kf8EACUwIDNWw1Tm AiDCsAWQPmgkwS+xA4EkkAXAKGn+LiVhU3IekUIwrpOwRNKk/56VjYpDYdqJbPUhcG1xZebfdDKW MUIRWIFMYCnNQ3AP/11RewHQbNQH2DPSwtqIZIHvpiIkgn44U3JjIQArsgCQ/wEAKaLbmN9GuyZ0 MoizB0D9UAB54mJQNh8BTBEJgNFFz2zk3Re8BDjQZGSTUdTl+9PjEPBsVIBUcXvxJIExu/5TgTGV 9evzC3GLOXsBdHH/CsEq8SYgPxAEgYzDSSLE/79wuofYXzc28HOxVHAt9gF/L+EjUAUxlAPCw0uF 5cUo9kddUQSQKThlM6ErcVRi+6R0lKRyBRACYCrCHmCH0/+Gl0uFaoODHSZEDsAhYXrE/wWxp5Oi snuzTgCKYfrisvP/UDZO48imIfAHgGVxY7clQf+WMTbwGFC7E5EFzMI/0NGz/1sxIsCI9yzRc7Gt sTEC58X/ZHIqQYzVxOxTMmOiJdKdAf0hwWJBgEokZIBh8Gg1V6j+TSIA6VGEsRMhKNAnwJNR/7y4 JmMHsjzhuxE30GFGgw6v8YOxMDG7QXNhMcpfEv//FA8U2vxVPkggyxXvRl95tUG/sHBzOi8vP34v 3yDS2REas0HAaEAvPjkxygJ9HmAAHgA1EAEAAAA8AAAAPDcyQzFDOUU1NzgwQTEzNEY4OTY1MzBE NDgwRjIyQkI3MDIxNDJCM0FAaGVybWVzLmJpdGxhYi5kZT4AHgA5EAEAAAAzAAAAPEQ4RThFMzE2 LTJCRjAtNENFNS1CRjVGLTE0OEE5MUJEQjY4MUBpY3MudWNpLmVkdT4AAB4ARxABAAAADwAAAG1l c3NhZ2UvcmZjODIyAAALAPIQAQAAAB8A8xABAAAAcAAAAEEAVwAlADMAQQAgAFsATwBwAGUAbgBz AGkAbQAtAGQAZQB2AF0AIABPAEcAUABYACAAYQBuAGQAIABJAEUAVABGAC0AaQBuAGcAIAB0AGgA aQBuAGcAcwAgAFsAdABlAHgAdABdAC4ARQBNAEwAAAALAPYQAAAAAEAABzATp2R2iOTJAUAACDDy eRyDiOTJAQMA3j+vbwAAAwDxPwcEAAAeAPg/AQAAAAwAAABEaXJrIEtyYXVzZQACAfk/AQAAAEcA AAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089QklUTEFCL09VPUJJVExBQi9DTj1SRUNJ UElFTlRTL0NOPURJUktLAAAeAPo/AQAAABUAAABTeXN0ZW0gQWRtaW5pc3RyYXRvcgAAAAACAfs/ AQAAAB4AAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAALgAAAAMA/T/kBAAAAwAZQAAAAAAD ABpAAAAAAAMAHUAAAAAAAwAeQAAAAAAeADBAAQAAAAYAAABESVJLSwAAAB4AMUABAAAABgAAAERJ UktLAAAAHgAyQAEAAAAlAAAAb3BlbnNpbS1kZXYtYm91bmNlc0BsaXN0cy5iZXJsaW9zLmRlAAAA AB4AM0ABAAAAEgAAAGxvcGVzQGljcy51Y2kuZWR1AAAAHgA4QAEAAAAGAAAARElSS0sAAAAeADlA AQAAAAIAAAAuAAAAAwB2QP////8LACkAAAAAAAsAIwAAAAAAAwAGEKBtVGgDAAcQowsAAAMAEBAA AAAAAwAREAAAAAAeAAgQAQAAAGUAAABGUk9NWU9VUlRSQUNLUkVDT1JEVkVSWVdFTExET0NVTUVO VEVESU5USElTTUFJTElOR0xJU1QsSURTQVlZT1VIQVZFR09PRENIQU5DRVNUT0dFVFRISU5HU0RP TkVOSUNFTFlIAAAAAAIBfwABAAAAPAAAADw3MkMxQzlFNTc4MEExMzRGODk2NTMwRDQ4MEYyMkJC NzAyMTQyQjNBQGhlcm1lcy5iaXRsYWIuZGU+APxM ------_=_NextPart_001_01C9E488.83096C2A-- From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: /// /// Inventory Item Types, eg Script, Notecard, Folder, etc /// public enum InventoryType : sbyte { /// Unknown Unknown = -1, /// Texture Texture = 0, /// Sound Sound = 1, /// Calling Card CallingCard = 2, /// Landmark Landmark = 3, /* /// Script //[Obsolete("See LSL")] Script = 4, /// Clothing //[Obsolete("See Wearable")] Clothing = 5, /// Object, both single and coalesced */ Object = 6, /// Notecard Notecard = 7, /// Category = 8, /// Folder Folder = 8, /// RootCategory = 9, /// an LSL Script LSL = 10, /* /// //[Obsolete("See LSL")] LSLBytecode = 11, /// //[Obsolete("See Texture")] TextureTGA = 12, /// //[Obsolete] Bodypart = 13, /// //[Obsolete] Trash = 14, */ /// Snapshot = 15, /* /// //[Obsolete] LostAndFound = 16, */ /// Attachment = 17, /// Wearable = 18, /// Animation = 19, /// Gesture = 20 } On Wed, 15 Jul 2009 22:56:07 -0400, "Frisby, Adam" wrote: > Does anyone know what the values of InventoryItems.InvType represent? It's > an integer and represents the type of inventory; but I cant seem to find > any documentation (either in code, or externally) about what the integers > correlate to. > > Adam > -- Jim !DSPAM:370,4a5e9ed719051028312470! From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: inventory to me - we did until recently have some lost assets after SI = sessions due to asset server crashing - previously the code would = attempt to store assets with descriptions bigger than database field = length. This seemed to happen mostly with SI uploaded items but also was = 100% reproducible if you had a sim with a long name and a parcel with a = long name and attempted to create a landmark - there are checks now to = stop this from happening that Justin kindly committed (and he was good = enough to add similar checks for MySQL) and we've not had a crash since = applying that patch over a week and a half ago. In terms of actual = inventory, no-one has reported loss of specific items. Sometimes slow to = load, but not loss. Is this something that has happened since 0.6.6 tag? Chris -----Original Message----- From: opensim-dev-bounces at lists.berlios.de = [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Melanie Sent: 27 July 2009 14:32 To: opensim-dev at lists.berlios.de Subject: Re: [Opensim-dev] Inventory loss Those MySQL issues listed below and others like it are corner cases=20 that OpenSim would never trigger. OpenSim is a very simplistic=20 database user, it doesn't even really use any relational features of=20 the database. So, I don't think that MySQL errors are something we need to concern=20 ourselves with at this point. Especially, your suggestion would not=20 help in those cases, as they are all about complete loss of rows.=20 That is unaffected by a "deleted" type flag. That is neither here nor there anyway, since such a "deleted" flag=20 would have to live under OpenSim.Data.XXXX. It has no business being in core at all. Melanie Colin B. Withers wrote: > Reason I wondered is simply the number of websites dedicated to = recovering from MYSQL database corruption, and offering tools for the = same. Google returns over 250,000 sites for 'mysql database corruption'. >=20 > MYSQL has had numerous bug fixes to fix database corruption, = introduced by differing versions of MYSQL, eg >=20 > Fixed in 4.0.18 > INSERT DELAYED ... SELECT ... could cause table corruption because = tables were not locked properly. This is now fixed by ignoring DELAYED = in this context. (Bug #1983)=20 >=20 > Fixed in 4.0.16 > Fixed bug in overrun check for BLOB values with compressed tables. = This was a bug introduced in 4.0.14. It caused MySQL to regard some = correct tables containing BLOB values as corrupted. (Bug #770, Bug = #1304, and maybe Bug #1295)=20 >=20 > Fixed in 4.0.15 > Fixed rare bug in MYISAM introduced in 4.0.3 where the index file = header was not updated directly after an UPDATE of split dynamic rows. = The symptom was that the table had a corrupted delete-link if mysqld was = shut down or the table was checked directly after the update. >=20 > Fixed in 4.0.14 > Comparison/sorting for latin1_de character set was rewritten. The old = algorithm could not handle cases like "s=E4" < "=DFa". See section = 5.6.1.1 German character set. In rare cases, it resulted in table = corruption. >=20 > and so on.. >=20 > My own experience with Opensim is that in the last 12 months there has = been three occasions where residents complained of stuff 'missing' (not = a single resident, but several at once) and a roll-back to the last = database backup cured the problems. >=20 > Rock >=20 > -----Original Message----- > From: opensim-dev-bounces at lists.berlios.de = [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Melanie > Sent: Monday, July 27, 2009 2:07 PM > To: opensim-dev at lists.berlios.de > Subject: Re: [Opensim-dev] Inventory loss >=20 > IMHO, inventory loss due to MySQL errors and/or corruption are below=20 > the radar. > Any losses would occur in OpenSim code, I believe. >=20 > Melanie >=20 > Colin B. Withers wrote: >> I wonder what proportion of inventory items that go astray are the = result of the success/failure of an operation, or are due to database = corruption issues. >>=20 >> Rock >>=20 >> -----Original Message----- >> From: opensim-dev-bounces at lists.berlios.de = [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Melanie >> Sent: Monday, July 27, 2009 12:30 PM >> To: opensim-dev at lists.berlios.de >> Subject: Re: [Opensim-dev] Inventory loss >>=20 >> There is a question here of why inventory loss occurs at all. At=20 >> what stage do we actually lose (as opposed to failing to bump the=20 >> folder serial) inventory items at all, and why? >>=20 >> While a "deleted" flag and an undelete function do make an admin's=20 >> life easier, I believe the real focus should be on the inventory=20 >> code. It will be redesigned anyway and once that happens, I think a=20 >> strong focus needs to be placed on data integrity preservation. >>=20 >> That would then mae the undelete functionality largely unnecessary.=20 >> Current inventory code often doesn't check for success of an=20 >> operation at all. That needs to be revisited. >>=20 >> Melanie >>=20 >> Thomas Grimshaw wrote: >>> Hey folks. >>>=20 >>> Been thinking a lot about inventory loss in OpenSim, something that = I=20 >>> think we should really do as much as possible to avoid. We've been=20 >>> experiencing numerous cases of lost inventory in K-Grid recently. >>>=20 >>> What i'd like to implement, is.. >>>=20 >>> When an item is removed from inventory (deleted, or rezzed if it's=20 >>> no-copy), it is not actually deleted by instead an "available" flag = is=20 >>> set in the inventory database. >>> All inventory queries will check for the flag and thus it will = appear as=20 >>> deleted to the user, but it can be restored easily by an admin if=20 >>> needed. A timestamp should also be set which indicates when the = item=20 >>> was made unavailable, so that routine cleanup can be performed on = items=20 >>> which were made unavailable a long time ago. >>>=20 >>> I wanted to get people's opinons of this before I implemented it in=20 >>> code. Can anyone think of any drawbacks or possible issues? Any = further=20 >>> room for improvement? >>>=20 >>> Cheers >>>=20 >>> Thomas Grimshaw >>> (RemedyTomm) >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>=20 >>>=20 >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >>=20 >>=20 > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev >=20 >=20 _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev No virus found in this incoming message. Checked by AVG - www.avg.com=20 Version: 8.5.392 / Virus Database: 270.13.29/2261 - Release Date: = 07/27/09 05:58:00 From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: t inventory to me - we did until recently have some lost assets after SI se= ssions due to asset server crashing - previously the code would attempt to = store assets with descriptions bigger than database field length. This seem= ed to happen mostly with SI uploaded items but also was 100% reproducible i= f you had a sim with a long name and a parcel with a long name and attempte= d to create a landmark - there are checks now to stop this from happening t= hat Justin kindly committed (and he was good enough to add similar checks f= or MySQL) and we've not had a crash since applying that patch over a we= ek and a half ago. In terms of actual inventory, no-one has reported loss o= f specific items. Sometimes slow to load, but not loss.

Is this something that has happened since 0.6.6 tag?

Chris

-----Original Message-----
From: opensim-dev-b= ounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Mel= anie
Sent: 27 July 2009 14:32
To: opensim-dev at lists.berli= os.de
Subject: Re: [Opensim-dev] Inventory loss

Those MySQL issues listed below and others like it are corner cases
that OpenSim would never trigger. OpenSim is a very simplistic
database user, it doesn't even really use any relational features of the database.
So, I don't think that MySQL errors are something we need to concern ourselves with at this point. Especially, your suggestion would not
help in those cases, as they are all about complete loss of rows.
That is unaffected by a "deleted" type flag.

That is neither here nor there anyway, since such a "deleted" fla= g
would have to live under OpenSim.Data.XXXX.

It has no business being in core at all.

Melanie


Colin B. Withers wrote:
> Reason I wondered is simply the number of websites dedicated to recove= ring from MYSQL database corruption, and offering tools for the same. Googl= e returns over 250,000 sites for 'mysql database corruption'.
>
> MYSQL has had numerous bug fixes to fix database corruption, introduce= d by differing versions of MYSQL, eg
>
> Fixed in 4.0.18
> INSERT DELAYED ... SELECT ... could cause table corruption because tab= les were not locked properly. This is now fixed by ignoring DELAYED in this= context. (Bug #1983)
>
> Fixed in 4.0.16
> Fixed bug in overrun check for BLOB values with compressed tables. Thi= s was a bug introduced in 4.0.14. It caused MySQL to regard some correct ta= bles containing BLOB values as corrupted. (Bug #770, Bug #1304, and maybe B= ug #1295)
>
> Fixed in 4.0.15
> Fixed rare bug in MYISAM introduced in 4.0.3 where the index file head= er was not updated directly after an UPDATE of split dynamic rows. The symp= tom was that the table had a corrupted delete-link if mysqld was shut down = or the table was checked directly after the update.
>
> Fixed in 4.0.14
> Comparison/sorting for latin1_de character set was rewritten. The old = algorithm could not handle cases like "s=E4" < "=DFa"= ;. See section 5.6.1.1 German character set. In rare cases, it resulted in = table corruption.
>
> and so on..
>
> My own experience with Opensim is that in the last 12 months there has= been three occasions where residents complained of stuff 'missing'= (not a single resident, but several at once) and a roll-back to the last d= atabase backup cured the problems.
>
> Rock
>
> -----Original Message-----
> From: opensim-= dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf O= f Melanie
> Sent: Monday, July 27, 2009 2:07 PM
> To: opensim-dev at lists.= berlios.de
> Subject: Re: [Opensim-dev] Inventory loss
>
> IMHO, inventory loss due to MySQL errors and/or corruption are below > the radar.
> Any losses would occur in OpenSim code, I believe.
>
> Melanie
>
> Colin B. Withers wrote:
>> I wonder what proportion of inventory items that go astray are the= result of the success/failure of an operation, or are due to database corr= uption issues.
>>
>> Rock
>>
>> -----Original Message-----
>> From: open= sim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Beha= lf Of Melanie
>> Sent: Monday, July 27, 2009 12:30 PM
>> To: opensim-dev at li= sts.berlios.de
>> Subject: Re: [Opensim-dev] Inventory loss
>>
>> There is a question here of why inventory loss occurs at all. At >> what stage do we actually lose (as opposed to failing to bump the<= br> >> folder serial) inventory items at all, and why?
>>
>> While a "deleted" flag and an undelete function do make = an admin's
>> life easier, I believe the real focus should be on the inventory >> code. It will be redesigned anyway and once that happens, I think = a
>> strong focus needs to be placed on data integrity preservation. >>
>> That would then mae the undelete functionality largely unnecessary= .
>> Current inventory code often doesn't check for success of an >> operation at all. That needs to be revisited.
>>
>> Melanie
>>
>> Thomas Grimshaw wrote:
>>> Hey folks.
>>>
>>> Been thinking a lot about inventory loss in OpenSim, something= that I
>>> think we should really do as much as possible to avoid. We'= ;ve been
>>> experiencing numerous cases of lost inventory in K-Grid recent= ly.
>>>
>>> What i'd like to implement, is..
>>>
>>> When an item is removed from inventory (deleted, or rezzed if = it's
>>> no-copy), it is not actually deleted by instead an "avail= able" flag is
>>> set in the inventory database.
>>> All inventory queries will check for the flag and thus it will= appear as
>>> deleted to the user, but it can be restored easily by an admin= if
>>> needed. =A0A timestamp should also be set which indicates when= the item
>>> was made unavailable, so that routine cleanup can be performed= on items
>>> which were made unavailable a long time ago.
>>>
>>> I wanted to get people's opinons of this before I implemen= ted it in
>>> code. Can anyone think of any drawbacks or possible issues? An= y further
>>> room for improvement?
>>>
>>> Cheers
>>>
>>> Thomas Grimshaw
>>> (RemedyTomm)
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at li= sts.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev=
>>>
>>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.= berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev=
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.= berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev=
>>
>>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berl= ios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berl= ios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>

_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.d= e
https://lists.berlios.de/mailman/listinfo/opensim-dev

No virus found in this incoming message.
Checked by AVG - www.avg.c= om
Version: 8.5.392 / Virus Database: 270.13.29/2261 - Release Date: 07/27/09 = 05:58:00
_________________________________________= ______
Opensim-dev mailing list
Opensim-dev at lists.berlios.d= e
https://lists.berlios.de/mailman/listinfo/opensim-dev



--
Michael Emo= ry Cerquoni - Nebadon Izumi @ http://osgrid.o= rg
--000e0cd47e38287f0e046fbd7b42-- From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: ventory to me - we did until recently have some lost assets after SI sessio= ns due to asset server crashing - previously the code would attempt to stor= e assets with descriptions bigger than database field length. This seemed t= o happen mostly with SI uploaded items but also was 100% reproducible if yo= u had a sim with a long name and a parcel with a long name and attempted to= create a landmark - there are checks now to stop this from happening that = Justin kindly committed (and he was good enough to add similar checks for M= ySQL) and we've not had a crash since applying that patch over a week and a= half ago. In terms of actual inventory, no-one has reported loss of specif= ic items. Sometimes slow to load, but not loss. Is this something that has happened since 0.6.6 tag? Chris -----Original Message----- From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Melanie Sent: 27 July 2009 14:32 To: opensim-dev at lists.berlios.de Subject: Re: [Opensim-dev] Inventory loss Those MySQL issues listed below and others like it are corner cases that OpenSim would never trigger. OpenSim is a very simplistic database user, it doesn't even really use any relational features of the database. So, I don't think that MySQL errors are something we need to concern ourselves with at this point. Especially, your suggestion would not help in those cases, as they are all about complete loss of rows. That is unaffected by a "deleted" type flag. That is neither here nor there anyway, since such a "deleted" flag would have to live under OpenSim.Data.XXXX. It has no business being in core at all. Melanie Colin B. Withers wrote: > Reason I wondered is simply the number of websites dedicated to recoverin= g from MYSQL database corruption, and offering tools for the same. Google r= eturns over 250,000 sites for 'mysql database corruption'. > > MYSQL has had numerous bug fixes to fix database corruption, introduced b= y differing versions of MYSQL, eg > > Fixed in 4.0.18 > INSERT DELAYED ... SELECT ... could cause table corruption because tables= were not locked properly. This is now fixed by ignoring DELAYED in this co= ntext. (Bug #1983) > > Fixed in 4.0.16 > Fixed bug in overrun check for BLOB values with compressed tables. This w= as a bug introduced in 4.0.14. It caused MySQL to regard some correct table= s containing BLOB values as corrupted. (Bug #770, Bug #1304, and maybe Bug = #1295) > > Fixed in 4.0.15 > Fixed rare bug in MYISAM introduced in 4.0.3 where the index file header = was not updated directly after an UPDATE of split dynamic rows. The symptom= was that the table had a corrupted delete-link if mysqld was shut down or = the table was checked directly after the update. > > Fixed in 4.0.14 > Comparison/sorting for latin1_de character set was rewritten. The old alg= orithm could not handle cases like "s=E4" < "=DFa". See section 5.6.1.1 Ger= man character set. In rare cases, it resulted in table corruption. > > and so on.. > > My own experience with Opensim is that in the last 12 months there has be= en three occasions where residents complained of stuff 'missing' (not a sin= gle resident, but several at once) and a roll-back to the last database bac= kup cured the problems. > > Rock > > -----Original Message----- > From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Melanie > Sent: Monday, July 27, 2009 2:07 PM > To: opensim-dev at lists.berlios.de > Subject: Re: [Opensim-dev] Inventory loss > > IMHO, inventory loss due to MySQL errors and/or corruption are below > the radar. > Any losses would occur in OpenSim code, I believe. > > Melanie > > Colin B. Withers wrote: >> I wonder what proportion of inventory items that go astray are the resul= t of the success/failure of an operation, or are due to database corruption= issues. >> >> Rock >> >> -----Original Message----- >> From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Melanie >> Sent: Monday, July 27, 2009 12:30 PM >> To: opensim-dev at lists.berlios.de >> Subject: Re: [Opensim-dev] Inventory loss >> >> There is a question here of why inventory loss occurs at all. At >> what stage do we actually lose (as opposed to failing to bump the >> folder serial) inventory items at all, and why? >> >> While a "deleted" flag and an undelete function do make an admin's >> life easier, I believe the real focus should be on the inventory >> code. It will be redesigned anyway and once that happens, I think a >> strong focus needs to be placed on data integrity preservation. >> >> That would then mae the undelete functionality largely unnecessary. >> Current inventory code often doesn't check for success of an >> operation at all. That needs to be revisited. >> >> Melanie >> >> Thomas Grimshaw wrote: >>> Hey folks. >>> >>> Been thinking a lot about inventory loss in OpenSim, something that I >>> think we should really do as much as possible to avoid. We've been >>> experiencing numerous cases of lost inventory in K-Grid recently. >>> >>> What i'd like to implement, is.. >>> >>> When an item is removed from inventory (deleted, or rezzed if it's >>> no-copy), it is not actually deleted by instead an "available" flag is >>> set in the inventory database. >>> All inventory queries will check for the flag and thus it will appear a= s >>> deleted to the user, but it can be restored easily by an admin if >>> needed. A timestamp should also be set which indicates when the item >>> was made unavailable, so that routine cleanup can be performed on items >>> which were made unavailable a long time ago. >>> >>> I wanted to get people's opinons of this before I implemented it in >>> code. Can anyone think of any drawbacks or possible issues? Any further >>> room for improvement? >>> >>> Cheers >>> >>> Thomas Grimshaw >>> (RemedyTomm) >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.392 / Virus Database: 270.13.29/2261 - Release Date: 07/27/09 = 05:58:00 _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- Michael Emory Cerquoni - Nebadon Izumi @ http://osgrid.org --_000_63FAD4F222230A4EA79DE9E8BE664735340F0360winxbeus19excha_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

It’s worth also noting the clientside inventory skelet= on can get corrupted – clearing cache will often restore supposedly missing inve= ntory.

 

Adam

 

From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Nebadon I= zumi
Sent: Monday, 27 July 2009 10:39 PM
To: opensim-dev at lists.berlios.de
Subject: Re: [Opensim-dev] Inventory loss

 

I don't recall OSgrid r= eally getting many complaints about it either, infact i do not recall any, I am n= ot saying its never occured, but its so minimal its not something i ever remem= ber occuring, even when our whole asset table corrupted, we were able to get 10= 0% recovery, i think we lost 1 asset. We run on MySQL, but run fragstore for b= lob storage, any grids still storing blobs inside the database is going to be i= n major trouble if they don't switch, storing blobs inside of any of the currently available database systems OpenSim's core is really a terrible id= ea and should not be done for anything that is considered a production level t= ype grid.

Neb

On Mon, Jul 27, 2009 at 6:39 AM, Chris Hart <Chris at codetorque.co.uk> wrote= :

From MSSQL side of the grid fence, I haven't had anyon= e complain of lost inventory to me - we did until recently have some lost ass= ets after SI sessions due to asset server crashing - previously the code would attempt to store assets with descriptions bigger than database field length= . This seemed to happen mostly with SI uploaded items but also was 100% reproducible if you had a sim with a long name and a parcel with a long nam= e and attempted to create a landmark - there are checks now to stop this from happening that Justin kindly committed (and he was good enough to add simil= ar checks for MySQL) and we've not had a crash since applying that patch over = a week and a half ago. In terms of actual inventory, no-one has reported loss= of specific items. Sometimes slow to load, but not loss.

Is this something that has happened since 0.6.6 tag?

Chris


-----Original Message-----
From: opensim-dev-b= ounces at lists.berlios.de [mailto:opensim-dev= -bounces at lists.berlios.de] On Behalf Of Melanie

Sent: 27 July 2009 14:3= 2
To: opensim-dev at lists.berli= os.de
Subject: Re: [Opensim-dev] Inventory loss

Those MySQL issues listed below and others like it are corner cases
that OpenSim would never trigger. OpenSim is a very simplistic
database user, it doesn't even really use any relational features of
the database.
So, I don't think that MySQL errors are something we need to concern
ourselves with at this point. Especially, your suggestion would not
help in those cases, as they are all about complete loss of rows.
That is unaffected by a "deleted" type flag.

That is neither here nor there anyway, since such a "deleted" fla= g
would have to live under OpenSim.Data.XXXX.

It has no business being in core at all.

Melanie


Colin B. Withers wrote:
> Reason I wondered is simply the number of websites dedicated to recove= ring from MYSQL database corruption, and offering tools for the same. Google ret= urns over 250,000 sites for 'mysql database corruption'.
>
> MYSQL has had numerous bug fixes to fix database corruption, introduce= d by differing versions of MYSQL, eg
>
> Fixed in 4.0.18
> INSERT DELAYED ... SELECT ... could cause table corruption because tab= les were not locked properly. This is now fixed by ignoring DELAYED in this context. (Bug #1983)
>
> Fixed in 4.0.16
> Fixed bug in overrun check for BLOB values with compressed tables. Thi= s was a bug introduced in 4.0.14. It caused MySQL to regard some correct tabl= es containing BLOB values as corrupted. (Bug #770, Bug #1304, and maybe Bug #1= 295)
>
> Fixed in 4.0.15
> Fixed rare bug in MYISAM introduced in 4.0.3 where the index file head= er was not updated directly after an UPDATE of split dynamic rows. The symptom= was that the table had a corrupted delete-link if mysqld was shut down or the t= able was checked directly after the update.
>
> Fixed in 4.0.14
> Comparison/sorting for latin1_de character set was rewritten. The old algorithm could not handle cases like "s=E4" < "=DFa"= ;. See section 5.6.1.1 German character set. In rare cases, it resulted in table corruption.
>
> and so on..
>
> My own experience with Opensim is that in the last 12 months there has been three occasions where residents complained of stuff 'missing' (not a single resident, but several at once) and a roll-back to the last database backup cured the problems.
>
> Rock
>
> -----Original Message-----
> From: opensim-= dev-bounces at lists.berlios.de [mailto:opensim-dev= -bounces at lists.berlios.de] On Behalf Of Melanie
> Sent: Monday, July 27, 2009 2:07 PM
> To: opensim-dev at lists.= berlios.de
> Subject: Re: [Opensim-dev] Inventory loss
>
> IMHO, inventory loss due to MySQL errors and/or corruption are below > the radar.
> Any losses would occur in OpenSim code, I believe.
>
> Melanie
>
> Colin B. Withers wrote:
>> I wonder what proportion of inventory items that go astray are the result of the success/failure of an operation, or are due to database corruption issues.
>>
>> Rock
>>
>> -----Original Message-----
>> From: open= sim-dev-bounces at lists.berlios.de [mailto:opensim-dev= -bounces at lists.berlios.de] On Behalf Of Melanie
>> Sent: Monday, July 27, 2009 12:30 PM
>> To: opensim-dev at li= sts.berlios.de
>> Subject: Re: [Opensim-dev] Inventory loss
>>
>> There is a question here of why inventory loss occurs at all. At >> what stage do we actually lose (as opposed to failing to bump the<= br> >> folder serial) inventory items at all, and why?
>>
>> While a "deleted" flag and an undelete function do make = an admin's
>> life easier, I believe the real focus should be on the inventory >> code. It will be redesigned anyway and once that happens, I think = a
>> strong focus needs to be placed on data integrity preservation. >>
>> That would then mae the undelete functionality largely unnecessary= .
>> Current inventory code often doesn't check for success of an
>> operation at all. That needs to be revisited.
>>
>> Melanie
>>
>> Thomas Grimshaw wrote:
>>> Hey folks.
>>>
>>> Been thinking a lot about inventory loss in OpenSim, something that I
>>> think we should really do as much as possible to avoid. We've = been
>>> experiencing numerous cases of lost inventory in K-Grid recent= ly.
>>>
>>> What i'd like to implement, is..
>>>
>>> When an item is removed from inventory (deleted, or rezzed if = it's
>>> no-copy), it is not actually deleted by instead an "available" flag is
>>> set in the inventory database.
>>> All inventory queries will check for the flag and thus it will appear as
>>> deleted to the user, but it can be restored easily by an admin= if
>>> needed.  A timestamp should also be set which indicates w= hen the item
>>> was made unavailable, so that routine cleanup can be performed= on items
>>> which were made unavailable a long time ago.
>>>
>>> I wanted to get people's opinons of this before I implemented = it in
>>> code. Can anyone think of any drawbacks or possible issues? An= y further
>>> room for improvement?
>>>
>>> Cheers
>>>
>>> Thomas Grimshaw
>>> (RemedyTomm)
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at li= sts.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev=
>>>
>>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.= berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev=
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.= berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev=
>>
>>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berl= ios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev=
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berl= ios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev=
>
>

_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.d= e
https://lists.berlios.de/mailman/listinfo/opensim-dev

No virus found in this incoming message.
Checked by AVG - www.avg.c= om
Version: 8.5.392 / Virus Database: 270.13.29/2261 - Release Date: 07/27/09 05:58:00

_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.d= e
https://lists.berlios.de/mailman/listinfo/opensim-dev




--
Michael Emory Cerquoni - Nebadon Izumi @ http= ://osgrid.org

--_000_63FAD4F222230A4EA79DE9E8BE664735340F0360winxbeus19excha_-- From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: undreds of threads severely limits scaling the number of concurrent clients= . UDP packets all come in on a single port and are put into incoming queues= for each client view. The client view UPD threads (1 per client) then dequ= eue that packet and make the appropriate calls into scene. When the scene h= as updates, it puts them into the outbound queue for every client view and = finally the client view thread comes around and sends the packets out to cl= ients. Inbound processing on the scene happens on the individual client vie= w thread, but often this work is small and most of the time is spent switch= ing threads in and out.=20 I tested a change where I eliminated the outbound queue and had the main th= read call directly into the send packet routing. As the number of active ag= ents increases, outbound traffic grows exponentially compared to inbound. T= his change alone allowed me to scale the number of active viewers on a sing= le region using TestClient up to more than 200. I also tried eliminating th= e inbound queues and instead making the calls to scene directly. This behav= ior, as Tom pointed out, causes a single client to stop up the entire packe= t processing thread when a complex operation comes along.=20 I think that it would be ideal, as I believe Mojito described, if there wer= e a small number of threads handling outbound client packet sending and the= y blocked on their packet queue to get work. For inbound traffic, simple op= erations should be called directly on the scene and the more complex operat= ions put into a queue for a set of slower processing threads. Having 300 th= reads (1 per client) is too many, but 1 was not enough. We could certainly = start with 1 thread for outbound UDP for all clients and grow as the number= of clients grows. Something on the order of 1 outbound thread per 50 clien= ts and 1 inbound thread per 5 or 10 clients would be about ideal in my esti= mation.=20 Dan lake Software Engineer Visual Applications Research Intel Labs -----Original Message----- From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at list= s.berlios.de] On Behalf Of Mojito Sorbet Sent: Friday, July 31, 2009 9:05 AM To: opensim-dev at lists.berlios.de Subject: Re: [Opensim-dev] Threads, threads, threads and more threads If it was me starting from scratch (and I do have experience building fast servers that handle hundreds of simultaneous client connections in limited resources), I would have one thread per blocking resource, driven by work queues. What the viewer might see as a single operation turns into a "workflow" along a series of these queues, each thread doing its part like an assembly line. The only thing that blocks is a hardware interface. So for example, there only needs to be one listening thread per UDP port, not one per viewer. A network interface can only deliver one packet at a time. The sending IP address on the packet keys you to the correct user context to match it up with. A disk interface on the other hand works better with multiple requests outstanding at once, so that the kernel seek optimization has something to work on; you would have perhaps 5 threads to round-robin handle disk I/O. The per-user context is where you keep track of the state of all the things that the viewer is doing at once, rather than spreading this information all over the call stacks of threads. As soon as the processing of an input packet needs to do something that might block, the request is put on the input queue of another thread that handles the blocking operation. It takes a bit to get used to programming like this, but I can report that the performance results are quite amazing regarding scalability. It also reduces the need for locks, since it is mostly just the work queues that are touched by more than one thread. _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: Albert -------------------------------------------------------------------- 2009/9/4 Andr=E9 Filipe > Hello, > I wonder if someone can access the Sciencesim (Sciencesim.com) with > Hypergrid. I would ask for someone to test if can connect. I use this > feature a lot and I can not stay without it. > > Best Regards > > Andr=E9 Filipe > Federal University of ABC > Sao Paulo - Brazil > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > --00151744805e8a69480472c4f669 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: --------------------------------------------------------------

2009/9/4 Andr=E9 Filipe <andrefilipemb at gmail.com><= br>
= Hello,

=A0I wonder if someone can access the Sciencesim=A0(Sciencesim= .com)=A0with Hypergrid.=A0=A0I would ask for someone to test if can connect= . I use this feature a lot and I can not stay without it.=A0

Best Regards

<= div style=3D"margin-bottom: 0.2em;"> Andr=E9 Filipe
Federal University= of ABC
Sao Paulo - Brazil
<= /div>


_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.d= e
https://lists.berlios.de/mailman/listinfo/opensim-dev


--00151744805e8a69480472c4f669-- From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: far", instead, go to others grids (condensationland.com:9000, jamland.de:9300), works well. From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: , but we have an other, 213.172.38.61:900, with 0.6.6.3 version and from 0.6.= 6 vefsions and 0.6.3 versions, we can acces. Strange. A. 2009/9/4 > The viewer cannot jump longer that 4096 regions in either direction. > You can use the UCI Gateways that I set up for this purpose: > > ucigrid04.nacs.uci.edu:9003 (@3000,3000) > ucigrid04.nacs.uci.edu:9007 (@7000,7000) > > I think ScienceSim is located in the 10000's. > If you're in the lows, get yourself to ucigrid04.nacs.uci.edu:9007, and > try this on the map: peak.sciencesim.com:9001 > Not sure if that's still valid. > > > Gustavo Alberto Navarro Bilbao wrote: > > >From our server always says "too far" > > > > Albert > > > > -------------------------------------------------------------------- > > > > 2009/9/4 Andr=E9 Filipe > > > > > > Hello, > > > > I wonder if someone can access the Sciencesim (Sciencesim.com) wit= h > > Hypergrid. I would ask for someone to test if can connect. I use > > this feature a lot and I can not stay without it. > > > > Best Regards > > > > Andr=E9 Filipe > > Federal University of ABC > > Sao Paulo - Brazil > > > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > > > > > -----------------------------------------------------------------------= - > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > --00151747b69085ed260472c64465 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In our case, we have some services in our grid. 213.172.38.61:9300 (0.6.6 .10108 i v 5) is in 6000/6000 coor= denates, 213.172.39.61:9700 (0.6.= 6=A0=A0 .239a1 i v 5) is in OSGrid in 9997/10004 coordenates.
From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: to far", instead, go to others grids (condensationland.com:9000,=A0 jamland.de:9300), works well.

From outside our serveer, if we try to acces to our services, is imposs= ible, but we have an other, 213.172.38= .61:900, with 0.6.6.3 version and from 0.6.6 vefsions and 0.6.3 version= s, we can acces.

Strange.

A.

2009/9/4 <diva at metaverseink.co= m>
The viewer cannot jump longer that 4096 regions in either direction.
You can use the UCI Gateways that I set up for this purpose:

ucigrid04.= nacs.uci.edu:9003 =A0(@3000,3000)
ucigrid04.= nacs.uci.edu:9007 =A0(@7000,7000)

I think ScienceSim is located in the 10000's.
If you're in the lows, get yourself to ucigrid04.nacs.uci.edu:9007, and
try this on the map: peak.sciencesim.com:9001
Not sure if that's still valid.


Gustavo Alberto Navarro Bilbao wrote:
> =A0>From our server always says "too far"
>
> Albert
>
> -------------------------------------------------------------------- >
> 2009/9/4 Andr=E9 Filipe <andrefilipemb at gmail.com
> <mailto:andrefilip= emb at gmail.com>>
>
> =A0 =A0 Hello,
>
> =A0 =A0 =A0I wonder if someone can access the Sciencesim (Sciencesim.c= om) with
> =A0 =A0 Hypergrid. =A0I would ask for someone to test if can connect. = I use
> =A0 =A0 this feature a lot and I can not stay without it.
>
> =A0 =A0 Best Regards
>
> =A0 =A0 Andr=E9 Filipe
> =A0 =A0 Federal University of ABC
> =A0 =A0 Sao Paulo - Brazil
>
>
> =A0 =A0 _______________________________________________
> =A0 =A0 Opensim-dev mailing list
> =A0 =A0 Opensim-= dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
> =A0 =A0 https://lists.berlios.de/mailman/li= stinfo/opensim-dev
>
>
>
> ----------------------------------------------------------------= --------
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berl= ios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.d= e
https://lists.berlios.de/mailman/listinfo/opensim-dev

--00151747b69085ed260472c64465-- From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: correct? http://www.adamfrisby.com/blog/category/technical/idealist/ Adam, what is the status of Xenki? Is Xenki development now being abandoned? (now that "Rei" viewer is OpenSource?) With all these various OpenSource Viewers/Browsers out there, would it be possible to work on some form of cross-platform compatibility or "standardization" between the various viewers and the various server platforms (OpenSim Core, OpenSim + ModRex, and 3Di?) Mark On Wed, Sep 30, 2009 at 1:11 PM, Frisby, Adam wrote= : > TribalServer fell into disrepair I believe, but MW & LBSA donated their > unique features into a Forge project at least 6 months ago. (look for > =91Tribal=92 in the projects list). > > > > 3Di is just OpenSim + a support contract + some extra modules for the 3D > models and analytics. I believe 3Di runs fairly close to OpenSim releases= , > and they do donate code back to core which indicates they would have to b= e. > > > > RealXtend was probably the only really =91fork fork=92 where the goal was= to do > some things differently; but that got merged back last November, and now = you > can run ModRex with OpenSim-trunk. (although sometimes compatibility issu= es > with the module do appear on new features, eg megaregions) > > > > So, I don=92t think there are any major forks anymore =96 3Di would be it= if > anything, and they aren=92t that much of one. > > > > Adam > > > > *From:* opensim-dev-bounces at lists.berlios.de [mailto: > opensim-dev-bounces at lists.berlios.de] *On Behalf Of *Mark Malewski > *Sent:* Wednesday, 30 September 2009 11:05 AM > *To:* diva at metaverseink.com; Opensim-dev at lists.berlios.de > > *Subject:* Re: [Opensim-dev] [realXtend] Re: 3Di Viewer "Rei" goes open > source (BSD licensed in-browser viewer) > > > > Diva, > > > > There are/were quite a few forks floating around out there. > > *> What opensim forks are you talking about? I don't know of any, so * > > *> please point me to one.* > > > > http://3di-opensim.com/en/ > > > > You've never heard of 3Di OpenSim Enterprise? > > > > > http://virtualeconomicforum.com/content-library/blogging/about/3di_to_sel= l_opensim_server_software/ > > > > I can think of maybe 4 forks just off the top of my head. I believe > "Tribal Media Server" (or Tribal Net) and "3Di Server" and RealXtend/ModR= ex > were all forks based on the original OpenSim core? > > > > I understand that RealXtend came back from being a separate fork, and > RealXtend has now integrated their work back into OpenSim as a module > (ModRex). I believe Adam Frisby helped with converting RealXtend into a > "ModRex" module, but what about "3Di Server" and "Tribal Media Server"? = Are > those not separate OpenSim-based forks? > > > > I understand that each of these OpenSim-based Server "forks" uses differe= nt > technologies (realXtend/ModRex supports Ogre3D, and 3Di Server supports > Irrlicht, etc.) I'm not quite sure what Tribal Media Server is (but it > seems to have been OpenSim-based fork as well that seemed to have a nice > Admin Control panel). > > > > I believe "Tribal Server" or "Tribal Net" was the name of Tribal Media's > Server. I believe it was a fork off of the original OpenSim core as well= . > > > > > http://www.ugotrade.com/2008/05/14/tribal-media-changing-the-game-with-op= ensim/ > > > > I believe Tribal Media's Server (Tribal Server) had a really nice Admin > Control Panel, and an easy way to get Tribal Sim servers online. > > > > As for 3Di server, I believe it supports "Irrlicht" 3D rendering engine. > (ModRex/RealXtend support Ogre3d rendering engine). > > > > I don't know all the exact specifics as to each of the various different > server forks, but I know much of RealXtend's work has been integrated bac= k > into OpenSim (as a ModRex module), but 3Di and Tribal Media servers (as f= ar > as I know) are not OpenSource, and have not had their work put back into > OpenSim. > > > > I don't know all the specifics as to the exact differences between all th= e > various server forks, but it would be nice to create a wiki page, showing= a > nice comparison chart between Tribal Media Server, 3Di Enterprise Server, > ModRex, and the native OpenSim Core. > > > > Just so people can see what features each of the various servers (such as > 3Di Enterprise Server, or Tribal Media Server, or ModRex) has. They all > seem to be OpenSim-based. I understand RealXtend is now "ModRex" (as an > OpenSim module) but it used to be an OpenSim fork. > > > > It would just be nice to know what features are in 3Di Enterprise Server, > and Tribal Media Server. (and maybe see a nice comparison chart on the w= iki > page showing each of the features between each of the various OpenSim-bas= ed > servers). > > > > Ultimately, I'd really love to see some of the work from 3Di and Tribal > Media contributed back (as OpenSource) to the OpenSim Community (as open > source modules for the OpenSim core), just as RealXtend has done (with > ModRex). > > > > Mark > > > > > > On Wed, Sep 30, 2009 at 12:02 PM, wrote: > > What opensim forks are you talking about? I don't know of any, so please > point me to one. > > > > Mark Malewski wrote: > > */ > > > Adam, > > > > > /**/=85 then if we can get someone to adjust the full viewer, we=92d= have > /* > > */> somewhat of a standard on our hands./* > > > > See, now that's what I'm talking about! Me "likey" the idea of > > standards! ;-) > > > > I'd really like to see some form standardization, so that viewers can > > work on each of the various platforms. In a perfect world, I'd really > > like to see some of these technologies that 3Di and Tribal Media > > are/were working on, slowly come back to the OpenSim Community as > > OpenSource Modules (similar to the RealXtend/ModRex module). > > > > That way we just have ONE single OpenSim core distribution, and then > > have various modules (like "ModRex" or a "3Di" module, or a > > "Tribal_Media" module) that can be installed on top of OpenSim core? > > > > This would seem to make MUCH more sense, instead of all the various > > forks out there. I really do like the idea of "standardization", and > > would really like to see Modules created instead of completely differen= t > > OpenSim "forks". > > > > Then it would be great to see the Viewers designed so that all the > > various viewers will work with all the different platform modules > > (ModRex, 3Di, Tribal Media Server, etc.) > > > > Mark > > > > > > On Wed, Sep 30, 2009 at 11:07 AM, Frisby, Adam > > > wrote: > > > > It works with vanilla but from my understanding not ModRex; the > > meshes are handled as Irrlicht meshes if I understand correctly. > > Synchronising these mesh standards (in both rex & 3diov) might be a > > good idea methinks. > > > > > > > > =85 then if we can get someone to adjust the full viewer, we=92d ha= ve > > somewhat of a standard on our hands. > > > > > > > > Adam > > > > > > > > *From:* opensim-dev-bounces at lists.berlios.de > > > > [mailto:opensim-dev-bounces at lists.berlios.de > > ] *On Behalf Of *Mark > > Malewski > > *Sent:* Wednesday, 30 September 2009 9:02 AM > > *To:* realxtend at googlegroups.com > > > ; Opensim-dev at lists.berlios.de > > > > > *Subject:* Re: [Opensim-dev] [realXtend] Re: 3Di Viewer "Rei" goes > > open source (BSD licensed in-browser viewer) > > > > > > > > Nlin, > > > > > > > > Does the "Rei" Viewer work with the OpenSim + ModRex (RealXtend) as > > well? > > > > Could you please explain the differences between a plain vanilla > > OpenSim Server, a OpenSim + ModRex (realXtend) server, and a 3di > server? > > > > > > > > > > > > Thank-you for all that you do, > > > > > > > > Mark > > > > > > > > > > > > On Wed, Sep 30, 2009 at 8:36 AM, Anu Mishra > > > wrote: > > > > Nlin > > > > > > > > Do you know if this viewer works with Realxtend server as well? > > > > > > > > Anu > > > > > > > > On 9/30/09, *Mark Malewski* > > > wrote: > > > > RealXtend, > > > > > > > > > > Have any of the RealXtend core developer's had a chance to look > > at this OpenSource "Rei" viewer yet? > > > > > > > > > > It seems to be an OpenSource web-based viewer. It looks pretty > > cool. Would this OpenSource contribution help RealXtend's > > Viewer project in any way? Could this viewer be easily modifie= d > > to work with BOTH the stock OpenSim AND also work with RealXten= d > > & ModRex? > > > > > > > > > > Mark > > > > > > > > On Wed, Sep 30, 2009 at 2:07 AM, Mark Malewski > > > > > wrote: > > > > Nlin, > > > > > > > > > > Thank-you very much for the post, that seems like an excellent > > contribution to the OpenSim Community! > > > > > > > > > > I'm wondering what type of effect this might have on RealXtend'= s > > project development of a new viewer? > > > > > > > > > > Will this "Rei" viewer work with the latest stock OpenSim serve= r? > > > > > > > > > > Mark > > > > > > > > On Tue, Sep 29, 2009 at 8:24 PM, nlin > > > wrote: > > > > > > Hello, > > > > Today 3Di's in-browser viewer source code has been opened > > up, as the project 3Di Viewer "Rei". The license is BSD. > > Please have a look if you are interested! > > > > > Project home page: http://3di-rei.org > > > Press release: http://3di.jp/en/news/2009093001.html > > > > We're very interested in further development of this open > > source viewer with the community. Thanks to the > > IdealistViewer developers, as portions of Rei use source > > code from an early version of IdealistViewer. Rei uses no > > code from GPL-licensed viewers. > > > > The Rei source code is in git at github, with the main > > repository at: http://github.com/3di/3di-viewer-rei > > > > Thanks, > > -nlin > > > > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ > > > > > > http://groups.google.com/group/realxtend > > http://www.realxtend.org > > -~----------~----~----~----~------~----~------~--~--- > > > > > > > > > > _______________________________________________ > > Opensim-dev mailing list > > > Opensim-dev at lists.berlios.de > > > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > > > > > > -----------------------------------------------------------------------= - > > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > --001485f794ccd7a9630474d00e1a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Adam, thank-you for the response. =A0You seem to know quite well wh= at all the various groups are working on. =A0;-)


> So, I don=92t = think there are any major forks anymore=A0=96=A0

> 3D= i=A0would be it if anything, and they aren=92t that much of one.

=

Ok, this is good to know. =A0It wa= s hard keeping track of everything that was going on out there, and I still= wasn't exactly sure what 3Di was working on (or if it was getting cont= ributed back to OpenSim Core, or as a separate OpenSim module). =A0I did kn= ow they were working on an "OpenViewer" (which I'm guessing h= as been renamed to "Rei" viewer?) =A0I'm still not quite sure= as to all the specifics of 3Di Server's features.

It would just be nice to get everything integrated back into= core (or as OpenSim modules).

>TribalServer fell into disre= pair I believe, but MW & LBSA

> donated = their unique features into a Forge project at least 6 >months ago. (look= for =91Tribal=92 in the projects list).

I'll need to lo= ok around. =A0It really would be nice to try and get as many of these great= things/features updated and integrated into Core (or as OpenSim modules) I= 'm still not quite sure what features 3Di's Enterprise server has.<= /div>

Do we have any contacts over at 3Di that we can t= alk to? =A0Do they have any plans to "OpenSource" their work (and= modules)?

It would be good to have some form of &= quot;standardization" among the various groups, so that the Viewers/Br= owsers (Hippo, Naali, and Rei) will at least be cross-platform and support = OpenSim Core, RealXtend/ModRex, and 3Di.

From what I understand, the "Rei" Viewer is b= ased on the Idealist Viewer, correct?


Adam, what is the status of Xenki? =A0Is Xenki developm= ent now being abandoned? (now that "Rei" viewer is OpenSource?) = =A0

With all these various OpenSource Viewers/Brow= sers out there, would it be possible to work on some form of cross-platform= compatibility or "standardization" between the various viewers a= nd the various server platforms (OpenSim Core, OpenSim + ModRex, and 3Di?)<= /div>

=A0=A0 =A0 =A0 =A0 =A0 =A0Mark


On Wed, Sep 30, 2009 at 1:11 PM, Frisby, Ad= am <adam at deep= think.com.au> wrote:

TribalServer fell into di= srepair I believe, but MW & LBSA donated their unique features into a Forge project at least 6 months ago. (= look for =91Tribal=92 in the projects list).

=A0

3Di is just OpenSim + a s= upport contract + some extra modules for the 3D models and analytics. I believe 3Di runs fairly close to OpenSim releases, and they do donate code back to core which indicates they would h= ave to be.

=A0

RealXtend was probably th= e only really =91fork fork=92 where the goal was to do some things differently; but that got merged back last November, = and now you can run ModRex with OpenSim-trunk. (although sometimes compatibilit= y issues with the module do appear on new features, eg megaregions)

=A0

So, I don=92t think there= are any major forks anymore =96 3Di would be it if anything, and they aren=92t that much of one.

=A0

Adam

=A0

From: opensim-dev-bounces at lists.berlio= s.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Mark M= alewski
Sent: Wednesday, 30 September 2009 11:05 AM
To: diva@= metaverseink.com; Opensim-dev at lists.berlios.de


Subject: Re: [Opensim-dev] [realXtend] Re: 3Di Viewer "Rei"= ; goes open source (BSD licensed in-browser viewer)

=A0

Diva,

=A0

There are/were quite a few forks floating around out there.

>=A0What opensim forks are you talking about? I don't know of any, so=A0

> please=A0point me to one.

=A0

=A0

You've never heard of 3Di OpenSim Enterprise?

=A0

=A0

I can think of maybe 4 forks just off the top of my head. =A0I believe "Tribal Media Server" (or Tribal Net) and "3Di Server" and RealXtend/ModRex were all forks based on the original Open= Sim core?

=A0

I understand that RealXtend came back from being a separate fork, and RealXtend has now integrated their work back into OpenSim as a mo= dule (ModRex). =A0I believe Adam Frisby helped with converting RealXtend into a "ModRex" module, but what about "3Di Server" and "Tribal Media Server"? =A0Are those not separate OpenSim-based forks?=A0

=A0

I understand that each of these OpenSim-based Server "forks" uses different technologies (realXtend/ModRex supports Ogre3D, and 3Di Server supports Irrlicht, etc.) =A0I'm not quite sure w= hat Tribal Media Server is (but it seems to have been OpenSim-based fork as wel= l that seemed to have a nice Admin Control panel).

=A0

I believe "Tribal Server" or "Tribal Net" was the name of Tribal Media's Server. =A0I believe it was a = fork off of the original OpenSim core as well.

=A0

I believe Tribal Media's Server (Tribal Server) had a really nice Admin Control Panel, and an easy way to get Tribal Sim servers online.=

=A0

As for 3Di server, I believe it supports "Irrlicht" 3D rendering engine. =A0(ModRex/RealXtend support Ogre3d rendering engine).

=A0

I don't know all the exact specifics as to each of the various different server forks, but I know much of RealXtend's work has= been integrated back into OpenSim (as a ModRex module), but 3Di and Tribal Media servers (as far as I know) are not OpenSource, and have not had their work = put back into OpenSim.

=A0

I don't know all the specifics as to the exact differences between all the various server forks, but it would be nice to create a wiki page, showing a nice comparison chart between Tribal Media Server, 3Di Enterprise Server, ModRex, and the native OpenSim Core.

=A0

Just so people can see what features each of the various servers (such as 3Di Enterprise Server, or Tribal Media Server, or ModRex) = has. =A0They all seem to be OpenSim-based. =A0I understand RealXtend is now "ModRex" (as an OpenSim module) but it used to be an OpenSim fork= .

=A0

It would just be nice to know what features are in 3Di Enterprise Server, and Tribal Media Server. =A0(and maybe see a nice comparison chart on the wiki page showing each of the features between each= of the various OpenSim-based servers).

=A0

Ultimately, I'd really love to see some of the work from 3Di and Tribal Media contributed back (as OpenSource) to the OpenSim Community = (as open source modules for the OpenSim core), just as RealXtend has done (with ModRex).

=A0

=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 Mark

=A0

=A0

On Wed, Sep 30, 2009 at 12:02 PM, <diva at metaverseink.com> wrote:

What opensim forks are you talking about? I don't know of any, so please
point me to one.



Mark Malewski wrote:
> */

> Adam,
>
> =A0> /**/=85 then if we can get someone to adjust the full viewer, we=92d have /*
> */> somewhat of a standard on our hands./*
>
> See, now that's what I'm talking about! =A0Me "likey"= ; the idea of
> standards! =A0;-)
>
> I'd really like to see some form standardization, so that viewers = can
> work on each of the various platforms. =A0In a perfect world, I'd really
> like to see some of these technologies that 3Di and Tribal Media
> are/were working on, slowly come back to the OpenSim Community as
> OpenSource Modules (similar to the RealXtend/ModRex module).
>
> That way we just have ONE single OpenSim core distribution, and then > have various modules (like "ModRex" or a "3Di" mod= ule, or a
> "Tribal_Media" module) that can be installed on top of OpenS= im core?
>
> This would seem to make MUCH more sense, instead of all the various > forks out there. =A0I really do like the idea of "standardization", and
> would really like to see Modules created instead of completely differe= nt
> OpenSim "forks".
>
> Then it would be great to see the Viewers designed so that all the
> various viewers will work with all the different platform modules
> (ModRex, 3Di, Tribal Media Server, etc.)
>
> =A0 =A0 =A0 =A0 =A0 =A0 Mark
>
>
> On Wed, Sep 30, 2009 at 11:07 AM, Frisby, Adam <adam at deepthink.com.au

> <mailto:adam at deepthink.com.au>> wrote:
>
> =A0 =A0 It works with vanilla but from my understanding not ModRex; the
> =A0 =A0 meshes are handled as Irrlicht meshes if I understand correctly.
> =A0 =A0 Synchronising these mesh standards (in both rex & 3diov) might be a
> =A0 =A0 good idea methinks.
>
>
>
> =A0 =A0 =85 then if we can get someone to adjust the full viewer, we= =92d have
> =A0 =A0 somewhat of a standard on our hands.
>
>
>
> =A0 =A0 Adam
>
>
>
> =A0 =A0 *From:* opensim-dev-bounces at lists.berlios.de
> =A0 =A0 <mailto:opensim-dev-bounces at lists.berlios.de>
> =A0 =A0 [mailto:opensim-dev-bounces at lists.berlios.de
> =A0 =A0 <mailto:opensim-dev-bounces at lists.berlios.de>] *On Behalf Of *Mark
> =A0 =A0 Malewski
> =A0 =A0 *Sent:* Wednesday, 30 September 2009 9:02 AM
> =A0 =A0 *To:* realxtend at googlegroups.com

> =A0 =A0 <mailto:realxtend at googlegroups.com>; Opensim-dev at lists.berlios.de=
> =A0 =A0 <mailto:Opensim-dev at lists.berlios.de>

> =A0 =A0 *Subject:* Re: [Opensim-dev] [realXtend] Re: 3Di Viewer "Rei" goes
> =A0 =A0 open source (BSD licensed in-browser viewer)
>
>
>
> =A0 =A0 Nlin,
>
>
>
> =A0 =A0 Does the "Rei" Viewer work with the OpenSim + ModRex (RealXtend) as
> =A0 =A0 well?
>
> =A0 =A0 Could you please explain the differences between a plain vanilla
> =A0 =A0 OpenSim Server, a OpenSim + ModRex (realXtend) server, and a 3di server?
>
>
>
>
>
> =A0 =A0 =A0 =A0 =A0 Thank-you for all that you do,
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Mark
>
>
>
>
>
> =A0 =A0 On Wed, Sep 30, 2009 at 8:36 AM, Anu Mishra <anuranjanm at gmail.com

> =A0 =A0 <mailto:anuranjanm at gmail.com>> wrote:
>
> =A0 =A0 Nlin
>
>
>
> =A0 =A0 Do you know if this viewer works with Realxtend server as well?
>
>
>
> =A0 =A0 Anu
>
>
>
> =A0 =A0 On 9/30/09, *Mark Malewski* <mark.malewski at gmail.com

> =A0 =A0 <mailto:mark.malewski at gmail.com>> wrote:
>
> =A0 =A0 =A0 =A0 RealXtend,
>
>
>
>
> =A0 =A0 =A0 =A0 Have any of the RealXtend core developer's had a chance to look
> =A0 =A0 =A0 =A0 at this OpenSource "Rei" viewer yet?
>
>
>
>
> =A0 =A0 =A0 =A0 It seems to be an OpenSource web-based viewer. =A0It looks pretty
> =A0 =A0 =A0 =A0 cool. =A0Would this OpenSource contribution help RealXtend's
> =A0 =A0 =A0 =A0 Viewer project in any way? =A0Could this viewer be easily modified
> =A0 =A0 =A0 =A0 to work with BOTH the stock OpenSim AND also work with RealXtend
> =A0 =A0 =A0 =A0 & ModRex?
>
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Mark
>
>
>
> =A0 =A0 =A0 =A0 On Wed, Sep 30, 2009 at 2:07 AM, Mark Malewski

> =A0 =A0 =A0 =A0 <mark.malewski at gmail.com <mailto:mark.malewski at gmail.com>> wrote:
>
> =A0 =A0 =A0 =A0 Nlin,
>
>
>
>
> =A0 =A0 =A0 =A0 Thank-you very much for the post, that seems like an excellent
> =A0 =A0 =A0 =A0 contribution to the OpenSim Community!
>
>
>
>
> =A0 =A0 =A0 =A0 I'm wondering what type of effect this might have on RealXtend's
> =A0 =A0 =A0 =A0 project development of a new viewer?
>
>
>
>
> =A0 =A0 =A0 =A0 Will this "Rei" viewer work with the latest stock OpenSim server?
>
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Mark
>
>
>
> =A0 =A0 =A0 =A0 On Tue, Sep 29, 2009 at 8:24 PM, nlin <nlin.message at gmail.com<= /p>

> =A0 =A0 =A0 =A0 <mailto:nlin.message at gmail.com>> wrote:
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 Hello,
>
> =A0 =A0 =A0 =A0 =A0 =A0 Today 3Di's in-browser viewer source code has been opened
> =A0 =A0 =A0 =A0 =A0 =A0 up, as the project 3Di Viewer "Rei". The license is BSD.
> =A0 =A0 =A0 =A0 =A0 =A0 Please have a look if you are interested!
>

> =A0 =A0 =A0 =A0 =A0 =A0 Project home page: http://3di-rei.org <http://3di-rei.org= />

> =A0 =A0 =A0 =A0 =A0 =A0 Press release: http://3di.jp/en/news/2009093001.html
>
> =A0 =A0 =A0 =A0 =A0 =A0 We're very interested in further development of this open
> =A0 =A0 =A0 =A0 =A0 =A0 source viewer with the community. Thanks to the
> =A0 =A0 =A0 =A0 =A0 =A0 IdealistViewer developers, as portions of Rei use source
> =A0 =A0 =A0 =A0 =A0 =A0 code from an early version of IdealistViewer. Rei uses no
> =A0 =A0 =A0 =A0 =A0 =A0 code from GPL-licensed viewers.
>
> =A0 =A0 =A0 =A0 =A0 =A0 The Rei source code is in git at github, with the main
> =A0 =A0 =A0 =A0 =A0 =A0 repository at: http://github.com/3di/3di-viewer-rei
>
> =A0 =A0 =A0 =A0 =A0 =A0 Thanks,
> =A0 =A0 =A0 =A0 =A0 =A0 -nlin
>
>
>
>
>
>
>
> =A0 =A0 =A0 =A0 --~--~---------~--~----~------------~-------~--~----~<= br> >
>
> =A0 =A0 =A0 =A0 http://groups.google.com/group/realxtend
> =A0 =A0 =A0 =A0 http://www.realxtend.org
> =A0 =A0 =A0 =A0 -~----------~----~----~----~------~----~------~--~---<= br> >
>
>
>
> =A0 =A0 _______________________________________________
> =A0 =A0 Opensim-dev mailing list

> =A0 =A0 Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>

> ------------------------------------------------------------------------

>
> _______________________________________________
> Opensim-dev mailing list
> Open= sim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-d= ev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

=A0


_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.d= e
https://lists.berlios.de/mailman/listinfo/opensim-dev


--001485f794ccd7a9630474d00e1a-- From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: to include hooks and mechanisms for expanding/enhancing the system with new capabilities WITHOUT having to make major changes to the system infrastructure. OpenSim doesn't seem to be "extensible". OpenSim seems to be "broken". There is a big difference. Maybe your definition of "extensible" means that it requires a rocket scientist just to get the trunk to even compile (or even work), and takes hours and hours of debugging code, just to get a module to even work. That isn't my idea of "extensible". I understand over the past few months, the server infrastructure (and architecture) has been changing quite a bit. It's hard to even tell if ModRex (or any other modules) even work with the current OpenSim trunk (or latest build) at this point. The average layperson doesn't want to spend hours and hours trying to compile from source, or debugging code, or searching for plugins/modules that may (or may not) exist, and even worse many of them may not be updated, or may not even work with the current OpenSim as "core" evolves. Often times many of these modules are not updated, and most have no clue how to even build from source, and for this reason it might be good to just have VERY simple "turn-key" distributions available for download. (Stable releases) Similar to how RealXtend has done in the past. I supposed I could sit down and begin working on creating a fully configured VMWare image of OpenSim with various modules installed and configured, that people could easily download, and be up and running in a few minutes (without having to hunt for various modules, or applications), or sifting through outdated wiki pages trying to figure out how to even get started or even get up and running, but to be honest most people just want something VERY easy to use, VERY easy to setup, and would love a nice GUI interface (like WixTD, etc.) that they can use to administer the server, add users, etc. Most laypeople don't want to hire a software engineer, or a programmer, just to get OpenSim to compile, or even get a module working, or just to get OpenSim running on a machine. If I want to use a plugin with Firefox, I've NEVER had to compile or debug code. If I want to enable a PHP module, I've NEVER had to debug any code. Most modules are included in the default distro, and modules can easily be turned on and off, by simply "enabling" them in the default ini (configuration) file. In my opinion, you may be confusing "extensible system" as an excuse as to why nothing should work properly. In my opinion, EVERY single working module that exists for OpenSim should be included in the default distro (in the modules directory), and these modules should ALL be disabled by default, but can be easily enabled by simply uncommenting out ONE single line in the default.ini configuration file. Include EVERY single working module with the default OpenSim distro, so users have a list of default working modules that are regularly updated so that they actually work (and are not broken), so that when a stable release comes out, a user can just enable or disable whatever modules they wish to use (by uncommenting out a line or two in the default .ini configuration file) and those modules are in the modules directory, and can easily be enabled by just uncommenting out a single line in the default ini configuration file. The problem is, it seems like a herd of cats are headed in all opposite directions, and people really just want something that actually works. Diva, is that honestly too much to ask? There are Applications and there are Operating Systems. What do you call OpenSim? Is it an Application or an Operating System? (or is it neither?) When I say "works", I'm talking about someone can download OpenSim, and be up and running (designing things from within the OpenSim Application platform such as creating 3D content, in-world). Not sitting down and downloading source code, or attempting to figure out how to learn C# or C++ or how to write a module, just to get simple things running. The thing that made RealXtend so popular was that it was easy to use, and they had distros that were already setup and ready to use (even with a nice "beneath the sea" demo world as part of the distro). Keep in mind that most of the people interested in OpenSim as a 3D development platform are laypeople, and are graphics designers (and Second Life users) that are NOT Computer Science majors, and are not engineers, and really don't know ANY programming languages (some may know a bit of Java, or HTML, or LSL), but most don't even know C++ or C# nor would they have any idea how to even compile or build from source. They just want to use OpenSim to design 3D content, and create their own virtual world. Do you expect a web developer to know C? or C++? or C#? Try thinking of OpenSim as a "3D Web Server" for users (similar to Apache). Yes, Apache is extensible, and many modules can be written for Apache, but most of the common modules are already tested and included with the Apache distro. Modules are tested, and included with all the latest releases, and users can easily comment (or uncomment) out a single line in the default configuration file, and have the included modules working. So I believe the key to making OpenSim widely adopted as a "usable" platform for 3D developers, would be to make OpenSim easy to use (so that ANYONE can get up and running in less than 10 minutes). I believe every single tested module should be included with the default distro's. So that users can easily enable/disable whatever modules they want, and users know that the modules included with each distro have been tested, and are working modules. At this point in time, does ANYONE actually know what works, and what doesn't work? Do we actually have a working distro, with working modules (that have been tested to work) with an actual OpenSim release? Since 0.7 release is supposed to be coming out soon (in a week?) is there any way that we can stop development, and begin testing all the OpenSim modules, and add all the OpenSim modules (that have been tested and are working) to an OpenSim 0.7 release candidate? RealXtend does a very good job of doing this (with their old distros), but now that ModRex is integrated with OpenSim core, we're back to the drawing board again. If someone wants to enable ModRex, they should just be able to uncomment out a line in the default .ini file, and all the features of ModRex should work. If someone wants to enable currency, they should just be able to just uncomment out a line in the default .ini file, and now the currency module should be enabled. Why not make things SIMPLE and EASY to use? If someone wants to write a module (and wants it included with the OpenSim distro) then it needs to be tested, and once it has been tested (and confirmed to work) then it can be included with the OpenSim distro. This way at least we know what modules work (and are tested). OpenSim has evolved so quickly, that I'm not quite sure what modules even exist (or even work) at this point, and I have a few old distro's running, but I was too scared to even upgrade because everyone said that "OpenSim is currently broken" (due to all the latest changes) and people really just really want a WORKING distro (with working modules). I'm still running OpenSim 0.62 and ReX Server 0.4 on my local machines simply because it has been months where things have been completely broken (as OpenSim trunk would not even compile) and OpenSim has been making some backend changes and I'm still not even sure that ModRex/RealXtend even works since it has migrated over to OpenSim? I think your definition of "extensibility" and "extensible systems architecture" is different from mine. I believe in having something that ACTUALLY WORKS (out of the box), and extensibility means that new capabilities could EASILY be added without having to make changes to the system infrastructure. Your definition of "extensibility" seems to mean, nothing works, everything is broken, and you need to hire a software engineer just to get a few basic modules up and running. In my opinion, "extensibility" means that all the various modules would come by default with the default OpenSim distro, and they could easily be turned on (enabled) or turned off (disabled) by simply uncommenting a line in the default.ini file. Similar to PHP distro, or Apache server, or various other platforms. Either OpenSim is an Application or it's an Operating System. Since it doesn't run on bare metal, I certainly would NOT call it an Operating System, therefore I would consider it a software Application. I would consider OpenSim a 3D development platform. In my opinion, I would consider OpenSim a Server platform (software application) and you need both the OpenSim Server (platform) and a compatible Viewer to make OpenSim work. The problem is that OpenSim has evolved so much (and so quickly) that much of the Wiki documentation is outdated, no one is quite sure what even works at this point, and what doesn't work at this point. There is no list of recently "tested" modules (that are known to work with the current build/latest distro). Most "noobs" just really want a distro that they can easily download (maybe in a VMWare format) so they can just fire up a pre-configured image, and be up and running in minutes (instead of days or weeks). I'm willing to help test, and I'm willing to help with documentation, and I'm willing to even create "distros" that are easy to use (and that are tested and working) but it seems like nobody is working together. What if we just STOPPED developing, for just ONE week, and worked together on creating an actual distro? Just a working (and well tested) distro, that is thoroughly tested, that is STABLE, and that has all the OpenSim modules working with it? Then release it as a OpenSim 0.7 release. That's all I ask. Then after OpenSim 0.7 release candidate comes out (and it well tested, and all the modules from the OpenSim GForge are tested to work and be compatible with the 0.7 release, and then we wrap everything up, and release it as a working distro! Just halt development for 1 week, and just focus on bug fixes, and getting the modules to all work so we can just have a nice OpenSim 0.7 release candidate, with lots of working modules (that are all tested) and are included in the default distro. People can still choose what modules they wish to enable, but at least include all the known working modules with the default distro (or create a "vanilla" distro, and a "full distro" with the OpenSim 0.7 Release). That way one has the working modules, and the other doesn't have the working modules. But this way at least we can have an actual TESTED release candidate, that has all the working OpenSim modules (with updated documentation). I'm willing to help with documentation, and testing, but I just want to see an actual release candidate (with working modules) come out. On Wed, Sep 30, 2009 at 2:03 PM, wrote: > Mark Malewski wrote: > > It would just be nice to get everything integrated back into core (or as > > OpenSim modules). > > This would be terrible. We're going in the opposite direction, which is > to have a minimal core and let people do their own extensions as they > wish, hopefully replacing the heck out of the reference implementations. > > I think you, and maybe others here, may need to understand better this > concept of extensible systems. That's at the very core of OpenSim from > the beginning, even before I started contributing -- OpenSim is not an > application, it's a platform with which to build applications. > > Some extenders of OpenSim may want to get together and try to make their > extensions work with each other. That's great and desirable. But let's > not prevent innovative ideas from emerging by throwing a massive > feature-full application out there as "OpenSim". > > Diva / Crista > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > --001485f1ecf4de0dba0474d34838 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Diva,

>> It wou= ld just be nice to get everything integrated back into core (or as
>&= gt; OpenSim modules).
>
>This would be terrible= .=A0

Diva, please explain WHY would having a working OpenSim= distro be terrible? =A0Having something that actually "works" is= terrible? =A0In my opinion, just the opposite is true.

You can spend your whole life developing things (that no one actually = uses, and that don't actually work or do much of anything, and that no = one will ever use) or you can make a WORKING product that is usable, and th= at is EASY to use, and that people will use.

You seem to prefer the latter. =A0

=

> I think you, and maybe others here, may need to u= nderstand better this
>concept of extensible systems. That's at t= he very core of OpenSim from
>the beginning, even before I started contributing -- OpenSim is not an<= br>>application, it's a platform with which to build applications.
I think you need to sit down and understand the concept = of "working product". =A0You also need to stop confusing "ex= tensible system" with "not working" product.

PHP, and Apache are what I would c= onsider "extensible systems". =A0PHP is easily downloaded, and it= works (out of the box). =A0Yet it comes with many different modules (as pa= rt of the default distro) and those modules have all been thoroughly tested= , and can easily be enabled by simply uncommenting out the module name in t= he default.ini file.

From an engineering standpoint, extensibility m= eans the system is designed to include hooks and mechanisms for expanding/e= nhancing the system with new capabilities WITHOUT having to make major chan= ges to the system infrastructure.=A0

OpenSim doesn't seem to be "extensible". = =A0OpenSim seems to be "broken". =A0There is a big difference. = =A0Maybe your definition of "extensible" means that it requires a= rocket scientist just to get the trunk to even compile (or even work), and= takes hours and hours of debugging code, just to get a module to even work= . =A0That isn't my idea of "extensible".

I understand over the past few months, the server infra= structure (and architecture) has been changing quite a bit. =A0It's har= d to even tell if ModRex (or any other modules) even work with the current = OpenSim trunk (or latest build) at this point. =A0

The average layperson doesn't want to spend hours a= nd hours trying to compile from source, or debugging code, or searching for= plugins/modules that may (or may not) exist, and even worse many of them m= ay not be updated, or may not even work with the current OpenSim as "c= ore" evolves. =A0Often times many of these modules are not updated, an= d most have no clue how to even build from source, and for this reason it m= ight be good to just have VERY simple "turn-key" distributions av= ailable for download. (Stable releases)

Similar to how RealXtend has done in the past. =A0

I supposed I could sit down and begin working on creat= ing a fully configured VMWare image =A0of OpenSim with various modules inst= alled and configured, that people could easily download, and be up and runn= ing in a few minutes (without having to hunt for various modules, or applic= ations), or sifting through outdated wiki pages trying to figure out how to= even get started or even get up and running, but to be honest most people = just want something VERY easy to use, VERY easy to setup, and would love a = nice GUI interface (like WixTD, etc.) that they can use to administer the s= erver, add users, etc.

Most laypeople don't want to hire a software engine= er, or a programmer, just to get OpenSim to compile, or even get a module w= orking, or just to get OpenSim running on a machine. =A0

If I want to use a plugin with Firefox, I've NEVER had to compile = or debug code. =A0If I want to enable a PHP module, I've NEVER had to d= ebug any code. =A0Most modules are included in the default distro, and modu= les can easily be turned on and off, by simply "enabling" them in= the default ini (configuration) file.

In my opinion, you may be confusing "extensible sy= stem" as an excuse as to why nothing should work properly.
<= br>
In my opinion, EVERY single working module that exists for Op= enSim should be included in the default distro (in the modules directory), = and these modules should ALL be disabled by default, but can be easily enab= led by simply uncommenting out ONE single line in the default.ini configura= tion file.

Include EVERY single working module with the default Op= enSim distro, so users have a list of default working modules that are regu= larly updated so that they actually work (and are not broken), so that when= a stable release comes out, a user can just enable or disable whatever mod= ules they wish to use (by uncommenting out a line or two in the default .in= i configuration file) and those modules are in the modules directory, and c= an easily be enabled by just uncommenting out a single line in the default = ini configuration file.

The problem is, it seems like a herd of cats are headed= in all opposite directions, and people really just want something that act= ually works. =A0Diva, is that honestly too much to ask?

There are Applications and there are Operating Systems. =A0What do you= call OpenSim? =A0Is it an Application or an Operating System? =A0(or is it= neither?)

When I say "works", I'm t= alking about someone can download OpenSim, and be up and running (designing= things from within the OpenSim Application platform such as creating 3D co= ntent, in-world). =A0Not sitting down and downloading source code, or attem= pting to figure out how to learn C# or C++ or how to write a module, just t= o get simple things running.

The thing that made RealXtend so popular was that it wa= s easy to use, and they had distros that were already setup and ready to us= e (even with a nice "beneath the sea" demo world as part of the d= istro).

Keep in mind that most of the people interested in Open= Sim as a 3D development platform are laypeople, and are graphics designers = (and Second Life users) that are NOT Computer Science majors, and are not e= ngineers, and really don't know ANY programming languages (some may kno= w a bit of Java, or HTML, or LSL), but most don't even know=A0C++ or C#= =A0nor would they have any idea how to even compile or build from source. = =A0They just want to use OpenSim to design 3D content, and create their own= virtual world.

Do you expect a web developer to know C? or C++? or C#?=

Try thinking of OpenSim as a "3D Web Server&= quot; for users (similar to Apache). =A0Yes, Apache is extensible, and many= modules can be written for Apache, but most of the common modules are alre= ady tested and included with the Apache distro. =A0Modules are tested, and = included with all the latest releases, and users can easily comment (or unc= omment) out a single line in the default configuration file, and have the i= ncluded modules working.

So I believe the key to making OpenSim widely adopted a= s a "usable" platform for 3D developers, would be to make OpenSim= easy to use (so that ANYONE can get up and running in less than 10 minutes= ). =A0I believe every single tested module should be included with the defa= ult distro's. =A0So that users can easily enable/disable whatever modul= es they want, and users know that the modules included with each distro hav= e been tested, and are working modules.

At this point in time, does ANYONE actually know what w= orks, and what doesn't work? =A0Do we actually have a working distro, w= ith working modules (that have been tested to work) with an actual OpenSim = release?

Since 0.7 release is supposed to be coming out soon (in= a week?) is there any way that we can stop development, and begin testing = all the OpenSim modules, and add all the OpenSim modules (that have been te= sted and are working) to an OpenSim 0.7 release candidate?

RealXtend does a very good job of doing this (with thei= r old distros), but now that ModRex is integrated with OpenSim core, we'= ;re back to the drawing board again.=A0

If someone= wants to enable ModRex, they should just be able to uncomment out a line i= n the default .ini file, and all the features of ModRex should work. =A0If = someone wants to enable currency, they should just be able to just uncommen= t out a line in the default .ini file, and now the currency module should b= e enabled. =A0

Why not make things SIMPLE and EASY to use?
<= br>
If someone wants to write a module (and wants it included wit= h the OpenSim distro) then it needs to be tested, and once it has been test= ed (and confirmed to work) then it can be included with the OpenSim distro.= =A0This way at least we know what modules work (and are tested).

OpenSim has evolved so quickly, that I'm not quite = sure what modules even exist (or even work) at this point, and=A0I have a f= ew old distro's running, but I was too scared to even upgrade because e= veryone said that "OpenSim is currently broken" (due to all the l= atest changes) and people really just really want a WORKING distro (with wo= rking modules).

I'm still running OpenSim 0.62 and ReX Server 0.4 o= n my local machines simply because it has been months where things have bee= n completely broken (as OpenSim trunk would not even compile) and OpenSim h= as been making some backend changes and I'm still not even sure that Mo= dRex/RealXtend even works since it has migrated over to OpenSim? =A0

I think your definition of "extensibility" an= d "extensible systems architecture" is different from mine. =A0I = believe in having something that ACTUALLY WORKS (out of the box), and exten= sibility means that new capabilities could EASILY be added without having t= o make changes to the system infrastructure.

Your definition of "extensibility" seems to m= ean, nothing works, everything is broken, and you need to hire a software e= ngineer just to get a few basic modules up and running.

In my opinion, "extensibility" means that all the various mo= dules would come by default with the default OpenSim distro, and they could= easily be turned on (enabled) or turned off (disabled) by simply uncomment= ing a line in the default.ini file. =A0Similar to PHP distro, or Apache ser= ver, or various other platforms.

Either OpenSim is an Application or it's an Operati= ng System. =A0Since it doesn't run on bare metal, I certainly would NOT= call it an Operating System, therefore I would consider it a software Appl= ication. =A0I would consider OpenSim a 3D development platform.

In my opinion, I would consider OpenSim a Server platfo= rm (software application) and you need both the OpenSim Server (platform) a= nd a compatible Viewer to make OpenSim work.

The p= roblem is that OpenSim has evolved so much (and so quickly) that much of th= e Wiki documentation is outdated, no one is quite sure what even works at t= his point, and what doesn't work at this point. There is no list of rec= ently "tested" modules (that are known to work with the current b= uild/latest distro).=A0

Most "noobs" just really want a distro that t= hey can easily download (maybe in a VMWare format) so they can just fire up= a pre-configured image, and be up and running in minutes (instead of days = or weeks).

I'm willing to help test, and I'm willing to he= lp with documentation, and I'm willing to even create "distros&quo= t; that are easy to use (and that are tested and working) but it seems like= nobody is working together.

What if we just STOPPED developing, for just ONE week, = and worked together on creating an actual distro? =A0Just a working (and we= ll tested) distro, that is thoroughly tested, that is STABLE, and that has = all the OpenSim modules working with it?

Then release it as a OpenSim 0.7 release.
That's all I ask. =A0Then after OpenSim 0.7 release candida= te comes out (and it well tested, and all the modules from the OpenSim GFor= ge are tested to work and be compatible with the 0.7 release, and then we w= rap everything up, and release it as a working distro!

Just halt development for 1 week, and just focus on bug= fixes, and getting the modules to all work so we can just have a nice Open= Sim 0.7 release candidate, with lots of working modules (that are all teste= d) and are included in the default distro. =A0

People can still choose what modules they wish to enabl= e, but at least include all the known working modules with the default dist= ro (or create a "vanilla" distro, and a "full distro" w= ith the OpenSim 0.7 Release). =A0That way one has the working modules, and = the other doesn't have the working modules.

But this way at least we can have an actual TESTED rele= ase candidate, that has all the working OpenSim modules (with updated docum= entation).

I'm willing to help with documentat= ion, and testing, but I just want to see an actual release candidate (with = working modules) come out.



On Wed, S= ep 30, 2009 at 2:03 PM, <diva at metaverseink.com> wrote:
Mark Malewski wrote:
> It would just be nice to get everything integrated back into core (or = as
> OpenSim modules).

This would be terrible. We're going in the opposite direction, wh= ich is
to have a minimal core and let people do their own extensions as they
wish, hopefully replacing the heck out of the reference implementations.
I think you, and maybe others here, may need to understand better this
concept of extensible systems. That's at the very core of OpenSim from<= br> the beginning, even before I started contributing -- OpenSim is not an
application, it's a platform with which to build applications.

Some extenders of OpenSim may want to get together and try to make their extensions work with each other. That's great and desirable. But let= 9;s
not prevent innovative ideas from emerging by throwing a massive
feature-full application out there as "OpenSim".

Diva / Crista
_________________________________________= ______
Opensim-dev mailing list
Opensim-dev at lists.berlios.d= e
https://lists.berlios.de/mailman/listinfo/opensim-dev

--001485f1ecf4de0dba0474d34838-- From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: to include hooks and mechanisms for expanding/enhancing the system with new= capabilities WITHOUT having to make major changes to the system infrastruc= ture. OpenSim doesn't seem to be "extensible". OpenSim seems to be "broken". Th= ere is a big difference. Maybe your definition of "extensible" means that = it requires a rocket scientist just to get the trunk to even compile (or ev= en work), and takes hours and hours of debugging code, just to get a module= to even work. That isn't my idea of "extensible". I understand over the past few months, the server infrastructure (and archi= tecture) has been changing quite a bit. It's hard to even tell if ModRex (= or any other modules) even work with the current OpenSim trunk (or latest b= uild) at this point. The average layperson doesn't want to spend hours and hours trying to compi= le from source, or debugging code, or searching for plugins/modules that ma= y (or may not) exist, and even worse many of them may not be updated, or ma= y not even work with the current OpenSim as "core" evolves. Often times ma= ny of these modules are not updated, and most have no clue how to even buil= d from source, and for this reason it might be good to just have VERY simpl= e "turn-key" distributions available for download. (Stable releases) Similar to how RealXtend has done in the past. I supposed I could sit down and begin working on creating a fully configure= d VMWare image of OpenSim with various modules installed and configured, t= hat people could easily download, and be up and running in a few minutes (w= ithout having to hunt for various modules, or applications), or sifting thr= ough outdated wiki pages trying to figure out how to even get started or ev= en get up and running, but to be honest most people just want something VER= Y easy to use, VERY easy to setup, and would love a nice GUI interface (lik= e WixTD, etc.) that they can use to administer the server, add users, etc. Most laypeople don't want to hire a software engineer, or a programmer, jus= t to get OpenSim to compile, or even get a module working, or just to get O= penSim running on a machine. If I want to use a plugin with Firefox, I've NEVER had to compile or debug = code. If I want to enable a PHP module, I've NEVER had to debug any code. = Most modules are included in the default distro, and modules can easily be= turned on and off, by simply "enabling" them in the default ini (configura= tion) file. In my opinion, you may be confusing "extensible system" as an excuse as to = why nothing should work properly. In my opinion, EVERY single working module that exists for OpenSim should b= e included in the default distro (in the modules directory), and these modu= les should ALL be disabled by default, but can be easily enabled by simply = uncommenting out ONE single line in the default.ini configuration file. Include EVERY single working module with the default OpenSim distro, so use= rs have a list of default working modules that are regularly updated so tha= t they actually work (and are not broken), so that when a stable release co= mes out, a user can just enable or disable whatever modules they wish to us= e (by uncommenting out a line or two in the default .ini configuration file= ) and those modules are in the modules directory, and can easily be enabled= by just uncommenting out a single line in the default ini configuration fi= le. The problem is, it seems like a herd of cats are headed in all opposite dir= ections, and people really just want something that actually works. Diva, = is that honestly too much to ask? There are Applications and there are Operating Systems. What do you call O= penSim? Is it an Application or an Operating System? (or is it neither?) When I say "works", I'm talking about someone can download OpenSim, and be = up and running (designing things from within the OpenSim Application platfo= rm such as creating 3D content, in-world). Not sitting down and downloadin= g source code, or attempting to figure out how to learn C# or C++ or how to= write a module, just to get simple things running. The thing that made RealXtend so popular was that it was easy to use, and t= hey had distros that were already setup and ready to use (even with a nice = "beneath the sea" demo world as part of the distro). Keep in mind that most of the people interested in OpenSim as a 3D developm= ent platform are laypeople, and are graphics designers (and Second Life use= rs) that are NOT Computer Science majors, and are not engineers, and really= don't know ANY programming languages (some may know a bit of Java, or HTML= , or LSL), but most don't even know C++ or C# nor would they have any idea = how to even compile or build from source. They just want to use OpenSim to= design 3D content, and create their own virtual world. Do you expect a web developer to know C? or C++? or C#? Try thinking of OpenSim as a "3D Web Server" for users (similar to Apache).= Yes, Apache is extensible, and many modules can be written for Apache, bu= t most of the common modules are already tested and included with the Apach= e distro. Modules are tested, and included with all the latest releases, a= nd users can easily comment (or uncomment) out a single line in the default= configuration file, and have the included modules working. So I believe the key to making OpenSim widely adopted as a "usable" platfor= m for 3D developers, would be to make OpenSim easy to use (so that ANYONE c= an get up and running in less than 10 minutes). I believe every single tes= ted module should be included with the default distro's. So that users can= easily enable/disable whatever modules they want, and users know that the = modules included with each distro have been tested, and are working modules= . At this point in time, does ANYONE actually know what works, and what doesn= 't work? Do we actually have a working distro, with working modules (that = have been tested to work) with an actual OpenSim release? Since 0.7 release is supposed to be coming out soon (in a week?) is there a= ny way that we can stop development, and begin testing all the OpenSim modu= les, and add all the OpenSim modules (that have been tested and are working= ) to an OpenSim 0.7 release candidate? RealXtend does a very good job of doing this (with their old distros), but = now that ModRex is integrated with OpenSim core, we're back to the drawing = board again. If someone wants to enable ModRex, they should just be able to uncomment ou= t a line in the default .ini file, and all the features of ModRex should wo= rk. If someone wants to enable currency, they should just be able to just = uncomment out a line in the default .ini file, and now the currency module = should be enabled. Why not make things SIMPLE and EASY to use? If someone wants to write a module (and wants it included with the OpenSim = distro) then it needs to be tested, and once it has been tested (and confir= med to work) then it can be included with the OpenSim distro. This way at = least we know what modules work (and are tested). OpenSim has evolved so quickly, that I'm not quite sure what modules even e= xist (or even work) at this point, and I have a few old distro's running, b= ut I was too scared to even upgrade because everyone said that "OpenSim is = currently broken" (due to all the latest changes) and people really just re= ally want a WORKING distro (with working modules). I'm still running OpenSim 0.62 and ReX Server 0.4 on my local machines simp= ly because it has been months where things have been completely broken (as = OpenSim trunk would not even compile) and OpenSim has been making some back= end changes and I'm still not even sure that ModRex/RealXtend even works si= nce it has migrated over to OpenSim? I think your definition of "extensibility" and "extensible systems architec= ture" is different from mine. I believe in having something that ACTUALLY = WORKS (out of the box), and extensibility means that new capabilities could= EASILY be added without having to make changes to the system infrastructur= e. Your definition of "extensibility" seems to mean, nothing works, everything= is broken, and you need to hire a software engineer just to get a few basi= c modules up and running. In my opinion, "extensibility" means that all the various modules would com= e by default with the default OpenSim distro, and they could easily be turn= ed on (enabled) or turned off (disabled) by simply uncommenting a line in t= he default.ini file. Similar to PHP distro, or Apache server, or various o= ther platforms. Either OpenSim is an Application or it's an Operating System. Since it doe= sn't run on bare metal, I certainly would NOT call it an Operating System, = therefore I would consider it a software Application. I would consider Ope= nSim a 3D development platform. In my opinion, I would consider OpenSim a Server platform (software applica= tion) and you need both the OpenSim Server (platform) and a compatible View= er to make OpenSim work. The problem is that OpenSim has evolved so much (and so quickly) that much = of the Wiki documentation is outdated, no one is quite sure what even works= at this point, and what doesn't work at this point. There is no list of re= cently "tested" modules (that are known to work with the current build/late= st distro). Most "noobs" just really want a distro that they can easily download (maybe= in a VMWare format) so they can just fire up a pre-configured image, and b= e up and running in minutes (instead of days or weeks). I'm willing to help test, and I'm willing to help with documentation, and I= 'm willing to even create "distros" that are easy to use (and that are test= ed and working) but it seems like nobody is working together. What if we just STOPPED developing, for just ONE week, and worked together = on creating an actual distro? Just a working (and well tested) distro, tha= t is thoroughly tested, that is STABLE, and that has all the OpenSim module= s working with it? Then release it as a OpenSim 0.7 release. That's all I ask. Then after OpenSim 0.7 release candidate comes out (and = it well tested, and all the modules from the OpenSim GForge are tested to w= ork and be compatible with the 0.7 release, and then we wrap everything up,= and release it as a working distro! Just halt development for 1 week, and just focus on bug fixes, and getting = the modules to all work so we can just have a nice OpenSim 0.7 release cand= idate, with lots of working modules (that are all tested) and are included = in the default distro. People can still choose what modules they wish to enable, but at least incl= ude all the known working modules with the default distro (or create a "van= illa" distro, and a "full distro" with the OpenSim 0.7 Release). That way = one has the working modules, and the other doesn't have the working modules= . But this way at least we can have an actual TESTED release candidate, that = has all the working OpenSim modules (with updated documentation). I'm willing to help with documentation, and testing, but I just want to see= an actual release candidate (with working modules) come out. On Wed, Sep 30, 2009 at 2:03 PM, > wrote: Mark Malewski wrote: > It would just be nice to get everything integrated back into core (or as > OpenSim modules). This would be terrible. We're going in the opposite direction, which is to have a minimal core and let people do their own extensions as they wish, hopefully replacing the heck out of the reference implementations. I think you, and maybe others here, may need to understand better this concept of extensible systems. That's at the very core of OpenSim from the beginning, even before I started contributing -- OpenSim is not an application, it's a platform with which to build applications. Some extenders of OpenSim may want to get together and try to make their extensions work with each other. That's great and desirable. But let's not prevent innovative ideas from emerging by throwing a massive feature-full application out there as "OpenSim". Diva / Crista _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev --_000_63FAD4F222230A4EA79DE9E8BE6647354D38EE74winxbeus19excha_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

tl; dr.

 

Adam

 

From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Mark Male= wski
Sent: Wednesday, 30 September 2009 3:45 PM
To: diva at metaverseink.com; opensim-dev at lists.berlios.de
Subject: [Opensim-dev] OpenSim 0.7 Release Candidate with ALL workin= g OpenSim Modules

 

Diva,

 

>> It would just be nice to get everything integrated back into core (or as
>> OpenSim modules).
>

>This would be terrible. 

 

Diva, please explain WHY would having a working OpenSi= m distro be terrible?  Having something that actually "works" = is terrible?  In my opinion, just the opposite is true.

 

You can spend your whole life developing things (that = no one actually uses, and that don't actually work or do much of anything, and tha= t no one will ever use) or you can make a WORKING product that is usable, and th= at is EASY to use, and that people will use.

 

You seem to prefer the latter.  

 

 

> I think you,= and maybe others here, may need to understand better this
>concept of extensible systems. That's at the very core of OpenSim from<= br> >the beginning, even before I started contributing -- OpenSim is not an<= br> >application, it's a platform with which to build applications.<= o:p>

I think you need to sit down and understand the concep= t of "working product".  You also need to stop confusing "extensible system" with "not working" product.

 

PHP, and Apache are what I would consider "extensible systems".  = PHP is easily downloaded, and it works (out of the box).  Yet it comes wit= h many different modules (as part of the default distro) and those modules ha= ve all been thoroughly tested, and can easily be enabled by simply uncommentin= g out the module name in the default.ini file.

 

From an engineering standpoint, extensibility means the system is designed to include hooks and mechanisms for expanding/enhancing the system with new capabilities WITHOUT having to make major changes to the system infrastructure. 

 

OpenSim doesn't seem to be "extensible".  OpenSim seems to be "broken".  There is a big differen= ce.  Maybe your definition of "extensible" means that it require= s a rocket scientist just to get the trunk to even compile (or even work), and takes hours and hours of debugging code, just to get a module to even work.  That isn't my idea of "extensible".

 

I understand over the past few months, the server infrastructure (and architecture) has been changing quite a bit.  It's hard to even tell if ModRex (or any other modules) even work with the curre= nt OpenSim trunk (or latest build) at this point.  

 

The average layperson doesn't want to spend hours and = hours trying to compile from source, or debugging code, or searching for plugins/modules that may (or may not) exist, and even worse many of them ma= y not be updated, or may not even work with the current OpenSim as "core" evolves.  Often times many of these modules are not updated, and most have no clue how to even build from source, and for this reason it might be good to just have VERY simple "turn-key" distributions available for download. (Stable releases)

 

Similar to how RealXtend has done in the past.  <= o:p>

 

I supposed I could sit down and begin working on creat= ing a fully configured VMWare image  of OpenSim with various modules install= ed and configured, that people could easily download, and be up and running in= a few minutes (without having to hunt for various modules, or applications), = or sifting through outdated wiki pages trying to figure out how to even get started or even get up and running, but to be honest most people just want something VERY easy to use, VERY easy to setup, and would love a nice GUI i= nterface (like WixTD, etc.) that they can use to administer the server, add users, e= tc.

 

Most laypeople don't want to hire a software engineer,= or a programmer, just to get OpenSim to compile, or even get a module working, o= r just to get OpenSim running on a machine.  

 

If I want to use a plugin with Firefox, I've NEVER had= to compile or debug code.  If I want to enable a PHP module, I've NEVER h= ad to debug any code.  Most modules are included in the default distro, a= nd modules can easily be turned on and off, by simply "enabling" the= m in the default ini (configuration) file.

 

In my opinion, you may be confusing "extensible system" as an excuse as to why nothing should work properly.

 

In my opinion, EVERY single working module that exists= for OpenSim should be included in the default distro (in the modules directory)= , and these modules should ALL be disabled by default, but can be easily enab= led by simply uncommenting out ONE single line in the default.ini configuration file.

 

Include EVERY single working module with the default O= penSim distro, so users have a list of default working modules that are regularly updated so that they actually work (and are not broken), so that when a sta= ble release comes out, a user can just enable or disable whatever modules they = wish to use (by uncommenting out a line or two in the default .ini configuration file) and those modules are in the modules directory, and can easily be ena= bled by just uncommenting out a single line in the default ini configuration fil= e.

 

The problem is, it seems like a herd of cats are heade= d in all opposite directions, and people really just want something that actuall= y works.  Diva, is that honestly too much to ask?

 

There are Applications and there are Operating Systems= .  What do you call OpenSim?  Is it an Application or an Operating System?  (or is it neither?)

 

When I say "works", I'm talking about someon= e can download OpenSim, and be up and running (designing things from within the OpenSim Application platform such as creating 3D content, in-world).  = Not sitting down and downloading source code, or attempting to figure out how t= o learn C# or C++ or how to write a module, just to get simple things running= .

 

The thing that made RealXtend so popular was that it w= as easy to use, and they had distros that were already setup and ready to use (even with a nice "beneath the sea" demo world as part of the distro).

 

Keep in mind that most of the people interested in Ope= nSim as a 3D development platform are laypeople, and are graphics designers (and= Second Life users) that are NOT Computer Science majors, and are not engineers, an= d really don't know ANY programming languages (some may know a bit of Java, o= r HTML, or LSL), but most don't even know C++ or C# nor would they = have any idea how to even compile or build from source.  They just want to = use OpenSim to design 3D content, and create their own virtual world.

 

Do you expect a web developer to know C? or C++? or C#= ?

 

Try thinking of OpenSim as a "3D Web Server"= for users (similar to Apache).  Yes, Apache is extensible, and many module= s can be written for Apache, but most of the common modules are already teste= d and included with the Apache distro.  Modules are tested, and included with all the latest releases, and users can easily comment (or uncomment) o= ut a single line in the default configuration file, and have the included module= s working.

 

So I believe the key to making OpenSim widely adopted = as a "usable" platform for 3D developers, would be to make OpenSim eas= y to use (so that ANYONE can get up and running in less than 10 minutes).  = I believe every single tested module should be included with the default distro's.  So that users can easily enable/disable whatever modules th= ey want, and users know that the modules included with each distro have been tested, and are working modules.

 

At this point in time, does ANYONE actually know what = works, and what doesn't work?  Do we actually have a working distro, with wor= king modules (that have been tested to work) with an actual OpenSim release?

 

Since 0.7 release is supposed to be coming out soon (i= n a week?) is there any way that we can stop development, and begin testing all= the OpenSim modules, and add all the OpenSim modules (that have been tested and= are working) to an OpenSim 0.7 release candidate?

 

RealXtend does a very good job of doing this (with the= ir old distros), but now that ModRex is integrated with OpenSim core, we're back t= o the drawing board again. 

 

If someone wants to enable ModRex, they should just be= able to uncomment out a line in the default .ini file, and all the features of ModRex should work.  If someone wants to enable currency, they should = just be able to just uncomment out a line in the default .ini file, and now the currency module should be enabled.  

 

Why not make things SIMPLE and EASY to use?=

 

If someone wants to write a module (and wants it inclu= ded with the OpenSim distro) then it needs to be tested, and once it has been tested (and confirmed to work) then it can be included with the OpenSim dis= tro.  This way at least we know what modules work (and are tested).

 

OpenSim has evolved so quickly, that I'm not quite sur= e what modules even exist (or even work) at this point, and I have a few old distro's running, but I was too scared to even upgrade because everyone sai= d that "OpenSim is currently broken" (due to all the latest changes= ) and people really just really want a WORKING distro (with working modules).=

 

I'm still running OpenSim 0.62 and ReX Server 0.4 on m= y local machines simply because it has been months where things have been completely broken (as OpenSim trunk would not even compile) and OpenSim has been making some backend changes and I'm still not even sure that ModRex/RealXtend even works since it has migrated over to OpenSim?  

 

I think your definition of "extensibility" a= nd "extensible systems architecture" is different from mine.  I believe in having something that ACTUALLY WORKS (out of the box), and extensibility means that new capabilities could EASILY be added without hav= ing to make changes to the system infrastructure.

 

Your definition of "extensibility" seems to = mean, nothing works, everything is broken, and you need to hire a software engine= er just to get a few basic modules up and running.

 

In my opinion, "extensibility" means that al= l the various modules would come by default with the default OpenSim distro, and = they could easily be turned on (enabled) or turned off (disabled) by simply uncommenting a line in the default.ini file.  Similar to PHP distro, o= r Apache server, or various other platforms.

 

Either OpenSim is an Application or it's an Operating System.  Since it doesn't run on bare metal, I certainly would NOT cal= l it an Operating System, therefore I would consider it a software Application.  I would consider OpenSim a 3D development platform.

 

In my opinion, I would consider OpenSim a Server platf= orm (software application) and you need both the OpenSim Server (platform) and = a compatible Viewer to make OpenSim work.

 

The problem is that OpenSim has evolved so much (and s= o quickly) that much of the Wiki documentation is outdated, no one is quite s= ure what even works at this point, and what doesn't work at this point. There i= s no list of recently "tested" modules (that are known to work with th= e current build/latest distro). 

 

Most "noobs" just really want a distro that = they can easily download (maybe in a VMWare format) so they can just fire up a pre-configured image, and be up and running in minutes (instead of days or weeks).

 

I'm willing to help test, and I'm willing to help with documentation, and I'm willing to even create "distros" that are = easy to use (and that are tested and working) but it seems like nobody is workin= g together.

 

What if we just STOPPED developing, for just ONE week,= and worked together on creating an actual distro?  Just a working (and wel= l tested) distro, that is thoroughly tested, that is STABLE, and that has all= the OpenSim modules working with it?

 

Then release it as a OpenSim 0.7 release.

 

That's all I ask.  Then after OpenSim 0.7 release candidate comes out (and it well tested, and all the modules from the OpenS= im GForge are tested to work and be compatible with the 0.7 release, and then = we wrap everything up, and release it as a working distro!

 

Just halt development for 1 week, and just focus on bu= g fixes, and getting the modules to all work so we can just have a nice OpenS= im 0.7 release candidate, with lots of working modules (that are all tested) a= nd are included in the default distro.  

 

People can still choose what modules they wish to enab= le, but at least include all the known working modules with the default distro = (or create a "vanilla" distro, and a "full distro" with the OpenSim 0.7 Release).  That way one has the working modules, and the o= ther doesn't have the working modules.

 

But this way at least we can have an actual TESTED rel= ease candidate, that has all the working OpenSim modules (with updated documentation).

 

I'm willing to help with documentation, and testing, b= ut I just want to see an actual release candidate (with working modules) come ou= t.

 

 

 

On Wed, Sep 30, 2009 at 2:03 PM, <diva at metaverseink.com> wrote:<= o:p>

Mark Malewski wrote: > It would just be nice to get everything integrated back into core (or = as
> OpenSim modules).

This would be terrible. We're going in the opposite direction, which is
to have a minimal core and let people do their own extensions as they
wish, hopefully replacing the heck out of the reference implementations.
I think you, and maybe others here, may need to understand better this
concept of extensible systems. That's at the very core of OpenSim from
the beginning, even before I started contributing -- OpenSim is not an
application, it's a platform with which to build applications.

Some extenders of OpenSim may want to get together and try to make their extensions work with each other. That's great and desirable. But let's
not prevent innovative ideas from emerging by throwing a massive
feature-full application out there as "OpenSim".

Diva / Crista

_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.d= e
https://lists.berlios.de/mailman/listinfo/opensim-dev

 

--_000_63FAD4F222230A4EA79DE9E8BE6647354D38EE74winxbeus19excha_-- From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: mocracy.html#electorate "The voting system itself should be used to choose new committers, both ful= l and partial. But here is one of the rare instances where secrecy is appro= priate. You can't have votes about potential committers posted to a public = mailing list, because the candidate's feelings (and reputation) could be hu= rt. Instead, the usual way is that an existing committer posts to a private= mailing list consisting only of the other committers, proposing that someo= ne be granted commit access. The other committers speak their minds freely,= knowing the discussion is private. Often there will be no disagreement, an= d therefore no vote necessary. After waiting a few days to make sure every = committer has had a chance to respond, the proposer mails the candidate and= offers him commit access. If there is disagreement, discussion ensues as f= or any other question, possibly resulting in a vote. For this process to be= open and frank, the mere fact that the discussion is taking place at all s= hould be secret. If the person under consideration knew it was going on, an= d then were never offered commit access, he could conclude that he had lost= the vote, and would likely feel hurt. Of course, if someone explicitly ask= s for commit access, then there is no choice but to consider the proposal a= nd explicitly accept or reject him. If the latter, then it should be done a= s politely as possible, with a clear explanation: "We liked your patches, b= ut haven't seen enough of them yet," or "We appreciate all your patches, bu= t they required considerable adjustments before they could be applied, so w= e don't feel comfortable giving you commit access yet. We hope that this wi= ll change over time, though." Remember, what you're saying could come as a = blow, depending on the person's level of confidence. Try to see it from the= ir point of view as you write the mail." --- I personally suggest reading that whole chapter (#4) for reasons why a lot = of projects have a committers mailing list (and yes it is a standard practi= ce.) Adam > -----Original Message----- > From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev- > bounces at lists.berlios.de] On Behalf Of Ryan McDougall > Sent: Monday, 19 October 2009 9:33 PM > To: opensim-dev at lists.berlios.de > Subject: [Opensim-dev] The notion of "core" >=20 > On Tue, Oct 20, 2009 at 2:49 AM, Frisby, Adam > wrote: > > Ter pretty much summed it up - both it and the irc channel are fairly > low-volume, and the 'topic' is restricted to only 'personal' or 'meta' > matters; such as discussion of approval of commit rights. > > > > It's pretty standard practice across open source projects with more > than 5 committers for the committers to have a mailing list for these > purposes, since realtime chats aren't practical across timezones. > > > > Adam > > >=20 > I am not sure I'd agree just how standard a process it is. >=20 > The one's I've been involved with or otherwise have some detailed > knowledge of, have never had them; including such big names as GNOME, > Fedora, and Linux. For example the GNOME foundation list is not only > world-readable, but anyone can join: > http://mail.gnome.org/mailman/listinfo/foundation-list . Actual > foundation members are voted by the community at large. >=20 > Basically the way they are able to operate is, they don't distribute > commit access according to monolithic vote of knighted members; they > have a system of maintainership, and each maintainer gives access > rights to his module/repo as she sees fit, in a web of trust. >=20 > One of the complaints one sometimes hears is how monolithic the > project is (even if the code-base is modular). Maybe the move to git, > and the maturation of the code allows more distribution and > specialization of responsibility? >=20 > My concerns with core mailing list are: >=20 > 1. It's "secret", ie. not world readable. I can understand limiting > membership to voting partners to avoid bikeshedding, but I can't > understand secrecy of any kind in an open source project. >=20 > 2. Decisions made there (aside from commit rights) affect other > people, and they not only have no voice to represent themselves, they > don't even get to know what is being said about them. That doesn't > seem fair somehow. >=20 > The knowledge that someone can read what you write makes you think > harder about what you say. Maybe a private list makes the problem of > disagreement within core worse rather than better? I haven't the > faintest idea who this snowcrash guy is, but when I was a topic of > discussion on -core, I remember not liking it at all. >=20 > As for the issue of timezones, I understand that completely! Which is > why I wish you guys used ML more frequently! :) >=20 > My intention is not to bike-shed, but to be productive. Either opensim > core is open to this point of view or it's not, and we move on from > there. >=20 > Cheers, and much love! > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: "The voting system itself should be used to choose new committers, both full and partial. But here is one of the rare instances where secrecy is appropriate. You can't have votes about potential committers posted to a public mailing list, because the candidate's feelings (and reputation) could be hurt. Instead, the usual way is that an existing committer posts to a private mailing list consisting only of the other committers, proposing that someone be granted commit access. The other committers speak their minds freely, knowing the discussion is private. Often there will be no disagreement, and therefore no vote necessary. After waiting a few days to make sure every committer has had a chance to respond, the proposer mails the candidate and offers him commit access. If there is disagreement, discussion ensues as for any other question, possibly resulting in a vote. For this process to be open and frank, the mere fact that the discussion is taking place at all should be secret . If the person under consideration knew it was going on, and then were never offered commit access, he could conclude that he had lost the vote, and would likely feel hurt. Of course, if someone explicitly asks for commit access, then there is no choice but to consider the proposal and explicitly accept or reject him. If the latter, then it should be done as politely as possible, with a clear explanation: "We liked your patches, but haven't seen enough of them yet," or "We appreciate all your patches, but they required considerable adjustments before they could be applied, so we don't feel comfortable giving you commit access yet. We hope that this will change over time, though." Remember, what you're saying could come as a blow, depending on the person's level of confidence. Try to see it from their point of view as you write the mail." --- I personally suggest reading that whole chapter (#4) for reasons why a lot of projects have a committers mailing list (and yes it is a standard practice.) Adam > -----Original Message----- > From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev- > bounces at lists.berlios.de] On Behalf Of Ryan McDougall > Sent: Monday, 19 October 2009 9:33 PM > To: opensim-dev at lists.berlios.de > Subject: [Opensim-dev] The notion of "core" > > On Tue, Oct 20, 2009 at 2:49 AM, Frisby, Adam > wrote: > > Ter pretty much summed it up - both it and the irc channel are fairly > low-volume, and the 'topic' is restricted to only 'personal' or 'meta' > matters; such as discussion of approval of commit rights. > > > > It's pretty standard practice across open source projects with more > than 5 committers for the committers to have a mailing list for these > purposes, since realtime chats aren't practical across timezones. > > > > Adam > > > > I am not sure I'd agree just how standard a process it is. > > The one's I've been involved with or otherwise have some detailed > knowledge of, have never had them; including such big names as GNOME, > Fedora, and Linux. For example the GNOME foundation list is not only > world-readable, but anyone can join: > http://mail.gnome.org/mailman/listinfo/foundation-list . Actual > foundation members are voted by the community at large. > > Basically the way they are able to operate is, they don't distribute > commit access according to monolithic vote of knighted members; they > have a system of maintainership, and each maintainer gives access > rights to his module/repo as she sees fit, in a web of trust. > > One of the complaints one sometimes hears is how monolithic the > project is (even if the code-base is modular). Maybe the move to git, > and the maturation of the code allows more distribution and > specialization of responsibility? > > My concerns with core mailing list are: > > 1. It's "secret", ie. not world readable. I can understand limiting > membership to voting partners to avoid bikeshedding, but I can't > understand secrecy of any kind in an open source project. > > 2. Decisions made there (aside from commit rights) affect other > people, and they not only have no voice to represent themselves, they > don't even get to know what is being said about them. That doesn't > seem fair somehow. > > The knowledge that someone can read what you write makes you think > harder about what you say. Maybe a private list makes the problem of > disagreement within core worse rather than better? I haven't the > faintest idea who this snowcrash guy is, but when I was a topic of > discussion on -core, I remember not liking it at all. > > As for the issue of timezones, I understand that completely! Which is > why I wish you guys used ML more frequently! :) > > My intention is not to bike-shed, but to be productive. Either opensim > core is open to this point of view or it's not, and we move on from > there. > > Cheers, and much love! > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: evolution of virtual worlds. It is no surprise that most Opensim developers wish to go beyond that first step, learning from past mistakes and finding better models for the future. I mentioned earlier our work at the IETF on new VW protocols, in which LL are a leading party --- see https://www.ietf.org/mailman/listinfo/ogpx , the mailing list of the VWRAP working group. What may surprise you is that even Lindens know that the current SL is not a good model for the future, which is why the protocols being discussed go far beyond their legacy ones. Indeed, Lindens will be facing a huge rewrite if this work bears fruit. When even Lindens don't wish their future to be constrained by the current SL design because they know its many problems, this really highlights how bad it would be for the Opensim team to do so. :-) I hope that one or more of these issues resonates with you, and makes it a bit clearer why Opensim really cannot afford to align itself with SL. There is no future in looking backwards. Morgaine. ======================================= On Mon, Nov 23, 2009 at 1:06 PM, Len Brown wrote: > Rock, > > I sympathize with you on many levels. I've also had my doubts > regarding the future of OpenSim, but I have also maintained some degree of > faith that things will pull through in the end. > > For me the shock came when I was abruptly informed that "OpenSim is > not Second Life, is not intended to be like Second Life, nor ever will." I > still haven't the foggiest idea what this developer had smoked for them to > so strongly assert that incredibly false statement. > > For me, the enjoyment of OpenSim has come from my intense devotion to > building and skinning. In fact, for the last few months I've been working > on a full region that has many hundreds of skins, clothes, hair, furniture, > etc, etc, that I'd like to package up as an OAR and give out freely, since > repeatedly I've been told that instead of giving money to help further > OpenSim I'd do more proactively by giving content. So I plan to do just > that and give my money to other open source initiatives that matter to me. > > I have a passion for writing, and have thought many times that one of > the greatest powers OpenSim would gain is having simple, straightforward, > step-by-step instructions on how to download, compile, install, administer > and overall just plain operate the core applications. What kills me is that > everyone who does a search for OpenSim inevitably hits the > opensimulator.org site and that is where the massive roadblock presents > itself. It's useless for most and irrelevant to the few who consider > themselves OpenSim experts. > > Heck, even now on the configuration page it still displays info for > 0.6.6 including (months old) known bugs in setting up region xml files. If > there was appointed a volunteer whose sole job was to keep information on > opensimulator.org relevant that one task would resolve a mountain of > negativity right there. I sit here in front of my computers a good 10 to 12 > hours a day. > > I would sincerely love to contribute to the OpenSim project, > especially in documentation support. But the thing holding me back is > communication. If I cannot get a straight answer on who to GIVE money to in > order to help, then I stand little chance of getting clear, straight answers > from developers when asking about issues I need to consider and incorporate > in documentation. > > If communication is a hurdle we can all overcome, with a genuine and > heart-felt effort to relay information, motives, and plans with one another, > then I'd sincerely appreciate having the opportunity to personally > contribute. I'm not a programmer today, but have a degree in programming > fro the 90's (so much has changed my degree is practically useless in that > regard). But I do know how to explain things and relay information in > simple terms. But only if my own questions will be answered with more than > "look it up or figure it out yourself" as my answer. > > If any of you would appreciate my help, feel free to let me know at > any time and I'll do what I can. > > - Len W. Brown > lenwbrown at gmail.com > > > On Mon, Nov 23, 2009 at 6:23 AM, Colin B. Withers < > Colin.Withers at eumetsat.int> wrote: > >> Hi guys, >> >> I have decided to leave the Opensim project. You will probably not even >> notice if I leave, as not being a programmer my only inputs were the writing >> of the step-by-step tutorials ( >> http://chapter-and-metaverse.blogspot.com/ ), the drafts of the OpenSim >> User Manual on the Forge, and helping out in the IRC channels, for >> newcomers. >> >> You may find my reasons for leaving Opensim interesting though (and please >> do not construe any of my reasons as an attack on anyone). >> >> 1. The Platform >> I raised this several times in the past in IRC, and made posts on my blog >> about the product lifecycle of the platform ( >> http://rock-vacirca.blogspot.com/2009/02/direction-of-virtual-worlds.html). I believe that the platforms underpinning both Second Life and Opensim >> are quite long in the tooth now, and I questioned how much product lifecycle >> there was left, particularly given that Opensim is now nearing 3 years of >> development, is still in Alpha, and if the current release of 0.6.7 is any >> indicator, then still only around two thirds into the development cycle. >> With the (inevitable) coming of much superior platforms, such as Blue Mars >> and (as a virtual world); Unity, for browser-based Virtual Wolrds; and now >> UDK (for creating sandboxes, standalones, and open grids), then I fear that >> Opensim has missed the boat as far as the remaining lifecycle of the >> platform is concerned. When you show people what is possible with these >> engines (for example this avatar editor for the forthcom >> ing APB (using the Unreal Engine): >> http://www.youtube.com/watch?v=icR3LtEMvZI or this city: >> http://www.youtube.com/watch?v=hmLzNbPXMDg (using the CryEngine), then >> neither SL not Opensim stands comparison. >> >> 2. Lack of Support for Currency in Opensim >> I felt the impact of this when I first made the switch from SL to Opensim. >> I had a thriving RP sim in SL (over 50 people, mainly female) and they all >> agreed to follow me over to my Opensim and the OSGrid. However, within a >> month they had all left, citing the same reason, the lack of places to shop, >> to buy the quality stuff they wanted (skins, hair, clothes etc), as a >> quality appearance, and the fun of shopping is what all the females placed >> high on their requirements from a Virtual World. They drifted back to Second >> Life, and the guys followed them. I have always believed that the lack of >> support for currency in the core was a mistake, but that is just my opinion. >> >> 3. Marketing >> I have also raised this issue several times, and blogged about it. It is >> far from clear just who an eventually released Opensim is actually aimed at. >> I think that any company that is interested in a firewalled corporate >> solution to collaboration and prototyping will already be looking at the >> Enterprise solution that is currently available from Second Life; that any >> indie group that is thinking of running a themed grid will need an economy >> to stay viable; and any individual who is looking for a private sandbox >> solution for their SL work will need full compatibility (which is not the >> case with the OS version of LSL diverging from the SL LSL). So, just who is >> the platform aimed at? I was also very disappointed in the view of one of >> the core devs who said that 'marketing is a null concept for us'. >> >> I am currently designing and creating cities for Blue Mars, and involved >> in a team for proving the UDK as a platform for the design and creation of >> Virtual Worlds (as opposed to purely games), and with so much documentation >> available for these mature engines (particularly for the UDK, Blue Mars lags >> behind somewhat in that department, but have hired extra staff to put that >> right), I am achieving the productivity I want, building the worlds that I >> want, with stable crash-free platforms. >> >> However, I do wish the Opensim team the very best in their endeavours, and >> I sincerely hope their goals are eventually achieved. >> >> If anyone would like to take over the Opensim Tutorials pages at >> http://chapter-and-metaverse.blogspot.com/ and >> http://chapter-and-metaverse2.blogspot.com/ (they will need some updating >> following several changes) then I am more than willing to pass the posts >> over, and of course the Opensim User Manual is there in the Forge for anyone >> to develop further. >> >> Best Regards and Good Luck >> >> Rock >> >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > --0016e6d7eefa4147ee047911d695 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Nov 23, 2009 at 1:06 PM, Len Brown <lenwbrown at gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 2= 04, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
For me the shock came when I was abruptly informed that "OpenSim is not Se= cond Life, is not intended to be like Second Life, nor ever will."=A0 I= still haven't the foggiest idea what this developer had smoked for them to so strongly assert that incredibly false statement.


= Len, let me give you an alternative perspective on that quote to help you s= ee the reasons for it.=A0 I'm not on the Opensim team, but after five y= ears in SL, two years in AWG, and a year of working on future VW protocols = in our IETF group, I have some background to know why Opensim needs to dist= ance itself from SL:

  • SL's statically tiled resource architecture is badly non= -scalable, because most resource usage in VWs cannot be statically mapp= ed (demand moves around).=A0 The inability to assign resources dynamically = in SL results in huge overload in busy places and gross wastage in idle are= as.=A0 It also limits the number of participants in events and the bandwidt= h of their interaction, as well as the size and complexity of everything in= a region.=A0 This architecture is fundamental to SL, yet it is a recipe fo= r failure.=A0 As long as Opensim adheres to the SL model, Opensim will be s= imilarly non-scalable.

  • The LSL scripting language is linguistically weak, semanti= cally obscure, and lacking in the glue that could allow components to coope= rate effectively.=A0 As a result, individual scripts are quite underpowered= and inefficient, and multi-script constructions do not scale well in compl= exity because the overheads of cooperation are so large.=A0 That's a ba= d restriction on progress which Opensim needs to leave behind.

  • LSL scripts are not scalable in power or size, and this wi= ll continue to be true even after SL allows C# and other CLR languages to b= e used.=A0 There is no possibility of using more CPU power for scripting th= an is available in one single simulator in SL.=A0 That is not a good founda= tion upon which to build an ambitious future of clever components.

  • SL's simulation environment is non-portable, having ev= olved over time into a plethora of special cases that will not be accuratel= y replicable anywhere else.=A0 In effect this means that there will never b= e effective interop with SL's scripted objects.=A0 It would not be a us= eful goal to seek compatibility with what could realistically be described = as an "ill-defined mess".

  • SL's object and type systems are non-extensible= , so compatibility with SL means living in the past, and worse, living in a= past defined entirely by one slow-moving company.=A0 Tying the capabilitie= s of Opensim to that millstone would be a disaster --- it would ensure the = death of Opensim versus any extensible alternative that may appear.=A0 Deve= loping new extensible forms of world data beyond SL's original set is a= must for Opensim's survival as a modern VW platform.

  • SL's viewer has deep knowledge of SL semantics be= cause the client and server were designed for each other rather than design= ed as endpoints of a standard protocol.=A0 This has the very bad consequenc= e that future VW viewers would need to know about SL specifics in order to = interoperate with SL, which is a poor approach that doesn't scale to me= taverse-wide diversity.=A0 Opensim needs to leave world-specific kludges be= hind if it has ambitions to underpin a highly diverse metaverse of worlds, = and this means leaving the SL viewer behind.

  • SL's constructed objects are non-hierarchical, = which means that creators cannot use objects created by others as subcompon= ents.=A0 This restriction completely blocks the hierarchical engineering pr= ocess that is the basis of progress in RL.=A0 In SL you always have to buil= d from "raw materials", so it is not possible to ride on the shou= lders of giants, nor harness a huge pyramid of people skills.=A0 Even Phili= p and Cory Linden admitted that this was a mistake -- see=A0 https://wiki.secon= dlife.com/wiki/Prim_and_Object_Hierarchy .=A0 We don't want to live= with their mistake.

  • SL is based on highly centralized concepts of id= entity, storage and control, which come together to create either a wal= led garden or a prison planet, depending on one's perspective.=A0 Whate= ver one's worldview, the end result is badly non-scalable in those thre= e areas.=A0 SL suffers hugely from that non-scalability despite the relativ= ely small size of the service at this early stage.=A0 Opensim needs decentr= alized / distributed mechanisms for identity, storage and control if= it is to scale for Internet-wide adoption.

  • From a futurist angle, Second Life has very narrow horizon= s and barely pays lip service to the virtual aspect of "= virtual worlds".=A0 Nobody could claim that a Flatland of square land = tiles all featuring the same Earth-like look and physics pushes the envelop= e of the imagination.=A0 To boldly go where Lindens did not go before (topo= logically and geographically or spatially) will be one of the most apprecia= ted developments in Opensim.=A0 SL's obsession with RL is an unwanted c= onstraint in VWs, and we need to go beyond it.


That is not the full list of problems with SL, but hopefu= lly it serves to illustrate some of the concerns that VW developers have to= consider in the light of the SL legacy.=A0 While Linden Lab deserves much = applause for their vision and for their work in creating Second Life, many = years have now passed, and lessons have been learned.=A0 Compatibility with= SL must not be the end goal of Opensim because of issues like those highli= ghted above.

From a longer perspective, SL represents only the first step in the evo= lution of virtual worlds.=A0 It is no surprise that most Opensim developers= wish to go beyond that first step, learning from past mistakes and finding= better models for the future.

I mentioned earlier our work at the IETF on new VW protocols, in which = LL are a leading party --- see=A0 https://www.ietf.org/mailman/listinfo/ogpx , the mailing = list of the VWRAP working group.=A0 What may surprise you is that even Lind= ens know that the current SL is not a good model for the future, which is w= hy the protocols being discussed go far beyond their legacy ones.=A0 Indeed= , Lindens will be facing a huge rewrite if this work bears fruit.=A0 When e= ven Lindens don't wish their future to be constrained by the current SL= design because they know its many problems, this really highlights how bad= it would be for the Opensim team to do so. :-)

I hope that one or more of these issues resonates with you, and makes i= t a bit clearer why Opensim really cannot afford to align itself with SL.= =A0 There is no future in looking backwards.


Morgaine.





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Mon, Nov 23, 2009 at 1:06 PM, Len Brown <lenwbrown at gmail.com>= ; wrote:
Rock,

=A0= =A0=A0=A0 I sympathize with you on many levels.=A0 I've also had my dou= bts regarding the future of OpenSim, but I have also maintained some degree= of faith that things will pull through in the end.

=A0=A0=A0=A0 For me the shock came when I was abruptly informed that &q= uot;OpenSim is not Second Life, is not intended to be like Second Life, nor= ever will."=A0 I still haven't the foggiest idea what this develo= per had smoked for them to so strongly assert that incredibly false stateme= nt.

=A0=A0=A0=A0 For me, the enjoyment of OpenSim has come from my intense = devotion to building and skinning.=A0 In fact, for the last few months I= 9;ve been working on a full region that has many hundreds of skins, clothes= , hair, furniture, etc, etc, that I'd like to package up as an OAR and = give out freely, since repeatedly I've been told that instead of giving= money to help further OpenSim I'd do more proactively by giving conten= t.=A0 So I plan to do just that and give my money to other open source init= iatives that matter to me.

=A0=A0=A0=A0 I have a passion for writing, and have thought many times = that one of the greatest powers OpenSim would gain is having simple, straig= htforward, step-by-step instructions on how to download, compile, install, = administer and overall just plain operate the core applications.=A0 What ki= lls me is that everyone who does a search for OpenSim inevitably hits the <= a href=3D"http://opensimulator.org" target=3D"_blank">opensimulator.org= site and that is where the massive roadblock presents itself.=A0 It's = useless for most and irrelevant to the few who consider themselves OpenSim = experts.

=A0=A0=A0=A0 Heck, even now on the configuration page it still displays= info for 0.6.6 including (months old) known bugs in setting up region xml = files.=A0 If there was appointed a volunteer whose sole job was to keep inf= ormation on opensimu= lator.org relevant that one task would resolve a mountain of negativity= right there.=A0 I sit here in front of my computers a good 10 to 12 hours = a day.

=A0=A0=A0=A0 I would sincerely love to contribute to the OpenSim projec= t, especially in documentation support.=A0 But the thing holding me back is= communication.=A0 If I cannot get a straight answer on who to GIVE money t= o in order to help, then I stand little chance of getting clear, straight a= nswers from developers when asking about issues I need to consider and inco= rporate in documentation.

=A0=A0=A0=A0 If communication is a hurdle we can all overcome, with a g= enuine and heart-felt effort to relay information, motives, and plans with = one another, then I'd sincerely appreciate having the opportunity to pe= rsonally contribute.=A0 I'm not a programmer today, but have a degree i= n programming fro the 90's (so much has changed my degree is practicall= y useless in that regard).=A0 But I do know how to explain things and relay= information in simple terms.=A0 But only if my own questions will be answe= red with more than "look it up or figure it out yourself" as my a= nswer.

=A0=A0=A0=A0 If any of you would appreciate my help, feel free to let m= e know at any time and I'll do what I can.

- Len W. Brown
=A0= =A0=A0=A0 lenwbrow= n at gmail.com


On Mon, Nov 23, 2009 at 6:23 AM, Colin B. Withers <Colin.Withers@= eumetsat.int> wrote:
Hi guys,

I have decided to leave the Opensim project. You will probably not even not= ice if I leave, as not being a programmer my only inputs were the writing o= f the step-by-step tutorials ( http://chapter-and-metaverse.blogspot.com/= ), the drafts of the OpenSim User Manual on the Forge, and helping out in = the IRC channels, for newcomers.

You may find my reasons for leaving Opensim interesting though (and please = do not construe any of my reasons as an attack on anyone).

1. The Platform
I raised this several times in the past in IRC, and made posts on my blog a= bout the product lifecycle of the platform ( h= ttp://rock-vacirca.blogspot.com/2009/02/direction-of-virtual-worlds.html ). I believe that the platforms underpinning both Second Life and Opensim= are quite long in the tooth now, and I questioned how much product lifecyc= le there was left, particularly given that Opensim is now nearing 3 years o= f development, is still in Alpha, and if the current release of 0.6.7 is an= y indicator, then still only around two thirds into the development cycle. = With the (inevitable) coming of much superior platforms, such as Blue Mars = and (as a virtual world); Unity, for browser-based Virtual Wolrds; and now = UDK (for creating sandboxes, standalones, and open grids), then I fear that= Opensim has missed the boat as far as the remaining lifecycle of the platf= orm is concerned. When you show people what is possible with these engines = (for example this avatar editor for the forthcom
=A0ing APB (using the Unreal Engine): http://www.youtube.com/watch?v=3DicR3= LtEMvZI or this city: http://www.youtube.com/watch?v=3DhmLzNbPXMDg = (using the CryEngine), then neither SL not Opensim stands comparison.

2. Lack of Support for Currency in Opensim
I felt the impact of this when I first made the switch from SL to Opensim. = I had a thriving RP sim in SL (over 50 people, mainly female) and they all = agreed to follow me over to my Opensim and the OSGrid. However, within a mo= nth they had all left, citing the same reason, the lack of places to shop, = to buy the quality stuff they wanted (skins, hair, clothes etc), as a quali= ty appearance, and the fun of shopping is what all the females placed high = on their requirements from a Virtual World. They drifted back to Second Lif= e, and the guys followed them. I have always believed that the lack of supp= ort for currency in the core was a mistake, but that is just my opinion.
3. Marketing
I have also raised this issue several times, and blogged about it. It is fa= r from clear just who an eventually released Opensim is actually aimed at. = I think that any company that is interested in a firewalled corporate solut= ion to collaboration and prototyping will already be looking at the Enterpr= ise solution that is currently available from Second Life; that any indie g= roup that is thinking of running a themed grid will need an economy to stay= viable; and any individual who is looking for a private sandbox solution f= or their SL work will need full compatibility (which is not the case with t= he OS version of LSL diverging from the SL LSL). So, just who is the platfo= rm aimed at? I was also very disappointed in the view of one of the core de= vs who said that 'marketing is a null concept for us'.

I am currently designing and creating cities for Blue Mars, and involved in= a team for proving the UDK as a platform for the design and creation of Vi= rtual Worlds (as opposed to purely games), and with so much documentation a= vailable for these mature engines (particularly for the UDK, Blue Mars lags= behind somewhat in that department, but have hired extra staff to put that= right), I am achieving the productivity I want, building the worlds that I= want, with stable crash-free platforms.

However, I do wish the Opensim team the very best in their endeavours, and = I sincerely hope their goals are eventually achieved.

If anyone would like to take over the Opensim Tutorials pages at http://chapt= er-and-metaverse.blogspot.com/ and http://chapter-and-metaverse2.blogspo= t.com/ (they will need some updating following several changes) then I = am more than willing to pass the posts over, and of course the Opensim User= Manual is there in the Forge for anyone to develop further.

Best Regards and Good Luck

Rock


_______________________________________________
Opensim-dev mailing list
Opensim-d= ev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev


_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.d= e
https://lists.berlios.de/mailman/listinfo/opensim-dev


--0016e6d7eefa4147ee047911d695-- From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: evolution of virtual worlds. It is no surprise that most Opensim developers wish to go beyond that first step, learning from past mistakes and finding better models for the future. I mentioned earlier our work at the IETF on new VW protocols, in which LL are a leading party --- see https://www.ietf.org/mailman/listinfo/ogpx , the mailing list of the VWRAP working group. What may surprise you is that even Lindens know that the current SL is not a good model for the future, which is why the protocols being discussed go far beyond their legacy ones. Indeed, Lindens will be facing a huge rewrite if this work bears fruit. When even Lindens don't wish their future to be constrained by the current SL design because they know its many problems, this really highlights how bad it would be for the Opensim team to do so. :-) I hope that one or more of these issues resonates with you, and makes it a bit clearer why Opensim really cannot afford to align itself with SL. There is no future in looking backwards. Morgaine. ======================================= On Mon, Nov 23, 2009 at 1:06 PM, Len Brown wrote: Rock, I sympathize with you on many levels. I've also had my doubts regarding the future of OpenSim, but I have also maintained some degree of faith that things will pull through in the end. For me the shock came when I was abruptly informed that "OpenSim is not Second Life, is not intended to be like Second Life, nor ever will." I still haven't the foggiest idea what this developer had smoked for them to so strongly assert that incredibly false statement. For me, the enjoyment of OpenSim has come from my intense devotion to building and skinning. In fact, for the last few months I've been working on a full region that has many hundreds of skins, clothes, hair, furniture, etc, etc, that I'd like to package up as an OAR and give out freely, since repeatedly I've been told that instead of giving money to help further OpenSim I'd do more proactively by giving content. So I plan to do just that and give my money to other open source initiatives that matter to me. I have a passion for writing, and have thought many times that one of the greatest powers OpenSim would gain is having simple, straightforward, step-by-step instructions on how to download, compile, install, administer and overall just plain operate the core applications. What kills me is that everyone who does a search for OpenSim inevitably hits the opensimulator.org site and that is where the massive roadblock presents itself. It's useless for most and irrelevant to the few who consider themselves OpenSim experts. Heck, even now on the configuration page it still displays info for 0.6.6 including (months old) known bugs in setting up region xml files. If there was appointed a volunteer whose sole job was to keep information on opensimulator.org relevant that one task would resolve a mountain of negativity right there. I sit here in front of my computers a good 10 to 12 hours a day. I would sincerely love to contribute to the OpenSim project, especially in documentation support. But the thing holding me back is communication. If I cannot get a straight answer on who to GIVE money to in order to help, then I stand little chance of getting clear, straight answers from developers when asking about issues I need to consider and incorporate in documentation. If communication is a hurdle we can all overcome, with a genuine and heart-felt effort to relay information, motives, and plans with one another, then I'd sincerely appreciate having the opportunity to personally contribute. I'm not a programmer today, but have a degree in programming fro the 90's (so much has changed my degree is practically useless in that regard). But I do know how to explain things and relay information in simple terms. But only if my own questions will be answered with more than "look it up or figure it out yourself" as my answer. If any of you would appreciate my help, feel free to let me know at any time and I'll do what I can. - Len W. Brown lenwbrown at gmail.com On Mon, Nov 23, 2009 at 6:23 AM, Colin B. Withers wrote: Hi guys, I have decided to leave the Opensim project. You will probably not even notice if I leave, as not being a programmer my only inputs were the writing of the step-by-step tutorials ( http://chapter-and-metaverse.blogspot.com/ ), the drafts of the OpenSim User Manual on the Forge, and helping out in the IRC channels, for newcomers. You may find my reasons for leaving Opensim interesting though (and please do not construe any of my reasons as an attack on anyone). 1. The Platform I raised this several times in the past in IRC, and made posts on my blog about the product lifecycle of the platform ( http://rock-vacirca.blogspot.com/2009/02/direction-of-virtual-worlds.html ). I believe that the platforms underpinning both Second Life and Opensim are quite long in the tooth now, and I questioned how much product lifecycle there was left, particularly given that Opensim is now nearing 3 years of development, is still in Alpha, and if the current release of 0.6.7 is any indicator, then still only around two thirds into the development cycle. With the (inevitable) coming of much superior platforms, such as Blue Mars and (as a virtual world); Unity, for browser-based Virtual Wolrds; and now UDK (for creating sandboxes, standalones, and open grids), then I fear that Opensim has missed the boat as far as the remaining lifecycle of the platform is concerned. When you show people what is possible with these engines (for example this avatar editor for the forthcom ing APB (using the Unreal Engine): http://www.youtube.com/watch?v=icR3LtEMvZI or this city: http://www.youtube.com/watch?v=hmLzNbPXMDg (using the CryEngine), then neither SL not Opensim stands comparison. 2. Lack of Support for Currency in Opensim I felt the impact of this when I first made the switch from SL to Opensim. I had a thriving RP sim in SL (over 50 people, mainly female) and they all agreed to follow me over to my Opensim and the OSGrid. However, within a month they had all left, citing the same reason, the lack of places to shop, to buy the quality stuff they wanted (skins, hair, clothes etc), as a quality appearance, and the fun of shopping is what all the females placed high on their requirements from a Virtual World. They drifted back to Second Life, and the guys followed them. I have always believed that the lack of support for currency in the core was a mistake, but that is just my opinion. 3. Marketing I have also raised this issue several times, and blogged about it. It is far from clear just who an eventually released Opensim is actually aimed at. I think that any company that is interested in a firewalled corporate solution to collaboration and prototyping will already be looking at the Enterprise solution that is currently available from Second Life; that any indie group that is thinking of running a themed grid will need an economy to stay viable; and any individual who is looking for a private sandbox solution for their SL work will need full compatibility (which is not the case with the OS version of LSL diverging from the SL LSL). So, just who is the platform aimed at? I was also very disappointed in the view of one of the core devs who said that 'marketing is a null concept for us'. I am currently designing and creating cities for Blue Mars, and involved in a team for proving the UDK as a platform for the design and creation of Virtual Worlds (as opposed to purely games), and with so much documentation available for these mature engines (particularly for the UDK, Blue Mars lags behind somewhat in that department, but have hired extra staff to put that right), I am achieving the productivity I want, building the worlds that I want, with stable crash-free platforms. However, I do wish the Opensim team the very best in their endeavours, and I sincerely hope their goals are eventually achieved. If anyone would like to take over the Opensim Tutorials pages at http://chapter-and-metaverse.blogspot.com/ and http://chapter-and-metaverse2.blogspot.com/ (they will need some updating following several changes) then I am more than willing to pass the posts over, and of course the Opensim User Manual is there in the Forge for anyone to develop further. Best Regards and Good Luck Rock _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.709 / Virus Database: 270.14.78/2521 - Release Date: 11/23/09 14:45:00 ------=_NextPart_000_002A_01CA6C68.7723E480 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

What she said! Thank you Morgaine for clarifying this for = all of us.  In my opinion this discussion was appropriate here to = understand roadmap and documentation efforts.  Thanks for caring to let the rest of = the community hear about your very smart opinions.  More talk like this will = bring the community together wherever it occurs.

 

From:= opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of = Morgaine
Sent: Monday, November 23, 2009 6:04 PM
To: opensim-dev at lists.berlios.de
Subject: Re: [Opensim-dev] Leaving Project

 

On Mon, Nov 23, 2009 at 1:06 PM, Len Brown <lenwbrown at gmail.com> = wrote:

 

For me the shock came when I was abruptly informed = that "OpenSim is not Second Life, is not intended to be like Second Life, nor ever will."  I still haven't the foggiest idea what this = developer had smoked for them to so strongly assert that incredibly false = statement.



Len, let me give you an alternative perspective on that quote to help = you see the reasons for it.  I'm not on the Opensim team, but after five = years in SL, two years in AWG, and a year of working on future VW protocols in = our IETF group, I have some background to know why Opensim needs to distance = itself from SL:

  • SL's statically tiled resource = architecture is badly non-scalable, because most resource usage in VWs = cannot be statically mapped (demand moves around).  The inability to = assign resources dynamically in SL results in huge overload in busy places = and gross wastage in idle areas.  It also limits the number of participants in events and the bandwidth of their interaction, as = well as the size and complexity of everything in a region.  This = architecture is fundamental to SL, yet it is a recipe for failure.  As long = as Opensim adheres to the SL model, Opensim will be similarly = non-scalable.

 

  • The LSL scripting language is = linguistically weak, semantically obscure, and lacking in the glue that could = allow components to cooperate effectively.  As a result, individual = scripts are quite underpowered and inefficient, and multi-script = constructions do not scale well in complexity because the overheads of cooperation = are so large.  That's a bad restriction on progress which Opensim = needs to leave behind.

 

  • LSL scripts are not scalable in power or = size, and this will continue to be true even after SL allows C# and other = CLR languages to be used.  There is no possibility of using more = CPU power for scripting than is available in one single simulator in = SL.  That is not a good foundation upon which to build an ambitious = future of clever components.

 

  • SL's simulation environment is = non-portable, having evolved over time into a plethora of special cases that will = not be accurately replicable anywhere else.  In effect this means = that there will never be effective interop with SL's scripted objects.  = It would not be a useful goal to seek compatibility with what could = realistically be described as an "ill-defined mess".

 

  • SL's object and type systems are = non-extensible, so compatibility with SL means living in the past, and worse, = living in a past defined entirely by one slow-moving company.  Tying the capabilities of Opensim to that millstone would be a disaster --- = it would ensure the death of Opensim versus any extensible alternative that = may appear.  Developing new extensible forms of world data beyond = SL's original set is a must for Opensim's survival as a modern VW = platform.

 

  • SL's viewer has deep knowledge of SL = semantics because the client and server were designed for each other rather = than designed as endpoints of a standard protocol.  This has the = very bad consequence that future VW viewers would need to know about SL = specifics in order to interoperate with SL, which is a poor approach that = doesn't scale to metaverse-wide diversity.  Opensim needs to leave world-specific kludges behind if it has ambitions to underpin a = highly diverse metaverse of worlds, and this means leaving the SL viewer = behind.

 

  • SL's constructed objects are = non-hierarchical, which means that creators cannot use objects created by others as subcomponents.  This restriction completely blocks the = hierarchical engineering process that is the basis of progress in RL.  In = SL you always have to build from "raw materials", so it is not = possible to ride on the shoulders of giants, nor harness a huge pyramid of = people skills.  Even Philip and Cory Linden admitted that this was a = mistake -- see  https= ://wiki.secondlife.com/wiki/Prim_and_Object_Hierarchy .  We don't want to live with their mistake.

 

  • SL is based on highly centralized = concepts of identity, storage and control, which come together to = create either a walled garden or a prison planet, depending on one's perspective.  Whatever one's worldview, the end result is = badly non-scalable in those three areas.  SL suffers hugely from = that non-scalability despite the relatively small size of the service at = this early stage.  Opensim needs decentralized / distributed = mechanisms for identity, storage and control if it is to scale for = Internet-wide adoption.

 

  • From a futurist angle, Second Life has = very narrow horizons and barely pays lip service to the = virtual aspect of "virtual worlds".  Nobody could claim that = a Flatland of square land tiles all featuring the same Earth-like = look and physics pushes the envelope of the imagination.  To boldly go = where Lindens did not go before (topologically and geographically or = spatially) will be one of the most appreciated developments in Opensim.  = SL's obsession with RL is an unwanted constraint in VWs, and we need to = go beyond it.



That is not the full list of problems with SL, but hopefully it serves = to illustrate some of the concerns that VW developers have to consider in = the light of the SL legacy.  While Linden Lab deserves much applause = for their vision and for their work in creating Second Life, many years have now = passed, and lessons have been learned.  Compatibility with SL must not be = the end goal of Opensim because of issues like those highlighted above.

From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: evolution of virtual worlds.  It is no surprise that most Opensim developers = wish to go beyond that first step, learning from past mistakes and finding = better models for the future.

I mentioned earlier our work at the IETF on new VW protocols, in which = LL are a leading party --- see  https://www.ietf.org/= mailman/listinfo/ogpx , the mailing list of the VWRAP working group.  What may surprise = you is that even Lindens know that the current SL is not a good model for the = future, which is why the protocols being discussed go far beyond their legacy ones.  Indeed, Lindens will be facing a huge rewrite if this work = bears fruit.  When even Lindens don't wish their future to be constrained = by the current SL design because they know its many problems, this really = highlights how bad it would be for the Opensim team to do so. :-)

I hope that one or more of these issues resonates with you, and makes it = a bit clearer why Opensim really cannot afford to align itself with SL.  = There is no future in looking backwards.


Morgaine.






=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Mon, Nov 23, 2009 at 1:06 PM, Len Brown <lenwbrown at gmail.com> = wrote:

Rock,

     I sympathize with you on many levels.  = I've also had my doubts regarding the future of OpenSim, but I have also = maintained some degree of faith that things will pull through in the end.

     For me the shock came when I was abruptly = informed that "OpenSim is not Second Life, is not intended to be like Second = Life, nor ever will."  I still haven't the foggiest idea what this developer had smoked for them to so strongly assert that incredibly = false statement.

     For me, the enjoyment of OpenSim has come from = my intense devotion to building and skinning.  In fact, for the last = few months I've been working on a full region that has many hundreds of = skins, clothes, hair, furniture, etc, etc, that I'd like to package up as an = OAR and give out freely, since repeatedly I've been told that instead of giving = money to help further OpenSim I'd do more proactively by giving content.  = So I plan to do just that and give my money to other open source initiatives = that matter to me.

     I have a passion for writing, and have thought = many times that one of the greatest powers OpenSim would gain is having = simple, straightforward, step-by-step instructions on how to download, compile, install, administer and overall just plain operate the core = applications.  What kills me is that everyone who does a search for OpenSim inevitably = hits the opensimulator.org site and that is where the massive roadblock presents itself.  It's useless for most and irrelevant to the few who consider themselves = OpenSim experts.

     Heck, even now on the configuration page it = still displays info for 0.6.6 including (months old) known bugs in setting up = region xml files.  If there was appointed a volunteer whose sole job was = to keep information on opensimulator.org relevant that one task would resolve a mountain of negativity right there.  I sit here in front of my computers a good 10 to 12 hours a = day.

     I would sincerely love to contribute to the = OpenSim project, especially in documentation support.  But the thing = holding me back is communication.  If I cannot get a straight answer on who to = GIVE money to in order to help, then I stand little chance of getting clear, straight answers from developers when asking about issues I need to = consider and incorporate in documentation.

     If communication is a hurdle we can all = overcome, with a genuine and heart-felt effort to relay information, motives, and plans = with one another, then I'd sincerely appreciate having the opportunity to = personally contribute.  I'm not a programmer today, but have a degree in = programming fro the 90's (so much has changed my degree is practically useless in = that regard).  But I do know how to explain things and relay information = in simple terms.  But only if my own questions will be answered with = more than "look it up or figure it out yourself" as my answer.

     If any of you would appreciate my help, feel = free to let me know at any time and I'll do what I can.

- Len W. Brown
     lenwbrown at gmail.com

 

On Mon, Nov 23, 2009 at 6:23 AM, Colin B. Withers = <Colin.Withers at eumetsat.int> wrote:

Hi guys,

I have decided to leave the Opensim project. You will probably not even = notice if I leave, as not being a programmer my only inputs were the writing of = the step-by-step tutorials ( http://chapter-and-metaverse.blogspot.com/ ), the = drafts of the OpenSim User Manual on the Forge, and helping out in the IRC = channels, for newcomers.

You may find my reasons for leaving Opensim interesting though (and = please do not construe any of my reasons as an attack on anyone).

1. The Platform
I raised this several times in the past in IRC, and made posts on my = blog about the product lifecycle of the platform ( http://rock-vacirca.blogspot.com/2009/02/direction-of-v= irtual-worlds.html ). I believe that the platforms underpinning both Second Life and = Opensim are quite long in the tooth now, and I questioned how much product lifecycle = there was left, particularly given that Opensim is now nearing 3 years of development, is still in Alpha, and if the current release of 0.6.7 is = any indicator, then still only around two thirds into the development cycle. = With the (inevitable) coming of much superior platforms, such as Blue Mars = and (as a virtual world); Unity, for browser-based Virtual Wolrds; and now UDK = (for creating sandboxes, standalones, and open grids), then I fear that = Opensim has missed the boat as far as the remaining lifecycle of the platform is = concerned. When you show people what is possible with these engines (for example = this avatar editor for the forthcom
 ing APB (using the Unreal Engine): http://www.youtube.com/watch?v=3DicR3LtEMvZI or this city: http://www.youtube.com/watch?v=3DhmLzNbPXMDg = (using the CryEngine), then neither SL not Opensim stands comparison.

2. Lack of Support for Currency in Opensim
I felt the impact of this when I first made the switch from SL to = Opensim. I had a thriving RP sim in SL (over 50 people, mainly female) and they all = agreed to follow me over to my Opensim and the OSGrid. However, within a month = they had all left, citing the same reason, the lack of places to shop, to buy = the quality stuff they wanted (skins, hair, clothes etc), as a quality = appearance, and the fun of shopping is what all the females placed high on their requirements from a Virtual World. They drifted back to Second Life, and = the guys followed them. I have always believed that the lack of support for currency in the core was a mistake, but that is just my opinion.

3. Marketing
I have also raised this issue several times, and blogged about it. It is = far from clear just who an eventually released Opensim is actually aimed at. = I think that any company that is interested in a firewalled corporate = solution to collaboration and prototyping will already be looking at the Enterprise solution that is currently available from Second Life; that any indie = group that is thinking of running a themed grid will need an economy to stay = viable; and any individual who is looking for a private sandbox solution for = their SL work will need full compatibility (which is not the case with the OS = version of LSL diverging from the SL LSL). So, just who is the platform aimed at? I = was also very disappointed in the view of one of the core devs who said that 'marketing is a null concept for us'.

I am currently designing and creating cities for Blue Mars, and involved = in a team for proving the UDK as a platform for the design and creation of = Virtual Worlds (as opposed to purely games), and with so much documentation = available for these mature engines (particularly for the UDK, Blue Mars lags = behind somewhat in that department, but have hired extra staff to put that = right), I am achieving the productivity I want, building the worlds that I want, = with stable crash-free platforms.

However, I do wish the Opensim team the very best in their endeavours, = and I sincerely hope their goals are eventually achieved.

If anyone would like to take over the Opensim Tutorials pages at http://chapter-and-metaverse.blogspot.com/ and http://chapter-and-metaverse2.blogspot.com/ (they will need some updating following several changes) then I am more = than willing to pass the posts over, and of course the Opensim User Manual is = there in the Forge for anyone to develop further.

Best Regards and Good Luck

Rock


_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

 


_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de=
https://lists.berlios.de/mailman/listinfo/opensim-dev

 

No = virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.709 / Virus Database: 270.14.78/2521 - Release Date: = 11/23/09 14:45:00

------=_NextPart_000_002A_01CA6C68.7723E480-- From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: on of virtual worlds.=A0 It is no surprise that most Opensim developers wish t= o go beyond that first step, learning from past mistakes and finding better models for the future.

I mentioned earlier our work at the IETF on new VW protocols, in which LL a= re a leading party --- see=A0 https://www.ietf.org/mailman/listinfo/ogpx , the mailing list of the VWRAP working group.=A0 What may surprise you is that even Lindens know that the current SL is not a good model for the futu= re, which is why the protocols being discussed go far beyond their legacy ones.=A0 Indeed, Lindens will be facing a huge rewrite if this work bears fruit.=A0 When even Lindens don't wish their future to be constrained b= y the current SL design because they know its many problems, this really highligh= ts how bad it would be for the Opensim team to do so. :-)

I hope that one or more of these issues resonates with you, and makes it a = bit clearer why Opensim really cannot afford to align itself with SL.=A0 There is no future in looking backwards.


Morgaine.






=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Mon, Nov 23, 2009 at 1:06 PM, Len Brown <lenwbrown at gmail.com= > wrote:

Rock,

=A0=A0=A0=A0 I sympathize with you on many levels.=A0 I've also had my doubts regarding the future of OpenSim, but I have also maintained s= ome degree of faith that things will pull through in the end.

=A0=A0=A0=A0 For me the shock came when I was abruptly informed that "OpenSim is not Second Life, is not intended to be like Second Li= fe, nor ever will."=A0 I still haven't the foggiest idea what this developer had smoked for them to so strongly assert that incredibly false statement.

=A0=A0=A0=A0 For me, the enjoyment of OpenSim has come from my intense devotion to building and skinning.=A0 In fact, for the last few months I've been working on a full region that has many hundreds of ski= ns, clothes, hair, furniture, etc, etc, that I'd like to package up as an O= AR and give out freely, since repeatedly I've been told that instead of giving= money to help further OpenSim I'd do more proactively by giving content.=A0 S= o I plan to do just that and give my money to other open source initiatives tha= t matter to me.

=A0=A0=A0=A0 I have a passion for writing, and have thought many times that one of the greatest powers OpenSim would gain is having simple, straightforward, step-by-step instructions on how to download, compile, install, administer and overall just plain operate the core applications.= =A0 What kills me is that everyone who does a search for OpenSim inevitably hit= s the opensimulator.or= g site and that is where the massive roadblock presents itself.=A0 It's useless for most and irrelevant to the few who consider themselves OpenSim experts.

=A0=A0=A0=A0 Heck, even now on the configuration page it still displays info for 0.6.6 including (months old) known bugs in setting up reg= ion xml files.=A0 If there was appointed a volunteer whose sole job was to keep information on opens= imulator.org relevant that one task would resolve a mountain of negativity right there.=A0 I sit here in front of my computers a good 10 to 12 hours a day.<= br>
=A0=A0=A0=A0 I would sincerely love to contribute to the OpenSim project, especially in documentation support.=A0 But the thing holding me back is communication.=A0 If I cannot get a straight answer on who to GIVE money to in order to help, then I stand little chance of getting clear, straight answers from developers when asking about issues I need to conside= r and incorporate in documentation.

=A0=A0=A0=A0 If communication is a hurdle we can all overcome, with a genuine and heart-felt effort to relay information, motives, and plans wi= th one another, then I'd sincerely appreciate having the opportunity to pe= rsonally contribute.=A0 I'm not a programmer today, but have a degree in program= ming fro the 90's (so much has changed my degree is practically useless in t= hat regard).=A0 But I do know how to explain things and relay information in simple terms.=A0 But only if my own questions will be answered with more than "look it up or figure it out yourself" as my answer.

=A0=A0=A0=A0 If any of you would appreciate my help, feel free to let me know at any time and I'll do what I can.

- Len W. Brown
=A0=A0=A0=A0 lenwb= rown at gmail.com

=A0

On Mon, Nov 23, 2009 at 6:23 AM, Colin B. Withers &l= t;Colin.Wit= hers at eumetsat.int> wrote:

Hi guys,

I have decided to leave the Opensim project. You will probably not even not= ice if I leave, as not being a programmer my only inputs were the writing of th= e step-by-step tutorials ( http://chapter-and-metaverse.blogspot.com/ ), th= e drafts of the OpenSim User Manual on the Forge, and helping out in the IRC channels, = for newcomers.

You may find my reasons for leaving Opensim interesting though (and please = do not construe any of my reasons as an attack on anyone).

1. The Platform
I raised this several times in the past in IRC, and made posts on my blog a= bout the product lifecycle of the platform ( http:/= /rock-vacirca.blogspot.com/2009/02/direction-of-virtual-worlds.html ). I believe that the platforms underpinning both Second Life and Opensim a= re quite long in the tooth now, and I questioned how much product lifecycle th= ere was left, particularly given that Opensim is now nearing 3 years of development, is still in Alpha, and if the current release of 0.6.7 is any indicator, then still only around two thirds into the development cycle. Wi= th the (inevitable) coming of much superior platforms, such as Blue Mars and (= as a virtual world); Unity, for browser-based Virtual Wolrds; and now UDK (for creating sandboxes, standalones, and open grids), then I fear that Opensim = has missed the boat as far as the remaining lifecycle of the platform is concer= ned. When you show people what is possible with these engines (for example this avatar editor for the forthcom
=A0ing APB (using the Unreal Engine): http://www.youtube.com/watch?v=3DicR3= LtEMvZI or this city: http://www.youtube.com/watch?v=3DhmLzNbPXMDg (using the CryEngine), then neither SL not Opensim stands comparison.

2. Lack of Support for Currency in Opensim
I felt the impact of this when I first made the switch from SL to Opensim. = I had a thriving RP sim in SL (over 50 people, mainly female) and they all ag= reed to follow me over to my Opensim and the OSGrid. However, within a month the= y had all left, citing the same reason, the lack of places to shop, to buy th= e quality stuff they wanted (skins, hair, clothes etc), as a quality appearan= ce, and the fun of shopping is what all the females placed high on their requirements from a Virtual World. They drifted back to Second Life, and th= e guys followed them. I have always believed that the lack of support for currency in the core was a mistake, but that is just my opinion.

3. Marketing
I have also raised this issue several times, and blogged about it. It is fa= r from clear just who an eventually released Opensim is actually aimed at. I think that any company that is interested in a firewalled corporate solutio= n to collaboration and prototyping will already be looking at the Enterprise solution that is currently available from Second Life; that any indie group that is thinking of running a themed grid will need an economy to stay viab= le; and any individual who is looking for a private sandbox solution for their = SL work will need full compatibility (which is not the case with the OS versio= n of LSL diverging from the SL LSL). So, just who is the platform aimed at? I wa= s also very disappointed in the view of one of the core devs who said that 'marketing is a null concept for us'.

I am currently designing and creating cities for Blue Mars, and involved in= a team for proving the UDK as a platform for the design and creation of Virtu= al Worlds (as opposed to purely games), and with so much documentation availab= le for these mature engines (particularly for the UDK, Blue Mars lags behind somewhat in that department, but have hired extra staff to put that right),= I am achieving the productivity I want, building the worlds that I want, with stable crash-free platforms.

However, I do wish the Opensim team the very best in their endeavours, and = I sincerely hope their goals are eventually achieved.

If anyone would like to take over the Opensim Tutorials pages at http://chapt= er-and-metaverse.blogspot.com/ and http://chapter-and-metaverse2.blogspot.com/ (they will need some updating following several changes) then I am more tha= n willing to pass the posts over, and of course the Opensim User Manual is th= ere in the Forge for anyone to develop further.

Best Regards and Good Luck

Rock


_______________________________________________
Opensim-dev mailing list
Opensim-d= ev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

=A0


_______________________________________________
Opensim-dev mailing list
Opensim-d= ev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

=A0

No virus found in this incoming message.


Checked by AVG - www.avg.c= om
Version: 9.0.709 / Virus Database: 270.14.78/2521 - Release Date: 11/23/09 14:45:00


_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.d= e
https://lists.berlios.de/mailman/listinfo/opensim-dev




--
=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
http://osgrid.org
http://del.icio.us/SPQR
http://twitter.com/jstallings2
http://www.linkedin.com/p= ub/5/770/a49
--0016364ed520fa4d130479123119-- From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: evolution of virtual worlds. It is no surprise that most Opensim developers wish to go beyond that first step, learning from past mistakes and finding better models for the future. I mentioned earlier our work at the IETF on new VW protocols, in which LL are a leading party --- see https://www.ietf.org/mailman/listinfo/ogpx , the mailing list of the VWRAP working group. What may surprise you is that even Lindens know that the current SL is not a good model for the future, which is why the protocols being discussed go far beyond their legacy ones. Indeed, Lindens will be facing a huge rewrite if this work bears fruit. When even Lindens don't wish their future to be constrained by the current SL design because they know its many problems, this really highlights how bad it would be for the Opensim team to do so. :-) I hope that one or more of these issues resonates with you, and makes it a bit clearer why Opensim really cannot afford to align itself with SL. There is no future in looking backwards. Morgaine. ======================================= On Mon, Nov 23, 2009 at 1:06 PM, Len Brown wrote: Rock, I sympathize with you on many levels. I've also had my doubts regarding the future of OpenSim, but I have also maintained some degree of faith that things will pull through in the end. For me the shock came when I was abruptly informed that "OpenSim is not Second Life, is not intended to be like Second Life, nor ever will." I still haven't the foggiest idea what this developer had smoked for them to so strongly assert that incredibly false statement. For me, the enjoyment of OpenSim has come from my intense devotion to building and skinning. In fact, for the last few months I've been working on a full region that has many hundreds of skins, clothes, hair, furniture, etc, etc, that I'd like to package up as an OAR and give out freely, since repeatedly I've been told that instead of giving money to help further OpenSim I'd do more proactively by giving content. So I plan to do just that and give my money to other open source initiatives that matter to me. I have a passion for writing, and have thought many times that one of the greatest powers OpenSim would gain is having simple, straightforward, step-by-step instructions on how to download, compile, install, administer and overall just plain operate the core applications. What kills me is that everyone who does a search for OpenSim inevitably hits the opensimulator.org site and that is where the massive roadblock presents itself. It's useless for most and irrelevant to the few who consider themselves OpenSim experts. Heck, even now on the configuration page it still displays info for 0.6.6 including (months old) known bugs in setting up region xml files. If there was appointed a volunteer whose sole job was to keep information on opensimulator.org relevant that one task would resolve a mountain of negativity right there. I sit here in front of my computers a good 10 to 12 hours a day. I would sincerely love to contribute to the OpenSim project, especially in documentation support. But the thing holding me back is communication. If I cannot get a straight answer on who to GIVE money to in order to help, then I stand little chance of getting clear, straight answers from developers when asking about issues I need to consider and incorporate in documentation. If communication is a hurdle we can all overcome, with a genuine and heart-felt effort to relay information, motives, and plans with one another, then I'd sincerely appreciate having the opportunity to personally contribute. I'm not a programmer today, but have a degree in programming fro the 90's (so much has changed my degree is practically useless in that regard). But I do know how to explain things and relay information in simple terms. But only if my own questions will be answered with more than "look it up or figure it out yourself" as my answer. If any of you would appreciate my help, feel free to let me know at any time and I'll do what I can. - Len W. Brown lenwbrown at gmail.com On Mon, Nov 23, 2009 at 6:23 AM, Colin B. Withers wrote: Hi guys, I have decided to leave the Opensim project. You will probably not even notice if I leave, as not being a programmer my only inputs were the writing of the step-by-step tutorials ( http://chapter-and-metaverse.blogspot.com/ ), the drafts of the OpenSim User Manual on the Forge, and helping out in the IRC channels, for newcomers. You may find my reasons for leaving Opensim interesting though (and please do not construe any of my reasons as an attack on anyone). 1. The Platform I raised this several times in the past in IRC, and made posts on my blog about the product lifecycle of the platform ( http://rock-vacirca.blogspot.com/2009/02/direction-of-virtual-worlds.html ). I believe that the platforms underpinning both Second Life and Opensim are quite long in the tooth now, and I questioned how much product lifecycle there was left, particularly given that Opensim is now nearing 3 years of development, is still in Alpha, and if the current release of 0.6.7 is any indicator, then still only around two thirds into the development cycle. With the (inevitable) coming of much superior platforms, such as Blue Mars and (as a virtual world); Unity, for browser-based Virtual Wolrds; and now UDK (for creating sandboxes, standalones, and open grids), then I fear that Opensim has missed the boat as far as the remaining lifecycle of the platform is concerned. When you show people what is possible with these engines (for example this avatar editor for the forthcom ing APB (using the Unreal Engine): http://www.youtube.com/watch?v=icR3LtEMvZI or this city: http://www.youtube.com/watch?v=hmLzNbPXMDg (using the CryEngine), then neither SL not Opensim stands comparison. 2. Lack of Support for Currency in Opensim I felt the impact of this when I first made the switch from SL to Opensim. I had a thriving RP sim in SL (over 50 people, mainly female) and they all agreed to follow me over to my Opensim and the OSGrid. However, within a month they had all left, citing the same reason, the lack of places to shop, to buy the quality stuff they wanted (skins, hair, clothes etc), as a quality appearance, and the fun of shopping is what all the females placed high on their requirements from a Virtual World. They drifted back to Second Life, and the guys followed them. I have always believed that the lack of support for currency in the core was a mistake, but that is just my opinion. 3. Marketing I have also raised this issue several times, and blogged about it. It is far from clear just who an eventually released Opensim is actually aimed at. I think that any company that is interested in a firewalled corporate solution to collaboration and prototyping will already be looking at the Enterprise solution that is currently available from Second Life; that any indie group that is thinking of running a themed grid will need an economy to stay viable; and any individual who is looking for a private sandbox solution for their SL work will need full compatibility (which is not the case with the OS version of LSL diverging from the SL LSL). So, just who is the platform aimed at? I was also very disappointed in the view of one of the core devs who said that 'marketing is a null concept for us'. I am currently designing and creating cities for Blue Mars, and involved in a team for proving the UDK as a platform for the design and creation of Virtual Worlds (as opposed to purely games), and with so much documentation available for these mature engines (particularly for the UDK, Blue Mars lags behind somewhat in that department, but have hired extra staff to put that right), I am achieving the productivity I want, building the worlds that I want, with stable crash-free platforms. However, I do wish the Opensim team the very best in their endeavours, and I sincerely hope their goals are eventually achieved. If anyone would like to take over the Opensim Tutorials pages at http://chapter-and-metaverse.blogspot.com/ and http://chapter-and-metaverse2.blogspot.com/ (they will need some updating following several changes) then I am more than willing to pass the posts over, and of course the Opensim User Manual is there in the Forge for anyone to develop further. Best Regards and Good Luck Rock _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ------=_NextPart_000_00B7_01CA6CF5.12D3D3E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Very interesting debate you have going on = here…

 

Just to summarise, it seems to me that while the project = roadmap so far has been to implement copy of Second Life the general feeling is = that we are now pretty much there and it is time to go after even greater things = and we need to decide a product road map on our own from here. Hope I am = summarising all this correctly from all emails flying around?

 

There are as many business models in the mix as there are companies involved. While my company makes money from utilising OpenSim = as an engine for private virtual worlds and business applications we develop = for our customers, there are people elsewhere whose main interest is to create = global public access grids to compete with other virtual worlds such as Second = Life. I think it is important that the focus remains considering OpenSim as an = engine and this way everyone’s business models can be satisfied = (hopefully).

 

Just quickly about the debate around the compatibility = between Second Life and OpenSim. Which ever way this all goes, long term virtual = worlds will definitely need a standard ways to communicate. It is important = that different platforms can talk with each other if we aim for a 3D = internet. Traditional internet would not have taken off the same way if there would have been = only 1 web server vendor to use (does not matter would it been Apache or MS IIS). = So lets make sure that our product roadmap does listen / follow what other = platforms are doing.

 

And finally, I sense from some of the discussions an anti = SL/LL tone the same way there has been an anti Microsoft tone in so many Open = Source projects in the past. So many good Open Source projects have been wasted = away in the past because they concentrated fighting the “big = evil” instead of writing code that was great and made sense. There is = absolutely no point diverting OpenSim from Second Life for just sake of it, because we = feel now that OpenSim is great enough product and we can do it all ourselves. = However, if we find that keeping the compatibility is going to stop us realising = some great things in the future then that is a different matter, but even = then each case should be considered carefully.

 

Regards,

 

Olli

 

From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of = Impalah Shenzhou
Sent: 24 November 2009 09:42
To: opensim-dev at lists.berlios.de
Subject: Re: [Opensim-dev] Leaving Project

 

Hi:

Morgaine, I agree with you except:

  • SL is based on highly centralized = concepts of identity, storage and control, which come = together to create either a walled garden or a prison planet, depending on = one's perspective.  Whatever one's worldview, the end result is = badly non-scalable in those three areas.  SL suffers hugely from = that non-scalability despite the relatively small size of the service at = this early stage.  Opensim needs decentralized / distributed = mechanisms for identity, storage and control if it is to = scale for Internet-wide adoption.


How can I trust anyone who hasn't been authorized through a well known = trusting system? Well, if you mean systems like OpenID, forget my comments. If = not, can you explain that?

About the topic...

Except with the lack of huge, updated and good documentation, and having = into account that there are no money incomes (no business angels out of = here)... it's a miracle for the project to be still alive :-)

No complaints about opensim, no opinions about Blue Mars and the = rest...


2009/11/24 Morgaine <morgaine.dinova at googlemail= .com>

On Mon, Nov 23, 2009 at 1:06 PM, Len Brown <lenwbrown at gmail.com> wrote:

 

For me the shock came when I was abruptly informed = that "OpenSim is not Second Life, is not intended to be like Second Life, nor ever will."  I still haven't the foggiest idea what this = developer had smoked for them to so strongly assert that incredibly false = statement.

 

Len, let me give you = an alternative perspective on that quote to help you see the reasons for = it.  I'm not on the Opensim team, but after five years in SL, two years in = AWG, and a year of working on future VW protocols in our IETF group, I have some background to know why Opensim needs to distance itself from = SL:

  • SL's statically tiled resource = architecture is badly non-scalable, because most resource usage in VWs = cannot be statically mapped (demand moves around).  The inability to = assign resources dynamically in SL results in huge overload in busy places = and gross wastage in idle areas.  It also limits the number of participants in events and the bandwidth of their interaction, as = well as the size and complexity of everything in a region.  This = architecture is fundamental to SL, yet it is a recipe for failure.  As long = as Opensim adheres to the SL model, Opensim will be similarly = non-scalable.

 

  • The LSL scripting language is = linguistically weak, semantically obscure, and lacking in the glue that could = allow components to cooperate effectively.  As a result, individual = scripts are quite underpowered and inefficient, and multi-script = constructions do not scale well in complexity because the overheads of cooperation = are so large.  That's a bad restriction on progress which Opensim = needs to leave behind.

 

  • LSL scripts are not scalable in power or = size, and this will continue to be true even after SL allows C# and other = CLR languages to be used.  There is no possibility of using more = CPU power for scripting than is available in one single simulator in = SL.  That is not a good foundation upon which to build an ambitious = future of clever components.

 

  • SL's simulation environment is = non-portable, having evolved over time into a plethora of special cases that will = not be accurately replicable anywhere else.  In effect this means = that there will never be effective interop with SL's scripted objects.  = It would not be a useful goal to seek compatibility with what could = realistically be described as an "ill-defined mess".

 

  • SL's object and type systems are = non-extensible, so compatibility with SL means living in the past, and worse, = living in a past defined entirely by one slow-moving company.  Tying the capabilities of Opensim to that millstone would be a disaster --- = it would ensure the death of Opensim versus any extensible alternative that = may appear.  Developing new extensible forms of world data beyond = SL's original set is a must for Opensim's survival as a modern VW = platform.

 

  • SL's viewer has deep knowledge of SL = semantics because the client and server were designed for each other rather = than designed as endpoints of a standard protocol.  This has the = very bad consequence that future VW viewers would need to know about SL = specifics in order to interoperate with SL, which is a poor approach that = doesn't scale to metaverse-wide diversity.  Opensim needs to leave world-specific kludges behind if it has ambitions to underpin a = highly diverse metaverse of worlds, and this means leaving the SL viewer = behind.

 

  • SL's constructed objects are = non-hierarchical, which means that creators cannot use objects created by others as subcomponents.  This restriction completely blocks the = hierarchical engineering process that is the basis of progress in RL.  In = SL you always have to build from "raw materials", so it is not = possible to ride on the shoulders of giants, nor harness a huge pyramid of = people skills.  Even Philip and Cory Linden admitted that this was a = mistake -- see  https://wiki.secondlife.com/wiki/Prim_and_Object_Hierar= chy .  We don't want to live with their mistake.

 

  • SL is based on highly centralized = concepts of identity, storage and control, which come together to = create either a walled garden or a prison planet, depending on one's perspective.  Whatever one's worldview, the end result is = badly non-scalable in those three areas.  SL suffers hugely from = that non-scalability despite the relatively small size of the service at = this early stage.  Opensim needs decentralized / distributed = mechanisms for identity, storage and control if it is to scale for Internet-wide adoption.

 

  • From a futurist angle, Second Life has = very narrow horizons and barely pays lip service to the = virtual aspect of "virtual worlds".  Nobody could claim that = a Flatland of square land tiles all featuring the same Earth-like = look and physics pushes the envelope of the imagination.  To boldly go = where Lindens did not go before (topologically and geographically or = spatially) will be one of the most appreciated developments in Opensim.  = SL's obsession with RL is an unwanted constraint in VWs, and we need to = go beyond it.



That is not the full list of problems with SL, but hopefully it serves = to illustrate some of the concerns that VW developers have to consider in = the light of the SL legacy.  While Linden Lab deserves much applause = for their vision and for their work in creating Second Life, many years have now = passed, and lessons have been learned.  Compatibility with SL must not be = the end goal of Opensim because of issues like those highlighted above.

From bogus@does.not.exist.com Sat Apr 19 02:14:48 2014 From: bogus@does.not.exist.com () Date: Sat, 19 Apr 2014 02:14:48 -0000 Subject: No subject Message-ID: evolution of virtual worlds.  It is no surprise that most Opensim developers = wish to go beyond that first step, learning from past mistakes and finding = better models for the future.

I mentioned earlier our work at the IETF on new VW protocols, in which = LL are a leading party --- see  https://www.ietf.org/mailman/listinfo/ogpx , the = mailing list of the VWRAP working group.  What may surprise you is that = even Lindens know that the current SL is not a good model for the future, = which is why the protocols being discussed go far beyond their legacy ones.  Indeed, Lindens will be facing a huge rewrite if this work bears = fruit.  When even Lindens don't wish their future to be constrained by the = current SL design because they know its many problems, this really highlights how = bad it would be for the Opensim team to do so. :-)

I hope that one or more of these issues resonates with you, and makes it = a bit clearer why Opensim really cannot afford to align itself with SL.  = There is no future in looking backwards.


Morgaine.






=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

On Mon, Nov 23, 2009 at 1:06 PM, Len Brown <lenwbrown at gmail.com> wrote:

Rock,

     I sympathize with you on many levels.  = I've also had my doubts regarding the future of OpenSim, but I have also = maintained some degree of faith that things will pull through in the end.

     For me the shock came when I was abruptly = informed that "OpenSim is not Second Life, is not intended to be like Second = Life, nor ever will."  I still haven't the foggiest idea what this developer had smoked for them to so strongly assert that incredibly = false statement.

     For me, the enjoyment of OpenSim has come from = my intense devotion to building and skinning.  In fact, for the last = few months I've been working on a full region that has many hundreds of = skins, clothes, hair, furniture, etc, etc, that I'd like to package up as an = OAR and give out freely, since repeatedly I've been told that instead of giving = money to help further OpenSim I'd do more proactively by giving content.  = So I plan to do just that and give my money to other open source initiatives = that matter to me.

     I have a passion for writing, and have thought = many times that one of the greatest powers OpenSim would gain is having = simple, straightforward, step-by-step instructions on how to download, compile, install, administer and overall just plain operate the core = applications.  What kills me is that everyone who does a search for OpenSim inevitably = hits the opensimulator.org site and that is where the massive roadblock presents itself.  It's useless for most and irrelevant to the few who consider themselves = OpenSim experts.

     Heck, even now on the configuration page it = still displays info for 0.6.6 including (months old) known bugs in setting up = region xml files.  If there was appointed a volunteer whose sole job was = to keep information on opensimulator.org relevant that one task would resolve a mountain of negativity right there.  I sit here in front of my computers a good 10 to 12 hours a = day.

     I would sincerely love to contribute to the = OpenSim project, especially in documentation support.  But the thing = holding me back is communication.  If I cannot get a straight answer on who to = GIVE money to in order to help, then I stand little chance of getting clear, straight answers from developers when asking about issues I need to = consider and incorporate in documentation.

     If communication is a hurdle we can all = overcome, with a genuine and heart-felt effort to relay information, motives, and plans = with one another, then I'd sincerely appreciate having the opportunity to = personally contribute.  I'm not a programmer today, but have a degree in = programming fro the 90's (so much has changed my degree is practically useless in = that regard).  But I do know how to explain things and relay information = in simple terms.  But only if my own questions will be answered with = more than "look it up or figure it out yourself" as my answer.

     If any of you would appreciate my help, feel = free to let me know at any time and I'll do what I can.

- Len W. Brown
     lenwbrown at gmail.com

 

On Mon, Nov 23, 2009 at 6:23 AM, Colin B. Withers = <Colin.Withers at eumetsat.int> wrote:

Hi guys,

I have decided to leave the Opensim project. You will probably not even = notice if I leave, as not being a programmer my only inputs were the writing of = the step-by-step tutorials ( http://chapter-and-metaverse.blogspot.com/ ), the = drafts of the OpenSim User Manual on the Forge, and helping out in the IRC = channels, for newcomers.

You may find my reasons for leaving Opensim interesting though (and = please do not construe any of my reasons as an attack on anyone).

1. The Platform
I raised this several times in the past in IRC, and made posts on my = blog about the product lifecycle of the platform ( http://rock-vacirca.blogspot.com/2009/02/direction-of-v= irtual-worlds.html ). I believe that the platforms underpinning both Second Life and = Opensim are quite long in the tooth now, and I questioned how much product lifecycle = there was left, particularly given that Opensim is now nearing 3 years of development, is still in Alpha, and if the current release of 0.6.7 is = any indicator, then still only around two thirds into the development cycle. = With the (inevitable) coming of much superior platforms, such as Blue Mars = and (as a virtual world); Unity, for browser-based Virtual Wolrds; and now UDK = (for creating sandboxes, standalones, and open grids), then I fear that = Opensim has missed the boat as far as the remaining lifecycle of the platform is = concerned. When you show people what is possible with these engines (for example = this avatar editor for the forthcom
 ing APB (using the Unreal Engine): http://www.youtube.com/watch?v=3DicR3LtEMvZI or this city: http://www.youtube.com/watch?v=3DhmLzNbPXMDg = (using the CryEngine), then neither SL not Opensim stands comparison.

2. Lack of Support for Currency in Opensim
I felt the impact of this when I first made the switch from SL to = Opensim. I had a thriving RP sim in SL (over 50 people, mainly female) and they all = agreed to follow me over to my Opensim and the OSGrid. However, within a month = they had all left, citing the same reason, the lack of places to shop, to buy = the quality stuff they wanted (skins, hair, clothes etc), as a quality appearance, = and the fun of shopping is what all the females placed high on their = requirements from a Virtual World. They drifted back to Second Life, and the guys followed = them. I have always believed that the lack of support for currency in the core = was a mistake, but that is just my opinion.

3. Marketing
I have also raised this issue several times, and blogged about it. It is = far from clear just who an eventually released Opensim is actually aimed at. = I think that any company that is interested in a firewalled corporate = solution to collaboration and prototyping will already be looking at the Enterprise solution that is currently available from Second Life; that any indie = group that is thinking of running a themed grid will need an economy to stay = viable; and any individual who is looking for a private sandbox solution for = their SL work will need full compatibility (which is not the case with the OS = version of LSL diverging from the SL LSL). So, just who is the platform aimed at? I = was also very disappointed in the view of one of the core devs who said that 'marketing is a null concept for us'.

I am currently designing and creating cities for Blue Mars, and involved = in a team for proving the UDK as a platform for the design and creation of = Virtual Worlds (as opposed to purely games), and with so much documentation = available for these mature engines (particularly for the UDK, Blue Mars lags = behind somewhat in that department, but have hired extra staff to put that = right), I am achieving the productivity I want, building the worlds that I want, = with stable crash-free platforms.

However, I do wish the Opensim team the very best in their endeavours, = and I sincerely hope their goals are eventually achieved.

If anyone would like to take over the Opensim Tutorials pages at http://chapter-and-metaverse.blogspot.com/ and http://chapter-and-metaverse2.blogspot.com/ (they will need some updating following several changes) then I am more = than willing to pass the posts over, and of course the Opensim User Manual is = there in the Forge for anyone to develop further.

Best Regards and Good Luck

Rock


_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

 


_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

 


_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de=
https://lists.berlios.de/mailman/listinfo/opensim-dev

 

------=_NextPart_000_00B7_01CA6CF5.12D3D3E0-- From jjustincc at googlemail.com Tue Apr 1 00:03:12 2014 From: jjustincc at googlemail.com (Justin Clark-Casey) Date: Tue, 01 Apr 2014 01:03:12 +0100 Subject: [Opensim-dev] Optimize pushing assets to other grids In-Reply-To: <53399CF4.9090609@t-data.com> References: <1396190871524-7579093.post@n2.nabble.com> <5338312A.4070302@metaverseink.com> <1396266948910-7579100.post@n2.nabble.com> <5339995A.4010208@t-data.com> <53399CF4.9090609@t-data.com> Message-ID: <533A0240.7010103@googlemail.com> I originally put in the MajorInterfaceVersion back in 2008 but I now think that's a very bad way to handle updates in a distributed system with no central control. Instead, just like the web, the protocol should be designed with extensbility in mind so that the system can evolve without massive disruption [1], allowing old and new components to co-exist. I think that one more planned bump of MajorInterfaceVersion would be acceptable to introduce extensibility but continual bumps are going to do damage to the system and people's confidence in the system. Not only does it affect the Hypergrid idea, but also in a large grid it makes it very difficult, if not impossible, to experiment with newer updates if they are not protocol compatible. I'll also note that the version number has not been bumped since October 2010. Unsurprisingly, nobody has wanted to inflict (or be blamed) for that pain so everybody has been at pains not to introduce incompatible updates (or only incompatible in minor ways). But really this compatibility should be achieved with a planned mechanism rather than the ad hoc measures that have always been used, and where one day luck runs out. [1] https://www.ics.uci.edu/~fielding/pubs/dissertation/net_app_arch.htm#sec_2_2 On 31/03/14 17:51, Melanie wrote: > There is no implicit versioning in the actual request protocol. That > would have been impossible to maintain in the long run. Instead, > there is a "protocol version". We can bump it when there are > incompatible changes on any protocol and it invalidates all of them. > So a sim version 7 will refuse to connect to a server version 6 and > vice versa. This gives us both control and simplicity. > > Melanie > > On 31/03/2014 18:45, Jim Williams wrote: >> Seems reasonable to me...A design approach I would have taken. >> >> One question. Is there some sort of versioning built into the protocol? >> One verb yes, but the dictionary numbers the definitions..... >> >> >> On Mon, Mar 31, 2014 at 12:35 PM, Melanie wrote: >> >>> This isn't designed as RPC, it's designed as REST. One URL/VERB >>> combination for each function. >>> We wanted to get away from the RPC concept. Let's not take backwards >>> steps here. >>> >>> Melanie >>> >>> On 31/03/2014 15:15, Oren Hurvitz wrote: >>>> This isn't overloading: it's an RPC endpoint that accepts many methods. >>> You >>>> wouldn't create a separate endpoint for each method, would you? >>>> >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>> http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579104.html >>>> Sent from the opensim-dev mailing list archive at Nabble.com. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> Opensim-dev at lists.berlios.de >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >> >> >> >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > . > -- Justin Clark-Casey (justincc) OSVW Consulting http://justincc.org http://twitter.com/justincc From orenh at kitely.com Tue Apr 1 13:00:30 2014 From: orenh at kitely.com (Oren Hurvitz) Date: Tue, 1 Apr 2014 06:00:30 -0700 (PDT) Subject: [Opensim-dev] REST handlers use partial string matching Message-ID: <1396357230099-7579119.post@n2.nabble.com> I tried to add a REST handler at the endpoint "/assets_exist". It turns out that I can't do that, because REST handlers are searched using partial string matches, so servers that don't implement the new handler will mistakenly choose the "/assets" endpoint instead. For now, I solved the problem by using a different endpoint: "/get_assets_exist". For the future, I think that this should be changed so that only full string matches work. Otherwise each time a new handler is added it will have to find an endpoint name that isn't a prefix of any current endpoint -- a difficult and error-prone task. Before I do that, does anyone know of endpoints that rely on the current behavior (partial string matches)? -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119.html Sent from the opensim-dev mailing list archive at Nabble.com. From melanie at t-data.com Tue Apr 1 17:55:14 2014 From: melanie at t-data.com (Melanie) Date: Tue, 01 Apr 2014 19:55:14 +0200 Subject: [Opensim-dev] REST handlers use partial string matching In-Reply-To: <1396357230099-7579119.post@n2.nabble.com> References: <1396357230099-7579119.post@n2.nabble.com> Message-ID: <533AFD82.9010603@t-data.com> The REST URLs need to use partial matching, however, current semantics are broken. Without partial matching, URLS like /assets/782911..... would not work. the issue here is that it should match whole URL parts, not partial URL parts. Matching partial words as it does now seems like someone was cutting corners, it's not by design. /assets/ should match /assets/9887234...... but not /assets_exist. The slash is the differentiator and partial compares of URL string prefixes should be done by full-string matches of slash/delimited parts, not prefix matching of the entire URL. Melanie On 01/04/2014 15:00, Oren Hurvitz wrote: > I tried to add a REST handler at the endpoint "/assets_exist". It turns out > that I can't do that, because REST handlers are searched using partial > string matches, so servers that don't implement the new handler will > mistakenly choose the "/assets" endpoint instead. > > For now, I solved the problem by using a different endpoint: > "/get_assets_exist". > > For the future, I think that this should be changed so that only full string > matches work. Otherwise each time a new handler is added it will have to > find an endpoint name that isn't a prefix of any current endpoint -- a > difficult and error-prone task. Before I do that, does anyone know of > endpoints that rely on the current behavior (partial string matches)? > > > > -- > View this message in context: http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119.html > Sent from the opensim-dev mailing list archive at Nabble.com. > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > From jjustincc at googlemail.com Tue Apr 1 17:59:57 2014 From: jjustincc at googlemail.com (Justin Clark-Casey) Date: Tue, 01 Apr 2014 18:59:57 +0100 Subject: [Opensim-dev] REST handlers use partial string matching In-Reply-To: <1396357230099-7579119.post@n2.nabble.com> References: <1396357230099-7579119.post@n2.nabble.com> Message-ID: <533AFE9D.1020406@googlemail.com> Hi Oren. I believe the expected way to retrieve metadata (and effectively an existence check) for a resource in REST would be to send a HEAD request [1] to the url, rather than to have a separate endpoint. I think changing the handling to exact matching is fine - I can't think why partial matching is done currently and I can't see how it makes sense in an HTTP context. As far as I know nothing makes use of partial matching. [1] http://books.google.co.uk/books?id=XUaErakHsoAC&pg=PA98&lpg=PA98&dq=restful+web+services+%22OPTIONS+method+lets%22&source=bl&ots=5jkmCnpNmy&sig=mXt_bcmXcZhoU6hFFm0L5j14IvE&hl=en&sa=X&ei=Hf06U--1E7GM7Aad2YHwAw&ved=0CDMQ6AEwAA#v=onepage&q=restful%20web%20services%20%22OPTIONS%20method%20lets%22&f=false On 01/04/14 14:00, Oren Hurvitz wrote: > I tried to add a REST handler at the endpoint "/assets_exist". It turns out > that I can't do that, because REST handlers are searched using partial > string matches, so servers that don't implement the new handler will > mistakenly choose the "/assets" endpoint instead. > > For now, I solved the problem by using a different endpoint: > "/get_assets_exist". > > For the future, I think that this should be changed so that only full string > matches work. Otherwise each time a new handler is added it will have to > find an endpoint name that isn't a prefix of any current endpoint -- a > difficult and error-prone task. Before I do that, does anyone know of > endpoints that rely on the current behavior (partial string matches)? > > > > -- > View this message in context: http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119.html > Sent from the opensim-dev mailing list archive at Nabble.com. > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- Justin Clark-Casey (justincc) OSVW Consulting http://justincc.org http://twitter.com/justincc From jjustincc at googlemail.com Tue Apr 1 18:03:55 2014 From: jjustincc at googlemail.com (Justin Clark-Casey) Date: Tue, 01 Apr 2014 19:03:55 +0100 Subject: [Opensim-dev] REST handlers use partial string matching In-Reply-To: <533AFD82.9010603@t-data.com> References: <1396357230099-7579119.post@n2.nabble.com> <533AFD82.9010603@t-data.com> Message-ID: <533AFF8B.6050607@googlemail.com> In what context is such partial matching required? It is not a requirement of REST, as far as I know. On 01/04/14 18:55, Melanie wrote: > The REST URLs need to use partial matching, however, current > semantics are broken. > > Without partial matching, URLS like /assets/782911..... would not > work. the issue here is that it should match whole URL parts, not > partial URL parts. Matching partial words as it does now seems like > someone was cutting corners, it's not by design. > > /assets/ should match /assets/9887234...... but not /assets_exist. > The slash is the differentiator and partial compares of URL string > prefixes should be done by full-string matches of slash/delimited > parts, not prefix matching of the entire URL. > > Melanie > > On 01/04/2014 15:00, Oren Hurvitz wrote: >> I tried to add a REST handler at the endpoint "/assets_exist". It turns out >> that I can't do that, because REST handlers are searched using partial >> string matches, so servers that don't implement the new handler will >> mistakenly choose the "/assets" endpoint instead. >> >> For now, I solved the problem by using a different endpoint: >> "/get_assets_exist". >> >> For the future, I think that this should be changed so that only full string >> matches work. Otherwise each time a new handler is added it will have to >> find an endpoint name that isn't a prefix of any current endpoint -- a >> difficult and error-prone task. Before I do that, does anyone know of >> endpoints that rely on the current behavior (partial string matches)? >> >> >> >> -- >> View this message in context: http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119.html >> Sent from the opensim-dev mailing list archive at Nabble.com. >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- Justin Clark-Casey (justincc) OSVW Consulting http://justincc.org http://twitter.com/justincc From melanie at t-data.com Tue Apr 1 19:00:30 2014 From: melanie at t-data.com (Melanie) Date: Tue, 01 Apr 2014 21:00:30 +0200 Subject: [Opensim-dev] REST handlers use partial string matching In-Reply-To: <533AFF8B.6050607@googlemail.com> References: <1396357230099-7579119.post@n2.nabble.com> <533AFD82.9010603@t-data.com> <533AFF8B.6050607@googlemail.com> Message-ID: <533B0CCE.5000308@t-data.com> It is required because it's the basis of "extra path info". It's not part of REST, but rather part of HTTP. Requesting /asset/456392f6-c0b3-a346-6465-8218cbe7abe84592 which is not a registered URL, will invoke /asset/ which is. The ID passed as part of the URL is then given to that handler as the extra path info. You have the same thing in apache. Basically, any URL longer than and starting with a registered URL will invoke that registered URL with extra path info. The fallacy in our server is that the matching isn't by path parts, but character-wise. Melanie On 01/04/2014 20:03, Justin Clark-Casey wrote: > In what context is such partial matching required? It is not a requirement of REST, as far as I know. > > On 01/04/14 18:55, Melanie wrote: >> The REST URLs need to use partial matching, however, current >> semantics are broken. >> >> Without partial matching, URLS like /assets/782911..... would not >> work. the issue here is that it should match whole URL parts, not >> partial URL parts. Matching partial words as it does now seems like >> someone was cutting corners, it's not by design. >> >> /assets/ should match /assets/9887234...... but not /assets_exist. >> The slash is the differentiator and partial compares of URL string >> prefixes should be done by full-string matches of slash/delimited >> parts, not prefix matching of the entire URL. >> >> Melanie >> >> On 01/04/2014 15:00, Oren Hurvitz wrote: >>> I tried to add a REST handler at the endpoint "/assets_exist". It turns out >>> that I can't do that, because REST handlers are searched using partial >>> string matches, so servers that don't implement the new handler will >>> mistakenly choose the "/assets" endpoint instead. >>> >>> For now, I solved the problem by using a different endpoint: >>> "/get_assets_exist". >>> >>> For the future, I think that this should be changed so that only full string >>> matches work. Otherwise each time a new handler is added it will have to >>> find an endpoint name that isn't a prefix of any current endpoint -- a >>> difficult and error-prone task. Before I do that, does anyone know of >>> endpoints that rely on the current behavior (partial string matches)? >>> >>> >>> >>> -- >>> View this message in context: http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119.html >>> Sent from the opensim-dev mailing list archive at Nabble.com. >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > From cmickeyb at gmail.com Tue Apr 1 19:08:02 2014 From: cmickeyb at gmail.com (Mic Bowman) Date: Tue, 1 Apr 2014 12:08:02 -0700 Subject: [Opensim-dev] REST handlers use partial string matching In-Reply-To: <533B0CCE.5000308@t-data.com> References: <1396357230099-7579119.post@n2.nabble.com> <533AFD82.9010603@t-data.com> <533AFF8B.6050607@googlemail.com> <533B0CCE.5000308@t-data.com> Message-ID: so what you're saying is just make sure the '/' is part of the match? to terminate the match? i think the problem is that /asset matches /asset_test which is not what is expected. so all registered partial matches should include the trailing '/' to disambiguate... or am i missing the point? On Tue, Apr 1, 2014 at 12:00 PM, Melanie wrote: > It is required because it's the basis of "extra path info". It's not > part of REST, but rather part of HTTP. > > Requesting > > /asset/456392f6-c0b3-a346-6465-8218cbe7abe84592 > > which is not a registered URL, will invoke > > /asset/ > > which is. The ID passed as part of the URL is then given to that > handler as the extra path info. You have the same thing in apache. > > Basically, any URL longer than and starting with a registered URL > will invoke that registered URL with extra path info. > The fallacy in our server is that the matching isn't by path parts, > but character-wise. > > Melanie > > On 01/04/2014 20:03, Justin Clark-Casey wrote: > > In what context is such partial matching required? It is not a > requirement of REST, as far as I know. > > > > On 01/04/14 18:55, Melanie wrote: > >> The REST URLs need to use partial matching, however, current > >> semantics are broken. > >> > >> Without partial matching, URLS like /assets/782911..... would not > >> work. the issue here is that it should match whole URL parts, not > >> partial URL parts. Matching partial words as it does now seems like > >> someone was cutting corners, it's not by design. > >> > >> /assets/ should match /assets/9887234...... but not /assets_exist. > >> The slash is the differentiator and partial compares of URL string > >> prefixes should be done by full-string matches of slash/delimited > >> parts, not prefix matching of the entire URL. > >> > >> Melanie > >> > >> On 01/04/2014 15:00, Oren Hurvitz wrote: > >>> I tried to add a REST handler at the endpoint "/assets_exist". It > turns out > >>> that I can't do that, because REST handlers are searched using partial > >>> string matches, so servers that don't implement the new handler will > >>> mistakenly choose the "/assets" endpoint instead. > >>> > >>> For now, I solved the problem by using a different endpoint: > >>> "/get_assets_exist". > >>> > >>> For the future, I think that this should be changed so that only full > string > >>> matches work. Otherwise each time a new handler is added it will have > to > >>> find an endpoint name that isn't a prefix of any current endpoint -- a > >>> difficult and error-prone task. Before I do that, does anyone know of > >>> endpoints that rely on the current behavior (partial string matches)? > >>> > >>> > >>> > >>> -- > >>> View this message in context: > http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119.html > >>> Sent from the opensim-dev mailing list archive at Nabble.com. > >>> _______________________________________________ > >>> Opensim-dev mailing list > >>> Opensim-dev at lists.berlios.de > >>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> > >>> > >> _______________________________________________ > >> Opensim-dev mailing list > >> Opensim-dev at lists.berlios.de > >> https://lists.berlios.de/mailman/listinfo/opensim-dev > >> > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jjustincc at googlemail.com Tue Apr 1 19:30:40 2014 From: jjustincc at googlemail.com (Justin Clark-Casey) Date: Tue, 01 Apr 2014 20:30:40 +0100 Subject: [Opensim-dev] REST handlers use partial string matching In-Reply-To: <533B0CCE.5000308@t-data.com> References: <1396357230099-7579119.post@n2.nabble.com> <533AFD82.9010603@t-data.com> <533AFF8B.6050607@googlemail.com> <533B0CCE.5000308@t-data.com> Message-ID: <533B13E0.9040107@googlemail.com> Ah okay, I see what you mean. Yes, the asset/ part matches the asset handler and then it is in charge of interpreting the subsequent 456392f6-c0b3-a346-6465-8218cbe7abe84592 section of the path. When you said 782911... below I thought that you were talking about UUID fragments as used by git to identify commits, where "782911" would normally be enough to identify an asset like "782911f6-c0b3-a346-6465-8218cbe7abe84592" so you could say something like GET http://myserver.com/asset/782911. But that was a misinterpretation. On 01/04/14 20:00, Melanie wrote: > It is required because it's the basis of "extra path info". It's not > part of REST, but rather part of HTTP. > > Requesting > > /asset/456392f6-c0b3-a346-6465-8218cbe7abe84592 > > which is not a registered URL, will invoke > > /asset/ > > which is. The ID passed as part of the URL is then given to that > handler as the extra path info. You have the same thing in apache. > > Basically, any URL longer than and starting with a registered URL > will invoke that registered URL with extra path info. > The fallacy in our server is that the matching isn't by path parts, > but character-wise. > > Melanie > > On 01/04/2014 20:03, Justin Clark-Casey wrote: >> In what context is such partial matching required? It is not a requirement of REST, as far as I know. >> >> On 01/04/14 18:55, Melanie wrote: >>> The REST URLs need to use partial matching, however, current >>> semantics are broken. >>> >>> Without partial matching, URLS like /assets/782911..... would not >>> work. the issue here is that it should match whole URL parts, not >>> partial URL parts. Matching partial words as it does now seems like >>> someone was cutting corners, it's not by design. >>> >>> /assets/ should match /assets/9887234...... but not /assets_exist. >>> The slash is the differentiator and partial compares of URL string >>> prefixes should be done by full-string matches of slash/delimited >>> parts, not prefix matching of the entire URL. >>> >>> Melanie >>> >>> On 01/04/2014 15:00, Oren Hurvitz wrote: >>>> I tried to add a REST handler at the endpoint "/assets_exist". It turns out >>>> that I can't do that, because REST handlers are searched using partial >>>> string matches, so servers that don't implement the new handler will >>>> mistakenly choose the "/assets" endpoint instead. >>>> >>>> For now, I solved the problem by using a different endpoint: >>>> "/get_assets_exist". >>>> >>>> For the future, I think that this should be changed so that only full string >>>> matches work. Otherwise each time a new handler is added it will have to >>>> find an endpoint name that isn't a prefix of any current endpoint -- a >>>> difficult and error-prone task. Before I do that, does anyone know of >>>> endpoints that rely on the current behavior (partial string matches)? >>>> >>>> >>>> >>>> -- >>>> View this message in context: http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119.html >>>> Sent from the opensim-dev mailing list archive at Nabble.com. >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> Opensim-dev at lists.berlios.de >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> >>>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >> > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > . > -- Justin Clark-Casey (justincc) OSVW Consulting http://justincc.org http://twitter.com/justincc From sphere1952 at gmail.com Tue Apr 1 19:47:21 2014 From: sphere1952 at gmail.com (Jim Williams) Date: Tue, 1 Apr 2014 15:47:21 -0400 Subject: [Opensim-dev] REST handlers use partial string matching In-Reply-To: References: <1396357230099-7579119.post@n2.nabble.com> <533AFD82.9010603@t-data.com> <533AFF8B.6050607@googlemail.com> <533B0CCE.5000308@t-data.com> Message-ID: I think the correct way to look at this is that any URI "..../handler/..." should be passed to the correct "handler" handler; which should then pass the rest of the path on to any sub-handlers as appropriate. You shouldn't be looking at the parts of a path element unless it is the leaf (follows the last slash). The URI began life as a directory tree, and you would not match part of the directory thinking it was a file. Any valid semantic URI parser will interpret elements of a URI strictly in context, and never assume anything about elements except within the context of the element to its immediate left. It would be ok for /asset and /asset_test to be treated as a match, but never ok for /asset/ and /asset_test or /asset_test/ to match. One is matching a directory to a file, and the other is matching two different directories. On Tue, Apr 1, 2014 at 3:08 PM, Mic Bowman wrote: > so what you're saying is just make sure the '/' is part of the match? to > terminate the match? i think the problem is that /asset matches /asset_test > which is not what is expected. so all registered partial matches should > include the trailing '/' to disambiguate... or am i missing the point? > > > > On Tue, Apr 1, 2014 at 12:00 PM, Melanie wrote: > >> It is required because it's the basis of "extra path info". It's not >> part of REST, but rather part of HTTP. >> >> Requesting >> >> /asset/456392f6-c0b3-a346-6465-8218cbe7abe84592 >> >> which is not a registered URL, will invoke >> >> /asset/ >> >> which is. The ID passed as part of the URL is then given to that >> handler as the extra path info. You have the same thing in apache. >> >> Basically, any URL longer than and starting with a registered URL >> will invoke that registered URL with extra path info. >> The fallacy in our server is that the matching isn't by path parts, >> but character-wise. >> >> Melanie >> >> On 01/04/2014 20:03, Justin Clark-Casey wrote: >> > In what context is such partial matching required? It is not a >> requirement of REST, as far as I know. >> > >> > On 01/04/14 18:55, Melanie wrote: >> >> The REST URLs need to use partial matching, however, current >> >> semantics are broken. >> >> >> >> Without partial matching, URLS like /assets/782911..... would not >> >> work. the issue here is that it should match whole URL parts, not >> >> partial URL parts. Matching partial words as it does now seems like >> >> someone was cutting corners, it's not by design. >> >> >> >> /assets/ should match /assets/9887234...... but not /assets_exist. >> >> The slash is the differentiator and partial compares of URL string >> >> prefixes should be done by full-string matches of slash/delimited >> >> parts, not prefix matching of the entire URL. >> >> >> >> Melanie >> >> >> >> On 01/04/2014 15:00, Oren Hurvitz wrote: >> >>> I tried to add a REST handler at the endpoint "/assets_exist". It >> turns out >> >>> that I can't do that, because REST handlers are searched using partial >> >>> string matches, so servers that don't implement the new handler will >> >>> mistakenly choose the "/assets" endpoint instead. >> >>> >> >>> For now, I solved the problem by using a different endpoint: >> >>> "/get_assets_exist". >> >>> >> >>> For the future, I think that this should be changed so that only full >> string >> >>> matches work. Otherwise each time a new handler is added it will have >> to >> >>> find an endpoint name that isn't a prefix of any current endpoint -- a >> >>> difficult and error-prone task. Before I do that, does anyone know of >> >>> endpoints that rely on the current behavior (partial string matches)? >> >>> >> >>> >> >>> >> >>> -- >> >>> View this message in context: >> http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119.html >> >>> Sent from the opensim-dev mailing list archive at Nabble.com. >> >>> _______________________________________________ >> >>> Opensim-dev mailing list >> >>> Opensim-dev at lists.berlios.de >> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >>> >> >>> >> >> _______________________________________________ >> >> Opensim-dev mailing list >> >> Opensim-dev at lists.berlios.de >> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> >> > >> > >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- No essence. No permanence. No perfection. Only action. -------------- next part -------------- An HTML attachment was scrubbed... URL: From orenh at kitely.com Tue Apr 1 19:49:49 2014 From: orenh at kitely.com (Oren Hurvitz) Date: Tue, 1 Apr 2014 12:49:49 -0700 (PDT) Subject: [Opensim-dev] REST handlers use partial string matching In-Reply-To: <533AFE9D.1020406@googlemail.com> References: <1396357230099-7579119.post@n2.nabble.com> <533AFE9D.1020406@googlemail.com> Message-ID: <1396381789745-7579127.post@n2.nabble.com> Re: why use POST instead of HEAD: because this lets me check the existence of many assets at once with a single HTTP request. The main use of the AssetsExist call is with HGAssetGatherer, which knows the full list of assets that it wants to send, so it's able to check all of them at once. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119p7579127.html Sent from the opensim-dev mailing list archive at Nabble.com. From cmickeyb at gmail.com Tue Apr 1 19:52:43 2014 From: cmickeyb at gmail.com (Mic Bowman) Date: Tue, 1 Apr 2014 12:52:43 -0700 Subject: [Opensim-dev] REST handlers use partial string matching In-Reply-To: <1396381789745-7579127.post@n2.nabble.com> References: <1396357230099-7579119.post@n2.nabble.com> <533AFE9D.1020406@googlemail.com> <1396381789745-7579127.post@n2.nabble.com> Message-ID: Do you really save much with a single request vs a keep alive on the connection? HTTP connection overhead is likely much smaller than the database operations... do you have a feel for how much we'll save with the multiplexed call? --mic On Tue, Apr 1, 2014 at 12:49 PM, Oren Hurvitz wrote: > Re: why use POST instead of HEAD: because this lets me check the existence > of > many assets at once with a single HTTP request. The main use of the > AssetsExist call is with HGAssetGatherer, which knows the full list of > assets that it wants to send, so it's able to check all of them at once. > > > > -- > View this message in context: > http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119p7579127.html > Sent from the opensim-dev mailing list archive at Nabble.com. > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From melanie at t-data.com Tue Apr 1 19:56:18 2014 From: melanie at t-data.com (Melanie) Date: Tue, 01 Apr 2014 21:56:18 +0200 Subject: [Opensim-dev] REST handlers use partial string matching In-Reply-To: References: <1396357230099-7579119.post@n2.nabble.com> <533AFD82.9010603@t-data.com> <533AFF8B.6050607@googlemail.com> <533B0CCE.5000308@t-data.com> Message-ID: <533B19E2.7030002@t-data.com> The proper method is to break up the local portion of the URL into words using "/" as the separator, then matching that list of words against similar lists created from the registered URLs, usually stored as a tree. There are two ways to match, "shortest match" and "more specific". The algorithm used by apache is "shortest match", meaning that as soon as a word list is fully matched against the request's words, it's considered a match and the handler is invoked. Everything past the matched portion becomes extra path info. Melanie On 01/04/2014 21:08, Mic Bowman wrote: > so what you're saying is just make sure the '/' is part of the match? to > terminate the match? i think the problem is that /asset matches /asset_test > which is not what is expected. so all registered partial matches should > include the trailing '/' to disambiguate... or am i missing the point? > > > > On Tue, Apr 1, 2014 at 12:00 PM, Melanie wrote: > >> It is required because it's the basis of "extra path info". It's not >> part of REST, but rather part of HTTP. >> >> Requesting >> >> /asset/456392f6-c0b3-a346-6465-8218cbe7abe84592 >> >> which is not a registered URL, will invoke >> >> /asset/ >> >> which is. The ID passed as part of the URL is then given to that >> handler as the extra path info. You have the same thing in apache. >> >> Basically, any URL longer than and starting with a registered URL >> will invoke that registered URL with extra path info. >> The fallacy in our server is that the matching isn't by path parts, >> but character-wise. >> >> Melanie >> >> On 01/04/2014 20:03, Justin Clark-Casey wrote: >> > In what context is such partial matching required? It is not a >> requirement of REST, as far as I know. >> > >> > On 01/04/14 18:55, Melanie wrote: >> >> The REST URLs need to use partial matching, however, current >> >> semantics are broken. >> >> >> >> Without partial matching, URLS like /assets/782911..... would not >> >> work. the issue here is that it should match whole URL parts, not >> >> partial URL parts. Matching partial words as it does now seems like >> >> someone was cutting corners, it's not by design. >> >> >> >> /assets/ should match /assets/9887234...... but not /assets_exist. >> >> The slash is the differentiator and partial compares of URL string >> >> prefixes should be done by full-string matches of slash/delimited >> >> parts, not prefix matching of the entire URL. >> >> >> >> Melanie >> >> >> >> On 01/04/2014 15:00, Oren Hurvitz wrote: >> >>> I tried to add a REST handler at the endpoint "/assets_exist". It >> turns out >> >>> that I can't do that, because REST handlers are searched using partial >> >>> string matches, so servers that don't implement the new handler will >> >>> mistakenly choose the "/assets" endpoint instead. >> >>> >> >>> For now, I solved the problem by using a different endpoint: >> >>> "/get_assets_exist". >> >>> >> >>> For the future, I think that this should be changed so that only full >> string >> >>> matches work. Otherwise each time a new handler is added it will have >> to >> >>> find an endpoint name that isn't a prefix of any current endpoint -- a >> >>> difficult and error-prone task. Before I do that, does anyone know of >> >>> endpoints that rely on the current behavior (partial string matches)? >> >>> >> >>> >> >>> >> >>> -- >> >>> View this message in context: >> http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119.html >> >>> Sent from the opensim-dev mailing list archive at Nabble.com. >> >>> _______________________________________________ >> >>> Opensim-dev mailing list >> >>> Opensim-dev at lists.berlios.de >> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >>> >> >>> >> >> _______________________________________________ >> >> Opensim-dev mailing list >> >> Opensim-dev at lists.berlios.de >> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> >> > >> > >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev From dahliatrimble at gmail.com Tue Apr 1 19:56:44 2014 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Tue, 1 Apr 2014 12:56:44 -0700 Subject: [Opensim-dev] REST handlers use partial string matching In-Reply-To: References: <1396357230099-7579119.post@n2.nabble.com> <533AFE9D.1020406@googlemail.com> <1396381789745-7579127.post@n2.nabble.com> Message-ID: Not sure about this particular application but keeping a connection open can eliminate the need to instantiate a connection whenever a request is made; a process that can make several round trips to multiple endpoints. On Tue, Apr 1, 2014 at 12:52 PM, Mic Bowman wrote: > Do you really save much with a single request vs a keep alive on the > connection? HTTP connection overhead is likely much smaller than the > database operations... do you have a feel for how much we'll save with the > multiplexed call? > > --mic > > > > On Tue, Apr 1, 2014 at 12:49 PM, Oren Hurvitz wrote: > >> Re: why use POST instead of HEAD: because this lets me check the >> existence of >> many assets at once with a single HTTP request. The main use of the >> AssetsExist call is with HGAssetGatherer, which knows the full list of >> assets that it wants to send, so it's able to check all of them at once. >> >> >> >> -- >> View this message in context: >> http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119p7579127.html >> Sent from the opensim-dev mailing list archive at Nabble.com. >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From melanie at t-data.com Tue Apr 1 19:59:01 2014 From: melanie at t-data.com (Melanie) Date: Tue, 01 Apr 2014 21:59:01 +0200 Subject: [Opensim-dev] REST handlers use partial string matching In-Reply-To: References: <1396357230099-7579119.post@n2.nabble.com> <533AFD82.9010603@t-data.com> <533AFF8B.6050607@googlemail.com> <533B0CCE.5000308@t-data.com> Message-ID: <533B1A85.7070207@t-data.com> Well, with URLs, it's not known which part (word) of the url local part is a directory and which is a file/script. http://www.example.com/dir/file.php/extra/info is legal. At the time of parsing, it is not intrinsically knowable that file.php is a script. Therefore, you can't look at just the last element, but need to match wordwise left to right. Melanie On 01/04/2014 21:47, Jim Williams wrote: > I think the correct way to look at this is that any URI "..../handler/..." > should be passed to the correct "handler" handler; which should then pass > the rest of the path on to any sub-handlers as appropriate. You shouldn't > be looking at the parts of a path element unless it is the leaf (follows > the last slash). The URI began life as a directory tree, and you would not > match part of the directory thinking it was a file. Any valid semantic URI > parser will interpret elements of a URI strictly in context, and never > assume anything about elements except within the context of the element to > its immediate left. > > It would be ok for /asset and /asset_test to be treated as a match, but > never ok for /asset/ and /asset_test or /asset_test/ to match. One is > matching a directory to a file, and the other is matching two different > directories. > > > > On Tue, Apr 1, 2014 at 3:08 PM, Mic Bowman wrote: > >> so what you're saying is just make sure the '/' is part of the match? to >> terminate the match? i think the problem is that /asset matches /asset_test >> which is not what is expected. so all registered partial matches should >> include the trailing '/' to disambiguate... or am i missing the point? >> >> >> >> On Tue, Apr 1, 2014 at 12:00 PM, Melanie wrote: >> >>> It is required because it's the basis of "extra path info". It's not >>> part of REST, but rather part of HTTP. >>> >>> Requesting >>> >>> /asset/456392f6-c0b3-a346-6465-8218cbe7abe84592 >>> >>> which is not a registered URL, will invoke >>> >>> /asset/ >>> >>> which is. The ID passed as part of the URL is then given to that >>> handler as the extra path info. You have the same thing in apache. >>> >>> Basically, any URL longer than and starting with a registered URL >>> will invoke that registered URL with extra path info. >>> The fallacy in our server is that the matching isn't by path parts, >>> but character-wise. >>> >>> Melanie >>> >>> On 01/04/2014 20:03, Justin Clark-Casey wrote: >>> > In what context is such partial matching required? It is not a >>> requirement of REST, as far as I know. >>> > >>> > On 01/04/14 18:55, Melanie wrote: >>> >> The REST URLs need to use partial matching, however, current >>> >> semantics are broken. >>> >> >>> >> Without partial matching, URLS like /assets/782911..... would not >>> >> work. the issue here is that it should match whole URL parts, not >>> >> partial URL parts. Matching partial words as it does now seems like >>> >> someone was cutting corners, it's not by design. >>> >> >>> >> /assets/ should match /assets/9887234...... but not /assets_exist. >>> >> The slash is the differentiator and partial compares of URL string >>> >> prefixes should be done by full-string matches of slash/delimited >>> >> parts, not prefix matching of the entire URL. >>> >> >>> >> Melanie >>> >> >>> >> On 01/04/2014 15:00, Oren Hurvitz wrote: >>> >>> I tried to add a REST handler at the endpoint "/assets_exist". It >>> turns out >>> >>> that I can't do that, because REST handlers are searched using partial >>> >>> string matches, so servers that don't implement the new handler will >>> >>> mistakenly choose the "/assets" endpoint instead. >>> >>> >>> >>> For now, I solved the problem by using a different endpoint: >>> >>> "/get_assets_exist". >>> >>> >>> >>> For the future, I think that this should be changed so that only full >>> string >>> >>> matches work. Otherwise each time a new handler is added it will have >>> to >>> >>> find an endpoint name that isn't a prefix of any current endpoint -- a >>> >>> difficult and error-prone task. Before I do that, does anyone know of >>> >>> endpoints that rely on the current behavior (partial string matches)? >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> View this message in context: >>> http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119.html >>> >>> Sent from the opensim-dev mailing list archive at Nabble.com. >>> >>> _______________________________________________ >>> >>> Opensim-dev mailing list >>> >>> Opensim-dev at lists.berlios.de >>> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> >>> >>> >>> >> _______________________________________________ >>> >> Opensim-dev mailing list >>> >> Opensim-dev at lists.berlios.de >>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >>> > >>> > >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev From sphere1952 at gmail.com Tue Apr 1 19:59:57 2014 From: sphere1952 at gmail.com (Jim Williams) Date: Tue, 1 Apr 2014 15:59:57 -0400 Subject: [Opensim-dev] Question re REST verses RPC, et. al. Message-ID: Why are you supporting push at all? Shouldn't this be being deprecated with the intent of removal???? (Also....a new protocol version ought to be as simple as adding /asset1/ next to /asset/ and adding a note to the log that the /asset/ resource is going to be removed at some point in the future.) -- No essence. No permanence. No perfection. Only action. -------------- next part -------------- An HTML attachment was scrubbed... URL: From melanie at t-data.com Tue Apr 1 19:59:56 2014 From: melanie at t-data.com (Melanie) Date: Tue, 01 Apr 2014 21:59:56 +0200 Subject: [Opensim-dev] REST handlers use partial string matching In-Reply-To: <1396381789745-7579127.post@n2.nabble.com> References: <1396357230099-7579119.post@n2.nabble.com> <533AFE9D.1020406@googlemail.com> <1396381789745-7579127.post@n2.nabble.com> Message-ID: <533B1ABC.6010009@t-data.com> HEAD is meant to test if a request endpoint is implemented and to retrieve metadata like detailed capabilities/options/flags. Melanie On 01/04/2014 21:49, Oren Hurvitz wrote: > Re: why use POST instead of HEAD: because this lets me check the existence of > many assets at once with a single HTTP request. The main use of the > AssetsExist call is with HGAssetGatherer, which knows the full list of > assets that it wants to send, so it's able to check all of them at once. > > > > -- > View this message in context: http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119p7579127.html > Sent from the opensim-dev mailing list archive at Nabble.com. > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > From melanie at t-data.com Tue Apr 1 20:02:49 2014 From: melanie at t-data.com (Melanie) Date: Tue, 01 Apr 2014 22:02:49 +0200 Subject: [Opensim-dev] REST handlers use partial string matching In-Reply-To: References: <1396357230099-7579119.post@n2.nabble.com> <533AFE9D.1020406@googlemail.com> <1396381789745-7579127.post@n2.nabble.com> Message-ID: <533B1B69.8050200@t-data.com> Because REST is cleaner and more modularized than RPC. Just compare the code and you will see that. Efficiency is achieved by designing the REST calls intelligently. The /asset/ endpoint for instance can benefit from keep-alive because it supports HEAD/GET?POST so multiple operations can reuse the connection. The exists query is orthogonal to that and should be another request endpoint. Melanie On 01/04/2014 21:56, Dahlia Trimble wrote: > Not sure about this particular application but keeping a connection open > can eliminate the need to instantiate a connection whenever a request is > made; a process that can make several round trips to multiple endpoints. > > > On Tue, Apr 1, 2014 at 12:52 PM, Mic Bowman wrote: > >> Do you really save much with a single request vs a keep alive on the >> connection? HTTP connection overhead is likely much smaller than the >> database operations... do you have a feel for how much we'll save with the >> multiplexed call? >> >> --mic >> >> >> >> On Tue, Apr 1, 2014 at 12:49 PM, Oren Hurvitz wrote: >> >>> Re: why use POST instead of HEAD: because this lets me check the >>> existence of >>> many assets at once with a single HTTP request. The main use of the >>> AssetsExist call is with HGAssetGatherer, which knows the full list of >>> assets that it wants to send, so it's able to check all of them at once. >>> >>> >>> >>> -- >>> View this message in context: >>> http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119p7579127.html >>> Sent from the opensim-dev mailing list archive at Nabble.com. >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev From sphere1952 at gmail.com Tue Apr 1 20:14:31 2014 From: sphere1952 at gmail.com (Jim Williams) Date: Tue, 1 Apr 2014 16:14:31 -0400 Subject: [Opensim-dev] REST handlers use partial string matching In-Reply-To: <533B1A85.7070207@t-data.com> References: <1396357230099-7579119.post@n2.nabble.com> <533AFD82.9010603@t-data.com> <533AFF8B.6050607@googlemail.com> <533B0CCE.5000308@t-data.com> <533B1A85.7070207@t-data.com> Message-ID: I said Semantic, not syntactic. :) I agree, but syntactically we should be doing no semantic thinking at all until we get to the handler for file.php (Python), who would do the semantic parsing and might feel like doing some pattern matching on the elements to the right. That is, we shouldn't even be looking at the last element during syntactic analysis. It's probably a mistake to even parse the string to the right of file.php, other than to find its end, but almost all parsers I've ever seen don't know when to stop. On Tue, Apr 1, 2014 at 3:59 PM, Melanie wrote: > Well, with URLs, it's not known which part (word) of the url local > part is a directory and which is a file/script. > > http://www.example.com/dir/file.php/extra/info > > is legal. At the time of parsing, it is not intrinsically knowable > that file.php is a script. Therefore, you can't look at just the > last element, but need to match wordwise left to right. > > Melanie > > On 01/04/2014 21:47, Jim Williams wrote: > > I think the correct way to look at this is that any URI > "..../handler/..." > > should be passed to the correct "handler" handler; which should then pass > > the rest of the path on to any sub-handlers as appropriate. You > shouldn't > > be looking at the parts of a path element unless it is the leaf (follows > > the last slash). The URI began life as a directory tree, and you would > not > > match part of the directory thinking it was a file. Any valid semantic > URI > > parser will interpret elements of a URI strictly in context, and never > > assume anything about elements except within the context of the element > to > > its immediate left. > > > > It would be ok for /asset and /asset_test to be treated as a match, but > > never ok for /asset/ and /asset_test or /asset_test/ to match. One is > > matching a directory to a file, and the other is matching two different > > directories. > > > > > > > > On Tue, Apr 1, 2014 at 3:08 PM, Mic Bowman wrote: > > > >> so what you're saying is just make sure the '/' is part of the match? to > >> terminate the match? i think the problem is that /asset matches > /asset_test > >> which is not what is expected. so all registered partial matches should > >> include the trailing '/' to disambiguate... or am i missing the point? > >> > >> > >> > >> On Tue, Apr 1, 2014 at 12:00 PM, Melanie wrote: > >> > >>> It is required because it's the basis of "extra path info". It's not > >>> part of REST, but rather part of HTTP. > >>> > >>> Requesting > >>> > >>> /asset/456392f6-c0b3-a346-6465-8218cbe7abe84592 > >>> > >>> which is not a registered URL, will invoke > >>> > >>> /asset/ > >>> > >>> which is. The ID passed as part of the URL is then given to that > >>> handler as the extra path info. You have the same thing in apache. > >>> > >>> Basically, any URL longer than and starting with a registered URL > >>> will invoke that registered URL with extra path info. > >>> The fallacy in our server is that the matching isn't by path parts, > >>> but character-wise. > >>> > >>> Melanie > >>> > >>> On 01/04/2014 20:03, Justin Clark-Casey wrote: > >>> > In what context is such partial matching required? It is not a > >>> requirement of REST, as far as I know. > >>> > > >>> > On 01/04/14 18:55, Melanie wrote: > >>> >> The REST URLs need to use partial matching, however, current > >>> >> semantics are broken. > >>> >> > >>> >> Without partial matching, URLS like /assets/782911..... would not > >>> >> work. the issue here is that it should match whole URL parts, not > >>> >> partial URL parts. Matching partial words as it does now seems like > >>> >> someone was cutting corners, it's not by design. > >>> >> > >>> >> /assets/ should match /assets/9887234...... but not /assets_exist. > >>> >> The slash is the differentiator and partial compares of URL string > >>> >> prefixes should be done by full-string matches of slash/delimited > >>> >> parts, not prefix matching of the entire URL. > >>> >> > >>> >> Melanie > >>> >> > >>> >> On 01/04/2014 15:00, Oren Hurvitz wrote: > >>> >>> I tried to add a REST handler at the endpoint "/assets_exist". It > >>> turns out > >>> >>> that I can't do that, because REST handlers are searched using > partial > >>> >>> string matches, so servers that don't implement the new handler > will > >>> >>> mistakenly choose the "/assets" endpoint instead. > >>> >>> > >>> >>> For now, I solved the problem by using a different endpoint: > >>> >>> "/get_assets_exist". > >>> >>> > >>> >>> For the future, I think that this should be changed so that only > full > >>> string > >>> >>> matches work. Otherwise each time a new handler is added it will > have > >>> to > >>> >>> find an endpoint name that isn't a prefix of any current endpoint > -- a > >>> >>> difficult and error-prone task. Before I do that, does anyone know > of > >>> >>> endpoints that rely on the current behavior (partial string > matches)? > >>> >>> > >>> >>> > >>> >>> > >>> >>> -- > >>> >>> View this message in context: > >>> > http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119.html > >>> >>> Sent from the opensim-dev mailing list archive at Nabble.com. > >>> >>> _______________________________________________ > >>> >>> Opensim-dev mailing list > >>> >>> Opensim-dev at lists.berlios.de > >>> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> >>> > >>> >>> > >>> >> _______________________________________________ > >>> >> Opensim-dev mailing list > >>> >> Opensim-dev at lists.berlios.de > >>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> >> > >>> > > >>> > > >>> _______________________________________________ > >>> Opensim-dev mailing list > >>> Opensim-dev at lists.berlios.de > >>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> > >> > >> > >> _______________________________________________ > >> Opensim-dev mailing list > >> Opensim-dev at lists.berlios.de > >> https://lists.berlios.de/mailman/listinfo/opensim-dev > >> > > > > > > > > > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- No essence. No permanence. No perfection. Only action. -------------- next part -------------- An HTML attachment was scrubbed... URL: From diva at metaverseink.com Tue Apr 1 20:15:50 2014 From: diva at metaverseink.com (Diva Canto) Date: Tue, 01 Apr 2014 13:15:50 -0700 Subject: [Opensim-dev] REST handlers use partial string matching In-Reply-To: <533B1B69.8050200@t-data.com> References: <1396357230099-7579119.post@n2.nabble.com> <533AFE9D.1020406@googlemail.com> <1396381789745-7579127.post@n2.nabble.com> <533B1B69.8050200@t-data.com> Message-ID: <533B1E76.8000805@metaverseink.com> BTW, for assets, in particular, there is already a GET metadata method, which is the same endpoint of the data itself, just with one more path compoenent /metadata/, if I remember correctly. This should be enough to know if the asset exists. Doesn't address the issue of multiple UUIDs in one call vs one at a time. On 4/1/2014 1:02 PM, Melanie wrote: > Because REST is cleaner and more modularized than RPC. Just compare > the code and you will see that. Efficiency is achieved by designing > the REST calls intelligently. The /asset/ endpoint for instance can > benefit from keep-alive because it supports HEAD/GET?POST so > multiple operations can reuse the connection. > The exists query is orthogonal to that and should be another request > endpoint. > > Melanie > > On 01/04/2014 21:56, Dahlia Trimble wrote: >> Not sure about this particular application but keeping a connection open >> can eliminate the need to instantiate a connection whenever a request is >> made; a process that can make several round trips to multiple endpoints. >> >> >> On Tue, Apr 1, 2014 at 12:52 PM, Mic Bowman wrote: >> >>> Do you really save much with a single request vs a keep alive on the >>> connection? HTTP connection overhead is likely much smaller than the >>> database operations... do you have a feel for how much we'll save with the >>> multiplexed call? >>> >>> --mic >>> >>> >>> >>> On Tue, Apr 1, 2014 at 12:49 PM, Oren Hurvitz wrote: >>> >>>> Re: why use POST instead of HEAD: because this lets me check the >>>> existence of >>>> many assets at once with a single HTTP request. The main use of the >>>> AssetsExist call is with HGAssetGatherer, which knows the full list of >>>> assets that it wants to send, so it's able to check all of them at once. >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>>> http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119p7579127.html >>>> Sent from the opensim-dev mailing list archive at Nabble.com. >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> Opensim-dev at lists.berlios.de >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> >>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > From orenh at kitely.com Tue Apr 1 21:21:12 2014 From: orenh at kitely.com (Oren Hurvitz) Date: Tue, 1 Apr 2014 14:21:12 -0700 (PDT) Subject: [Opensim-dev] REST handlers use partial string matching In-Reply-To: References: <1396357230099-7579119.post@n2.nabble.com> <533AFE9D.1020406@googlemail.com> <1396381789745-7579127.post@n2.nabble.com> Message-ID: <1396387272022-7579137.post@n2.nabble.com> The AssetsExist API is implemented efficiently in all levels of the stack including the database, where a single query checks all the assets. So a single HTTP request will be vastly more efficient than multiple calls, even if KeepAlive works. And I never trust KeepAlive anyway because I've used proxies that didn't enable KeepAlive by default (mod_ajp_proxy). -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119p7579137.html Sent from the opensim-dev mailing list archive at Nabble.com. From jjustincc at googlemail.com Wed Apr 2 01:41:53 2014 From: jjustincc at googlemail.com (Justin Clark-Casey) Date: Wed, 02 Apr 2014 02:41:53 +0100 Subject: [Opensim-dev] Preparing for OpenSimulator 0.8 Message-ID: <533B6AE1.5020108@googlemail.com> Hi folks. For the past 3 years, we've had a significant OpenSimulator release at about 4 to 8 month intervals. As the last major release (0.7.6) was in September 2013, we are due for another, and this seems like a reasonable point. From my perspective, releases drive a very significant level of OpenSimulator adoption. It's also the case that I may have a limited window of time to act as release manager, after which things may get very busy for me for an extended period. There was some disagreement over how the last release was handled, particularly over the period when I asked that developers take care to leave master stable. However, it's quite hard for me to see how this could be done in another way without significantly more manpower. Even when the release is branched, if the release branch and master diverge significantly (or master is broken) then a lot of the testing done by users is lost - very few people actually pick up and test release candidates. So unless there is disagreement, I'm going to ask that people take care to keep master stable until the end of April or release, whichever occurs first. This certainly does not mean a halt to development on master, it's just a request that people take a common sense approach to holding off from putting in destabilising or very complicated changes for a while, unless these are to fix significant bugs or regressions. I'm very happy to hear alternatives, though I would also need people to help if they involve more work. In any case, Robert has very kindly volunteered to look at some of the current regressions but more help is always very welcome. The current regressions or very major bugs have a 0.8 target in Mantis. As with every release so far, only major regressions are guaranteed to receive some sort of attention, where the answer may still be WONTFIX for this release. Regards, -- Justin Clark-Casey (justincc) OSVW Consulting http://justincc.org http://twitter.com/justincc From nebadon2025 at gmail.com Wed Apr 2 01:45:13 2014 From: nebadon2025 at gmail.com (Michael Emory Cerquoni) Date: Tue, 1 Apr 2014 21:45:13 -0400 Subject: [Opensim-dev] Preparing for OpenSimulator 0.8 In-Reply-To: <533B6AE1.5020108@googlemail.com> References: <533B6AE1.5020108@googlemail.com> Message-ID: +1 no disagreement here! anyone who wants to get crazy can do so in a new branch for now? On Apr 1, 2014 9:42 PM, "Justin Clark-Casey" wrote: > Hi folks. For the past 3 years, we've had a significant OpenSimulator > release at about 4 to 8 month intervals. > > As the last major release (0.7.6) was in September 2013, we are due for > another, and this seems like a reasonable point. From my perspective, > releases drive a very significant level of OpenSimulator adoption. It's > also the case that I may have a limited window of time to act as release > manager, after which things may get very busy for me for an extended period. > > There was some disagreement over how the last release was handled, > particularly over the period when I asked that developers take care to > leave master stable. However, it's quite hard for me to see how this could > be done in another way without significantly more manpower. Even when the > release is branched, if the release branch and master diverge significantly > (or master is broken) then a lot of the testing done by users is lost - > very few people actually pick up and test release candidates. > > So unless there is disagreement, I'm going to ask that people take care to > keep master stable until the end of April or release, whichever occurs > first. This certainly does not mean a halt to development on master, it's > just a request that people take a common sense approach to holding off from > putting in destabilising or very complicated changes for a while, unless > these are to fix significant bugs or regressions. > > I'm very happy to hear alternatives, though I would also need people to > help if they involve more work. In any case, Robert has very kindly > volunteered to look at some of the current regressions but more help is > always very welcome. > > The current regressions or very major bugs have a 0.8 target in Mantis. > As with every release so far, only major regressions are guaranteed to > receive some sort of attention, where the answer may still be WONTFIX for > this release. > > Regards, > > -- > Justin Clark-Casey (justincc) > OSVW Consulting > http://justincc.org > http://twitter.com/justincc > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From orenh at kitely.com Wed Apr 2 06:07:42 2014 From: orenh at kitely.com (Oren Hurvitz) Date: Tue, 1 Apr 2014 23:07:42 -0700 (PDT) Subject: [Opensim-dev] REST handlers use partial string matching In-Reply-To: <533B19E2.7030002@t-data.com> References: <1396357230099-7579119.post@n2.nabble.com> <533AFD82.9010603@t-data.com> <533AFF8B.6050607@googlemail.com> <533B0CCE.5000308@t-data.com> <533B19E2.7030002@t-data.com> Message-ID: <1396418862788-7579140.post@n2.nabble.com> I changed BaseHttpServer to require handler paths to match a full path component. For example, these match: "/assets" and "/assets/12345" But these don't match: "/assets" and "/assets_exist" -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119p7579140.html Sent from the opensim-dev mailing list archive at Nabble.com. From melanie at t-data.com Wed Apr 2 06:13:52 2014 From: melanie at t-data.com (Melanie) Date: Wed, 02 Apr 2014 08:13:52 +0200 Subject: [Opensim-dev] REST handlers use partial string matching In-Reply-To: <1396418862788-7579140.post@n2.nabble.com> References: <1396357230099-7579119.post@n2.nabble.com> <533AFD82.9010603@t-data.com> <533AFF8B.6050607@googlemail.com> <533B0CCE.5000308@t-data.com> <533B19E2.7030002@t-data.com> <1396418862788-7579140.post@n2.nabble.com> Message-ID: <533BAAA0.2060103@t-data.com> Thanks, that was a good catch! Melanie On 02/04/2014 08:07, Oren Hurvitz wrote: > I changed BaseHttpServer to require handler paths to match a full path > component. > > For example, these match: "/assets" and "/assets/12345" > But these don't match: "/assets" and "/assets_exist" > > > > > -- > View this message in context: http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119p7579140.html > Sent from the opensim-dev mailing list archive at Nabble.com. > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > From orenh at kitely.com Wed Apr 2 07:11:38 2014 From: orenh at kitely.com (Oren Hurvitz) Date: Wed, 2 Apr 2014 00:11:38 -0700 (PDT) Subject: [Opensim-dev] Optimize pushing assets to other grids In-Reply-To: <5339B3D2.4060902@metaverseink.com> References: <1396190871524-7579093.post@n2.nabble.com> <5338312A.4070302@metaverseink.com> <1396266948910-7579100.post@n2.nabble.com> <5339995A.4010208@t-data.com> <1396284763662-7579112.post@n2.nabble.com> <5339B3D2.4060902@metaverseink.com> Message-ID: <1396422698476-7579142.post@n2.nabble.com> I've added AssetsExist to master. It's implemented using REST, at "/get_assets_exist". Regarding getting server capabilities: later I realized that Hypergrid already has the "helo" command, which serves this purpose. Currently it returns only one type of property: whether the server is based on Robust or Simian. But it would be trivial to allow it to return other properties and preferences as well. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579142.html Sent from the opensim-dev mailing list archive at Nabble.com. From orenh at kitely.com Wed Apr 2 09:00:31 2014 From: orenh at kitely.com (Oren Hurvitz) Date: Wed, 2 Apr 2014 02:00:31 -0700 (PDT) Subject: [Opensim-dev] Viewer doesn't render attachments after teleport Message-ID: <1396429231035-7579143.post@n2.nabble.com> I'm seeing strange behavior from viewers: after an avatar HG teleports to another grid, his attachments sometimes aren't visible to *some* of the avatars in the region. The isn't that the attachments have been detached: the log shows that they came across perfectly. And some of the avatars in the region *do* see the attachments, while some do not. For example, in Singularity, an avatar already in the region sees the incoming avatar's attachments, whereas the incoming avatar himself does not! In Firestorm the problem is the reverse: the incoming avatar does see his attachments, but the avatar already in the grid doesn't. Waiting doesn't solve the problem. But other actions sometimes do: * Most tellingly, sometimes merely changing the zoom level of the viewer (using the mousewheel) makes the attachments appear. No packets are sent to or from the viewer at this time (I checked). * If the avatar walks forward then sometimes one or more of the attachments appear. But strangely, walking backwards doesn't make them appear. I looked carefully at the packets being sent to see if anything is missing, or whether the packets differ between avatars that do see the attachments and those who don't, but I can't see a difference. And in any case, the fact that sometimes the attachments can appear even without any packets being sent (as in the mousewheel example) means that it's something to do with the viewer. I don't want to just say "it's a viewer problem" and move on, because it's a problem for users of OpenSim. My working assumption is that by sending additional packets, or at different times, we can make the viewer refresh itself and show the attachments. This would only need to happen shortly after a teleport. Does anyone know what we could do to force the viewer to redraw the attachments? I tried sending additional "ObjectUpdate" packets for the attachments, but this didn't help. Oren -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Viewer-doesn-t-render-attachments-after-teleport-tp7579143.html Sent from the opensim-dev mailing list archive at Nabble.com. From orenh at kitely.com Wed Apr 2 09:05:36 2014 From: orenh at kitely.com (Oren Hurvitz) Date: Wed, 2 Apr 2014 02:05:36 -0700 (PDT) Subject: [Opensim-dev] Viewer doesn't render attachments after teleport In-Reply-To: <1396429231035-7579143.post@n2.nabble.com> References: <1396429231035-7579143.post@n2.nabble.com> Message-ID: <1396429536428-7579144.post@n2.nabble.com> Here's another interesting finding: even when the attachments aren't visible, I can click on them to edit them. The viewer renders a yellow outline around the shape of the attachment (in Singularity), even while the area inside the outline still doesn't show the attachment. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Viewer-doesn-t-render-attachments-after-teleport-tp7579143p7579144.html Sent from the opensim-dev mailing list archive at Nabble.com. From sphere1952 at gmail.com Wed Apr 2 11:01:17 2014 From: sphere1952 at gmail.com (Jim Williams) Date: Wed, 2 Apr 2014 07:01:17 -0400 Subject: [Opensim-dev] Viewer doesn't render attachments after teleport In-Reply-To: <1396429231035-7579143.post@n2.nabble.com> References: <1396429231035-7579143.post@n2.nabble.com> Message-ID: Are you sure this is just attachments? I've been having to right-click on certain objects after teleport for months now (in FS) under certain circumstances. This has been happening both in OSG and Metropolis. The problem usually happens if I jump again too soon after a teleport, and it is usually the same prims each time -- though which prims may change over time. I haven't noticed this to be specific to HG, though I do tend to double jump more when Hyperjumping. Mostly, I've learned to wait a few seconds before jumping a second time. On Wed, Apr 2, 2014 at 5:00 AM, Oren Hurvitz wrote: > I'm seeing strange behavior from viewers: after an avatar HG teleports to > another grid, his attachments sometimes aren't visible to *some* of the > avatars in the region. > > The isn't that the attachments have been detached: the log shows that they > came across perfectly. And some of the avatars in the region *do* see the > attachments, while some do not. For example, in Singularity, an avatar > already in the region sees the incoming avatar's attachments, whereas the > incoming avatar himself does not! In Firestorm the problem is the reverse: > the incoming avatar does see his attachments, but the avatar already in the > grid doesn't. > > Waiting doesn't solve the problem. But other actions sometimes do: > * Most tellingly, sometimes merely changing the zoom level of the viewer > (using the mousewheel) makes the attachments appear. No packets are sent to > or from the viewer at this time (I checked). > * If the avatar walks forward then sometimes one or more of the attachments > appear. But strangely, walking backwards doesn't make them appear. > > I looked carefully at the packets being sent to see if anything is missing, > or whether the packets differ between avatars that do see the attachments > and those who don't, but I can't see a difference. And in any case, the > fact > that sometimes the attachments can appear even without any packets being > sent (as in the mousewheel example) means that it's something to do with > the > viewer. > > I don't want to just say "it's a viewer problem" and move on, because it's > a > problem for users of OpenSim. My working assumption is that by sending > additional packets, or at different times, we can make the viewer refresh > itself and show the attachments. This would only need to happen shortly > after a teleport. > > Does anyone know what we could do to force the viewer to redraw the > attachments? I tried sending additional "ObjectUpdate" packets for the > attachments, but this didn't help. > > Oren > > > > -- > View this message in context: > http://opensim-dev.2196679.n2.nabble.com/Viewer-doesn-t-render-attachments-after-teleport-tp7579143.html > Sent from the opensim-dev mailing list archive at Nabble.com. > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- No essence. No permanence. No perfection. Only action. -------------- next part -------------- An HTML attachment was scrubbed... URL: From orenh at kitely.com Wed Apr 2 11:16:45 2014 From: orenh at kitely.com (Oren Hurvitz) Date: Wed, 2 Apr 2014 04:16:45 -0700 (PDT) Subject: [Opensim-dev] Viewer doesn't render attachments after teleport In-Reply-To: <1396429536428-7579144.post@n2.nabble.com> References: <1396429231035-7579143.post@n2.nabble.com> <1396429536428-7579144.post@n2.nabble.com> Message-ID: <1396437405521-7579146.post@n2.nabble.com> I got some great advice off-list from Nicky Perian. When there's a problem of missing prims, go to the Graphics Preferences and toggle the option "Basic shaders". I tried this, and toggling this option (on or off, both work) makes the missing prims appear immediately. This proves that the viewer has the correct data, and it's just not showing it. But I still want to find some combination of packets that will make the viewers show the prims, since obviously most users will not know to use this trick, and it's a hassle. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Viewer-doesn-t-render-attachments-after-teleport-tp7579143p7579146.html Sent from the opensim-dev mailing list archive at Nabble.com. From melanie at t-data.com Wed Apr 2 11:20:29 2014 From: melanie at t-data.com (Melanie) Date: Wed, 02 Apr 2014 13:20:29 +0200 Subject: [Opensim-dev] Viewer doesn't render attachments after teleport In-Reply-To: <1396437405521-7579146.post@n2.nabble.com> References: <1396429231035-7579143.post@n2.nabble.com> <1396429536428-7579144.post@n2.nabble.com> <1396437405521-7579146.post@n2.nabble.com> Message-ID: <533BF27D.5000707@t-data.com> I don't know if this may be related, but for some reason OpenSim fails to update the viewer's notion of position properly. The most noticeable effect is that sometimes after changing regions or even parcels, sound is no longer heard. The audibility check happens viewerside, just as the object visibility check. If the viewer gets a wrong location, it may consider the attachments as "too far away" and not render them - that is probably related to why zooming can make them appear. Therefore I don't believe we need to send any extra packets related to these objects, but rather we are missing some packet or sending wrong data related to the avatar's location. This appears to be the case on moving in world as well as teleports, but I have so far never observed it at login. Melanie On 02/04/2014 13:16, Oren Hurvitz wrote: > I got some great advice off-list from Nicky Perian. When there's a problem of > missing prims, go to the Graphics Preferences and toggle the option "Basic > shaders". I tried this, and toggling this option (on or off, both work) > makes the missing prims appear immediately. > > This proves that the viewer has the correct data, and it's just not showing > it. But I still want to find some combination of packets that will make the > viewers show the prims, since obviously most users will not know to use this > trick, and it's a hassle. > > > > -- > View this message in context: http://opensim-dev.2196679.n2.nabble.com/Viewer-doesn-t-render-attachments-after-teleport-tp7579143p7579146.html > Sent from the opensim-dev mailing list archive at Nabble.com. > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > From dahliatrimble at gmail.com Wed Apr 2 11:39:13 2014 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Wed, 2 Apr 2014 04:39:13 -0700 Subject: [Opensim-dev] Viewer doesn't render attachments after teleport In-Reply-To: <1396429536428-7579144.post@n2.nabble.com> References: <1396429231035-7579143.post@n2.nabble.com> <1396429536428-7579144.post@n2.nabble.com> Message-ID: I'd probably check the order of the packets. I'd suspect the ObjectUpdate for the agent should be sent first, then any attachment ObjectUpdate packets. It probably wouldn't hurt if the root prim is sent before any child prims but I'd hope the viewers could handle that situation. On Wed, Apr 2, 2014 at 2:05 AM, Oren Hurvitz wrote: > Here's another interesting finding: even when the attachments aren't > visible, > I can click on them to edit them. The viewer renders a yellow outline > around > the shape of the attachment (in Singularity), even while the area inside > the > outline still doesn't show the attachment. > > > > -- > View this message in context: > http://opensim-dev.2196679.n2.nabble.com/Viewer-doesn-t-render-attachments-after-teleport-tp7579143p7579144.html > Sent from the opensim-dev mailing list archive at Nabble.com. > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dahliatrimble at gmail.com Wed Apr 2 11:44:05 2014 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Wed, 2 Apr 2014 04:44:05 -0700 Subject: [Opensim-dev] Viewer doesn't render attachments after teleport In-Reply-To: <533BF27D.5000707@t-data.com> References: <1396429231035-7579143.post@n2.nabble.com> <1396429536428-7579144.post@n2.nabble.com> <1396437405521-7579146.post@n2.nabble.com> <533BF27D.5000707@t-data.com> Message-ID: Attachment positions are relative to bones. They really cannot be "too far away" On Wed, Apr 2, 2014 at 4:20 AM, Melanie wrote: > I don't know if this may be related, but for some reason OpenSim > fails to update the viewer's notion of position properly. > > The most noticeable effect is that sometimes after changing regions > or even parcels, sound is no longer heard. The audibility check > happens viewerside, just as the object visibility check. > > If the viewer gets a wrong location, it may consider the attachments > as "too far away" and not render them - that is probably related to > why zooming can make them appear. > > Therefore I don't believe we need to send any extra packets related > to these objects, but rather we are missing some packet or sending > wrong data related to the avatar's location. > > This appears to be the case on moving in world as well as teleports, > but I have so far never observed it at login. > > Melanie > > > On 02/04/2014 13:16, Oren Hurvitz wrote: > > I got some great advice off-list from Nicky Perian. When there's a > problem of > > missing prims, go to the Graphics Preferences and toggle the option > "Basic > > shaders". I tried this, and toggling this option (on or off, both work) > > makes the missing prims appear immediately. > > > > This proves that the viewer has the correct data, and it's just not > showing > > it. But I still want to find some combination of packets that will make > the > > viewers show the prims, since obviously most users will not know to use > this > > trick, and it's a hassle. > > > > > > > > -- > > View this message in context: > http://opensim-dev.2196679.n2.nabble.com/Viewer-doesn-t-render-attachments-after-teleport-tp7579143p7579146.html > > Sent from the opensim-dev mailing list archive at Nabble.com. > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dahliatrimble at gmail.com Wed Apr 2 11:50:28 2014 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Wed, 2 Apr 2014 04:50:28 -0700 Subject: [Opensim-dev] Viewer doesn't render attachments after teleport In-Reply-To: References: <1396429231035-7579143.post@n2.nabble.com> <1396429536428-7579144.post@n2.nabble.com> <1396437405521-7579146.post@n2.nabble.com> <533BF27D.5000707@t-data.com> Message-ID: I've seen attachment rezzing failures in SL for years. Right-clicking usually fixes it. If there is an issue then I suspect it's a long-standing viewer bug that may be exacerbated by some combination of legal protocol. If it is somehow related to packet ordering, then we might be able to send it in a particular order but given the non-stream nature of UDP we cannot guarantee it will be received in any order. On Wed, Apr 2, 2014 at 4:44 AM, Dahlia Trimble wrote: > Attachment positions are relative to bones. They really cannot be "too far > away" > > > On Wed, Apr 2, 2014 at 4:20 AM, Melanie wrote: > >> I don't know if this may be related, but for some reason OpenSim >> fails to update the viewer's notion of position properly. >> >> The most noticeable effect is that sometimes after changing regions >> or even parcels, sound is no longer heard. The audibility check >> happens viewerside, just as the object visibility check. >> >> If the viewer gets a wrong location, it may consider the attachments >> as "too far away" and not render them - that is probably related to >> why zooming can make them appear. >> >> Therefore I don't believe we need to send any extra packets related >> to these objects, but rather we are missing some packet or sending >> wrong data related to the avatar's location. >> >> This appears to be the case on moving in world as well as teleports, >> but I have so far never observed it at login. >> >> Melanie >> >> >> On 02/04/2014 13:16, Oren Hurvitz wrote: >> > I got some great advice off-list from Nicky Perian. When there's a >> problem of >> > missing prims, go to the Graphics Preferences and toggle the option >> "Basic >> > shaders". I tried this, and toggling this option (on or off, both work) >> > makes the missing prims appear immediately. >> > >> > This proves that the viewer has the correct data, and it's just not >> showing >> > it. But I still want to find some combination of packets that will make >> the >> > viewers show the prims, since obviously most users will not know to use >> this >> > trick, and it's a hassle. >> > >> > >> > >> > -- >> > View this message in context: >> http://opensim-dev.2196679.n2.nabble.com/Viewer-doesn-t-render-attachments-after-teleport-tp7579143p7579146.html >> > Sent from the opensim-dev mailing list archive at Nabble.com. >> > _______________________________________________ >> > Opensim-dev mailing list >> > Opensim-dev at lists.berlios.de >> > https://lists.berlios.de/mailman/listinfo/opensim-dev >> > >> > >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sphere1952 at gmail.com Wed Apr 2 14:07:59 2014 From: sphere1952 at gmail.com (Jim Williams) Date: Wed, 2 Apr 2014 10:07:59 -0400 Subject: [Opensim-dev] Preparing for OpenSimulator 0.8 In-Reply-To: <533B6AE1.5020108@googlemail.com> References: <533B6AE1.5020108@googlemail.com> Message-ID: Hi Justin, The fact that your message is a plea rather than an announcement makes it rather clear why I felt I had to leave OSG and move my sim to Metro. It also explains to me why I felt I had to add myself to this list at the same time -- self protection. If your release cycle is 4 months shouldn't there be a hard and fast feature freeze at the end of the first month? And there should be no back-talk or exceptions. Bug fixes ought to be just about 3/4 of the effort anyway. What OpenSim needs is credibility as a stable working system, not more features. If it''s a choice between what is going on now and having no development on OpenSim, I think I'd rather see no development. I have no way of stopping the badness from happening at my end other than complaining about it. On Tue, Apr 1, 2014 at 9:41 PM, Justin Clark-Casey wrote: > Hi folks. For the past 3 years, we've had a significant OpenSimulator > release at about 4 to 8 month intervals. > > As the last major release (0.7.6) was in September 2013, we are due for > another, and this seems like a reasonable point. From my perspective, > releases drive a very significant level of OpenSimulator adoption. It's > also the case that I may have a limited window of time to act as release > manager, after which things may get very busy for me for an extended period. > > There was some disagreement over how the last release was handled, > particularly over the period when I asked that developers take care to > leave master stable. However, it's quite hard for me to see how this could > be done in another way without significantly more manpower. Even when the > release is branched, if the release branch and master diverge significantly > (or master is broken) then a lot of the testing done by users is lost - > very few people actually pick up and test release candidates. > > So unless there is disagreement, I'm going to ask that people take care to > keep master stable until the end of April or release, whichever occurs > first. This certainly does not mean a halt to development on master, it's > just a request that people take a common sense approach to holding off from > putting in destabilising or very complicated changes for a while, unless > these are to fix significant bugs or regressions. > > I'm very happy to hear alternatives, though I would also need people to > help if they involve more work. In any case, Robert has very kindly > volunteered to look at some of the current regressions but more help is > always very welcome. > > The current regressions or very major bugs have a 0.8 target in Mantis. > As with every release so far, only major regressions are guaranteed to > receive some sort of attention, where the answer may still be WONTFIX for > this release. > > Regards, > > -- > Justin Clark-Casey (justincc) > OSVW Consulting > http://justincc.org > http://twitter.com/justincc > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- No essence. No permanence. No perfection. Only action. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nebadon2025 at gmail.com Wed Apr 2 14:22:57 2014 From: nebadon2025 at gmail.com (Michael Emory Cerquoni) Date: Wed, 2 Apr 2014 10:22:57 -0400 Subject: [Opensim-dev] Preparing for OpenSimulator 0.8 In-Reply-To: References: <533B6AE1.5020108@googlemail.com> Message-ID: Jim, You are way off topic here, this has nothing to do with OSG or Metro grids, I don't know why you suddenly feel the need to criticize everyone and everything announced here, but it has finally gotten to the point where I feel I need to step in and say something about this, your comments of late seem unproductive and volatile as if you are just trying to start arguments, please keep the drama out of these communications, Justin is simply trying to keep things moving forward in a productive manner and all I see from you lately is negativity and nothing that lends to any kind of improvement, this is a developer channel, if you want to lend to development than do something productive other than criticize, start submitting patches or get directly involved in debugging and filing bug reports or something, but please take the drama else where it is no appreciated. On Wed, Apr 2, 2014 at 10:07 AM, Jim Williams wrote: > Hi Justin, > > The fact that your message is a plea rather than an announcement makes it > rather clear why I felt I had to leave OSG and move my sim to Metro. It > also explains to me why I felt I had to add myself to this list at the same > time -- self protection. > > If your release cycle is 4 months shouldn't there be a hard and fast > feature freeze at the end of the first month? And there should be no > back-talk or exceptions. Bug fixes ought to be just about 3/4 of the > effort anyway. What OpenSim needs is credibility as a stable working > system, not more features. > > If it''s a choice between what is going on now and having no development > on OpenSim, I think I'd rather see no development. I have no way of > stopping the badness from happening at my end other than complaining about > it. > > > > On Tue, Apr 1, 2014 at 9:41 PM, Justin Clark-Casey < > jjustincc at googlemail.com> wrote: > >> Hi folks. For the past 3 years, we've had a significant OpenSimulator >> release at about 4 to 8 month intervals. >> >> As the last major release (0.7.6) was in September 2013, we are due for >> another, and this seems like a reasonable point. From my perspective, >> releases drive a very significant level of OpenSimulator adoption. It's >> also the case that I may have a limited window of time to act as release >> manager, after which things may get very busy for me for an extended period. >> >> There was some disagreement over how the last release was handled, >> particularly over the period when I asked that developers take care to >> leave master stable. However, it's quite hard for me to see how this could >> be done in another way without significantly more manpower. Even when the >> release is branched, if the release branch and master diverge significantly >> (or master is broken) then a lot of the testing done by users is lost - >> very few people actually pick up and test release candidates. >> >> So unless there is disagreement, I'm going to ask that people take care >> to keep master stable until the end of April or release, whichever occurs >> first. This certainly does not mean a halt to development on master, it's >> just a request that people take a common sense approach to holding off from >> putting in destabilising or very complicated changes for a while, unless >> these are to fix significant bugs or regressions. >> >> I'm very happy to hear alternatives, though I would also need people to >> help if they involve more work. In any case, Robert has very kindly >> volunteered to look at some of the current regressions but more help is >> always very welcome. >> >> The current regressions or very major bugs have a 0.8 target in Mantis. >> As with every release so far, only major regressions are guaranteed to >> receive some sort of attention, where the answer may still be WONTFIX for >> this release. >> >> Regards, >> >> -- >> Justin Clark-Casey (justincc) >> OSVW Consulting >> http://justincc.org >> http://twitter.com/justincc >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > -- > No essence. No permanence. No perfection. Only action. > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- Michael Emory Cerquoni -------------- next part -------------- An HTML attachment was scrubbed... URL: From diva at metaverseink.com Wed Apr 2 14:34:22 2014 From: diva at metaverseink.com (Diva Canto) Date: Wed, 02 Apr 2014 07:34:22 -0700 Subject: [Opensim-dev] Optimize pushing assets to other grids In-Reply-To: <1396422698476-7579142.post@n2.nabble.com> References: <1396190871524-7579093.post@n2.nabble.com> <5338312A.4070302@metaverseink.com> <1396266948910-7579100.post@n2.nabble.com> <5339995A.4010208@t-data.com> <1396284763662-7579112.post@n2.nabble.com> <5339B3D2.4060902@metaverseink.com> <1396422698476-7579142.post@n2.nabble.com> Message-ID: <533C1FEE.7020400@metaverseink.com> Yep, that's exactly its purpose. Feel free to add more info in the response. On 4/2/2014 12:11 AM, Oren Hurvitz wrote: > I've added AssetsExist to master. It's implemented using REST, at > "/get_assets_exist". > > Regarding getting server capabilities: later I realized that Hypergrid > already has the "helo" command, which serves this purpose. Currently it > returns only one type of property: whether the server is based on Robust or > Simian. But it would be trivial to allow it to return other properties and > preferences as well. > > > > -- > View this message in context: http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579142.html > Sent from the opensim-dev mailing list archive at Nabble.com. > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > From sphere1952 at gmail.com Wed Apr 2 14:39:46 2014 From: sphere1952 at gmail.com (Jim Williams) Date: Wed, 2 Apr 2014 10:39:46 -0400 Subject: [Opensim-dev] Preparing for OpenSimulator 0.8 In-Reply-To: References: <533B6AE1.5020108@googlemail.com> Message-ID: The basic problem is that their development will effect me as a user. I have no complaints about what Justin is trying to do. My complaint is how he has to word what he is doing, and I think it is because there is something wrong with the organization of this development project. Having looked at that organization, I'd say that the basic problem is that it is oriented about what potential developers might want to do rather than about what users might want. It's an organization I would want nothing to do with even if I wanted to work upon OpenSim rather than within it. Not only do I not want to do development, I want to use the system which was developed. The only reason I joined this list is because I think that the development currently happening is a threat to my continued enjoyment of the product. The difference between me and most end users is that I'm a retired programmer -- I know how these things go. So, you may drop dead for all I care. You are not helping to protect my environment. On Wed, Apr 2, 2014 at 10:22 AM, Michael Emory Cerquoni < nebadon2025 at gmail.com> wrote: > Jim, > > You are way off topic here, this has nothing to do with OSG or Metro > grids, I don't know why you suddenly feel the need to criticize everyone > and everything announced here, but it has finally gotten to the point where > I feel I need to step in and say something about this, your comments of > late seem unproductive and volatile as if you are just trying to start > arguments, please keep the drama out of these communications, Justin is > simply trying to keep things moving forward in a productive manner and all > I see from you lately is negativity and nothing that lends to any kind of > improvement, this is a developer channel, if you want to lend to > development than do something productive other than criticize, start > submitting patches or get directly involved in debugging and filing bug > reports or something, but please take the drama else where it is no > appreciated. > > > On Wed, Apr 2, 2014 at 10:07 AM, Jim Williams wrote: > >> Hi Justin, >> >> The fact that your message is a plea rather than an announcement makes it >> rather clear why I felt I had to leave OSG and move my sim to Metro. It >> also explains to me why I felt I had to add myself to this list at the same >> time -- self protection. >> >> If your release cycle is 4 months shouldn't there be a hard and fast >> feature freeze at the end of the first month? And there should be no >> back-talk or exceptions. Bug fixes ought to be just about 3/4 of the >> effort anyway. What OpenSim needs is credibility as a stable working >> system, not more features. >> >> If it''s a choice between what is going on now and having no development >> on OpenSim, I think I'd rather see no development. I have no way of >> stopping the badness from happening at my end other than complaining about >> it. >> >> >> >> On Tue, Apr 1, 2014 at 9:41 PM, Justin Clark-Casey < >> jjustincc at googlemail.com> wrote: >> >>> Hi folks. For the past 3 years, we've had a significant OpenSimulator >>> release at about 4 to 8 month intervals. >>> >>> As the last major release (0.7.6) was in September 2013, we are due for >>> another, and this seems like a reasonable point. From my perspective, >>> releases drive a very significant level of OpenSimulator adoption. It's >>> also the case that I may have a limited window of time to act as release >>> manager, after which things may get very busy for me for an extended period. >>> >>> There was some disagreement over how the last release was handled, >>> particularly over the period when I asked that developers take care to >>> leave master stable. However, it's quite hard for me to see how this could >>> be done in another way without significantly more manpower. Even when the >>> release is branched, if the release branch and master diverge significantly >>> (or master is broken) then a lot of the testing done by users is lost - >>> very few people actually pick up and test release candidates. >>> >>> So unless there is disagreement, I'm going to ask that people take care >>> to keep master stable until the end of April or release, whichever occurs >>> first. This certainly does not mean a halt to development on master, it's >>> just a request that people take a common sense approach to holding off from >>> putting in destabilising or very complicated changes for a while, unless >>> these are to fix significant bugs or regressions. >>> >>> I'm very happy to hear alternatives, though I would also need people to >>> help if they involve more work. In any case, Robert has very kindly >>> volunteered to look at some of the current regressions but more help is >>> always very welcome. >>> >>> The current regressions or very major bugs have a 0.8 target in Mantis. >>> As with every release so far, only major regressions are guaranteed to >>> receive some sort of attention, where the answer may still be WONTFIX for >>> this release. >>> >>> Regards, >>> >>> -- >>> Justin Clark-Casey (justincc) >>> OSVW Consulting >>> http://justincc.org >>> http://twitter.com/justincc >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >> >> >> -- >> No essence. No permanence. No perfection. Only action. >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > -- > Michael Emory Cerquoni > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- No essence. No permanence. No perfection. Only action. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nebadon2025 at gmail.com Wed Apr 2 14:44:24 2014 From: nebadon2025 at gmail.com (Michael Emory Cerquoni) Date: Wed, 2 Apr 2014 10:44:24 -0400 Subject: [Opensim-dev] Preparing for OpenSimulator 0.8 In-Reply-To: References: <533B6AE1.5020108@googlemail.com> Message-ID: Well if you are wondering why no one takes you seriously its because of stuff like the last line of your email, good luck with that! On Wed, Apr 2, 2014 at 10:39 AM, Jim Williams wrote: > The basic problem is that their development will effect me as a user. > > I have no complaints about what Justin is trying to do. My complaint is > how he has to word what he is doing, and I think it is because there is > something wrong with the organization of this development project. Having > looked at that organization, I'd say that the basic problem is that it is > oriented about what potential developers might want to do rather than about > what users might want. It's an organization I would want nothing to do > with even if I wanted to work upon OpenSim rather than within it. > > Not only do I not want to do development, I want to use the system which > was developed. The only reason I joined this list is because I think that > the development currently happening is a threat to my continued enjoyment > of the product. The difference between me and most end users is that I'm a > retired programmer -- I know how these things go. > > So, you may drop dead for all I care. You are not helping to protect my > environment. > > > > On Wed, Apr 2, 2014 at 10:22 AM, Michael Emory Cerquoni < > nebadon2025 at gmail.com> wrote: > >> Jim, >> >> You are way off topic here, this has nothing to do with OSG or Metro >> grids, I don't know why you suddenly feel the need to criticize everyone >> and everything announced here, but it has finally gotten to the point where >> I feel I need to step in and say something about this, your comments of >> late seem unproductive and volatile as if you are just trying to start >> arguments, please keep the drama out of these communications, Justin is >> simply trying to keep things moving forward in a productive manner and all >> I see from you lately is negativity and nothing that lends to any kind of >> improvement, this is a developer channel, if you want to lend to >> development than do something productive other than criticize, start >> submitting patches or get directly involved in debugging and filing bug >> reports or something, but please take the drama else where it is no >> appreciated. >> >> >> On Wed, Apr 2, 2014 at 10:07 AM, Jim Williams wrote: >> >>> Hi Justin, >>> >>> The fact that your message is a plea rather than an announcement makes >>> it rather clear why I felt I had to leave OSG and move my sim to Metro. It >>> also explains to me why I felt I had to add myself to this list at the same >>> time -- self protection. >>> >>> If your release cycle is 4 months shouldn't there be a hard and fast >>> feature freeze at the end of the first month? And there should be no >>> back-talk or exceptions. Bug fixes ought to be just about 3/4 of the >>> effort anyway. What OpenSim needs is credibility as a stable working >>> system, not more features. >>> >>> If it''s a choice between what is going on now and having no development >>> on OpenSim, I think I'd rather see no development. I have no way of >>> stopping the badness from happening at my end other than complaining about >>> it. >>> >>> >>> >>> On Tue, Apr 1, 2014 at 9:41 PM, Justin Clark-Casey < >>> jjustincc at googlemail.com> wrote: >>> >>>> Hi folks. For the past 3 years, we've had a significant OpenSimulator >>>> release at about 4 to 8 month intervals. >>>> >>>> As the last major release (0.7.6) was in September 2013, we are due for >>>> another, and this seems like a reasonable point. From my perspective, >>>> releases drive a very significant level of OpenSimulator adoption. It's >>>> also the case that I may have a limited window of time to act as release >>>> manager, after which things may get very busy for me for an extended period. >>>> >>>> There was some disagreement over how the last release was handled, >>>> particularly over the period when I asked that developers take care to >>>> leave master stable. However, it's quite hard for me to see how this could >>>> be done in another way without significantly more manpower. Even when the >>>> release is branched, if the release branch and master diverge significantly >>>> (or master is broken) then a lot of the testing done by users is lost - >>>> very few people actually pick up and test release candidates. >>>> >>>> So unless there is disagreement, I'm going to ask that people take care >>>> to keep master stable until the end of April or release, whichever occurs >>>> first. This certainly does not mean a halt to development on master, it's >>>> just a request that people take a common sense approach to holding off from >>>> putting in destabilising or very complicated changes for a while, unless >>>> these are to fix significant bugs or regressions. >>>> >>>> I'm very happy to hear alternatives, though I would also need people to >>>> help if they involve more work. In any case, Robert has very kindly >>>> volunteered to look at some of the current regressions but more help is >>>> always very welcome. >>>> >>>> The current regressions or very major bugs have a 0.8 target in Mantis. >>>> As with every release so far, only major regressions are guaranteed to >>>> receive some sort of attention, where the answer may still be WONTFIX for >>>> this release. >>>> >>>> Regards, >>>> >>>> -- >>>> Justin Clark-Casey (justincc) >>>> OSVW Consulting >>>> http://justincc.org >>>> http://twitter.com/justincc >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> Opensim-dev at lists.berlios.de >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> >>> >>> >>> >>> -- >>> No essence. No permanence. No perfection. Only action. >>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >> >> >> -- >> Michael Emory Cerquoni >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > -- > No essence. No permanence. No perfection. Only action. > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- Michael Emory Cerquoni -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmickeyb at gmail.com Wed Apr 2 15:37:39 2014 From: cmickeyb at gmail.com (Mic Bowman) Date: Wed, 2 Apr 2014 08:37:39 -0700 Subject: [Opensim-dev] Optimize pushing assets to other grids In-Reply-To: <1396422698476-7579142.post@n2.nabble.com> References: <1396190871524-7579093.post@n2.nabble.com> <5338312A.4070302@metaverseink.com> <1396266948910-7579100.post@n2.nabble.com> <5339995A.4010208@t-data.com> <1396284763662-7579112.post@n2.nabble.com> <5339B3D2.4060902@metaverseink.com> <1396422698476-7579142.post@n2.nabble.com> Message-ID: How is this hooked up in the simulator? I'll need to update the simian connectors. On Wed, Apr 2, 2014 at 12:11 AM, Oren Hurvitz wrote: > I've added AssetsExist to master. It's implemented using REST, at > "/get_assets_exist". > > Regarding getting server capabilities: later I realized that Hypergrid > already has the "helo" command, which serves this purpose. Currently it > returns only one type of property: whether the server is based on Robust or > Simian. But it would be trivial to allow it to return other properties and > preferences as well. > > > > -- > View this message in context: > http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579142.html > Sent from the opensim-dev mailing list archive at Nabble.com. > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From orenh at kitely.com Wed Apr 2 15:46:58 2014 From: orenh at kitely.com (Oren Hurvitz) Date: Wed, 2 Apr 2014 08:46:58 -0700 (PDT) Subject: [Opensim-dev] Optimize pushing assets to other grids In-Reply-To: References: <5338312A.4070302@metaverseink.com> <1396266948910-7579100.post@n2.nabble.com> <5339995A.4010208@t-data.com> <1396284763662-7579112.post@n2.nabble.com> <5339B3D2.4060902@metaverseink.com> <1396422698476-7579142.post@n2.nabble.com> Message-ID: I already implemented SimianAssetServiceConnector.AssetsExist(). But since I didn't change Simian itself, it works by simply calling GetMetadata() to check if each asset exists. You can either leave this as-is, or implement an explicit AssetsExist operation that checks all the assets at once, like I've done in Robust. On Wed, Apr 2, 2014 at 6:38 PM, Mic Bowman [via opensim-dev] < ml-node+s2196679n7579156h50 at n2.nabble.com> wrote: > How is this hooked up in the simulator? I'll need to update the simian > connectors. > > > On Wed, Apr 2, 2014 at 12:11 AM, Oren Hurvitz <[hidden email] > > wrote: > >> I've added AssetsExist to master. It's implemented using REST, at >> "/get_assets_exist". >> >> Regarding getting server capabilities: later I realized that Hypergrid >> already has the "helo" command, which serves this purpose. Currently it >> returns only one type of property: whether the server is based on Robust >> or >> Simian. But it would be trivial to allow it to return other properties and >> preferences as well. >> >> >> >> -- >> View this message in context: >> http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579142.html >> Sent from the opensim-dev mailing list archive at Nabble.com. >> _______________________________________________ >> Opensim-dev mailing list >> [hidden email] >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > _______________________________________________ > Opensim-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/opensim-dev > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579156.html > To unsubscribe from Optimize pushing assets to other grids, click here > . > NAML > -- Oren Hurvitz VP R&D Kitely Ltd. Email: orenh at kitely.com -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579157.html Sent from the opensim-dev mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ai.ai.austin at gmail.com Wed Apr 2 16:34:10 2014 From: ai.ai.austin at gmail.com (Ai Austin) Date: Wed, 02 Apr 2014 17:34:10 +0100 Subject: [Opensim-dev] Preparing for OpenSimulator 0.8 In-Reply-To: References: Message-ID: <533c3c03.a4f2c20a.287e.563b@mx.google.com> >From: Jim Williams >Not only do I not want to do development, I want to use the system >which was developed. ... So, you may drop dead for all I care. You >are not helping to protect my environment. Whoooaaa Jim... take it easy... that's way out of order in an open source contributed effort community.. and really not nice on a list for the developers who put their time and effort in to give us all software we can enjoy and use. I for one will be very pleased to see the stable release of 0.8.0 which testing is showing is very stable and up-to-date running on our own grid, on add-on regions on OSGrid and doing hypergrid jumps to a range of other grids. I am very glad that Justin one again is willing to take on the release preparation on behalf of all of us in the community.. developers, testers, documenters, wiki and blog writers, and users. From robertltux at gmail.com Wed Apr 2 17:17:00 2014 From: robertltux at gmail.com (Robert Martin) Date: Wed, 2 Apr 2014 13:17:00 -0400 Subject: [Opensim-dev] Preparing for OpenSimulator 0.8 In-Reply-To: <533c3c03.a4f2c20a.287e.563b@mx.google.com> References: <533c3c03.a4f2c20a.287e.563b@mx.google.com> Message-ID: from my POV i would think that a Freeze For Release would be a good idea since a constant MUST DO NEW FEATURE thing is what prevents having a good release. One thing that would be nice as a sidebar would be for there to be a single shell exe that starts the webserver then starts the sim and gives an all clear when the sim is ready (of course having a good working web control panel would be good). On Wed, Apr 2, 2014 at 12:34 PM, Ai Austin wrote: > >> From: Jim Williams >> Not only do I not want to do development, I want to use the system which >> was developed. ... So, you may drop dead for all I care. You are not >> helping to protect my environment. > > > Whoooaaa Jim... take it easy... that's way out of order in an open source > contributed effort community.. and really not nice on a list for the > developers who put their time and effort in to give us all software we can > enjoy and use. > > I for one will be very pleased to see the stable release of 0.8.0 which > testing is showing is very stable and up-to-date running on our own grid, on > add-on regions on OSGrid and doing hypergrid jumps to a range of other > grids. I am very glad that Justin one again is willing to take on the > release preparation on behalf of all of us in the community.. developers, > testers, documenters, wiki and blog writers, and users. > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev -- Robert L Martin From nebadon2025 at gmail.com Wed Apr 2 19:28:23 2014 From: nebadon2025 at gmail.com (Michael Emory Cerquoni) Date: Wed, 2 Apr 2014 15:28:23 -0400 Subject: [Opensim-dev] Optimize pushing assets to other grids In-Reply-To: References: <5338312A.4070302@metaverseink.com> <1396266948910-7579100.post@n2.nabble.com> <5339995A.4010208@t-data.com> <1396284763662-7579112.post@n2.nabble.com> <5339B3D2.4060902@metaverseink.com> <1396422698476-7579142.post@n2.nabble.com> Message-ID: excuse my ignorance here but are these changes directly to the asset server itself or are these simulator level changes? On Wed, Apr 2, 2014 at 11:46 AM, Oren Hurvitz wrote: > I already implemented SimianAssetServiceConnector.AssetsExist(). But since > I didn't change Simian itself, it works by simply calling GetMetadata() to > check if each asset exists. You can either leave this as-is, or implement > an explicit AssetsExist operation that checks all the assets at once, like > I've done in Robust. > > > On Wed, Apr 2, 2014 at 6:38 PM, Mic Bowman [via opensim-dev] <[hidden > email] > wrote: > >> How is this hooked up in the simulator? I'll need to update the simian >> connectors. >> >> >> On Wed, Apr 2, 2014 at 12:11 AM, Oren Hurvitz <[hidden email] >> > wrote: >> >>> I've added AssetsExist to master. It's implemented using REST, at >>> "/get_assets_exist". >>> >>> Regarding getting server capabilities: later I realized that Hypergrid >>> already has the "helo" command, which serves this purpose. Currently it >>> returns only one type of property: whether the server is based on Robust >>> or >>> Simian. But it would be trivial to allow it to return other properties >>> and >>> preferences as well. >>> >>> >>> >>> -- >>> View this message in context: >>> http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579142.html >>> Sent from the opensim-dev mailing list archive at Nabble.com. >>> _______________________________________________ >>> Opensim-dev mailing list >>> [hidden email] >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >> >> _______________________________________________ >> Opensim-dev mailing list >> [hidden email] >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> ------------------------------ >> If you reply to this email, your message will be added to the >> discussion below: >> >> http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579156.html >> To unsubscribe from Optimize pushing assets to other grids, click here. >> NAML >> > > > > -- > Oren Hurvitz > VP R&D > Kitely Ltd. > > Email: [hidden email][hidden > email] > > ------------------------------ > View this message in context: Re: Optimize pushing assets to other grids > Sent from the opensim-dev mailing list archiveat Nabble.com. > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- Michael Emory Cerquoni -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmickeyb at gmail.com Wed Apr 2 20:16:18 2014 From: cmickeyb at gmail.com (Mic Bowman) Date: Wed, 2 Apr 2014 13:16:18 -0700 Subject: [Opensim-dev] Optimize pushing assets to other grids In-Reply-To: References: <5338312A.4070302@metaverseink.com> <1396266948910-7579100.post@n2.nabble.com> <5339995A.4010208@t-data.com> <1396284763662-7579112.post@n2.nabble.com> <5339B3D2.4060902@metaverseink.com> <1396422698476-7579142.post@n2.nabble.com> Message-ID: Thanks. I'll take a look at what you've got. It's pretty easy to add the call to the Simian services. PHP you know. I don't have to screw around with http path prefix matching or anything... :-) --mic On Wed, Apr 2, 2014 at 8:46 AM, Oren Hurvitz wrote: > I already implemented SimianAssetServiceConnector.AssetsExist(). But since > I didn't change Simian itself, it works by simply calling GetMetadata() to > check if each asset exists. You can either leave this as-is, or implement > an explicit AssetsExist operation that checks all the assets at once, like > I've done in Robust. > > > On Wed, Apr 2, 2014 at 6:38 PM, Mic Bowman [via opensim-dev] <[hidden > email] > wrote: > >> How is this hooked up in the simulator? I'll need to update the simian >> connectors. >> >> >> On Wed, Apr 2, 2014 at 12:11 AM, Oren Hurvitz <[hidden email] >> > wrote: >> >>> I've added AssetsExist to master. It's implemented using REST, at >>> "/get_assets_exist". >>> >>> Regarding getting server capabilities: later I realized that Hypergrid >>> already has the "helo" command, which serves this purpose. Currently it >>> returns only one type of property: whether the server is based on Robust >>> or >>> Simian. But it would be trivial to allow it to return other properties >>> and >>> preferences as well. >>> >>> >>> >>> -- >>> View this message in context: >>> http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579142.html >>> Sent from the opensim-dev mailing list archive at Nabble.com. >>> _______________________________________________ >>> Opensim-dev mailing list >>> [hidden email] >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >> >> _______________________________________________ >> Opensim-dev mailing list >> [hidden email] >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> ------------------------------ >> If you reply to this email, your message will be added to the >> discussion below: >> >> http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579156.html >> To unsubscribe from Optimize pushing assets to other grids, click here. >> NAML >> > > > > -- > Oren Hurvitz > VP R&D > Kitely Ltd. > > Email: [hidden email][hidden > email] > > ------------------------------ > View this message in context: Re: Optimize pushing assets to other grids > Sent from the opensim-dev mailing list archiveat Nabble.com. > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From orenh at kitely.com Wed Apr 2 20:43:43 2014 From: orenh at kitely.com (Oren Hurvitz) Date: Wed, 2 Apr 2014 13:43:43 -0700 (PDT) Subject: [Opensim-dev] Optimize pushing assets to other grids In-Reply-To: References: <5339995A.4010208@t-data.com> <1396284763662-7579112.post@n2.nabble.com> <5339B3D2.4060902@metaverseink.com> <1396422698476-7579142.post@n2.nabble.com> Message-ID: The actual work is done in the assets server, and there's code in the simulators to call this API. On Wed, Apr 2, 2014 at 10:28 PM, Nebadon Izumi [via opensim-dev] < ml-node+s2196679n7579160h74 at n2.nabble.com> wrote: > excuse my ignorance here but are these changes directly to the asset > server itself or are these simulator level changes? > -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579162.html Sent from the opensim-dev mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From diva at metaverseink.com Wed Apr 2 20:50:57 2014 From: diva at metaverseink.com (Diva Canto) Date: Wed, 02 Apr 2014 13:50:57 -0700 Subject: [Opensim-dev] Optimize pushing assets to other grids In-Reply-To: References: <5339995A.4010208@t-data.com> <1396284763662-7579112.post@n2.nabble.com> <5339B3D2.4060902@metaverseink.com> <1396422698476-7579142.post@n2.nabble.com> Message-ID: <533C7831.9010403@metaverseink.com> I'm guessing OSGrid's asset server won't be able to reply to this new service, unless you change it. I'm also guessing that's ok -- it will behave as it behaves currently, the assets are copied over again. On 4/2/2014 1:43 PM, Oren Hurvitz wrote: > The actual work is done in the assets server, and there's code in the > simulators to call this API. > > > On Wed, Apr 2, 2014 at 10:28 PM, Nebadon Izumi [via opensim-dev] > <[hidden email] > wrote: > > excuse my ignorance here but are these changes directly to the > asset server itself or are these simulator level changes? > > > ------------------------------------------------------------------------ > View this message in context: Re: Optimize pushing assets to other > grids > > Sent from the opensim-dev mailing list archive > at Nabble.com. > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From nickyperian at gmail.com Wed Apr 2 21:42:39 2014 From: nickyperian at gmail.com (Nicky Perian) Date: Wed, 2 Apr 2014 16:42:39 -0500 Subject: [Opensim-dev] Viewer doesn't render attachments after teleport In-Reply-To: References: <1396429231035-7579143.post@n2.nabble.com> <1396429536428-7579144.post@n2.nabble.com> <1396437405521-7579146.post@n2.nabble.com> <533BF27D.5000707@t-data.com> Message-ID: Kokua's feature Refresh scene does the following and can be manually done on any viewer. Graphics->Advanced->Basic shaders tick to off. At this point the frame rate will climb to as high a value that the network will allow. In Kokua an info log message is written just to eat a little time at the high frame rate. Then, Basis shaders are ticked back on. This dresses the scene. Based on that I don't know if the prim/attachment is fully present in the viewer or not. Does the high frame rate over ride some net latency and pull all the prim's elementary data in or was it there all along and the redressing just put everything in order? LL has viewer interesting (interest list) in work and didn't want me to do any work on the missing prim issue until that viewer is in release. The Refresh scene was put in instead of a hackish approach of dropping Basic shaders before TP and turning them back on at completion. There appears to be some thread issues in TP's as my experimentation showed that setting a variable before TP did not necessarily insure that the arrival part of TP would have that same value. As noted in this thread about ordering, I think there is merit in exploring that aspect. On Wed, Apr 2, 2014 at 6:50 AM, Dahlia Trimble wrote: > I've seen attachment rezzing failures in SL for years. Right-clicking > usually fixes it. If there is an issue then I suspect it's a long-standing > viewer bug that may be exacerbated by some combination of legal protocol. > If it is somehow related to packet ordering, then we might be able to send > it in a particular order but given the non-stream nature of UDP we cannot > guarantee it will be received in any order. > > > On Wed, Apr 2, 2014 at 4:44 AM, Dahlia Trimble wrote: > >> Attachment positions are relative to bones. They really cannot be "too >> far away" >> >> >> On Wed, Apr 2, 2014 at 4:20 AM, Melanie wrote: >> >>> I don't know if this may be related, but for some reason OpenSim >>> fails to update the viewer's notion of position properly. >>> >>> The most noticeable effect is that sometimes after changing regions >>> or even parcels, sound is no longer heard. The audibility check >>> happens viewerside, just as the object visibility check. >>> >>> If the viewer gets a wrong location, it may consider the attachments >>> as "too far away" and not render them - that is probably related to >>> why zooming can make them appear. >>> >>> Therefore I don't believe we need to send any extra packets related >>> to these objects, but rather we are missing some packet or sending >>> wrong data related to the avatar's location. >>> >>> This appears to be the case on moving in world as well as teleports, >>> but I have so far never observed it at login. >>> >>> Melanie >>> >>> >>> On 02/04/2014 13:16, Oren Hurvitz wrote: >>> > I got some great advice off-list from Nicky Perian. When there's a >>> problem of >>> > missing prims, go to the Graphics Preferences and toggle the option >>> "Basic >>> > shaders". I tried this, and toggling this option (on or off, both work) >>> > makes the missing prims appear immediately. >>> > >>> > This proves that the viewer has the correct data, and it's just not >>> showing >>> > it. But I still want to find some combination of packets that will >>> make the >>> > viewers show the prims, since obviously most users will not know to >>> use this >>> > trick, and it's a hassle. >>> > >>> > >>> > >>> > -- >>> > View this message in context: >>> http://opensim-dev.2196679.n2.nabble.com/Viewer-doesn-t-render-attachments-after-teleport-tp7579143p7579146.html >>> > Sent from the opensim-dev mailing list archive at Nabble.com. >>> > _______________________________________________ >>> > Opensim-dev mailing list >>> > Opensim-dev at lists.berlios.de >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev >>> > >>> > >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >> > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fly.man.opensim at gmail.com Wed Apr 2 22:00:27 2014 From: fly.man.opensim at gmail.com (Fly Man) Date: Thu, 3 Apr 2014 00:00:27 +0200 Subject: [Opensim-dev] Preparing for OpenSimulator 0.8 In-Reply-To: References: <533c3c03.a4f2c20a.287e.563b@mx.google.com> Message-ID: I think sometimes it matters that there's a stable release schedule, Sept 2013 is far in the past and there has been a lot of changes in Opensim since then. Strangely enough there haven't been "in between" releases or something like that. At this moment I think a lot of grid owners are sweating as a new release might blow their support channels as the users will want to new features asap. My advice: Do a "in between" release so people can see the changes and use the 0.8 release as the large release for a lot of features that people have been wanting. Use the "in between" to see if there's any large issues arising. 2014-04-02 19:17 GMT+02:00 Robert Martin : > from my POV i would think that a Freeze For Release would be a good > idea since a constant MUST DO NEW FEATURE thing is what prevents > having a good release. > > One thing that would be nice as a sidebar would be for there to be a > single shell exe that starts the webserver then starts the sim and > gives an all clear when the sim is ready (of course having a good > working web control panel would be good). > > On Wed, Apr 2, 2014 at 12:34 PM, Ai Austin wrote: > > > >> From: Jim Williams > >> Not only do I not want to do development, I want to use the system which > >> was developed. ... So, you may drop dead for all I care. You are not > >> helping to protect my environment. > > > > > > Whoooaaa Jim... take it easy... that's way out of order in an open source > > contributed effort community.. and really not nice on a list for the > > developers who put their time and effort in to give us all software we > can > > enjoy and use. > > > > I for one will be very pleased to see the stable release of 0.8.0 which > > testing is showing is very stable and up-to-date running on our own > grid, on > > add-on regions on OSGrid and doing hypergrid jumps to a range of other > > grids. I am very glad that Justin one again is willing to take on the > > release preparation on behalf of all of us in the community.. developers, > > testers, documenters, wiki and blog writers, and users. > > > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > -- > Robert L Martin > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nebadon2025 at gmail.com Wed Apr 2 22:13:59 2014 From: nebadon2025 at gmail.com (Michael Emory Cerquoni) Date: Wed, 2 Apr 2014 18:13:59 -0400 Subject: [Opensim-dev] Preparing for OpenSimulator 0.8 In-Reply-To: References: <533c3c03.a4f2c20a.287e.563b@mx.google.com> Message-ID: OSgrid does releases very often and we do not modify the code in anyway all we do is add the osprofile and ossearch dlls to our release, anyone wanting to test newer releases could always use an OSgrid release and report bugs this way, we even provide zips of the source that come directly from http://opensimulator.org/viewgit, just need to replace our ini's with your own ini files and you are running the same code that we would push out into an official release basically. http://www.osgrid.org/index.php/downloads On Wed, Apr 2, 2014 at 6:00 PM, Fly Man wrote: > I think sometimes it matters that there's a stable release schedule, Sept > 2013 is far in the past and there has been a lot of changes in Opensim > since then. > > Strangely enough there haven't been "in between" releases or something > like that. At this moment I think a lot of grid owners are sweating as a > new release might blow their support channels as the users will want to new > features asap. > > My advice: Do a "in between" release so people can see the changes and use > the 0.8 release as the large release for a lot of features that people have > been wanting. Use the "in between" to see if there's any large issues > arising. > > > 2014-04-02 19:17 GMT+02:00 Robert Martin : > > from my POV i would think that a Freeze For Release would be a good >> idea since a constant MUST DO NEW FEATURE thing is what prevents >> having a good release. >> >> One thing that would be nice as a sidebar would be for there to be a >> single shell exe that starts the webserver then starts the sim and >> gives an all clear when the sim is ready (of course having a good >> working web control panel would be good). >> >> On Wed, Apr 2, 2014 at 12:34 PM, Ai Austin >> wrote: >> > >> >> From: Jim Williams >> >> Not only do I not want to do development, I want to use the system >> which >> >> was developed. ... So, you may drop dead for all I care. You are not >> >> helping to protect my environment. >> > >> > >> > Whoooaaa Jim... take it easy... that's way out of order in an open >> source >> > contributed effort community.. and really not nice on a list for the >> > developers who put their time and effort in to give us all software we >> can >> > enjoy and use. >> > >> > I for one will be very pleased to see the stable release of 0.8.0 which >> > testing is showing is very stable and up-to-date running on our own >> grid, on >> > add-on regions on OSGrid and doing hypergrid jumps to a range of other >> > grids. I am very glad that Justin one again is willing to take on the >> > release preparation on behalf of all of us in the community.. >> developers, >> > testers, documenters, wiki and blog writers, and users. >> > >> > >> > _______________________________________________ >> > Opensim-dev mailing list >> > Opensim-dev at lists.berlios.de >> > https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> >> >> -- >> Robert L Martin >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- Michael Emory Cerquoni -------------- next part -------------- An HTML attachment was scrubbed... URL: From jjustincc at googlemail.com Thu Apr 3 00:56:07 2014 From: jjustincc at googlemail.com (Justin Clark-Casey) Date: Thu, 03 Apr 2014 01:56:07 +0100 Subject: [Opensim-dev] Preparing for OpenSimulator 0.8 In-Reply-To: References: <533B6AE1.5020108@googlemail.com> Message-ID: <533CB1A7.3000502@googlemail.com> Yes, that would be one alternative. But to emphasise, I'm only asking for a common-sense approach to avoid destabilising master right now, not a blanket ban on commits or anything like that. On 02/04/14 02:45, Michael Emory Cerquoni wrote: > +1 no disagreement here! anyone who wants to get crazy can do so in a new branch for now? > > On Apr 1, 2014 9:42 PM, "Justin Clark-Casey" > wrote: > > Hi folks. For the past 3 years, we've had a significant OpenSimulator release at about 4 to 8 month intervals. > > As the last major release (0.7.6) was in September 2013, we are due for another, and this seems like a reasonable > point. From my perspective, releases drive a very significant level of OpenSimulator adoption. It's also the case > that I may have a limited window of time to act as release manager, after which things may get very busy for me for > an extended period. > > There was some disagreement over how the last release was handled, particularly over the period when I asked that > developers take care to leave master stable. However, it's quite hard for me to see how this could be done in > another way without significantly more manpower. Even when the release is branched, if the release branch and > master diverge significantly (or master is broken) then a lot of the testing done by users is lost - very few people > actually pick up and test release candidates. > > So unless there is disagreement, I'm going to ask that people take care to keep master stable until the end of April > or release, whichever occurs first. This certainly does not mean a halt to development on master, it's just a > request that people take a common sense approach to holding off from putting in destabilising or very complicated > changes for a while, unless these are to fix significant bugs or regressions. > > I'm very happy to hear alternatives, though I would also need people to help if they involve more work. In any > case, Robert has very kindly volunteered to look at some of the current regressions but more help is always very > welcome. > > The current regressions or very major bugs have a 0.8 target in Mantis. As with every release so far, only major > regressions are guaranteed to receive some sort of attention, where the answer may still be WONTFIX for this release. > > Regards, > > -- > Justin Clark-Casey (justincc) > OSVW Consulting > http://justincc.org > http://twitter.com/justincc > _________________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/__mailman/listinfo/opensim-dev > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- Justin Clark-Casey (justincc) OSVW Consulting http://justincc.org http://twitter.com/justincc From jjustincc at googlemail.com Thu Apr 3 01:01:33 2014 From: jjustincc at googlemail.com (Justin Clark-Casey) Date: Thu, 03 Apr 2014 02:01:33 +0100 Subject: [Opensim-dev] REST handlers use partial string matching In-Reply-To: <1396381789745-7579127.post@n2.nabble.com> References: <1396357230099-7579119.post@n2.nabble.com> <533AFE9D.1020406@googlemail.com> <1396381789745-7579127.post@n2.nabble.com> Message-ID: <533CB2ED.1050601@googlemail.com> Yeah, it's an interesting problem. A quick google doesn't reveal any obvious solutions, though one StackOverflow thread [1] has an interesting approach of wrapping multiple requests in a 'batch' request. So I don't object to this, but I don't think that we should kid ourselves that we're writing pure REST interfaces. get_asset_exists is effectively an RPC call which POSTs a bunch of UUIDs and gets data back - it is not an HTTP verb operating on a resource. Also, it would be great if you could add this new call to [2]. I'm very slowly trying to document all the various interfaces, protocols and calls, so that it's possible for other projects to implement them, to get a better overview of interfaces in OpenSimulator, etc. [1] http://stackoverflow.com/questions/14636332/convention-for-combining-rest-requests-and-replies [2] http://opensimulator.org/wiki/AssetService On 01/04/14 20:49, Oren Hurvitz wrote: > Re: why use POST instead of HEAD: because this lets me check the existence of > many assets at once with a single HTTP request. The main use of the > AssetsExist call is with HGAssetGatherer, which knows the full list of > assets that it wants to send, so it's able to check all of them at once. > > > > -- > View this message in context: http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119p7579127.html > Sent from the opensim-dev mailing list archive at Nabble.com. > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > . > -- Justin Clark-Casey (justincc) OSVW Consulting http://justincc.org http://twitter.com/justincc From jjustincc at googlemail.com Thu Apr 3 01:08:36 2014 From: jjustincc at googlemail.com (Justin Clark-Casey) Date: Thu, 03 Apr 2014 02:08:36 +0100 Subject: [Opensim-dev] Viewer doesn't render attachments after teleport In-Reply-To: <533BF27D.5000707@t-data.com> References: <1396429231035-7579143.post@n2.nabble.com> <1396429536428-7579144.post@n2.nabble.com> <1396437405521-7579146.post@n2.nabble.com> <533BF27D.5000707@t-data.com> Message-ID: <533CB494.6020207@googlemail.com> I also used to see this issue a lot when testing attachments. At the time, I remember looking into it and adjusting a few things to make OpenSimulator's output packet order match LL much more closely but with no effect. I haven't seen it for a while so I was hoping it had gone away, though that may also just be because I don't get the chance to go in-world very often. One possible thing to investigate is whether SOG updates with a position of <0,0,0> are somehow getting out to the region before attachments are properly set up. This might account for audio issues, etc. It might also be a shot in the dark, though I think this used to happen under some circumstances (along with other effects such as HUD attachments wrongly appearing on other viewer's screens). On 02/04/14 12:20, Melanie wrote: > I don't know if this may be related, but for some reason OpenSim > fails to update the viewer's notion of position properly. > > The most noticeable effect is that sometimes after changing regions > or even parcels, sound is no longer heard. The audibility check > happens viewerside, just as the object visibility check. > > If the viewer gets a wrong location, it may consider the attachments > as "too far away" and not render them - that is probably related to > why zooming can make them appear. > > Therefore I don't believe we need to send any extra packets related > to these objects, but rather we are missing some packet or sending > wrong data related to the avatar's location. > > This appears to be the case on moving in world as well as teleports, > but I have so far never observed it at login. > > Melanie > > > On 02/04/2014 13:16, Oren Hurvitz wrote: >> I got some great advice off-list from Nicky Perian. When there's a problem of >> missing prims, go to the Graphics Preferences and toggle the option "Basic >> shaders". I tried this, and toggling this option (on or off, both work) >> makes the missing prims appear immediately. >> >> This proves that the viewer has the correct data, and it's just not showing >> it. But I still want to find some combination of packets that will make the >> viewers show the prims, since obviously most users will not know to use this >> trick, and it's a hassle. >> >> >> >> -- >> View this message in context: http://opensim-dev.2196679.n2.nabble.com/Viewer-doesn-t-render-attachments-after-teleport-tp7579143p7579146.html >> Sent from the opensim-dev mailing list archive at Nabble.com. >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > . > -- Justin Clark-Casey (justincc) OSVW Consulting http://justincc.org http://twitter.com/justincc From rigun at rigutech.nl Sun Apr 6 09:49:35 2014 From: rigun at rigutech.nl (R.Gunther) Date: Sun, 06 Apr 2014 11:49:35 +0200 Subject: [Opensim-dev] HG friedns 0.8dev not compatible with 0.7.6.n ? Message-ID: <5341232F.8050909@rigutech.nl> Running my own grid works fine. But for some reason if i make friends with users on diva or old 0.7 opens/grid. Friends seems to fail. i have friend myself in osgriud and thats the only one thats working right ? Do i have a setting wrongh, or are the 0.7.6 grids setup wrong. I use the build in core freinds / groups for that. Or is there a bug ? Richard From aine.caoimhe at rogers.com Mon Apr 7 10:29:22 2014 From: aine.caoimhe at rogers.com (Aine) Date: Mon, 7 Apr 2014 06:29:22 -0400 Subject: [Opensim-dev] HG friedns 0.8dev not compatible with 0.7.6.n ? In-Reply-To: <5341232F.8050909@rigutech.nl> References: <5341232F.8050909@rigutech.nl> Message-ID: <001201cf524c$3e7d60b0$bb782210$@caoimhe@rogers.com> This is a bug that first appeared approximately a year ago and is somewhat more widespread issue. See: http://opensimulator.org/mantis/view.php?id=6603 http://opensimulator.org/mantis/view.php?id=6769 -----Original Message----- From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of R.Gunther Sent: Sunday, April 06, 2014 5:50 AM To: opensim-dev at lists.berlios.de Subject: [Opensim-dev] HG friedns 0.8dev not compatible with 0.7.6.n ? Running my own grid works fine. But for some reason if i make friends with users on diva or old 0.7 opens/grid. Friends seems to fail. i have friend myself in osgriud and thats the only one thats working right ? Do i have a setting wrongh, or are the 0.7.6 grids setup wrong. I use the build in core freinds / groups for that. Or is there a bug ? Richard _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4355 / Virus Database: 3722/7309 - Release Date: 04/06/14 From j.frank.nichols at gmail.com Mon Apr 7 19:02:05 2014 From: j.frank.nichols at gmail.com (Frank Nichols) Date: Mon, 7 Apr 2014 15:02:05 -0400 Subject: [Opensim-dev] OpenSimDefaults.ini clean up Message-ID: <9A70FC02-12BB-4E89-B64C-9EF8DEBA25D4@gmail.com> I would appreciate any comments on changing the OpenSimDefaults.ini file so that it will be the same form factor as the OpenSim.ini.example file. Currently the defaults file is an older format and as such it is difficult to compare the two when looking for changes or settings. I suggest (and am willing to do the work to make a patch) that the defaults file be updated to the same form factor as the OpenSim.ini.example file. In the case of any settings in the defaults that are not in the OpenSim.ini.example, those would be consolidated at the end of each associated section - i.e.. any thing in defaults [Startup] that is not in the .example [Startup] would be moved to the end of the defaults [Startup] section and updated to the same form factor as the rest of the settings. When completed the two files run when through diff would result in ONLY those lines that are different - those being lines in defaults not in example and the line for the default setting - i.e.: An example to demonstrate: OpenSim.ini.example [Startup] ;# {ConsolePrompt} {} {ConsolePrompt} {} "Region (\R) " ;; Console prompt ;; Certain special characters can be used to customize the prompt ;; Currently, these are ;; \R - substitute region name ;; \\ - substitute \ ; ConsolePrompt = "Region (\R) " OpenSimDefaults.ini currently: [Startup] ; Console prompt ; Certain special characters can be used to customize the prompt ; Currently, these are ; \R - substitute region name ; \\ - substtitue \ ConsolePrompt = "Region (\R) " OpenSimDefaults.ini proposed: [Startup] ;# {ConsolePrompt} {} {ConsolePrompt} {} "Region (\R) " ;; Console prompt ;; Certain special characters can be used to customize the prompt ;; Currently, these are ;; \R - substitute region name ;; \\ - substitute \ ConsolePrompt = "Region (\R) " The proposed change would make comparing the two files for changes and differences easier. It would be a clean diff obviously, since the defaults is 1800 lines and the example is only 1000. But, it might help. Frank Nichols From jak at ateb.co.uk Tue Apr 8 11:49:04 2014 From: jak at ateb.co.uk (Jak Daniels) Date: Tue, 08 Apr 2014 12:49:04 +0100 Subject: [Opensim-dev] OpenSimDefaults.ini clean up In-Reply-To: <9A70FC02-12BB-4E89-B64C-9EF8DEBA25D4@gmail.com> References: <9A70FC02-12BB-4E89-B64C-9EF8DEBA25D4@gmail.com> Message-ID: <5343E230.2090003@ateb.co.uk> +1 for this, however moving things in defaults that are not in example to the end of a section, particularly in the larger sections might move a setting more out of context and make the defaults file less readable. Jak On 07/04/2014 20:02, Frank Nichols wrote: > I would appreciate any comments on changing the OpenSimDefaults.ini file so that it will be the same form factor as the OpenSim.ini.example file. Currently the defaults file is an older format and as such it is difficult to compare the two when looking for changes or settings. > > I suggest (and am willing to do the work to make a patch) that the defaults file be updated to the same form factor as the OpenSim.ini.example file. In the case of any settings in the defaults that are not in the OpenSim.ini.example, those would be consolidated at the end of each associated section - i.e.. any thing in defaults [Startup] that is not in the .example [Startup] would be moved to the end of the defaults [Startup] section and updated to the same form factor as the rest of the settings. > > When completed the two files run when through diff would result in ONLY those lines that are different - those being lines in defaults not in example and the line for the default setting - i.e.: > > An example to demonstrate: > > OpenSim.ini.example > > [Startup] > ;# {ConsolePrompt} {} {ConsolePrompt} {} "Region (\R) " > ;; Console prompt > ;; Certain special characters can be used to customize the prompt > ;; Currently, these are > ;; \R - substitute region name > ;; \\ - substitute \ > ; ConsolePrompt = "Region (\R) " > > OpenSimDefaults.ini currently: > > [Startup] > ; Console prompt > ; Certain special characters can be used to customize the prompt > ; Currently, these are > ; \R - substitute region name > ; \\ - substtitue \ > ConsolePrompt = "Region (\R) " > > > OpenSimDefaults.ini proposed: > > [Startup] > ;# {ConsolePrompt} {} {ConsolePrompt} {} "Region (\R) " > ;; Console prompt > ;; Certain special characters can be used to customize the prompt > ;; Currently, these are > ;; \R - substitute region name > ;; \\ - substitute \ > ConsolePrompt = "Region (\R) " > > The proposed change would make comparing the two files for changes and differences easier. It would be a clean diff obviously, since the defaults is 1800 lines and the example is only 1000. But, it might help. > > Frank Nichols > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From ste at smxy.org Tue Apr 8 14:19:10 2014 From: ste at smxy.org (Shaun T. Erickson) Date: Tue, 08 Apr 2014 10:19:10 -0400 Subject: [Opensim-dev] OpenSimDefaults.ini clean up In-Reply-To: <5343E230.2090003@ateb.co.uk> References: <9A70FC02-12BB-4E89-B64C-9EF8DEBA25D4@gmail.com> <5343E230.2090003@ateb.co.uk> Message-ID: <5344055E.5000207@smxy.org> Yeah, I would definitely vote against moving things to the end of sections. It's perfectly fine to have, say: A B C D E in the defaults file, but only have, say: A C E in OpenSim.ini.example. -ste On 4/8/14, 7:49 AM, Jak Daniels wrote: > +1 for this, however moving things in defaults that are not in example > to the end of a section, particularly in the larger sections might > move a setting more out of context and make the defaults file less > readable. -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.stallings at gmail.com Tue Apr 8 14:32:40 2014 From: james.stallings at gmail.com (James Stallings II) Date: Tue, 8 Apr 2014 09:32:40 -0500 Subject: [Opensim-dev] OpenSimDefaults.ini clean up In-Reply-To: <5344055E.5000207@smxy.org> References: <9A70FC02-12BB-4E89-B64C-9EF8DEBA25D4@gmail.com> <5343E230.2090003@ateb.co.uk> <5344055E.5000207@smxy.org> Message-ID: I think if any of this is touched, it should be to the OpenSim.ini file, to remove the proprietary formatting for the gui configurator that is not present in opensim core. For my part, it isn't a problem; but as far as I'm concerned modifying the format of OpenSimDefaults.ini is probably going at it a bit backward. Cheers James On Tue, Apr 8, 2014 at 9:19 AM, Shaun T. Erickson wrote: > Yeah, I would definitely vote against moving things to the end of > sections. It's perfectly fine to have, say: > > A > B > C > D > E > > in the defaults file, but only have, say: > > A > C > E > > in OpenSim.ini.example. > > -ste > > > On 4/8/14, 7:49 AM, Jak Daniels wrote: > > +1 for this, however moving things in defaults that are not in example to > the end of a section, particularly in the larger sections might move a > setting more out of context and make the defaults file less readable. > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From marceled9 at gmail.com Tue Apr 8 15:20:56 2014 From: marceled9 at gmail.com (M.E. Verhagen) Date: Tue, 8 Apr 2014 17:20:56 +0200 Subject: [Opensim-dev] OpenSimDefaults.ini clean up In-Reply-To: References: <9A70FC02-12BB-4E89-B64C-9EF8DEBA25D4@gmail.com> <5343E230.2090003@ateb.co.uk> <5344055E.5000207@smxy.org> Message-ID: I would be careful with touching the defaults in the defaults file. It is always good to have a file where you can look up the defaults when you somehow messed up in opensim.ini. You probably will never need those settings which are in defaults but not in opensim.ini. -------------- next part -------------- An HTML attachment was scrubbed... URL: From melanie at t-data.com Tue Apr 8 15:23:25 2014 From: melanie at t-data.com (Melanie) Date: Tue, 08 Apr 2014 17:23:25 +0200 Subject: [Opensim-dev] OpenSimDefaults.ini clean up In-Reply-To: References: <9A70FC02-12BB-4E89-B64C-9EF8DEBA25D4@gmail.com> <5343E230.2090003@ateb.co.uk> <5344055E.5000207@smxy.org> Message-ID: <5344146D.6050203@t-data.com> The GUI configurator doesn't even exist yet. It's not proprietary, it's just not done yet. The work was put in to create this formatting to encourage the creation of such a GUI tool. It will certainly not be removed. - Melanie On 08/04/2014 16:32, James Stallings II wrote: > I think if any of this is touched, it should be to the OpenSim.ini file, to > remove the proprietary formatting for the gui configurator that is not > present in opensim core. > > For my part, it isn't a problem; but as far as I'm concerned modifying the > format of OpenSimDefaults.ini is probably going at it a bit backward. > > Cheers > James > > > > On Tue, Apr 8, 2014 at 9:19 AM, Shaun T. Erickson wrote: > >> Yeah, I would definitely vote against moving things to the end of >> sections. It's perfectly fine to have, say: >> >> A >> B >> C >> D >> E >> >> in the defaults file, but only have, say: >> >> A >> C >> E >> >> in OpenSim.ini.example. >> >> -ste >> >> >> On 4/8/14, 7:49 AM, Jak Daniels wrote: >> >> +1 for this, however moving things in defaults that are not in example to >> the end of a section, particularly in the larger sections might move a >> setting more out of context and make the defaults file less readable. >> >> >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev From melanie at t-data.com Tue Apr 8 15:25:41 2014 From: melanie at t-data.com (Melanie) Date: Tue, 08 Apr 2014 17:25:41 +0200 Subject: [Opensim-dev] OpenSimDefaults.ini clean up In-Reply-To: <5344055E.5000207@smxy.org> References: <9A70FC02-12BB-4E89-B64C-9EF8DEBA25D4@gmail.com> <5343E230.2090003@ateb.co.uk> <5344055E.5000207@smxy.org> Message-ID: <534414F5.9080305@t-data.com> I'm also against moving things to the end of sections. Having the options present in Opensim.ini in the same order as in the defaults file makes sense for diffing, but moving them to the end of sections does not because it would cause the readability issues mentioned as well as make it even more confusing if someone copies a section to their ini from the defaults file, breaking that scheme. The defaults file is overwritten in every update. - Melanie On 08/04/2014 16:19, Shaun T. Erickson wrote: > Yeah, I would definitely vote against moving things to the end of > sections. It's perfectly fine to have, say: > > A > B > C > D > E > > in the defaults file, but only have, say: > > A > C > E > > in OpenSim.ini.example. > > -ste > > On 4/8/14, 7:49 AM, Jak Daniels wrote: >> +1 for this, however moving things in defaults that are not in example >> to the end of a section, particularly in the larger sections might >> move a setting more out of context and make the defaults file less >> readable. > > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev From marcus.llewellyn at gmail.com Tue Apr 8 16:43:05 2014 From: marcus.llewellyn at gmail.com (Marcus Llewellyn) Date: Tue, 8 Apr 2014 11:43:05 -0500 Subject: [Opensim-dev] OpenSimDefaults.ini clean up In-Reply-To: <534414F5.9080305@t-data.com> References: <9A70FC02-12BB-4E89-B64C-9EF8DEBA25D4@gmail.com> <5343E230.2090003@ateb.co.uk> <5344055E.5000207@smxy.org> <534414F5.9080305@t-data.com> Message-ID: In regard to the specially formatted comments meant to aid external configuration tools, it may be worth considering adding these to OpenSimDefaults.ini. Currently, OpenSim.ini.example contains them, but OpenSimDefaults does not. When one strips OpenSim.ini.example down to *only* active sections, keys, and values while including those configuration comments, you end up easily seeing that every single option is being paired with a special configuration comment. On the other hand, if you do the same thing to a grid's OpenSim.ini file (I used OSgrid's), it becomes much less consistent. Sections like Startup or XEngine will only have a few of these config/option pairings. Some sections like RegionReady, VivoxVoice, and BulletSim have none at all. The authors of these OpenSIm.ini files aren't at fault. They simply have more imperative things to do than track down all of the possible option values or dependencies. Since, presumably, options added to OpenSim.ini files like OSgrid's are largely derived from OpenSimDefaults.ini, it could be of benefit to provide the config comments in OpenSimDefaults as well. OpenSim.ini.example is setup only for standalones. Simulators configured for grids obviously use more options (about 7 times the options in OSgrid's case). Any future configuration tool would probably be most useful on configuration files meant for either mode of operation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.stallings at gmail.com Tue Apr 8 22:45:15 2014 From: james.stallings at gmail.com (James Stallings II) Date: Tue, 8 Apr 2014 17:45:15 -0500 Subject: [Opensim-dev] OpenSimDefaults.ini clean up In-Reply-To: References: <9A70FC02-12BB-4E89-B64C-9EF8DEBA25D4@gmail.com> <5343E230.2090003@ateb.co.uk> <5344055E.5000207@smxy.org> <534414F5.9080305@t-data.com> Message-ID: Actually Mel, I would not suggest that you do so. I've found some fairly useful workflows involving the shell utilities find, diff, grep and sed that really kind of move such concerns aside, allowing me to analyze and/or edit large groups of files all in one big glorious command line invocation :3 Note that heavy CYA safety nets are in place ;) It isn't especially advanced by way of technique what I'm doing, really just using those tools together for their intended purposes. If someone does get around to writing a gui configurator, that would be awesome (/me pokes marcus) Sorry for the confusion about the proprietary nature of the thing Mel, I guess I got the wrong idea last time we spoke of it, and that has been quite some time. In any case, my strategy is basically to use grep as a filter to get rid of the 'comments' on the fly, single out things I need to compare, etc which I then pass to diff or sed. I use find to generate lists of paths to the files I need to compare or edit (or not, depending whether I'm working on files in bulk). It's kind of a cowboy way of doing things, but it's very quick and effective if you don't get too crazy with it. Safe too if you make sure to keep good backups. Cheers! James/Hiro On Tue, Apr 8, 2014 at 11:43 AM, Marcus Llewellyn < marcus.llewellyn at gmail.com> wrote: > In regard to the specially formatted comments meant to aid external > configuration tools, it may be worth considering adding these to > OpenSimDefaults.ini. Currently, OpenSim.ini.example contains them, but > OpenSimDefaults does not. > > When one strips OpenSim.ini.example down to *only* active sections, keys, > and values while including those configuration comments, you end up easily > seeing that every single option is being paired with a special > configuration comment. > > On the other hand, if you do the same thing to a grid's OpenSim.ini file > (I used OSgrid's), it becomes much less consistent. Sections like Startup > or XEngine will only have a few of these config/option pairings. Some > sections like RegionReady, VivoxVoice, and BulletSim have none at all. The > authors of these OpenSIm.ini files aren't at fault. They simply have more > imperative things to do than track down all of the possible option values > or dependencies. > > Since, presumably, options added to OpenSim.ini files like OSgrid's are > largely derived from OpenSimDefaults.ini, it could be of benefit to provide > the config comments in OpenSimDefaults as well. OpenSim.ini.example is > setup only for standalones. Simulators configured for grids obviously use > more options (about 7 times the options in OSgrid's case). Any future > configuration tool would probably be most useful on configuration files > meant for either mode of operation. > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From melanie at t-data.com Tue Apr 8 22:48:41 2014 From: melanie at t-data.com (Melanie) Date: Wed, 09 Apr 2014 00:48:41 +0200 Subject: [Opensim-dev] OpenSimDefaults.ini clean up In-Reply-To: References: <9A70FC02-12BB-4E89-B64C-9EF8DEBA25D4@gmail.com> <5343E230.2090003@ateb.co.uk> <5344055E.5000207@smxy.org> <534414F5.9080305@t-data.com> Message-ID: <53447CC9.5090103@t-data.com> Well, you're familiar with the command line, which many are now. Also, without cygwin, Windows is somewhat command line challenged. As for the "proprietary" bit - Avination does not use ini files. This encoding was done for the benefit of the open source community, we ourselves have no need of it. Melanie On 09/04/2014 00:45, James Stallings II wrote: > Actually Mel, I would not suggest that you do so. I've found some fairly > useful workflows involving the shell utilities find, diff, grep and sed > that really kind of move such concerns aside, allowing me to analyze and/or > edit large groups of files all in one big glorious command line invocation > :3 > > Note that heavy CYA safety nets are in place ;) > > It isn't especially advanced by way of technique what I'm doing, really > just using those tools together for their intended purposes. > > If someone does get around to writing a gui configurator, that would be > awesome (/me pokes marcus) > > Sorry for the confusion about the proprietary nature of the thing Mel, I > guess I got the wrong idea last time we spoke of it, and that has been > quite some time. > > In any case, my strategy is basically to use grep as a filter to get rid of > the 'comments' on the fly, single out things I need to compare, etc which I > then pass to diff or sed. I use find to generate lists of paths to the > files I need to compare or edit (or not, depending whether I'm working on > files in bulk). > > It's kind of a cowboy way of doing things, but it's very quick and > effective if you don't get too crazy with it. Safe too if you make sure to > keep good backups. > > > Cheers! > James/Hiro > > > > On Tue, Apr 8, 2014 at 11:43 AM, Marcus Llewellyn < > marcus.llewellyn at gmail.com> wrote: > >> In regard to the specially formatted comments meant to aid external >> configuration tools, it may be worth considering adding these to >> OpenSimDefaults.ini. Currently, OpenSim.ini.example contains them, but >> OpenSimDefaults does not. >> >> When one strips OpenSim.ini.example down to *only* active sections, keys, >> and values while including those configuration comments, you end up easily >> seeing that every single option is being paired with a special >> configuration comment. >> >> On the other hand, if you do the same thing to a grid's OpenSim.ini file >> (I used OSgrid's), it becomes much less consistent. Sections like Startup >> or XEngine will only have a few of these config/option pairings. Some >> sections like RegionReady, VivoxVoice, and BulletSim have none at all. The >> authors of these OpenSIm.ini files aren't at fault. They simply have more >> imperative things to do than track down all of the possible option values >> or dependencies. >> >> Since, presumably, options added to OpenSim.ini files like OSgrid's are >> largely derived from OpenSimDefaults.ini, it could be of benefit to provide >> the config comments in OpenSimDefaults as well. OpenSim.ini.example is >> setup only for standalones. Simulators configured for grids obviously use >> more options (about 7 times the options in OSgrid's case). Any future >> configuration tool would probably be most useful on configuration files >> meant for either mode of operation. >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev From james.stallings at gmail.com Thu Apr 10 14:01:56 2014 From: james.stallings at gmail.com (James Stallings II) Date: Thu, 10 Apr 2014 09:01:56 -0500 Subject: [Opensim-dev] Parcel Access Enforcement Message-ID: Greetings Devs :) I have a use case that requires the unlikely and less than popular parcel permissions access control featureset. Historically speaking, this has not been an area of development that has seen much love, and understandably so; none of us are particularly interested in fully duplicating the operational envelope of the Second Life experience. That coupled with the ability to deploy regions at whim, it is no wonder no one wants to involve themselves particularly deeply with making this work properly. That being said, I have a need at present, and there is also the simple fact that we have a dearth of UI components in the viewer we may well never get shut of, and a lot of of unfinished and/or unpolished code in the repo that touches on this functionality. The short story is, it may be above the waterline, but there is a hole in the boat, and one of my users is driving it headlong into the surf. So much for metaphors. I have heard a variety of conflicting reports about the state of this part of the codebase; some say it works well; others say it should not be counted on to work at all. The commit logs tell the tale that some have taken an interest and are working diligently to eliminate certain bugs; unfortunately, the work in progress has not yet brought the functionality into a state where it is yet useful, at least according to my testing. I'm not unwilling to undertake the work needed to bring this situation into a more satisfactory light; indeed, I've already begun, and I need only a little guidance today. I have thoroughly instrumented the method "public void EventManagerOnAvatarEnteringNewParcel(ScenePresence avatar, int localLandID, UUID regionID)" in the land management module, and was immediately confronted with a couple of surprises: First, when the code is called at all, it is called twice; and as far as I can tell, it is called only after a successful login has been completed. Neither does it seem to be called when an avatar teleports into the region. Instead, the method "public bool TestLandRestrictions(UUID agentID, out string reason, ref float posX, ref float posY)" is called from "OpenSim/Region/Framework/Scenes/Scene.cs" and "OpenSim/Region/Framework/Scenes/ScenePresence.cs", and mediates (rather less than consistently) whether the avatar is allowed into the parcel on the region. Being aware that there are several ways for an avatar to enter a parcel, which I will leave off enumerating at present, I would suggest that perhaps I have some misapprehensions as to the proper stages of authentication at login-time. So my question is this: should both of these functions come into play as an avatar enters a region (and consequently, a parcel)? or should there be a single methoid conducting these presence permission checks? Please advise at your convenience :) Many thanks and cheers James/Hiro -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.stallings at gmail.com Thu Apr 10 14:30:03 2014 From: james.stallings at gmail.com (James Stallings II) Date: Thu, 10 Apr 2014 09:30:03 -0500 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: References: Message-ID: After some further exploration, I have seen where the method calls taking precedence from out of Scene are handling ViaLogin; but they are also doing some of the same lifting performed in the Land Management module. This seems to be duplication of effort, if not duplication of code; and is certainly less elegant than I would hope to find in our codebase (in an ideal world ;) This is likely the result of the ad-hoc nature of the development life of the project over the years; I can see the scene code being a good deal older than the Land Management module. I'll be working with this throughout the day, hoping to improve the code as I'm able; your thoughts, advice and commentary are solicited and appreciated. Cheers James On Thu, Apr 10, 2014 at 9:01 AM, James Stallings II < james.stallings at gmail.com> wrote: > Greetings Devs :) > > I have a use case that requires the unlikely and less than popular parcel > permissions access control featureset. > > Historically speaking, this has not been an area of development that has > seen much love, and understandably so; none of us are particularly > interested in fully duplicating the operational envelope of the Second Life > experience. That coupled with the ability to deploy regions at whim, it is > no wonder no one wants to involve themselves particularly deeply with > making this work properly. > > That being said, I have a need at present, and there is also the simple > fact that we have a dearth of UI components in the viewer we may well never > get shut of, and a lot of of unfinished and/or unpolished code in the repo > that touches on this functionality. > > The short story is, it may be above the waterline, but there is a hole in > the boat, and one of my users is driving it headlong into the surf. > > So much for metaphors. > > I have heard a variety of conflicting reports about the state of this part > of the codebase; some say it works well; others say it should not be > counted on to work at all. The commit logs tell the tale that some have > taken an interest and are working diligently to eliminate certain bugs; > unfortunately, the work in progress has not yet brought the functionality > into a state where it is yet useful, at least according to my testing. > > I'm not unwilling to undertake the work needed to bring this situation > into a more satisfactory light; indeed, I've already begun, and I need only > a little guidance today. > > I have thoroughly instrumented the method "public void > EventManagerOnAvatarEnteringNewParcel(ScenePresence avatar, int > localLandID, UUID regionID)" > in the land management module, and was immediately confronted with a > couple of surprises: > First, when the code is called at all, it is called twice; and as far as I > can tell, it is called only after a successful login has been completed. > Neither does it seem to be called when an avatar teleports into the region. > > Instead, the method "public bool TestLandRestrictions(UUID agentID, out > string reason, ref float posX, ref float posY)" is called from > "OpenSim/Region/Framework/Scenes/Scene.cs" and > "OpenSim/Region/Framework/Scenes/ScenePresence.cs", and mediates (rather > less than consistently) whether the avatar is allowed into the parcel on > the region. > > Being aware that there are several ways for an avatar to enter a parcel, > which I will leave off enumerating at present, I would suggest that perhaps > I have some misapprehensions as to the proper stages of authentication at > login-time. > > So my question is this: should both of these functions come into play as > an avatar enters a region (and consequently, a parcel)? or should there be > a single methoid conducting these presence permission checks? > > Please advise at your convenience :) > > Many thanks and cheers > James/Hiro > > > -- > =================================== > http://osgrid.org/ > http://simhost.com > http://twitter.com/jstallings2 > > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.stallings at gmail.com Thu Apr 10 15:05:21 2014 From: james.stallings at gmail.com (James Stallings II) Date: Thu, 10 Apr 2014 10:05:21 -0500 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: References: Message-ID: Subsequent work (instrumentation to Scene) shows that the permissions checking code is also being called twice there. Cheers James On Thu, Apr 10, 2014 at 9:30 AM, James Stallings II < james.stallings at gmail.com> wrote: > After some further exploration, I have seen where the method calls taking > precedence from out of Scene are handling ViaLogin; but they are also doing > some of the same lifting performed in the Land Management module. This > seems to be duplication of effort, if not duplication of code; and is > certainly less elegant than I would hope to find in our codebase (in an > ideal world ;) > > This is likely the result of the ad-hoc nature of the development life of > the project over the years; I can see the scene code being a good deal > older than the Land Management module. > > I'll be working with this throughout the day, hoping to improve the code > as I'm able; your thoughts, advice and commentary are solicited and > appreciated. > > Cheers > James > > > > On Thu, Apr 10, 2014 at 9:01 AM, James Stallings II < > james.stallings at gmail.com> wrote: > >> Greetings Devs :) >> >> I have a use case that requires the unlikely and less than popular parcel >> permissions access control featureset. >> >> Historically speaking, this has not been an area of development that has >> seen much love, and understandably so; none of us are particularly >> interested in fully duplicating the operational envelope of the Second Life >> experience. That coupled with the ability to deploy regions at whim, it is >> no wonder no one wants to involve themselves particularly deeply with >> making this work properly. >> >> That being said, I have a need at present, and there is also the simple >> fact that we have a dearth of UI components in the viewer we may well never >> get shut of, and a lot of of unfinished and/or unpolished code in the repo >> that touches on this functionality. >> >> The short story is, it may be above the waterline, but there is a hole in >> the boat, and one of my users is driving it headlong into the surf. >> >> So much for metaphors. >> >> I have heard a variety of conflicting reports about the state of this >> part of the codebase; some say it works well; others say it should not be >> counted on to work at all. The commit logs tell the tale that some have >> taken an interest and are working diligently to eliminate certain bugs; >> unfortunately, the work in progress has not yet brought the functionality >> into a state where it is yet useful, at least according to my testing. >> >> I'm not unwilling to undertake the work needed to bring this situation >> into a more satisfactory light; indeed, I've already begun, and I need only >> a little guidance today. >> >> I have thoroughly instrumented the method "public void >> EventManagerOnAvatarEnteringNewParcel(ScenePresence avatar, int >> localLandID, UUID regionID)" >> in the land management module, and was immediately confronted with a >> couple of surprises: >> First, when the code is called at all, it is called twice; and as far as >> I can tell, it is called only after a successful login has been completed. >> Neither does it seem to be called when an avatar teleports into the region. >> >> Instead, the method "public bool TestLandRestrictions(UUID agentID, out >> string reason, ref float posX, ref float posY)" is called from >> "OpenSim/Region/Framework/Scenes/Scene.cs" and >> "OpenSim/Region/Framework/Scenes/ScenePresence.cs", and mediates (rather >> less than consistently) whether the avatar is allowed into the parcel on >> the region. >> >> Being aware that there are several ways for an avatar to enter a parcel, >> which I will leave off enumerating at present, I would suggest that perhaps >> I have some misapprehensions as to the proper stages of authentication at >> login-time. >> >> So my question is this: should both of these functions come into play as >> an avatar enters a region (and consequently, a parcel)? or should there be >> a single methoid conducting these presence permission checks? >> >> Please advise at your convenience :) >> >> Many thanks and cheers >> James/Hiro >> >> >> -- >> =================================== >> http://osgrid.org/ >> http://simhost.com >> http://twitter.com/jstallings2 >> >> > > > -- > =================================== > http://osgrid.org/ > http://simhost.com > http://twitter.com/jstallings2 > > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From melanie at t-data.com Thu Apr 10 15:10:54 2014 From: melanie at t-data.com (Melanie) Date: Thu, 10 Apr 2014 17:10:54 +0200 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: References: Message-ID: <5346B47E.2000204@t-data.com> The code for parcel access works, as far as I'm aware. It was originally fixed in Avination and that should have been donated to OpenSim a long time ago. Maybe a good starting point is to see what you would like that doesnt' work before you go and fix things that aren't broken. Melanie On 10/04/2014 17:05, James Stallings II wrote: > Subsequent work (instrumentation to Scene) shows that the permissions > checking code is also being called twice there. > > Cheers > James > > > > On Thu, Apr 10, 2014 at 9:30 AM, James Stallings II < > james.stallings at gmail.com> wrote: > >> After some further exploration, I have seen where the method calls taking >> precedence from out of Scene are handling ViaLogin; but they are also doing >> some of the same lifting performed in the Land Management module. This >> seems to be duplication of effort, if not duplication of code; and is >> certainly less elegant than I would hope to find in our codebase (in an >> ideal world ;) >> >> This is likely the result of the ad-hoc nature of the development life of >> the project over the years; I can see the scene code being a good deal >> older than the Land Management module. >> >> I'll be working with this throughout the day, hoping to improve the code >> as I'm able; your thoughts, advice and commentary are solicited and >> appreciated. >> >> Cheers >> James >> >> >> >> On Thu, Apr 10, 2014 at 9:01 AM, James Stallings II < >> james.stallings at gmail.com> wrote: >> >>> Greetings Devs :) >>> >>> I have a use case that requires the unlikely and less than popular parcel >>> permissions access control featureset. >>> >>> Historically speaking, this has not been an area of development that has >>> seen much love, and understandably so; none of us are particularly >>> interested in fully duplicating the operational envelope of the Second Life >>> experience. That coupled with the ability to deploy regions at whim, it is >>> no wonder no one wants to involve themselves particularly deeply with >>> making this work properly. >>> >>> That being said, I have a need at present, and there is also the simple >>> fact that we have a dearth of UI components in the viewer we may well never >>> get shut of, and a lot of of unfinished and/or unpolished code in the repo >>> that touches on this functionality. >>> >>> The short story is, it may be above the waterline, but there is a hole in >>> the boat, and one of my users is driving it headlong into the surf. >>> >>> So much for metaphors. >>> >>> I have heard a variety of conflicting reports about the state of this >>> part of the codebase; some say it works well; others say it should not be >>> counted on to work at all. The commit logs tell the tale that some have >>> taken an interest and are working diligently to eliminate certain bugs; >>> unfortunately, the work in progress has not yet brought the functionality >>> into a state where it is yet useful, at least according to my testing. >>> >>> I'm not unwilling to undertake the work needed to bring this situation >>> into a more satisfactory light; indeed, I've already begun, and I need only >>> a little guidance today. >>> >>> I have thoroughly instrumented the method "public void >>> EventManagerOnAvatarEnteringNewParcel(ScenePresence avatar, int >>> localLandID, UUID regionID)" >>> in the land management module, and was immediately confronted with a >>> couple of surprises: >>> First, when the code is called at all, it is called twice; and as far as >>> I can tell, it is called only after a successful login has been completed. >>> Neither does it seem to be called when an avatar teleports into the region. >>> >>> Instead, the method "public bool TestLandRestrictions(UUID agentID, out >>> string reason, ref float posX, ref float posY)" is called from >>> "OpenSim/Region/Framework/Scenes/Scene.cs" and >>> "OpenSim/Region/Framework/Scenes/ScenePresence.cs", and mediates (rather >>> less than consistently) whether the avatar is allowed into the parcel on >>> the region. >>> >>> Being aware that there are several ways for an avatar to enter a parcel, >>> which I will leave off enumerating at present, I would suggest that perhaps >>> I have some misapprehensions as to the proper stages of authentication at >>> login-time. >>> >>> So my question is this: should both of these functions come into play as >>> an avatar enters a region (and consequently, a parcel)? or should there be >>> a single methoid conducting these presence permission checks? >>> >>> Please advise at your convenience :) >>> >>> Many thanks and cheers >>> James/Hiro >>> >>> >>> -- >>> =================================== >>> http://osgrid.org/ >>> http://simhost.com >>> http://twitter.com/jstallings2 >>> >>> >> >> >> -- >> =================================== >> http://osgrid.org/ >> http://simhost.com >> http://twitter.com/jstallings2 >> >> > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev From james.stallings at gmail.com Thu Apr 10 15:20:44 2014 From: james.stallings at gmail.com (James Stallings II) Date: Thu, 10 Apr 2014 10:20:44 -0500 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: <5346B47E.2000204@t-data.com> References: <5346B47E.2000204@t-data.com> Message-ID: "Maybe a good starting point is to see what you would like that doesnt' work before you go and fix things that..." Actually, that *is* where I began. My user reports various failures, which are repeatable on the running regions. No amount of reconfiguration predictably affects the experience on the regions. We do have a couple of regions that seem to work perfectly, including that which I'm working with; it started working after I completely replaced the OpenSim.ini with one that was identical excepting the http_listener specifcation. Unfortunately, repeating this process with the same OpenSim.ini on a different region that doesn't work did not produce a region that does. To say that it works intermittently is a bit of an understatement; though it does seem that once it begins working it continues to do so. Try not to be so defensive Mel; I'm not attacking you or your work, I'm just attempting to figure out what's happening on these regions. I have eliminated everything I can find but the code, which I am told by others is not to be trusted as fully functional; and I am not afraid to get in and get my hands dirty. Cheers James On Thu, Apr 10, 2014 at 10:10 AM, Melanie wrote: > The code for parcel access works, as far as I'm aware. It was > originally fixed in Avination and that should have been donated to > OpenSim a long time ago. Maybe a good starting point is to see what > you would like that doesnt' work before you go and fix things that > aren't broken. > > Melanie > > > On 10/04/2014 17:05, James Stallings II wrote: > > Subsequent work (instrumentation to Scene) shows that the permissions > > checking code is also being called twice there. > > > > Cheers > > James > > > > > > > > On Thu, Apr 10, 2014 at 9:30 AM, James Stallings II < > > james.stallings at gmail.com> wrote: > > > >> After some further exploration, I have seen where the method calls > taking > >> precedence from out of Scene are handling ViaLogin; but they are also > doing > >> some of the same lifting performed in the Land Management module. This > >> seems to be duplication of effort, if not duplication of code; and is > >> certainly less elegant than I would hope to find in our codebase (in an > >> ideal world ;) > >> > >> This is likely the result of the ad-hoc nature of the development life > of > >> the project over the years; I can see the scene code being a good deal > >> older than the Land Management module. > >> > >> I'll be working with this throughout the day, hoping to improve the code > >> as I'm able; your thoughts, advice and commentary are solicited and > >> appreciated. > >> > >> Cheers > >> James > >> > >> > >> > >> On Thu, Apr 10, 2014 at 9:01 AM, James Stallings II < > >> james.stallings at gmail.com> wrote: > >> > >>> Greetings Devs :) > >>> > >>> I have a use case that requires the unlikely and less than popular > parcel > >>> permissions access control featureset. > >>> > >>> Historically speaking, this has not been an area of development that > has > >>> seen much love, and understandably so; none of us are particularly > >>> interested in fully duplicating the operational envelope of the Second > Life > >>> experience. That coupled with the ability to deploy regions at whim, > it is > >>> no wonder no one wants to involve themselves particularly deeply with > >>> making this work properly. > >>> > >>> That being said, I have a need at present, and there is also the simple > >>> fact that we have a dearth of UI components in the viewer we may well > never > >>> get shut of, and a lot of of unfinished and/or unpolished code in the > repo > >>> that touches on this functionality. > >>> > >>> The short story is, it may be above the waterline, but there is a hole > in > >>> the boat, and one of my users is driving it headlong into the surf. > >>> > >>> So much for metaphors. > >>> > >>> I have heard a variety of conflicting reports about the state of this > >>> part of the codebase; some say it works well; others say it should not > be > >>> counted on to work at all. The commit logs tell the tale that some have > >>> taken an interest and are working diligently to eliminate certain bugs; > >>> unfortunately, the work in progress has not yet brought the > functionality > >>> into a state where it is yet useful, at least according to my testing. > >>> > >>> I'm not unwilling to undertake the work needed to bring this situation > >>> into a more satisfactory light; indeed, I've already begun, and I need > only > >>> a little guidance today. > >>> > >>> I have thoroughly instrumented the method "public void > >>> EventManagerOnAvatarEnteringNewParcel(ScenePresence avatar, int > >>> localLandID, UUID regionID)" > >>> in the land management module, and was immediately confronted with a > >>> couple of surprises: > >>> First, when the code is called at all, it is called twice; and as far > as > >>> I can tell, it is called only after a successful login has been > completed. > >>> Neither does it seem to be called when an avatar teleports into the > region. > >>> > >>> Instead, the method "public bool TestLandRestrictions(UUID agentID, out > >>> string reason, ref float posX, ref float posY)" is called from > >>> "OpenSim/Region/Framework/Scenes/Scene.cs" and > >>> "OpenSim/Region/Framework/Scenes/ScenePresence.cs", and mediates > (rather > >>> less than consistently) whether the avatar is allowed into the parcel > on > >>> the region. > >>> > >>> Being aware that there are several ways for an avatar to enter a > parcel, > >>> which I will leave off enumerating at present, I would suggest that > perhaps > >>> I have some misapprehensions as to the proper stages of authentication > at > >>> login-time. > >>> > >>> So my question is this: should both of these functions come into play > as > >>> an avatar enters a region (and consequently, a parcel)? or should > there be > >>> a single methoid conducting these presence permission checks? > >>> > >>> Please advise at your convenience :) > >>> > >>> Many thanks and cheers > >>> James/Hiro > >>> > >>> > >>> -- > >>> =================================== > >>> http://osgrid.org/ > >>> http://simhost.com > >>> http://twitter.com/jstallings2 > >>> > >>> > >> > >> > >> -- > >> =================================== > >> http://osgrid.org/ > >> http://simhost.com > >> http://twitter.com/jstallings2 > >> > >> > > > > > > > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From melanie at t-data.com Thu Apr 10 15:23:18 2014 From: melanie at t-data.com (Melanie) Date: Thu, 10 Apr 2014 17:23:18 +0200 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: References: <5346B47E.2000204@t-data.com> Message-ID: <5346B766.1050005@t-data.com> I'm not even being defensive. I just don't like the idea of poking code with a sharp stick instead of debugging it properly. - Melanie On 10/04/2014 17:20, James Stallings II wrote: > "Maybe a good starting point is to see what you would like that doesnt' > work before you go and fix things that..." > > Actually, that *is* where I began. > > My user reports various failures, which are repeatable on the running > regions. No amount of reconfiguration predictably affects the experience on > the regions. > > We do have a couple of regions that seem to work perfectly, including that > which I'm working with; it started working after I completely replaced the > OpenSim.ini with one that was identical excepting the http_listener > specifcation. Unfortunately, repeating this process with the same > OpenSim.ini on a different region that doesn't work did not produce a > region that does. > > To say that it works intermittently is a bit of an understatement; though > it does seem that once it begins working it continues to do so. > > > Try not to be so defensive Mel; I'm not attacking you or your work, I'm > just attempting to figure out what's happening on these regions. I have > eliminated everything I can find but the code, which I am told by others is > not to be trusted as fully functional; and I am not afraid to get in and > get my hands dirty. > > > Cheers > James > > > > On Thu, Apr 10, 2014 at 10:10 AM, Melanie wrote: > >> The code for parcel access works, as far as I'm aware. It was >> originally fixed in Avination and that should have been donated to >> OpenSim a long time ago. Maybe a good starting point is to see what >> you would like that doesnt' work before you go and fix things that >> aren't broken. >> >> Melanie >> >> >> On 10/04/2014 17:05, James Stallings II wrote: >> > Subsequent work (instrumentation to Scene) shows that the permissions >> > checking code is also being called twice there. >> > >> > Cheers >> > James >> > >> > >> > >> > On Thu, Apr 10, 2014 at 9:30 AM, James Stallings II < >> > james.stallings at gmail.com> wrote: >> > >> >> After some further exploration, I have seen where the method calls >> taking >> >> precedence from out of Scene are handling ViaLogin; but they are also >> doing >> >> some of the same lifting performed in the Land Management module. This >> >> seems to be duplication of effort, if not duplication of code; and is >> >> certainly less elegant than I would hope to find in our codebase (in an >> >> ideal world ;) >> >> >> >> This is likely the result of the ad-hoc nature of the development life >> of >> >> the project over the years; I can see the scene code being a good deal >> >> older than the Land Management module. >> >> >> >> I'll be working with this throughout the day, hoping to improve the code >> >> as I'm able; your thoughts, advice and commentary are solicited and >> >> appreciated. >> >> >> >> Cheers >> >> James >> >> >> >> >> >> >> >> On Thu, Apr 10, 2014 at 9:01 AM, James Stallings II < >> >> james.stallings at gmail.com> wrote: >> >> >> >>> Greetings Devs :) >> >>> >> >>> I have a use case that requires the unlikely and less than popular >> parcel >> >>> permissions access control featureset. >> >>> >> >>> Historically speaking, this has not been an area of development that >> has >> >>> seen much love, and understandably so; none of us are particularly >> >>> interested in fully duplicating the operational envelope of the Second >> Life >> >>> experience. That coupled with the ability to deploy regions at whim, >> it is >> >>> no wonder no one wants to involve themselves particularly deeply with >> >>> making this work properly. >> >>> >> >>> That being said, I have a need at present, and there is also the simple >> >>> fact that we have a dearth of UI components in the viewer we may well >> never >> >>> get shut of, and a lot of of unfinished and/or unpolished code in the >> repo >> >>> that touches on this functionality. >> >>> >> >>> The short story is, it may be above the waterline, but there is a hole >> in >> >>> the boat, and one of my users is driving it headlong into the surf. >> >>> >> >>> So much for metaphors. >> >>> >> >>> I have heard a variety of conflicting reports about the state of this >> >>> part of the codebase; some say it works well; others say it should not >> be >> >>> counted on to work at all. The commit logs tell the tale that some have >> >>> taken an interest and are working diligently to eliminate certain bugs; >> >>> unfortunately, the work in progress has not yet brought the >> functionality >> >>> into a state where it is yet useful, at least according to my testing. >> >>> >> >>> I'm not unwilling to undertake the work needed to bring this situation >> >>> into a more satisfactory light; indeed, I've already begun, and I need >> only >> >>> a little guidance today. >> >>> >> >>> I have thoroughly instrumented the method "public void >> >>> EventManagerOnAvatarEnteringNewParcel(ScenePresence avatar, int >> >>> localLandID, UUID regionID)" >> >>> in the land management module, and was immediately confronted with a >> >>> couple of surprises: >> >>> First, when the code is called at all, it is called twice; and as far >> as >> >>> I can tell, it is called only after a successful login has been >> completed. >> >>> Neither does it seem to be called when an avatar teleports into the >> region. >> >>> >> >>> Instead, the method "public bool TestLandRestrictions(UUID agentID, out >> >>> string reason, ref float posX, ref float posY)" is called from >> >>> "OpenSim/Region/Framework/Scenes/Scene.cs" and >> >>> "OpenSim/Region/Framework/Scenes/ScenePresence.cs", and mediates >> (rather >> >>> less than consistently) whether the avatar is allowed into the parcel >> on >> >>> the region. >> >>> >> >>> Being aware that there are several ways for an avatar to enter a >> parcel, >> >>> which I will leave off enumerating at present, I would suggest that >> perhaps >> >>> I have some misapprehensions as to the proper stages of authentication >> at >> >>> login-time. >> >>> >> >>> So my question is this: should both of these functions come into play >> as >> >>> an avatar enters a region (and consequently, a parcel)? or should >> there be >> >>> a single methoid conducting these presence permission checks? >> >>> >> >>> Please advise at your convenience :) >> >>> >> >>> Many thanks and cheers >> >>> James/Hiro >> >>> >> >>> >> >>> -- >> >>> =================================== >> >>> http://osgrid.org/ >> >>> http://simhost.com >> >>> http://twitter.com/jstallings2 >> >>> >> >>> >> >> >> >> >> >> -- >> >> =================================== >> >> http://osgrid.org/ >> >> http://simhost.com >> >> http://twitter.com/jstallings2 >> >> >> >> >> > >> > >> > >> > >> > _______________________________________________ >> > Opensim-dev mailing list >> > Opensim-dev at lists.berlios.de >> > https://lists.berlios.de/mailman/listinfo/opensim-dev >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev From james.stallings at gmail.com Thu Apr 10 15:25:17 2014 From: james.stallings at gmail.com (James Stallings II) Date: Thu, 10 Apr 2014 10:25:17 -0500 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: <5346B766.1050005@t-data.com> References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> Message-ID: The only code I'm affecting the local copy on my server; it isn't as if I'm going to break break the central repo back to 2006. Hell, I don't even have commit. And FWIW, last I hear adding log statements to code is a valid tried and true debugging method. On Thu, Apr 10, 2014 at 10:23 AM, Melanie wrote: > I'm not even being defensive. I just don't like the idea of poking > code with a sharp stick instead of debugging it properly. > > - Melanie > > On 10/04/2014 17:20, James Stallings II wrote: > > "Maybe a good starting point is to see what you would like that doesnt' > > work before you go and fix things that..." > > > > Actually, that *is* where I began. > > > > My user reports various failures, which are repeatable on the running > > regions. No amount of reconfiguration predictably affects the experience > on > > the regions. > > > > We do have a couple of regions that seem to work perfectly, including > that > > which I'm working with; it started working after I completely replaced > the > > OpenSim.ini with one that was identical excepting the http_listener > > specifcation. Unfortunately, repeating this process with the same > > OpenSim.ini on a different region that doesn't work did not produce a > > region that does. > > > > To say that it works intermittently is a bit of an understatement; though > > it does seem that once it begins working it continues to do so. > > > > > > Try not to be so defensive Mel; I'm not attacking you or your work, I'm > > just attempting to figure out what's happening on these regions. I have > > eliminated everything I can find but the code, which I am told by others > is > > not to be trusted as fully functional; and I am not afraid to get in and > > get my hands dirty. > > > > > > Cheers > > James > > > > > > > > On Thu, Apr 10, 2014 at 10:10 AM, Melanie wrote: > > > >> The code for parcel access works, as far as I'm aware. It was > >> originally fixed in Avination and that should have been donated to > >> OpenSim a long time ago. Maybe a good starting point is to see what > >> you would like that doesnt' work before you go and fix things that > >> aren't broken. > >> > >> Melanie > >> > >> > >> On 10/04/2014 17:05, James Stallings II wrote: > >> > Subsequent work (instrumentation to Scene) shows that the permissions > >> > checking code is also being called twice there. > >> > > >> > Cheers > >> > James > >> > > >> > > >> > > >> > On Thu, Apr 10, 2014 at 9:30 AM, James Stallings II < > >> > james.stallings at gmail.com> wrote: > >> > > >> >> After some further exploration, I have seen where the method calls > >> taking > >> >> precedence from out of Scene are handling ViaLogin; but they are also > >> doing > >> >> some of the same lifting performed in the Land Management module. > This > >> >> seems to be duplication of effort, if not duplication of code; and is > >> >> certainly less elegant than I would hope to find in our codebase (in > an > >> >> ideal world ;) > >> >> > >> >> This is likely the result of the ad-hoc nature of the development > life > >> of > >> >> the project over the years; I can see the scene code being a good > deal > >> >> older than the Land Management module. > >> >> > >> >> I'll be working with this throughout the day, hoping to improve the > code > >> >> as I'm able; your thoughts, advice and commentary are solicited and > >> >> appreciated. > >> >> > >> >> Cheers > >> >> James > >> >> > >> >> > >> >> > >> >> On Thu, Apr 10, 2014 at 9:01 AM, James Stallings II < > >> >> james.stallings at gmail.com> wrote: > >> >> > >> >>> Greetings Devs :) > >> >>> > >> >>> I have a use case that requires the unlikely and less than popular > >> parcel > >> >>> permissions access control featureset. > >> >>> > >> >>> Historically speaking, this has not been an area of development that > >> has > >> >>> seen much love, and understandably so; none of us are particularly > >> >>> interested in fully duplicating the operational envelope of the > Second > >> Life > >> >>> experience. That coupled with the ability to deploy regions at whim, > >> it is > >> >>> no wonder no one wants to involve themselves particularly deeply > with > >> >>> making this work properly. > >> >>> > >> >>> That being said, I have a need at present, and there is also the > simple > >> >>> fact that we have a dearth of UI components in the viewer we may > well > >> never > >> >>> get shut of, and a lot of of unfinished and/or unpolished code in > the > >> repo > >> >>> that touches on this functionality. > >> >>> > >> >>> The short story is, it may be above the waterline, but there is a > hole > >> in > >> >>> the boat, and one of my users is driving it headlong into the surf. > >> >>> > >> >>> So much for metaphors. > >> >>> > >> >>> I have heard a variety of conflicting reports about the state of > this > >> >>> part of the codebase; some say it works well; others say it should > not > >> be > >> >>> counted on to work at all. The commit logs tell the tale that some > have > >> >>> taken an interest and are working diligently to eliminate certain > bugs; > >> >>> unfortunately, the work in progress has not yet brought the > >> functionality > >> >>> into a state where it is yet useful, at least according to my > testing. > >> >>> > >> >>> I'm not unwilling to undertake the work needed to bring this > situation > >> >>> into a more satisfactory light; indeed, I've already begun, and I > need > >> only > >> >>> a little guidance today. > >> >>> > >> >>> I have thoroughly instrumented the method "public void > >> >>> EventManagerOnAvatarEnteringNewParcel(ScenePresence avatar, int > >> >>> localLandID, UUID regionID)" > >> >>> in the land management module, and was immediately confronted with a > >> >>> couple of surprises: > >> >>> First, when the code is called at all, it is called twice; and as > far > >> as > >> >>> I can tell, it is called only after a successful login has been > >> completed. > >> >>> Neither does it seem to be called when an avatar teleports into the > >> region. > >> >>> > >> >>> Instead, the method "public bool TestLandRestrictions(UUID agentID, > out > >> >>> string reason, ref float posX, ref float posY)" is called from > >> >>> "OpenSim/Region/Framework/Scenes/Scene.cs" and > >> >>> "OpenSim/Region/Framework/Scenes/ScenePresence.cs", and mediates > >> (rather > >> >>> less than consistently) whether the avatar is allowed into the > parcel > >> on > >> >>> the region. > >> >>> > >> >>> Being aware that there are several ways for an avatar to enter a > >> parcel, > >> >>> which I will leave off enumerating at present, I would suggest that > >> perhaps > >> >>> I have some misapprehensions as to the proper stages of > authentication > >> at > >> >>> login-time. > >> >>> > >> >>> So my question is this: should both of these functions come into > play > >> as > >> >>> an avatar enters a region (and consequently, a parcel)? or should > >> there be > >> >>> a single methoid conducting these presence permission checks? > >> >>> > >> >>> Please advise at your convenience :) > >> >>> > >> >>> Many thanks and cheers > >> >>> James/Hiro > >> >>> > >> >>> > >> >>> -- > >> >>> =================================== > >> >>> http://osgrid.org/ > >> >>> http://simhost.com > >> >>> http://twitter.com/jstallings2 > >> >>> > >> >>> > >> >> > >> >> > >> >> -- > >> >> =================================== > >> >> http://osgrid.org/ > >> >> http://simhost.com > >> >> http://twitter.com/jstallings2 > >> >> > >> >> > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > Opensim-dev mailing list > >> > Opensim-dev at lists.berlios.de > >> > https://lists.berlios.de/mailman/listinfo/opensim-dev > >> _______________________________________________ > >> Opensim-dev mailing list > >> Opensim-dev at lists.berlios.de > >> https://lists.berlios.de/mailman/listinfo/opensim-dev > >> > > > > > > > > > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From melanie at t-data.com Thu Apr 10 15:49:33 2014 From: melanie at t-data.com (Melanie) Date: Thu, 10 Apr 2014 17:49:33 +0200 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> Message-ID: <5346BD8D.3050804@t-data.com> Indeed it is :) - Melanie On 10/04/2014 17:25, James Stallings II wrote: > The only code I'm affecting the local copy on my server; it isn't as if I'm > going to break break the central repo back to 2006. Hell, I don't even have > commit. And FWIW, last I hear adding log statements to code is a valid > tried and true debugging method. > > > > > > > On Thu, Apr 10, 2014 at 10:23 AM, Melanie wrote: > >> I'm not even being defensive. I just don't like the idea of poking >> code with a sharp stick instead of debugging it properly. >> >> - Melanie >> >> On 10/04/2014 17:20, James Stallings II wrote: >> > "Maybe a good starting point is to see what you would like that doesnt' >> > work before you go and fix things that..." >> > >> > Actually, that *is* where I began. >> > >> > My user reports various failures, which are repeatable on the running >> > regions. No amount of reconfiguration predictably affects the experience >> on >> > the regions. >> > >> > We do have a couple of regions that seem to work perfectly, including >> that >> > which I'm working with; it started working after I completely replaced >> the >> > OpenSim.ini with one that was identical excepting the http_listener >> > specifcation. Unfortunately, repeating this process with the same >> > OpenSim.ini on a different region that doesn't work did not produce a >> > region that does. >> > >> > To say that it works intermittently is a bit of an understatement; though >> > it does seem that once it begins working it continues to do so. >> > >> > >> > Try not to be so defensive Mel; I'm not attacking you or your work, I'm >> > just attempting to figure out what's happening on these regions. I have >> > eliminated everything I can find but the code, which I am told by others >> is >> > not to be trusted as fully functional; and I am not afraid to get in and >> > get my hands dirty. >> > >> > >> > Cheers >> > James >> > >> > >> > >> > On Thu, Apr 10, 2014 at 10:10 AM, Melanie wrote: >> > >> >> The code for parcel access works, as far as I'm aware. It was >> >> originally fixed in Avination and that should have been donated to >> >> OpenSim a long time ago. Maybe a good starting point is to see what >> >> you would like that doesnt' work before you go and fix things that >> >> aren't broken. >> >> >> >> Melanie >> >> >> >> >> >> On 10/04/2014 17:05, James Stallings II wrote: >> >> > Subsequent work (instrumentation to Scene) shows that the permissions >> >> > checking code is also being called twice there. >> >> > >> >> > Cheers >> >> > James >> >> > >> >> > >> >> > >> >> > On Thu, Apr 10, 2014 at 9:30 AM, James Stallings II < >> >> > james.stallings at gmail.com> wrote: >> >> > >> >> >> After some further exploration, I have seen where the method calls >> >> taking >> >> >> precedence from out of Scene are handling ViaLogin; but they are also >> >> doing >> >> >> some of the same lifting performed in the Land Management module. >> This >> >> >> seems to be duplication of effort, if not duplication of code; and is >> >> >> certainly less elegant than I would hope to find in our codebase (in >> an >> >> >> ideal world ;) >> >> >> >> >> >> This is likely the result of the ad-hoc nature of the development >> life >> >> of >> >> >> the project over the years; I can see the scene code being a good >> deal >> >> >> older than the Land Management module. >> >> >> >> >> >> I'll be working with this throughout the day, hoping to improve the >> code >> >> >> as I'm able; your thoughts, advice and commentary are solicited and >> >> >> appreciated. >> >> >> >> >> >> Cheers >> >> >> James >> >> >> >> >> >> >> >> >> >> >> >> On Thu, Apr 10, 2014 at 9:01 AM, James Stallings II < >> >> >> james.stallings at gmail.com> wrote: >> >> >> >> >> >>> Greetings Devs :) >> >> >>> >> >> >>> I have a use case that requires the unlikely and less than popular >> >> parcel >> >> >>> permissions access control featureset. >> >> >>> >> >> >>> Historically speaking, this has not been an area of development that >> >> has >> >> >>> seen much love, and understandably so; none of us are particularly >> >> >>> interested in fully duplicating the operational envelope of the >> Second >> >> Life >> >> >>> experience. That coupled with the ability to deploy regions at whim, >> >> it is >> >> >>> no wonder no one wants to involve themselves particularly deeply >> with >> >> >>> making this work properly. >> >> >>> >> >> >>> That being said, I have a need at present, and there is also the >> simple >> >> >>> fact that we have a dearth of UI components in the viewer we may >> well >> >> never >> >> >>> get shut of, and a lot of of unfinished and/or unpolished code in >> the >> >> repo >> >> >>> that touches on this functionality. >> >> >>> >> >> >>> The short story is, it may be above the waterline, but there is a >> hole >> >> in >> >> >>> the boat, and one of my users is driving it headlong into the surf. >> >> >>> >> >> >>> So much for metaphors. >> >> >>> >> >> >>> I have heard a variety of conflicting reports about the state of >> this >> >> >>> part of the codebase; some say it works well; others say it should >> not >> >> be >> >> >>> counted on to work at all. The commit logs tell the tale that some >> have >> >> >>> taken an interest and are working diligently to eliminate certain >> bugs; >> >> >>> unfortunately, the work in progress has not yet brought the >> >> functionality >> >> >>> into a state where it is yet useful, at least according to my >> testing. >> >> >>> >> >> >>> I'm not unwilling to undertake the work needed to bring this >> situation >> >> >>> into a more satisfactory light; indeed, I've already begun, and I >> need >> >> only >> >> >>> a little guidance today. >> >> >>> >> >> >>> I have thoroughly instrumented the method "public void >> >> >>> EventManagerOnAvatarEnteringNewParcel(ScenePresence avatar, int >> >> >>> localLandID, UUID regionID)" >> >> >>> in the land management module, and was immediately confronted with a >> >> >>> couple of surprises: >> >> >>> First, when the code is called at all, it is called twice; and as >> far >> >> as >> >> >>> I can tell, it is called only after a successful login has been >> >> completed. >> >> >>> Neither does it seem to be called when an avatar teleports into the >> >> region. >> >> >>> >> >> >>> Instead, the method "public bool TestLandRestrictions(UUID agentID, >> out >> >> >>> string reason, ref float posX, ref float posY)" is called from >> >> >>> "OpenSim/Region/Framework/Scenes/Scene.cs" and >> >> >>> "OpenSim/Region/Framework/Scenes/ScenePresence.cs", and mediates >> >> (rather >> >> >>> less than consistently) whether the avatar is allowed into the >> parcel >> >> on >> >> >>> the region. >> >> >>> >> >> >>> Being aware that there are several ways for an avatar to enter a >> >> parcel, >> >> >>> which I will leave off enumerating at present, I would suggest that >> >> perhaps >> >> >>> I have some misapprehensions as to the proper stages of >> authentication >> >> at >> >> >>> login-time. >> >> >>> >> >> >>> So my question is this: should both of these functions come into >> play >> >> as >> >> >>> an avatar enters a region (and consequently, a parcel)? or should >> >> there be >> >> >>> a single methoid conducting these presence permission checks? >> >> >>> >> >> >>> Please advise at your convenience :) >> >> >>> >> >> >>> Many thanks and cheers >> >> >>> James/Hiro >> >> >>> >> >> >>> >> >> >>> -- >> >> >>> =================================== >> >> >>> http://osgrid.org/ >> >> >>> http://simhost.com >> >> >>> http://twitter.com/jstallings2 >> >> >>> >> >> >>> >> >> >> >> >> >> >> >> >> -- >> >> >> =================================== >> >> >> http://osgrid.org/ >> >> >> http://simhost.com >> >> >> http://twitter.com/jstallings2 >> >> >> >> >> >> >> >> > >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > Opensim-dev mailing list >> >> > Opensim-dev at lists.berlios.de >> >> > https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> _______________________________________________ >> >> Opensim-dev mailing list >> >> Opensim-dev at lists.berlios.de >> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> >> > >> > >> > >> > >> > >> > _______________________________________________ >> > Opensim-dev mailing list >> > Opensim-dev at lists.berlios.de >> > https://lists.berlios.de/mailman/listinfo/opensim-dev >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev From james.stallings at gmail.com Thu Apr 10 15:52:09 2014 From: james.stallings at gmail.com (James Stallings II) Date: Thu, 10 Apr 2014 10:52:09 -0500 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> Message-ID: So, Melanie, I'll bite: What do you suggest for 'proper debugging' in this context? On Thu, Apr 10, 2014 at 10:25 AM, James Stallings II < james.stallings at gmail.com> wrote: > The only code I'm affecting the local copy on my server; it isn't as if > I'm going to break break the central repo back to 2006. Hell, I don't even > have commit. And FWIW, last I hear adding log statements to code is a valid > tried and true debugging method. > > > > > > > On Thu, Apr 10, 2014 at 10:23 AM, Melanie wrote: > >> I'm not even being defensive. I just don't like the idea of poking >> code with a sharp stick instead of debugging it properly. >> >> - Melanie >> >> On 10/04/2014 17:20, James Stallings II wrote: >> > "Maybe a good starting point is to see what you would like that doesnt' >> > work before you go and fix things that..." >> > >> > Actually, that *is* where I began. >> > >> > My user reports various failures, which are repeatable on the running >> > regions. No amount of reconfiguration predictably affects the >> experience on >> > the regions. >> > >> > We do have a couple of regions that seem to work perfectly, including >> that >> > which I'm working with; it started working after I completely replaced >> the >> > OpenSim.ini with one that was identical excepting the http_listener >> > specifcation. Unfortunately, repeating this process with the same >> > OpenSim.ini on a different region that doesn't work did not produce a >> > region that does. >> > >> > To say that it works intermittently is a bit of an understatement; >> though >> > it does seem that once it begins working it continues to do so. >> > >> > >> > Try not to be so defensive Mel; I'm not attacking you or your work, I'm >> > just attempting to figure out what's happening on these regions. I have >> > eliminated everything I can find but the code, which I am told by >> others is >> > not to be trusted as fully functional; and I am not afraid to get in and >> > get my hands dirty. >> > >> > >> > Cheers >> > James >> > >> > >> > >> > On Thu, Apr 10, 2014 at 10:10 AM, Melanie wrote: >> > >> >> The code for parcel access works, as far as I'm aware. It was >> >> originally fixed in Avination and that should have been donated to >> >> OpenSim a long time ago. Maybe a good starting point is to see what >> >> you would like that doesnt' work before you go and fix things that >> >> aren't broken. >> >> >> >> Melanie >> >> >> >> >> >> On 10/04/2014 17:05, James Stallings II wrote: >> >> > Subsequent work (instrumentation to Scene) shows that the permissions >> >> > checking code is also being called twice there. >> >> > >> >> > Cheers >> >> > James >> >> > >> >> > >> >> > >> >> > On Thu, Apr 10, 2014 at 9:30 AM, James Stallings II < >> >> > james.stallings at gmail.com> wrote: >> >> > >> >> >> After some further exploration, I have seen where the method calls >> >> taking >> >> >> precedence from out of Scene are handling ViaLogin; but they are >> also >> >> doing >> >> >> some of the same lifting performed in the Land Management module. >> This >> >> >> seems to be duplication of effort, if not duplication of code; and >> is >> >> >> certainly less elegant than I would hope to find in our codebase >> (in an >> >> >> ideal world ;) >> >> >> >> >> >> This is likely the result of the ad-hoc nature of the development >> life >> >> of >> >> >> the project over the years; I can see the scene code being a good >> deal >> >> >> older than the Land Management module. >> >> >> >> >> >> I'll be working with this throughout the day, hoping to improve the >> code >> >> >> as I'm able; your thoughts, advice and commentary are solicited and >> >> >> appreciated. >> >> >> >> >> >> Cheers >> >> >> James >> >> >> >> >> >> >> >> >> >> >> >> On Thu, Apr 10, 2014 at 9:01 AM, James Stallings II < >> >> >> james.stallings at gmail.com> wrote: >> >> >> >> >> >>> Greetings Devs :) >> >> >>> >> >> >>> I have a use case that requires the unlikely and less than popular >> >> parcel >> >> >>> permissions access control featureset. >> >> >>> >> >> >>> Historically speaking, this has not been an area of development >> that >> >> has >> >> >>> seen much love, and understandably so; none of us are particularly >> >> >>> interested in fully duplicating the operational envelope of the >> Second >> >> Life >> >> >>> experience. That coupled with the ability to deploy regions at >> whim, >> >> it is >> >> >>> no wonder no one wants to involve themselves particularly deeply >> with >> >> >>> making this work properly. >> >> >>> >> >> >>> That being said, I have a need at present, and there is also the >> simple >> >> >>> fact that we have a dearth of UI components in the viewer we may >> well >> >> never >> >> >>> get shut of, and a lot of of unfinished and/or unpolished code in >> the >> >> repo >> >> >>> that touches on this functionality. >> >> >>> >> >> >>> The short story is, it may be above the waterline, but there is a >> hole >> >> in >> >> >>> the boat, and one of my users is driving it headlong into the surf. >> >> >>> >> >> >>> So much for metaphors. >> >> >>> >> >> >>> I have heard a variety of conflicting reports about the state of >> this >> >> >>> part of the codebase; some say it works well; others say it should >> not >> >> be >> >> >>> counted on to work at all. The commit logs tell the tale that some >> have >> >> >>> taken an interest and are working diligently to eliminate certain >> bugs; >> >> >>> unfortunately, the work in progress has not yet brought the >> >> functionality >> >> >>> into a state where it is yet useful, at least according to my >> testing. >> >> >>> >> >> >>> I'm not unwilling to undertake the work needed to bring this >> situation >> >> >>> into a more satisfactory light; indeed, I've already begun, and I >> need >> >> only >> >> >>> a little guidance today. >> >> >>> >> >> >>> I have thoroughly instrumented the method "public void >> >> >>> EventManagerOnAvatarEnteringNewParcel(ScenePresence avatar, int >> >> >>> localLandID, UUID regionID)" >> >> >>> in the land management module, and was immediately confronted with >> a >> >> >>> couple of surprises: >> >> >>> First, when the code is called at all, it is called twice; and as >> far >> >> as >> >> >>> I can tell, it is called only after a successful login has been >> >> completed. >> >> >>> Neither does it seem to be called when an avatar teleports into the >> >> region. >> >> >>> >> >> >>> Instead, the method "public bool TestLandRestrictions(UUID >> agentID, out >> >> >>> string reason, ref float posX, ref float posY)" is called from >> >> >>> "OpenSim/Region/Framework/Scenes/Scene.cs" and >> >> >>> "OpenSim/Region/Framework/Scenes/ScenePresence.cs", and mediates >> >> (rather >> >> >>> less than consistently) whether the avatar is allowed into the >> parcel >> >> on >> >> >>> the region. >> >> >>> >> >> >>> Being aware that there are several ways for an avatar to enter a >> >> parcel, >> >> >>> which I will leave off enumerating at present, I would suggest that >> >> perhaps >> >> >>> I have some misapprehensions as to the proper stages of >> authentication >> >> at >> >> >>> login-time. >> >> >>> >> >> >>> So my question is this: should both of these functions come into >> play >> >> as >> >> >>> an avatar enters a region (and consequently, a parcel)? or should >> >> there be >> >> >>> a single methoid conducting these presence permission checks? >> >> >>> >> >> >>> Please advise at your convenience :) >> >> >>> >> >> >>> Many thanks and cheers >> >> >>> James/Hiro >> >> >>> >> >> >>> >> >> >>> -- >> >> >>> =================================== >> >> >>> http://osgrid.org/ >> >> >>> http://simhost.com >> >> >>> http://twitter.com/jstallings2 >> >> >>> >> >> >>> >> >> >> >> >> >> >> >> >> -- >> >> >> =================================== >> >> >> http://osgrid.org/ >> >> >> http://simhost.com >> >> >> http://twitter.com/jstallings2 >> >> >> >> >> >> >> >> > >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > Opensim-dev mailing list >> >> > Opensim-dev at lists.berlios.de >> >> > https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> _______________________________________________ >> >> Opensim-dev mailing list >> >> Opensim-dev at lists.berlios.de >> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> >> > >> > >> > >> > >> > >> > _______________________________________________ >> > Opensim-dev mailing list >> > Opensim-dev at lists.berlios.de >> > https://lists.berlios.de/mailman/listinfo/opensim-dev >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > -- > =================================== > http://osgrid.org/ > http://simhost.com > http://twitter.com/jstallings2 > > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From melanie at t-data.com Thu Apr 10 15:56:35 2014 From: melanie at t-data.com (Melanie) Date: Thu, 10 Apr 2014 17:56:35 +0200 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> Message-ID: <5346BF33.80203@t-data.com> No biting needed :) Debug output is a pretty good start and you did answer my concern when you mentioned the intermittent nature of the issue. I was worried that this would lead to a refactoring frenzy, possibly breaking even the parts that do work, but the fact that it's not consistently reproducible means that you're doing the proper debugging already. - Melanie On 10/04/2014 17:52, James Stallings II wrote: > So, Melanie, I'll bite: What do you suggest for 'proper debugging' in this > context? > > > On Thu, Apr 10, 2014 at 10:25 AM, James Stallings II < > james.stallings at gmail.com> wrote: > >> The only code I'm affecting the local copy on my server; it isn't as if >> I'm going to break break the central repo back to 2006. Hell, I don't even >> have commit. And FWIW, last I hear adding log statements to code is a valid >> tried and true debugging method. >> >> >> >> >> >> >> On Thu, Apr 10, 2014 at 10:23 AM, Melanie wrote: >> >>> I'm not even being defensive. I just don't like the idea of poking >>> code with a sharp stick instead of debugging it properly. >>> >>> - Melanie >>> >>> On 10/04/2014 17:20, James Stallings II wrote: >>> > "Maybe a good starting point is to see what you would like that doesnt' >>> > work before you go and fix things that..." >>> > >>> > Actually, that *is* where I began. >>> > >>> > My user reports various failures, which are repeatable on the running >>> > regions. No amount of reconfiguration predictably affects the >>> experience on >>> > the regions. >>> > >>> > We do have a couple of regions that seem to work perfectly, including >>> that >>> > which I'm working with; it started working after I completely replaced >>> the >>> > OpenSim.ini with one that was identical excepting the http_listener >>> > specifcation. Unfortunately, repeating this process with the same >>> > OpenSim.ini on a different region that doesn't work did not produce a >>> > region that does. >>> > >>> > To say that it works intermittently is a bit of an understatement; >>> though >>> > it does seem that once it begins working it continues to do so. >>> > >>> > >>> > Try not to be so defensive Mel; I'm not attacking you or your work, I'm >>> > just attempting to figure out what's happening on these regions. I have >>> > eliminated everything I can find but the code, which I am told by >>> others is >>> > not to be trusted as fully functional; and I am not afraid to get in and >>> > get my hands dirty. >>> > >>> > >>> > Cheers >>> > James >>> > >>> > >>> > >>> > On Thu, Apr 10, 2014 at 10:10 AM, Melanie wrote: >>> > >>> >> The code for parcel access works, as far as I'm aware. It was >>> >> originally fixed in Avination and that should have been donated to >>> >> OpenSim a long time ago. Maybe a good starting point is to see what >>> >> you would like that doesnt' work before you go and fix things that >>> >> aren't broken. >>> >> >>> >> Melanie >>> >> >>> >> >>> >> On 10/04/2014 17:05, James Stallings II wrote: >>> >> > Subsequent work (instrumentation to Scene) shows that the permissions >>> >> > checking code is also being called twice there. >>> >> > >>> >> > Cheers >>> >> > James >>> >> > >>> >> > >>> >> > >>> >> > On Thu, Apr 10, 2014 at 9:30 AM, James Stallings II < >>> >> > james.stallings at gmail.com> wrote: >>> >> > >>> >> >> After some further exploration, I have seen where the method calls >>> >> taking >>> >> >> precedence from out of Scene are handling ViaLogin; but they are >>> also >>> >> doing >>> >> >> some of the same lifting performed in the Land Management module. >>> This >>> >> >> seems to be duplication of effort, if not duplication of code; and >>> is >>> >> >> certainly less elegant than I would hope to find in our codebase >>> (in an >>> >> >> ideal world ;) >>> >> >> >>> >> >> This is likely the result of the ad-hoc nature of the development >>> life >>> >> of >>> >> >> the project over the years; I can see the scene code being a good >>> deal >>> >> >> older than the Land Management module. >>> >> >> >>> >> >> I'll be working with this throughout the day, hoping to improve the >>> code >>> >> >> as I'm able; your thoughts, advice and commentary are solicited and >>> >> >> appreciated. >>> >> >> >>> >> >> Cheers >>> >> >> James >>> >> >> >>> >> >> >>> >> >> >>> >> >> On Thu, Apr 10, 2014 at 9:01 AM, James Stallings II < >>> >> >> james.stallings at gmail.com> wrote: >>> >> >> >>> >> >>> Greetings Devs :) >>> >> >>> >>> >> >>> I have a use case that requires the unlikely and less than popular >>> >> parcel >>> >> >>> permissions access control featureset. >>> >> >>> >>> >> >>> Historically speaking, this has not been an area of development >>> that >>> >> has >>> >> >>> seen much love, and understandably so; none of us are particularly >>> >> >>> interested in fully duplicating the operational envelope of the >>> Second >>> >> Life >>> >> >>> experience. That coupled with the ability to deploy regions at >>> whim, >>> >> it is >>> >> >>> no wonder no one wants to involve themselves particularly deeply >>> with >>> >> >>> making this work properly. >>> >> >>> >>> >> >>> That being said, I have a need at present, and there is also the >>> simple >>> >> >>> fact that we have a dearth of UI components in the viewer we may >>> well >>> >> never >>> >> >>> get shut of, and a lot of of unfinished and/or unpolished code in >>> the >>> >> repo >>> >> >>> that touches on this functionality. >>> >> >>> >>> >> >>> The short story is, it may be above the waterline, but there is a >>> hole >>> >> in >>> >> >>> the boat, and one of my users is driving it headlong into the surf. >>> >> >>> >>> >> >>> So much for metaphors. >>> >> >>> >>> >> >>> I have heard a variety of conflicting reports about the state of >>> this >>> >> >>> part of the codebase; some say it works well; others say it should >>> not >>> >> be >>> >> >>> counted on to work at all. The commit logs tell the tale that some >>> have >>> >> >>> taken an interest and are working diligently to eliminate certain >>> bugs; >>> >> >>> unfortunately, the work in progress has not yet brought the >>> >> functionality >>> >> >>> into a state where it is yet useful, at least according to my >>> testing. >>> >> >>> >>> >> >>> I'm not unwilling to undertake the work needed to bring this >>> situation >>> >> >>> into a more satisfactory light; indeed, I've already begun, and I >>> need >>> >> only >>> >> >>> a little guidance today. >>> >> >>> >>> >> >>> I have thoroughly instrumented the method "public void >>> >> >>> EventManagerOnAvatarEnteringNewParcel(ScenePresence avatar, int >>> >> >>> localLandID, UUID regionID)" >>> >> >>> in the land management module, and was immediately confronted with >>> a >>> >> >>> couple of surprises: >>> >> >>> First, when the code is called at all, it is called twice; and as >>> far >>> >> as >>> >> >>> I can tell, it is called only after a successful login has been >>> >> completed. >>> >> >>> Neither does it seem to be called when an avatar teleports into the >>> >> region. >>> >> >>> >>> >> >>> Instead, the method "public bool TestLandRestrictions(UUID >>> agentID, out >>> >> >>> string reason, ref float posX, ref float posY)" is called from >>> >> >>> "OpenSim/Region/Framework/Scenes/Scene.cs" and >>> >> >>> "OpenSim/Region/Framework/Scenes/ScenePresence.cs", and mediates >>> >> (rather >>> >> >>> less than consistently) whether the avatar is allowed into the >>> parcel >>> >> on >>> >> >>> the region. >>> >> >>> >>> >> >>> Being aware that there are several ways for an avatar to enter a >>> >> parcel, >>> >> >>> which I will leave off enumerating at present, I would suggest that >>> >> perhaps >>> >> >>> I have some misapprehensions as to the proper stages of >>> authentication >>> >> at >>> >> >>> login-time. >>> >> >>> >>> >> >>> So my question is this: should both of these functions come into >>> play >>> >> as >>> >> >>> an avatar enters a region (and consequently, a parcel)? or should >>> >> there be >>> >> >>> a single methoid conducting these presence permission checks? >>> >> >>> >>> >> >>> Please advise at your convenience :) >>> >> >>> >>> >> >>> Many thanks and cheers >>> >> >>> James/Hiro >>> >> >>> >>> >> >>> >>> >> >>> -- >>> >> >>> =================================== >>> >> >>> http://osgrid.org/ >>> >> >>> http://simhost.com >>> >> >>> http://twitter.com/jstallings2 >>> >> >>> >>> >> >>> >>> >> >> >>> >> >> >>> >> >> -- >>> >> >> =================================== >>> >> >> http://osgrid.org/ >>> >> >> http://simhost.com >>> >> >> http://twitter.com/jstallings2 >>> >> >> >>> >> >> >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > _______________________________________________ >>> >> > Opensim-dev mailing list >>> >> > Opensim-dev at lists.berlios.de >>> >> > https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> _______________________________________________ >>> >> Opensim-dev mailing list >>> >> Opensim-dev at lists.berlios.de >>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >>> > >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > Opensim-dev mailing list >>> > Opensim-dev at lists.berlios.de >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >> >> >> -- >> =================================== >> http://osgrid.org/ >> http://simhost.com >> http://twitter.com/jstallings2 >> >> > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev From rknop at pobox.com Thu Apr 10 15:59:01 2014 From: rknop at pobox.com (Robert A. Knop Jr.) Date: Thu, 10 Apr 2014 08:59:01 -0700 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> Message-ID: <20140410155900.GA3167@schumann> On Thu, Apr 10, 2014 at 10:25:17AM -0500, James Stallings II wrote: > And FWIW, last I hear adding log statements to code is a valid > tried and true debugging method. I wish to subscribe all of my students in my programming class to your newsletter. (The number of times I told them to print stuff to figure out where the code was, and the number of times I told them to print in more places, was phenomenal. They got tired of hearing me say it, but somehow still needed to hear it.) (They often needed similar guidance in figuring out how to use breakpoints in debuggers.) -Rob -- --Rob Knop E-mail: rknop at pobox.com Home Page: http://www.pobox.com/~rknop/ Blog: http://www.galacticinteractions.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 828 bytes Desc: Digital signature URL: From james.stallings at gmail.com Thu Apr 10 16:07:27 2014 From: james.stallings at gmail.com (James Stallings II) Date: Thu, 10 Apr 2014 11:07:27 -0500 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: <5346BF33.80203@t-data.com> References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> <5346BF33.80203@t-data.com> Message-ID: Thanks, I appreciate that :) Don't worry about a refactoring effort. I'm very much aware that Scene and ScenePresence are complicated beyond my understanding (this is why I brought the matter to the list) and am not about to call for much of anything except expert advice. For now, my focus is on determining first why the two authentication methods are each called twice; and then (and only then! ;) will I try to make some determination as to whether it's right and proper that they should. One thing I had tried earlier (and this is more in line with poking things with sticks) is to comment out the calls to TestLandRestrictions in scene, to attempt letting the Land Management module to bear the full responsibility of authenticating the inbound avatar. This kind of worked; the avatar was allowed into the parcel, but was warned that he was banned and should leave immediately. No other enforcement of access took place. This is what brought me to the understanding of the ViaLogin subtlety, and so I returned those calls in scene to their proper places. It occurs to me that scene might be modified slightly to rely on the Land Management module for access permisison enforcement, but I already suspect that this would not be productive for reasons that I have not yet been able to fully articulate to myself. The hunt continues. I do appreciate what you do Melanie, and I do appreciate it when you help me. Cheers! James On Thu, Apr 10, 2014 at 10:56 AM, Melanie wrote: > No biting needed :) > > Debug output is a pretty good start and you did answer my concern > when you mentioned the intermittent nature of the issue. > I was worried that this would lead to a refactoring frenzy, possibly > breaking even the parts that do work, but the fact that it's not > consistently reproducible means that you're doing the proper > debugging already. > > - Melanie > > On 10/04/2014 17:52, James Stallings II wrote: > > So, Melanie, I'll bite: What do you suggest for 'proper debugging' in > this > > context? > > > > > > On Thu, Apr 10, 2014 at 10:25 AM, James Stallings II < > > james.stallings at gmail.com> wrote: > > > >> The only code I'm affecting the local copy on my server; it isn't as if > >> I'm going to break break the central repo back to 2006. Hell, I don't > even > >> have commit. And FWIW, last I hear adding log statements to code is a > valid > >> tried and true debugging method. > >> > >> > >> > >> > >> > >> > >> On Thu, Apr 10, 2014 at 10:23 AM, Melanie wrote: > >> > >>> I'm not even being defensive. I just don't like the idea of poking > >>> code with a sharp stick instead of debugging it properly. > >>> > >>> - Melanie > >>> > >>> On 10/04/2014 17:20, James Stallings II wrote: > >>> > "Maybe a good starting point is to see what you would like that > doesnt' > >>> > work before you go and fix things that..." > >>> > > >>> > Actually, that *is* where I began. > >>> > > >>> > My user reports various failures, which are repeatable on the running > >>> > regions. No amount of reconfiguration predictably affects the > >>> experience on > >>> > the regions. > >>> > > >>> > We do have a couple of regions that seem to work perfectly, including > >>> that > >>> > which I'm working with; it started working after I completely > replaced > >>> the > >>> > OpenSim.ini with one that was identical excepting the http_listener > >>> > specifcation. Unfortunately, repeating this process with the same > >>> > OpenSim.ini on a different region that doesn't work did not produce a > >>> > region that does. > >>> > > >>> > To say that it works intermittently is a bit of an understatement; > >>> though > >>> > it does seem that once it begins working it continues to do so. > >>> > > >>> > > >>> > Try not to be so defensive Mel; I'm not attacking you or your work, > I'm > >>> > just attempting to figure out what's happening on these regions. I > have > >>> > eliminated everything I can find but the code, which I am told by > >>> others is > >>> > not to be trusted as fully functional; and I am not afraid to get in > and > >>> > get my hands dirty. > >>> > > >>> > > >>> > Cheers > >>> > James > >>> > > >>> > > >>> > > >>> > On Thu, Apr 10, 2014 at 10:10 AM, Melanie > wrote: > >>> > > >>> >> The code for parcel access works, as far as I'm aware. It was > >>> >> originally fixed in Avination and that should have been donated to > >>> >> OpenSim a long time ago. Maybe a good starting point is to see what > >>> >> you would like that doesnt' work before you go and fix things that > >>> >> aren't broken. > >>> >> > >>> >> Melanie > >>> >> > >>> >> > >>> >> On 10/04/2014 17:05, James Stallings II wrote: > >>> >> > Subsequent work (instrumentation to Scene) shows that the > permissions > >>> >> > checking code is also being called twice there. > >>> >> > > >>> >> > Cheers > >>> >> > James > >>> >> > > >>> >> > > >>> >> > > >>> >> > On Thu, Apr 10, 2014 at 9:30 AM, James Stallings II < > >>> >> > james.stallings at gmail.com> wrote: > >>> >> > > >>> >> >> After some further exploration, I have seen where the method > calls > >>> >> taking > >>> >> >> precedence from out of Scene are handling ViaLogin; but they are > >>> also > >>> >> doing > >>> >> >> some of the same lifting performed in the Land Management module. > >>> This > >>> >> >> seems to be duplication of effort, if not duplication of code; > and > >>> is > >>> >> >> certainly less elegant than I would hope to find in our codebase > >>> (in an > >>> >> >> ideal world ;) > >>> >> >> > >>> >> >> This is likely the result of the ad-hoc nature of the development > >>> life > >>> >> of > >>> >> >> the project over the years; I can see the scene code being a good > >>> deal > >>> >> >> older than the Land Management module. > >>> >> >> > >>> >> >> I'll be working with this throughout the day, hoping to improve > the > >>> code > >>> >> >> as I'm able; your thoughts, advice and commentary are solicited > and > >>> >> >> appreciated. > >>> >> >> > >>> >> >> Cheers > >>> >> >> James > >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> On Thu, Apr 10, 2014 at 9:01 AM, James Stallings II < > >>> >> >> james.stallings at gmail.com> wrote: > >>> >> >> > >>> >> >>> Greetings Devs :) > >>> >> >>> > >>> >> >>> I have a use case that requires the unlikely and less than > popular > >>> >> parcel > >>> >> >>> permissions access control featureset. > >>> >> >>> > >>> >> >>> Historically speaking, this has not been an area of development > >>> that > >>> >> has > >>> >> >>> seen much love, and understandably so; none of us are > particularly > >>> >> >>> interested in fully duplicating the operational envelope of the > >>> Second > >>> >> Life > >>> >> >>> experience. That coupled with the ability to deploy regions at > >>> whim, > >>> >> it is > >>> >> >>> no wonder no one wants to involve themselves particularly deeply > >>> with > >>> >> >>> making this work properly. > >>> >> >>> > >>> >> >>> That being said, I have a need at present, and there is also the > >>> simple > >>> >> >>> fact that we have a dearth of UI components in the viewer we may > >>> well > >>> >> never > >>> >> >>> get shut of, and a lot of of unfinished and/or unpolished code > in > >>> the > >>> >> repo > >>> >> >>> that touches on this functionality. > >>> >> >>> > >>> >> >>> The short story is, it may be above the waterline, but there is > a > >>> hole > >>> >> in > >>> >> >>> the boat, and one of my users is driving it headlong into the > surf. > >>> >> >>> > >>> >> >>> So much for metaphors. > >>> >> >>> > >>> >> >>> I have heard a variety of conflicting reports about the state of > >>> this > >>> >> >>> part of the codebase; some say it works well; others say it > should > >>> not > >>> >> be > >>> >> >>> counted on to work at all. The commit logs tell the tale that > some > >>> have > >>> >> >>> taken an interest and are working diligently to eliminate > certain > >>> bugs; > >>> >> >>> unfortunately, the work in progress has not yet brought the > >>> >> functionality > >>> >> >>> into a state where it is yet useful, at least according to my > >>> testing. > >>> >> >>> > >>> >> >>> I'm not unwilling to undertake the work needed to bring this > >>> situation > >>> >> >>> into a more satisfactory light; indeed, I've already begun, and > I > >>> need > >>> >> only > >>> >> >>> a little guidance today. > >>> >> >>> > >>> >> >>> I have thoroughly instrumented the method "public void > >>> >> >>> EventManagerOnAvatarEnteringNewParcel(ScenePresence avatar, int > >>> >> >>> localLandID, UUID regionID)" > >>> >> >>> in the land management module, and was immediately confronted > with > >>> a > >>> >> >>> couple of surprises: > >>> >> >>> First, when the code is called at all, it is called twice; and > as > >>> far > >>> >> as > >>> >> >>> I can tell, it is called only after a successful login has been > >>> >> completed. > >>> >> >>> Neither does it seem to be called when an avatar teleports into > the > >>> >> region. > >>> >> >>> > >>> >> >>> Instead, the method "public bool TestLandRestrictions(UUID > >>> agentID, out > >>> >> >>> string reason, ref float posX, ref float posY)" is called from > >>> >> >>> "OpenSim/Region/Framework/Scenes/Scene.cs" and > >>> >> >>> "OpenSim/Region/Framework/Scenes/ScenePresence.cs", and mediates > >>> >> (rather > >>> >> >>> less than consistently) whether the avatar is allowed into the > >>> parcel > >>> >> on > >>> >> >>> the region. > >>> >> >>> > >>> >> >>> Being aware that there are several ways for an avatar to enter a > >>> >> parcel, > >>> >> >>> which I will leave off enumerating at present, I would suggest > that > >>> >> perhaps > >>> >> >>> I have some misapprehensions as to the proper stages of > >>> authentication > >>> >> at > >>> >> >>> login-time. > >>> >> >>> > >>> >> >>> So my question is this: should both of these functions come into > >>> play > >>> >> as > >>> >> >>> an avatar enters a region (and consequently, a parcel)? or > should > >>> >> there be > >>> >> >>> a single methoid conducting these presence permission checks? > >>> >> >>> > >>> >> >>> Please advise at your convenience :) > >>> >> >>> > >>> >> >>> Many thanks and cheers > >>> >> >>> James/Hiro > >>> >> >>> > >>> >> >>> > >>> >> >>> -- > >>> >> >>> =================================== > >>> >> >>> http://osgrid.org/ > >>> >> >>> http://simhost.com > >>> >> >>> http://twitter.com/jstallings2 > >>> >> >>> > >>> >> >>> > >>> >> >> > >>> >> >> > >>> >> >> -- > >>> >> >> =================================== > >>> >> >> http://osgrid.org/ > >>> >> >> http://simhost.com > >>> >> >> http://twitter.com/jstallings2 > >>> >> >> > >>> >> >> > >>> >> > > >>> >> > > >>> >> > > >>> >> > > >>> >> > _______________________________________________ > >>> >> > Opensim-dev mailing list > >>> >> > Opensim-dev at lists.berlios.de > >>> >> > https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> >> _______________________________________________ > >>> >> Opensim-dev mailing list > >>> >> Opensim-dev at lists.berlios.de > >>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> >> > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > _______________________________________________ > >>> > Opensim-dev mailing list > >>> > Opensim-dev at lists.berlios.de > >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> _______________________________________________ > >>> Opensim-dev mailing list > >>> Opensim-dev at lists.berlios.de > >>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> > >> > >> > >> > >> -- > >> =================================== > >> http://osgrid.org/ > >> http://simhost.com > >> http://twitter.com/jstallings2 > >> > >> > > > > > > > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.stallings at gmail.com Thu Apr 10 16:14:59 2014 From: james.stallings at gmail.com (James Stallings II) Date: Thu, 10 Apr 2014 11:14:59 -0500 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: <20140410155900.GA3167@schumann> References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> <20140410155900.GA3167@schumann> Message-ID: It would seem that the two invocations of the TestLandRestrictions method in Scene occur in each of NewUserConnection and QueryAccess. EventManagerOnAvatarEnteringNewParcel is, fairly obviously, and event callback method; at this point I don't have but a guess where this might be called excepting from within EventManagerOnSignificantClientMovement. I'd like to think that the two calls to TestLandRestrictions in Scene might be reduced to one; but I'm not yet convinced it is the way to go. More to follow. Cheers On Thu, Apr 10, 2014 at 10:59 AM, Robert A. Knop Jr. wrote: > On Thu, Apr 10, 2014 at 10:25:17AM -0500, James Stallings II wrote: > > And FWIW, last I hear adding log statements to code is a valid > > tried and true debugging method. > > I wish to subscribe all of my students in my programming class to your > newsletter. > > (The number of times I told them to print stuff to figure out where the > code was, and the number of times I told them to print in more places, > was phenomenal. They got tired of hearing me say it, but somehow still > needed to hear it.) > > (They often needed similar guidance in figuring out how to use > breakpoints in debuggers.) > > -Rob > > -- > --Rob Knop > E-mail: rknop at pobox.com > Home Page: http://www.pobox.com/~rknop/ > Blog: http://www.galacticinteractions.org/ > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.stallings at gmail.com Thu Apr 10 16:26:45 2014 From: james.stallings at gmail.com (James Stallings II) Date: Thu, 10 Apr 2014 11:26:45 -0500 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> <20140410155900.GA3167@schumann> Message-ID: One thing that may be happening is that our test is illuminating an edge case: there is only the default parcel on the region, and as a result, there is no 'nearest safe place/target' to which to move the banned avatar; that would involve a teleport off the region. On Thu, Apr 10, 2014 at 11:14 AM, James Stallings II < james.stallings at gmail.com> wrote: > It would seem that the two invocations of the TestLandRestrictions method > in Scene occur in each of NewUserConnection and > QueryAccess. EventManagerOnAvatarEnteringNewParcel is, fairly obviously, > and event callback method; at this point I don't have but a guess where > this might be called excepting from > within EventManagerOnSignificantClientMovement. > > I'd like to think that the two calls to TestLandRestrictions in Scene > might be reduced to one; but I'm not yet convinced it is the way to go. > > More to follow. > > Cheers > > > > On Thu, Apr 10, 2014 at 10:59 AM, Robert A. Knop Jr. wrote: > >> On Thu, Apr 10, 2014 at 10:25:17AM -0500, James Stallings II wrote: >> > And FWIW, last I hear adding log statements to code is a valid >> > tried and true debugging method. >> >> I wish to subscribe all of my students in my programming class to your >> newsletter. >> >> (The number of times I told them to print stuff to figure out where the >> code was, and the number of times I told them to print in more places, >> was phenomenal. They got tired of hearing me say it, but somehow still >> needed to hear it.) >> >> (They often needed similar guidance in figuring out how to use >> breakpoints in debuggers.) >> >> -Rob >> >> -- >> --Rob Knop >> E-mail: rknop at pobox.com >> Home Page: http://www.pobox.com/~rknop/ >> Blog: http://www.galacticinteractions.org/ >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > -- > =================================== > http://osgrid.org/ > http://simhost.com > http://twitter.com/jstallings2 > > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From melanie at t-data.com Thu Apr 10 16:29:32 2014 From: melanie at t-data.com (Melanie) Date: Thu, 10 Apr 2014 18:29:32 +0200 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> <20140410155900.GA3167@schumann> Message-ID: <5346C6EC.9080906@t-data.com> The QueryAccess is a pre-authorization. So the double call is intentional and unavoidable. - Melanie On 10/04/2014 18:14, James Stallings II wrote: > It would seem that the two invocations of the TestLandRestrictions method > in Scene occur in each of NewUserConnection and > QueryAccess. EventManagerOnAvatarEnteringNewParcel is, fairly obviously, > and event callback method; at this point I don't have but a guess where > this might be called excepting from > within EventManagerOnSignificantClientMovement. > > I'd like to think that the two calls to TestLandRestrictions in Scene might > be reduced to one; but I'm not yet convinced it is the way to go. > > More to follow. > > Cheers > > > > On Thu, Apr 10, 2014 at 10:59 AM, Robert A. Knop Jr. wrote: > >> On Thu, Apr 10, 2014 at 10:25:17AM -0500, James Stallings II wrote: >> > And FWIW, last I hear adding log statements to code is a valid >> > tried and true debugging method. >> >> I wish to subscribe all of my students in my programming class to your >> newsletter. >> >> (The number of times I told them to print stuff to figure out where the >> code was, and the number of times I told them to print in more places, >> was phenomenal. They got tired of hearing me say it, but somehow still >> needed to hear it.) >> >> (They often needed similar guidance in figuring out how to use >> breakpoints in debuggers.) >> >> -Rob >> >> -- >> --Rob Knop >> E-mail: rknop at pobox.com >> Home Page: http://www.pobox.com/~rknop/ >> Blog: http://www.galacticinteractions.org/ >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev From james.stallings at gmail.com Thu Apr 10 16:30:46 2014 From: james.stallings at gmail.com (James Stallings II) Date: Thu, 10 Apr 2014 11:30:46 -0500 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: <5346C6EC.9080906@t-data.com> References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> <20140410155900.GA3167@schumann> <5346C6EC.9080906@t-data.com> Message-ID: I kinder suspected something to that effect. It goes without saying that a lot occurs during the login process than is immediately apparent when one sits and watches the consoles. Right now I'm leaning towards the previously-mentioned edge case. On Thu, Apr 10, 2014 at 11:29 AM, Melanie wrote: > The QueryAccess is a pre-authorization. So the double call is > intentional and unavoidable. > > - Melanie > > On 10/04/2014 18:14, James Stallings II wrote: > > It would seem that the two invocations of the TestLandRestrictions method > > in Scene occur in each of NewUserConnection and > > QueryAccess. EventManagerOnAvatarEnteringNewParcel is, fairly obviously, > > and event callback method; at this point I don't have but a guess where > > this might be called excepting from > > within EventManagerOnSignificantClientMovement. > > > > I'd like to think that the two calls to TestLandRestrictions in Scene > might > > be reduced to one; but I'm not yet convinced it is the way to go. > > > > More to follow. > > > > Cheers > > > > > > > > On Thu, Apr 10, 2014 at 10:59 AM, Robert A. Knop Jr. >wrote: > > > >> On Thu, Apr 10, 2014 at 10:25:17AM -0500, James Stallings II wrote: > >> > And FWIW, last I hear adding log statements to code is a valid > >> > tried and true debugging method. > >> > >> I wish to subscribe all of my students in my programming class to your > >> newsletter. > >> > >> (The number of times I told them to print stuff to figure out where the > >> code was, and the number of times I told them to print in more places, > >> was phenomenal. They got tired of hearing me say it, but somehow still > >> needed to hear it.) > >> > >> (They often needed similar guidance in figuring out how to use > >> breakpoints in debuggers.) > >> > >> -Rob > >> > >> -- > >> --Rob Knop > >> E-mail: rknop at pobox.com > >> Home Page: http://www.pobox.com/~rknop/ > >> Blog: http://www.galacticinteractions.org/ > >> > >> _______________________________________________ > >> Opensim-dev mailing list > >> Opensim-dev at lists.berlios.de > >> https://lists.berlios.de/mailman/listinfo/opensim-dev > >> > > > > > > > > > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.stallings at gmail.com Thu Apr 10 16:33:40 2014 From: james.stallings at gmail.com (James Stallings II) Date: Thu, 10 Apr 2014 11:33:40 -0500 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> <20140410155900.GA3167@schumann> <5346C6EC.9080906@t-data.com> Message-ID: Quick question (related) is there a configuration point I'm missing that enables 'forceful bans'? On Thu, Apr 10, 2014 at 11:30 AM, James Stallings II < james.stallings at gmail.com> wrote: > I kinder suspected something to that effect. It goes without saying that a > lot occurs during the login process than is immediately apparent when one > sits and watches the consoles. > > Right now I'm leaning towards the previously-mentioned edge case. > > > On Thu, Apr 10, 2014 at 11:29 AM, Melanie wrote: > >> The QueryAccess is a pre-authorization. So the double call is >> intentional and unavoidable. >> >> - Melanie >> >> On 10/04/2014 18:14, James Stallings II wrote: >> > It would seem that the two invocations of the TestLandRestrictions >> method >> > in Scene occur in each of NewUserConnection and >> > QueryAccess. EventManagerOnAvatarEnteringNewParcel is, fairly obviously, >> > and event callback method; at this point I don't have but a guess where >> > this might be called excepting from >> > within EventManagerOnSignificantClientMovement. >> > >> > I'd like to think that the two calls to TestLandRestrictions in Scene >> might >> > be reduced to one; but I'm not yet convinced it is the way to go. >> > >> > More to follow. >> > >> > Cheers >> > >> > >> > >> > On Thu, Apr 10, 2014 at 10:59 AM, Robert A. Knop Jr. > >wrote: >> > >> >> On Thu, Apr 10, 2014 at 10:25:17AM -0500, James Stallings II wrote: >> >> > And FWIW, last I hear adding log statements to code is a valid >> >> > tried and true debugging method. >> >> >> >> I wish to subscribe all of my students in my programming class to your >> >> newsletter. >> >> >> >> (The number of times I told them to print stuff to figure out where the >> >> code was, and the number of times I told them to print in more places, >> >> was phenomenal. They got tired of hearing me say it, but somehow still >> >> needed to hear it.) >> >> >> >> (They often needed similar guidance in figuring out how to use >> >> breakpoints in debuggers.) >> >> >> >> -Rob >> >> >> >> -- >> >> --Rob Knop >> >> E-mail: rknop at pobox.com >> >> Home Page: http://www.pobox.com/~rknop/ >> >> Blog: http://www.galacticinteractions.org/ >> >> >> >> _______________________________________________ >> >> Opensim-dev mailing list >> >> Opensim-dev at lists.berlios.de >> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> >> > >> > >> > >> > >> > >> > _______________________________________________ >> > Opensim-dev mailing list >> > Opensim-dev at lists.berlios.de >> > https://lists.berlios.de/mailman/listinfo/opensim-dev >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > -- > =================================== > http://osgrid.org/ > http://simhost.com > http://twitter.com/jstallings2 > > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From melanie at t-data.com Thu Apr 10 16:37:01 2014 From: melanie at t-data.com (Melanie) Date: Thu, 10 Apr 2014 18:37:01 +0200 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> <20140410155900.GA3167@schumann> <5346C6EC.9080906@t-data.com> Message-ID: <5346C8AD.5000809@t-data.com> Yes. allow_forceful_banlines, I believe. Long time since I looked at it. - Melanie On 10/04/2014 18:33, James Stallings II wrote: > Quick question (related) is there a configuration point I'm missing that > enables 'forceful bans'? > > > > On Thu, Apr 10, 2014 at 11:30 AM, James Stallings II < > james.stallings at gmail.com> wrote: > >> I kinder suspected something to that effect. It goes without saying that a >> lot occurs during the login process than is immediately apparent when one >> sits and watches the consoles. >> >> Right now I'm leaning towards the previously-mentioned edge case. >> >> >> On Thu, Apr 10, 2014 at 11:29 AM, Melanie wrote: >> >>> The QueryAccess is a pre-authorization. So the double call is >>> intentional and unavoidable. >>> >>> - Melanie >>> >>> On 10/04/2014 18:14, James Stallings II wrote: >>> > It would seem that the two invocations of the TestLandRestrictions >>> method >>> > in Scene occur in each of NewUserConnection and >>> > QueryAccess. EventManagerOnAvatarEnteringNewParcel is, fairly obviously, >>> > and event callback method; at this point I don't have but a guess where >>> > this might be called excepting from >>> > within EventManagerOnSignificantClientMovement. >>> > >>> > I'd like to think that the two calls to TestLandRestrictions in Scene >>> might >>> > be reduced to one; but I'm not yet convinced it is the way to go. >>> > >>> > More to follow. >>> > >>> > Cheers >>> > >>> > >>> > >>> > On Thu, Apr 10, 2014 at 10:59 AM, Robert A. Knop Jr. >> >wrote: >>> > >>> >> On Thu, Apr 10, 2014 at 10:25:17AM -0500, James Stallings II wrote: >>> >> > And FWIW, last I hear adding log statements to code is a valid >>> >> > tried and true debugging method. >>> >> >>> >> I wish to subscribe all of my students in my programming class to your >>> >> newsletter. >>> >> >>> >> (The number of times I told them to print stuff to figure out where the >>> >> code was, and the number of times I told them to print in more places, >>> >> was phenomenal. They got tired of hearing me say it, but somehow still >>> >> needed to hear it.) >>> >> >>> >> (They often needed similar guidance in figuring out how to use >>> >> breakpoints in debuggers.) >>> >> >>> >> -Rob >>> >> >>> >> -- >>> >> --Rob Knop >>> >> E-mail: rknop at pobox.com >>> >> Home Page: http://www.pobox.com/~rknop/ >>> >> Blog: http://www.galacticinteractions.org/ >>> >> >>> >> _______________________________________________ >>> >> Opensim-dev mailing list >>> >> Opensim-dev at lists.berlios.de >>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >>> > >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > Opensim-dev mailing list >>> > Opensim-dev at lists.berlios.de >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >> >> >> -- >> =================================== >> http://osgrid.org/ >> http://simhost.com >> http://twitter.com/jstallings2 >> >> > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev From james.stallings at gmail.com Thu Apr 10 16:37:59 2014 From: james.stallings at gmail.com (James Stallings II) Date: Thu, 10 Apr 2014 11:37:59 -0500 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: <5346C8AD.5000809@t-data.com> References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> <20140410155900.GA3167@schumann> <5346C6EC.9080906@t-data.com> <5346C8AD.5000809@t-data.com> Message-ID: I thought I recalled such a thing, been about as long since I looked at it ;) Thanks Mel James On Thu, Apr 10, 2014 at 11:37 AM, Melanie wrote: > Yes. allow_forceful_banlines, I believe. Long time since I looked at it. > > - Melanie > > On 10/04/2014 18:33, James Stallings II wrote: > > Quick question (related) is there a configuration point I'm missing that > > enables 'forceful bans'? > > > > > > > > On Thu, Apr 10, 2014 at 11:30 AM, James Stallings II < > > james.stallings at gmail.com> wrote: > > > >> I kinder suspected something to that effect. It goes without saying > that a > >> lot occurs during the login process than is immediately apparent when > one > >> sits and watches the consoles. > >> > >> Right now I'm leaning towards the previously-mentioned edge case. > >> > >> > >> On Thu, Apr 10, 2014 at 11:29 AM, Melanie wrote: > >> > >>> The QueryAccess is a pre-authorization. So the double call is > >>> intentional and unavoidable. > >>> > >>> - Melanie > >>> > >>> On 10/04/2014 18:14, James Stallings II wrote: > >>> > It would seem that the two invocations of the TestLandRestrictions > >>> method > >>> > in Scene occur in each of NewUserConnection and > >>> > QueryAccess. EventManagerOnAvatarEnteringNewParcel is, fairly > obviously, > >>> > and event callback method; at this point I don't have but a guess > where > >>> > this might be called excepting from > >>> > within EventManagerOnSignificantClientMovement. > >>> > > >>> > I'd like to think that the two calls to TestLandRestrictions in Scene > >>> might > >>> > be reduced to one; but I'm not yet convinced it is the way to go. > >>> > > >>> > More to follow. > >>> > > >>> > Cheers > >>> > > >>> > > >>> > > >>> > On Thu, Apr 10, 2014 at 10:59 AM, Robert A. Knop Jr. < > rknop at pobox.com > >>> >wrote: > >>> > > >>> >> On Thu, Apr 10, 2014 at 10:25:17AM -0500, James Stallings II wrote: > >>> >> > And FWIW, last I hear adding log statements to code is a valid > >>> >> > tried and true debugging method. > >>> >> > >>> >> I wish to subscribe all of my students in my programming class to > your > >>> >> newsletter. > >>> >> > >>> >> (The number of times I told them to print stuff to figure out where > the > >>> >> code was, and the number of times I told them to print in more > places, > >>> >> was phenomenal. They got tired of hearing me say it, but somehow > still > >>> >> needed to hear it.) > >>> >> > >>> >> (They often needed similar guidance in figuring out how to use > >>> >> breakpoints in debuggers.) > >>> >> > >>> >> -Rob > >>> >> > >>> >> -- > >>> >> --Rob Knop > >>> >> E-mail: rknop at pobox.com > >>> >> Home Page: http://www.pobox.com/~rknop/ > >>> >> Blog: http://www.galacticinteractions.org/ > >>> >> > >>> >> _______________________________________________ > >>> >> Opensim-dev mailing list > >>> >> Opensim-dev at lists.berlios.de > >>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> >> > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > _______________________________________________ > >>> > Opensim-dev mailing list > >>> > Opensim-dev at lists.berlios.de > >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> _______________________________________________ > >>> Opensim-dev mailing list > >>> Opensim-dev at lists.berlios.de > >>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> > >> > >> > >> > >> -- > >> =================================== > >> http://osgrid.org/ > >> http://simhost.com > >> http://twitter.com/jstallings2 > >> > >> > > > > > > > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.stallings at gmail.com Thu Apr 10 16:43:15 2014 From: james.stallings at gmail.com (James Stallings II) Date: Thu, 10 Apr 2014 11:43:15 -0500 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> <20140410155900.GA3167@schumann> <5346C6EC.9080906@t-data.com> <5346C8AD.5000809@t-data.com> Message-ID: Mel, cant get a grep on allow_f* anywhere in the source tree, looks like it has gone the way of the elves On Thu, Apr 10, 2014 at 11:37 AM, James Stallings II < james.stallings at gmail.com> wrote: > I thought I recalled such a thing, been about as long since I looked at it > ;) > > Thanks Mel > > > James > > > > On Thu, Apr 10, 2014 at 11:37 AM, Melanie wrote: > >> Yes. allow_forceful_banlines, I believe. Long time since I looked at it. >> >> - Melanie >> >> On 10/04/2014 18:33, James Stallings II wrote: >> > Quick question (related) is there a configuration point I'm missing that >> > enables 'forceful bans'? >> > >> > >> > >> > On Thu, Apr 10, 2014 at 11:30 AM, James Stallings II < >> > james.stallings at gmail.com> wrote: >> > >> >> I kinder suspected something to that effect. It goes without saying >> that a >> >> lot occurs during the login process than is immediately apparent when >> one >> >> sits and watches the consoles. >> >> >> >> Right now I'm leaning towards the previously-mentioned edge case. >> >> >> >> >> >> On Thu, Apr 10, 2014 at 11:29 AM, Melanie wrote: >> >> >> >>> The QueryAccess is a pre-authorization. So the double call is >> >>> intentional and unavoidable. >> >>> >> >>> - Melanie >> >>> >> >>> On 10/04/2014 18:14, James Stallings II wrote: >> >>> > It would seem that the two invocations of the TestLandRestrictions >> >>> method >> >>> > in Scene occur in each of NewUserConnection and >> >>> > QueryAccess. EventManagerOnAvatarEnteringNewParcel is, fairly >> obviously, >> >>> > and event callback method; at this point I don't have but a guess >> where >> >>> > this might be called excepting from >> >>> > within EventManagerOnSignificantClientMovement. >> >>> > >> >>> > I'd like to think that the two calls to TestLandRestrictions in >> Scene >> >>> might >> >>> > be reduced to one; but I'm not yet convinced it is the way to go. >> >>> > >> >>> > More to follow. >> >>> > >> >>> > Cheers >> >>> > >> >>> > >> >>> > >> >>> > On Thu, Apr 10, 2014 at 10:59 AM, Robert A. Knop Jr. < >> rknop at pobox.com >> >>> >wrote: >> >>> > >> >>> >> On Thu, Apr 10, 2014 at 10:25:17AM -0500, James Stallings II wrote: >> >>> >> > And FWIW, last I hear adding log statements to code is a valid >> >>> >> > tried and true debugging method. >> >>> >> >> >>> >> I wish to subscribe all of my students in my programming class to >> your >> >>> >> newsletter. >> >>> >> >> >>> >> (The number of times I told them to print stuff to figure out >> where the >> >>> >> code was, and the number of times I told them to print in more >> places, >> >>> >> was phenomenal. They got tired of hearing me say it, but somehow >> still >> >>> >> needed to hear it.) >> >>> >> >> >>> >> (They often needed similar guidance in figuring out how to use >> >>> >> breakpoints in debuggers.) >> >>> >> >> >>> >> -Rob >> >>> >> >> >>> >> -- >> >>> >> --Rob Knop >> >>> >> E-mail: rknop at pobox.com >> >>> >> Home Page: http://www.pobox.com/~rknop/ >> >>> >> Blog: http://www.galacticinteractions.org/ >> >>> >> >> >>> >> _______________________________________________ >> >>> >> Opensim-dev mailing list >> >>> >> Opensim-dev at lists.berlios.de >> >>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >>> >> >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > _______________________________________________ >> >>> > Opensim-dev mailing list >> >>> > Opensim-dev at lists.berlios.de >> >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev >> >>> _______________________________________________ >> >>> Opensim-dev mailing list >> >>> Opensim-dev at lists.berlios.de >> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >>> >> >> >> >> >> >> >> >> -- >> >> =================================== >> >> http://osgrid.org/ >> >> http://simhost.com >> >> http://twitter.com/jstallings2 >> >> >> >> >> > >> > >> > >> > >> > _______________________________________________ >> > Opensim-dev mailing list >> > Opensim-dev at lists.berlios.de >> > https://lists.berlios.de/mailman/listinfo/opensim-dev >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > -- > =================================== > http://osgrid.org/ > http://simhost.com > http://twitter.com/jstallings2 > > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From melanie at t-data.com Thu Apr 10 16:45:04 2014 From: melanie at t-data.com (Melanie) Date: Thu, 10 Apr 2014 18:45:04 +0200 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> <20140410155900.GA3167@schumann> <5346C6EC.9080906@t-data.com> <5346C8AD.5000809@t-data.com> Message-ID: <5346CA90.90707@t-data.com> Why, the elves are still around! I know a couple. - Melanie On 10/04/2014 18:43, James Stallings II wrote: > Mel, cant get a grep on allow_f* anywhere in the source tree, looks like it > has gone the way of the elves > > > On Thu, Apr 10, 2014 at 11:37 AM, James Stallings II < > james.stallings at gmail.com> wrote: > >> I thought I recalled such a thing, been about as long since I looked at it >> ;) >> >> Thanks Mel >> >> >> James >> >> >> >> On Thu, Apr 10, 2014 at 11:37 AM, Melanie wrote: >> >>> Yes. allow_forceful_banlines, I believe. Long time since I looked at it. >>> >>> - Melanie >>> >>> On 10/04/2014 18:33, James Stallings II wrote: >>> > Quick question (related) is there a configuration point I'm missing that >>> > enables 'forceful bans'? >>> > >>> > >>> > >>> > On Thu, Apr 10, 2014 at 11:30 AM, James Stallings II < >>> > james.stallings at gmail.com> wrote: >>> > >>> >> I kinder suspected something to that effect. It goes without saying >>> that a >>> >> lot occurs during the login process than is immediately apparent when >>> one >>> >> sits and watches the consoles. >>> >> >>> >> Right now I'm leaning towards the previously-mentioned edge case. >>> >> >>> >> >>> >> On Thu, Apr 10, 2014 at 11:29 AM, Melanie wrote: >>> >> >>> >>> The QueryAccess is a pre-authorization. So the double call is >>> >>> intentional and unavoidable. >>> >>> >>> >>> - Melanie >>> >>> >>> >>> On 10/04/2014 18:14, James Stallings II wrote: >>> >>> > It would seem that the two invocations of the TestLandRestrictions >>> >>> method >>> >>> > in Scene occur in each of NewUserConnection and >>> >>> > QueryAccess. EventManagerOnAvatarEnteringNewParcel is, fairly >>> obviously, >>> >>> > and event callback method; at this point I don't have but a guess >>> where >>> >>> > this might be called excepting from >>> >>> > within EventManagerOnSignificantClientMovement. >>> >>> > >>> >>> > I'd like to think that the two calls to TestLandRestrictions in >>> Scene >>> >>> might >>> >>> > be reduced to one; but I'm not yet convinced it is the way to go. >>> >>> > >>> >>> > More to follow. >>> >>> > >>> >>> > Cheers >>> >>> > >>> >>> > >>> >>> > >>> >>> > On Thu, Apr 10, 2014 at 10:59 AM, Robert A. Knop Jr. < >>> rknop at pobox.com >>> >>> >wrote: >>> >>> > >>> >>> >> On Thu, Apr 10, 2014 at 10:25:17AM -0500, James Stallings II wrote: >>> >>> >> > And FWIW, last I hear adding log statements to code is a valid >>> >>> >> > tried and true debugging method. >>> >>> >> >>> >>> >> I wish to subscribe all of my students in my programming class to >>> your >>> >>> >> newsletter. >>> >>> >> >>> >>> >> (The number of times I told them to print stuff to figure out >>> where the >>> >>> >> code was, and the number of times I told them to print in more >>> places, >>> >>> >> was phenomenal. They got tired of hearing me say it, but somehow >>> still >>> >>> >> needed to hear it.) >>> >>> >> >>> >>> >> (They often needed similar guidance in figuring out how to use >>> >>> >> breakpoints in debuggers.) >>> >>> >> >>> >>> >> -Rob >>> >>> >> >>> >>> >> -- >>> >>> >> --Rob Knop >>> >>> >> E-mail: rknop at pobox.com >>> >>> >> Home Page: http://www.pobox.com/~rknop/ >>> >>> >> Blog: http://www.galacticinteractions.org/ >>> >>> >> >>> >>> >> _______________________________________________ >>> >>> >> Opensim-dev mailing list >>> >>> >> Opensim-dev at lists.berlios.de >>> >>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> >> >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > _______________________________________________ >>> >>> > Opensim-dev mailing list >>> >>> > Opensim-dev at lists.berlios.de >>> >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> _______________________________________________ >>> >>> Opensim-dev mailing list >>> >>> Opensim-dev at lists.berlios.de >>> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> >>> >> >>> >> >>> >> >>> >> -- >>> >> =================================== >>> >> http://osgrid.org/ >>> >> http://simhost.com >>> >> http://twitter.com/jstallings2 >>> >> >>> >> >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > Opensim-dev mailing list >>> > Opensim-dev at lists.berlios.de >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >> >> >> -- >> =================================== >> http://osgrid.org/ >> http://simhost.com >> http://twitter.com/jstallings2 >> >> > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev From melanie at t-data.com Thu Apr 10 16:48:26 2014 From: melanie at t-data.com (Melanie) Date: Thu, 10 Apr 2014 18:48:26 +0200 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> <20140410155900.GA3167@schumann> <5346C6EC.9080906@t-data.com> <5346C8AD.5000809@t-data.com> Message-ID: <5346CB5A.3080702@t-data.com> The setting is still there. It is defaulted to true and the code to set it from files has been removed and is dead. So bans should be forceful. - Melanie On 10/04/2014 18:43, James Stallings II wrote: > Mel, cant get a grep on allow_f* anywhere in the source tree, looks like it > has gone the way of the elves > > > On Thu, Apr 10, 2014 at 11:37 AM, James Stallings II < > james.stallings at gmail.com> wrote: > >> I thought I recalled such a thing, been about as long since I looked at it >> ;) >> >> Thanks Mel >> >> >> James >> >> >> >> On Thu, Apr 10, 2014 at 11:37 AM, Melanie wrote: >> >>> Yes. allow_forceful_banlines, I believe. Long time since I looked at it. >>> >>> - Melanie >>> >>> On 10/04/2014 18:33, James Stallings II wrote: >>> > Quick question (related) is there a configuration point I'm missing that >>> > enables 'forceful bans'? >>> > >>> > >>> > >>> > On Thu, Apr 10, 2014 at 11:30 AM, James Stallings II < >>> > james.stallings at gmail.com> wrote: >>> > >>> >> I kinder suspected something to that effect. It goes without saying >>> that a >>> >> lot occurs during the login process than is immediately apparent when >>> one >>> >> sits and watches the consoles. >>> >> >>> >> Right now I'm leaning towards the previously-mentioned edge case. >>> >> >>> >> >>> >> On Thu, Apr 10, 2014 at 11:29 AM, Melanie wrote: >>> >> >>> >>> The QueryAccess is a pre-authorization. So the double call is >>> >>> intentional and unavoidable. >>> >>> >>> >>> - Melanie >>> >>> >>> >>> On 10/04/2014 18:14, James Stallings II wrote: >>> >>> > It would seem that the two invocations of the TestLandRestrictions >>> >>> method >>> >>> > in Scene occur in each of NewUserConnection and >>> >>> > QueryAccess. EventManagerOnAvatarEnteringNewParcel is, fairly >>> obviously, >>> >>> > and event callback method; at this point I don't have but a guess >>> where >>> >>> > this might be called excepting from >>> >>> > within EventManagerOnSignificantClientMovement. >>> >>> > >>> >>> > I'd like to think that the two calls to TestLandRestrictions in >>> Scene >>> >>> might >>> >>> > be reduced to one; but I'm not yet convinced it is the way to go. >>> >>> > >>> >>> > More to follow. >>> >>> > >>> >>> > Cheers >>> >>> > >>> >>> > >>> >>> > >>> >>> > On Thu, Apr 10, 2014 at 10:59 AM, Robert A. Knop Jr. < >>> rknop at pobox.com >>> >>> >wrote: >>> >>> > >>> >>> >> On Thu, Apr 10, 2014 at 10:25:17AM -0500, James Stallings II wrote: >>> >>> >> > And FWIW, last I hear adding log statements to code is a valid >>> >>> >> > tried and true debugging method. >>> >>> >> >>> >>> >> I wish to subscribe all of my students in my programming class to >>> your >>> >>> >> newsletter. >>> >>> >> >>> >>> >> (The number of times I told them to print stuff to figure out >>> where the >>> >>> >> code was, and the number of times I told them to print in more >>> places, >>> >>> >> was phenomenal. They got tired of hearing me say it, but somehow >>> still >>> >>> >> needed to hear it.) >>> >>> >> >>> >>> >> (They often needed similar guidance in figuring out how to use >>> >>> >> breakpoints in debuggers.) >>> >>> >> >>> >>> >> -Rob >>> >>> >> >>> >>> >> -- >>> >>> >> --Rob Knop >>> >>> >> E-mail: rknop at pobox.com >>> >>> >> Home Page: http://www.pobox.com/~rknop/ >>> >>> >> Blog: http://www.galacticinteractions.org/ >>> >>> >> >>> >>> >> _______________________________________________ >>> >>> >> Opensim-dev mailing list >>> >>> >> Opensim-dev at lists.berlios.de >>> >>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> >> >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > _______________________________________________ >>> >>> > Opensim-dev mailing list >>> >>> > Opensim-dev at lists.berlios.de >>> >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> _______________________________________________ >>> >>> Opensim-dev mailing list >>> >>> Opensim-dev at lists.berlios.de >>> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> >>> >> >>> >> >>> >> >>> >> -- >>> >> =================================== >>> >> http://osgrid.org/ >>> >> http://simhost.com >>> >> http://twitter.com/jstallings2 >>> >> >>> >> >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > Opensim-dev mailing list >>> > Opensim-dev at lists.berlios.de >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >> >> >> -- >> =================================== >> http://osgrid.org/ >> http://simhost.com >> http://twitter.com/jstallings2 >> >> > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev From james.stallings at gmail.com Thu Apr 10 16:48:18 2014 From: james.stallings at gmail.com (James Stallings II) Date: Thu, 10 Apr 2014 11:48:18 -0500 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: <5346CB5A.3080702@t-data.com> References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> <20140410155900.GA3167@schumann> <5346C6EC.9080906@t-data.com> <5346C8AD.5000809@t-data.com> <5346CB5A.3080702@t-data.com> Message-ID: Fair enough, tyvm :) On Thu, Apr 10, 2014 at 11:48 AM, Melanie wrote: > The setting is still there. It is defaulted to true and the code to > set it from files has been removed and is dead. So bans should be > forceful. > > - Melanie > > On 10/04/2014 18:43, James Stallings II wrote: > > Mel, cant get a grep on allow_f* anywhere in the source tree, looks like > it > > has gone the way of the elves > > > > > > On Thu, Apr 10, 2014 at 11:37 AM, James Stallings II < > > james.stallings at gmail.com> wrote: > > > >> I thought I recalled such a thing, been about as long since I looked at > it > >> ;) > >> > >> Thanks Mel > >> > >> > >> James > >> > >> > >> > >> On Thu, Apr 10, 2014 at 11:37 AM, Melanie wrote: > >> > >>> Yes. allow_forceful_banlines, I believe. Long time since I looked at > it. > >>> > >>> - Melanie > >>> > >>> On 10/04/2014 18:33, James Stallings II wrote: > >>> > Quick question (related) is there a configuration point I'm missing > that > >>> > enables 'forceful bans'? > >>> > > >>> > > >>> > > >>> > On Thu, Apr 10, 2014 at 11:30 AM, James Stallings II < > >>> > james.stallings at gmail.com> wrote: > >>> > > >>> >> I kinder suspected something to that effect. It goes without saying > >>> that a > >>> >> lot occurs during the login process than is immediately apparent > when > >>> one > >>> >> sits and watches the consoles. > >>> >> > >>> >> Right now I'm leaning towards the previously-mentioned edge case. > >>> >> > >>> >> > >>> >> On Thu, Apr 10, 2014 at 11:29 AM, Melanie > wrote: > >>> >> > >>> >>> The QueryAccess is a pre-authorization. So the double call is > >>> >>> intentional and unavoidable. > >>> >>> > >>> >>> - Melanie > >>> >>> > >>> >>> On 10/04/2014 18:14, James Stallings II wrote: > >>> >>> > It would seem that the two invocations of the > TestLandRestrictions > >>> >>> method > >>> >>> > in Scene occur in each of NewUserConnection and > >>> >>> > QueryAccess. EventManagerOnAvatarEnteringNewParcel is, fairly > >>> obviously, > >>> >>> > and event callback method; at this point I don't have but a guess > >>> where > >>> >>> > this might be called excepting from > >>> >>> > within EventManagerOnSignificantClientMovement. > >>> >>> > > >>> >>> > I'd like to think that the two calls to TestLandRestrictions in > >>> Scene > >>> >>> might > >>> >>> > be reduced to one; but I'm not yet convinced it is the way to go. > >>> >>> > > >>> >>> > More to follow. > >>> >>> > > >>> >>> > Cheers > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> > On Thu, Apr 10, 2014 at 10:59 AM, Robert A. Knop Jr. < > >>> rknop at pobox.com > >>> >>> >wrote: > >>> >>> > > >>> >>> >> On Thu, Apr 10, 2014 at 10:25:17AM -0500, James Stallings II > wrote: > >>> >>> >> > And FWIW, last I hear adding log statements to code is a valid > >>> >>> >> > tried and true debugging method. > >>> >>> >> > >>> >>> >> I wish to subscribe all of my students in my programming class > to > >>> your > >>> >>> >> newsletter. > >>> >>> >> > >>> >>> >> (The number of times I told them to print stuff to figure out > >>> where the > >>> >>> >> code was, and the number of times I told them to print in more > >>> places, > >>> >>> >> was phenomenal. They got tired of hearing me say it, but > somehow > >>> still > >>> >>> >> needed to hear it.) > >>> >>> >> > >>> >>> >> (They often needed similar guidance in figuring out how to use > >>> >>> >> breakpoints in debuggers.) > >>> >>> >> > >>> >>> >> -Rob > >>> >>> >> > >>> >>> >> -- > >>> >>> >> --Rob Knop > >>> >>> >> E-mail: rknop at pobox.com > >>> >>> >> Home Page: http://www.pobox.com/~rknop/ > >>> >>> >> Blog: http://www.galacticinteractions.org/ > >>> >>> >> > >>> >>> >> _______________________________________________ > >>> >>> >> Opensim-dev mailing list > >>> >>> >> Opensim-dev at lists.berlios.de > >>> >>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> >>> >> > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> > _______________________________________________ > >>> >>> > Opensim-dev mailing list > >>> >>> > Opensim-dev at lists.berlios.de > >>> >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> >>> _______________________________________________ > >>> >>> Opensim-dev mailing list > >>> >>> Opensim-dev at lists.berlios.de > >>> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> >>> > >>> >> > >>> >> > >>> >> > >>> >> -- > >>> >> =================================== > >>> >> http://osgrid.org/ > >>> >> http://simhost.com > >>> >> http://twitter.com/jstallings2 > >>> >> > >>> >> > >>> > > >>> > > >>> > > >>> > > >>> > _______________________________________________ > >>> > Opensim-dev mailing list > >>> > Opensim-dev at lists.berlios.de > >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> _______________________________________________ > >>> Opensim-dev mailing list > >>> Opensim-dev at lists.berlios.de > >>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> > >> > >> > >> > >> -- > >> =================================== > >> http://osgrid.org/ > >> http://simhost.com > >> http://twitter.com/jstallings2 > >> > >> > > > > > > > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.stallings at gmail.com Thu Apr 10 16:44:06 2014 From: james.stallings at gmail.com (James Stallings II) Date: Thu, 10 Apr 2014 11:44:06 -0500 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> <20140410155900.GA3167@schumann> <5346C6EC.9080906@t-data.com> <5346C8AD.5000809@t-data.com> Message-ID: There are still getters and setters on the property, but I cant ref the config point anywhere On Thu, Apr 10, 2014 at 11:43 AM, James Stallings II < james.stallings at gmail.com> wrote: > Mel, cant get a grep on allow_f* anywhere in the source tree, looks like > it has gone the way of the elves > > > On Thu, Apr 10, 2014 at 11:37 AM, James Stallings II < > james.stallings at gmail.com> wrote: > >> I thought I recalled such a thing, been about as long since I looked at >> it ;) >> >> Thanks Mel >> >> >> James >> >> >> >> On Thu, Apr 10, 2014 at 11:37 AM, Melanie wrote: >> >>> Yes. allow_forceful_banlines, I believe. Long time since I looked at it. >>> >>> - Melanie >>> >>> On 10/04/2014 18:33, James Stallings II wrote: >>> > Quick question (related) is there a configuration point I'm missing >>> that >>> > enables 'forceful bans'? >>> > >>> > >>> > >>> > On Thu, Apr 10, 2014 at 11:30 AM, James Stallings II < >>> > james.stallings at gmail.com> wrote: >>> > >>> >> I kinder suspected something to that effect. It goes without saying >>> that a >>> >> lot occurs during the login process than is immediately apparent when >>> one >>> >> sits and watches the consoles. >>> >> >>> >> Right now I'm leaning towards the previously-mentioned edge case. >>> >> >>> >> >>> >> On Thu, Apr 10, 2014 at 11:29 AM, Melanie wrote: >>> >> >>> >>> The QueryAccess is a pre-authorization. So the double call is >>> >>> intentional and unavoidable. >>> >>> >>> >>> - Melanie >>> >>> >>> >>> On 10/04/2014 18:14, James Stallings II wrote: >>> >>> > It would seem that the two invocations of the TestLandRestrictions >>> >>> method >>> >>> > in Scene occur in each of NewUserConnection and >>> >>> > QueryAccess. EventManagerOnAvatarEnteringNewParcel is, fairly >>> obviously, >>> >>> > and event callback method; at this point I don't have but a guess >>> where >>> >>> > this might be called excepting from >>> >>> > within EventManagerOnSignificantClientMovement. >>> >>> > >>> >>> > I'd like to think that the two calls to TestLandRestrictions in >>> Scene >>> >>> might >>> >>> > be reduced to one; but I'm not yet convinced it is the way to go. >>> >>> > >>> >>> > More to follow. >>> >>> > >>> >>> > Cheers >>> >>> > >>> >>> > >>> >>> > >>> >>> > On Thu, Apr 10, 2014 at 10:59 AM, Robert A. Knop Jr. < >>> rknop at pobox.com >>> >>> >wrote: >>> >>> > >>> >>> >> On Thu, Apr 10, 2014 at 10:25:17AM -0500, James Stallings II >>> wrote: >>> >>> >> > And FWIW, last I hear adding log statements to code is a valid >>> >>> >> > tried and true debugging method. >>> >>> >> >>> >>> >> I wish to subscribe all of my students in my programming class to >>> your >>> >>> >> newsletter. >>> >>> >> >>> >>> >> (The number of times I told them to print stuff to figure out >>> where the >>> >>> >> code was, and the number of times I told them to print in more >>> places, >>> >>> >> was phenomenal. They got tired of hearing me say it, but somehow >>> still >>> >>> >> needed to hear it.) >>> >>> >> >>> >>> >> (They often needed similar guidance in figuring out how to use >>> >>> >> breakpoints in debuggers.) >>> >>> >> >>> >>> >> -Rob >>> >>> >> >>> >>> >> -- >>> >>> >> --Rob Knop >>> >>> >> E-mail: rknop at pobox.com >>> >>> >> Home Page: http://www.pobox.com/~rknop/ >>> >>> >> Blog: http://www.galacticinteractions.org/ >>> >>> >> >>> >>> >> _______________________________________________ >>> >>> >> Opensim-dev mailing list >>> >>> >> Opensim-dev at lists.berlios.de >>> >>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> >> >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > _______________________________________________ >>> >>> > Opensim-dev mailing list >>> >>> > Opensim-dev at lists.berlios.de >>> >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> _______________________________________________ >>> >>> Opensim-dev mailing list >>> >>> Opensim-dev at lists.berlios.de >>> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> >>> >> >>> >> >>> >> >>> >> -- >>> >> =================================== >>> >> http://osgrid.org/ >>> >> http://simhost.com >>> >> http://twitter.com/jstallings2 >>> >> >>> >> >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > Opensim-dev mailing list >>> > Opensim-dev at lists.berlios.de >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >> >> >> -- >> =================================== >> http://osgrid.org/ >> http://simhost.com >> http://twitter.com/jstallings2 >> >> > > > -- > =================================== > http://osgrid.org/ > http://simhost.com > http://twitter.com/jstallings2 > > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From melanie at t-data.com Thu Apr 10 16:51:39 2014 From: melanie at t-data.com (Melanie) Date: Thu, 10 Apr 2014 18:51:39 +0200 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> <20140410155900.GA3167@schumann> <5346C6EC.9080906@t-data.com> <5346C8AD.5000809@t-data.com> Message-ID: <5346CC1B.9080905@t-data.com> It used to go through event manager - an ancient way of doing it. - Melanie On 10/04/2014 18:44, James Stallings II wrote: > There are still getters and setters on the property, but I cant ref the > config point anywhere > > > On Thu, Apr 10, 2014 at 11:43 AM, James Stallings II < > james.stallings at gmail.com> wrote: > >> Mel, cant get a grep on allow_f* anywhere in the source tree, looks like >> it has gone the way of the elves >> >> >> On Thu, Apr 10, 2014 at 11:37 AM, James Stallings II < >> james.stallings at gmail.com> wrote: >> >>> I thought I recalled such a thing, been about as long since I looked at >>> it ;) >>> >>> Thanks Mel >>> >>> >>> James >>> >>> >>> >>> On Thu, Apr 10, 2014 at 11:37 AM, Melanie wrote: >>> >>>> Yes. allow_forceful_banlines, I believe. Long time since I looked at it. >>>> >>>> - Melanie >>>> >>>> On 10/04/2014 18:33, James Stallings II wrote: >>>> > Quick question (related) is there a configuration point I'm missing >>>> that >>>> > enables 'forceful bans'? >>>> > >>>> > >>>> > >>>> > On Thu, Apr 10, 2014 at 11:30 AM, James Stallings II < >>>> > james.stallings at gmail.com> wrote: >>>> > >>>> >> I kinder suspected something to that effect. It goes without saying >>>> that a >>>> >> lot occurs during the login process than is immediately apparent when >>>> one >>>> >> sits and watches the consoles. >>>> >> >>>> >> Right now I'm leaning towards the previously-mentioned edge case. >>>> >> >>>> >> >>>> >> On Thu, Apr 10, 2014 at 11:29 AM, Melanie wrote: >>>> >> >>>> >>> The QueryAccess is a pre-authorization. So the double call is >>>> >>> intentional and unavoidable. >>>> >>> >>>> >>> - Melanie >>>> >>> >>>> >>> On 10/04/2014 18:14, James Stallings II wrote: >>>> >>> > It would seem that the two invocations of the TestLandRestrictions >>>> >>> method >>>> >>> > in Scene occur in each of NewUserConnection and >>>> >>> > QueryAccess. EventManagerOnAvatarEnteringNewParcel is, fairly >>>> obviously, >>>> >>> > and event callback method; at this point I don't have but a guess >>>> where >>>> >>> > this might be called excepting from >>>> >>> > within EventManagerOnSignificantClientMovement. >>>> >>> > >>>> >>> > I'd like to think that the two calls to TestLandRestrictions in >>>> Scene >>>> >>> might >>>> >>> > be reduced to one; but I'm not yet convinced it is the way to go. >>>> >>> > >>>> >>> > More to follow. >>>> >>> > >>>> >>> > Cheers >>>> >>> > >>>> >>> > >>>> >>> > >>>> >>> > On Thu, Apr 10, 2014 at 10:59 AM, Robert A. Knop Jr. < >>>> rknop at pobox.com >>>> >>> >wrote: >>>> >>> > >>>> >>> >> On Thu, Apr 10, 2014 at 10:25:17AM -0500, James Stallings II >>>> wrote: >>>> >>> >> > And FWIW, last I hear adding log statements to code is a valid >>>> >>> >> > tried and true debugging method. >>>> >>> >> >>>> >>> >> I wish to subscribe all of my students in my programming class to >>>> your >>>> >>> >> newsletter. >>>> >>> >> >>>> >>> >> (The number of times I told them to print stuff to figure out >>>> where the >>>> >>> >> code was, and the number of times I told them to print in more >>>> places, >>>> >>> >> was phenomenal. They got tired of hearing me say it, but somehow >>>> still >>>> >>> >> needed to hear it.) >>>> >>> >> >>>> >>> >> (They often needed similar guidance in figuring out how to use >>>> >>> >> breakpoints in debuggers.) >>>> >>> >> >>>> >>> >> -Rob >>>> >>> >> >>>> >>> >> -- >>>> >>> >> --Rob Knop >>>> >>> >> E-mail: rknop at pobox.com >>>> >>> >> Home Page: http://www.pobox.com/~rknop/ >>>> >>> >> Blog: http://www.galacticinteractions.org/ >>>> >>> >> >>>> >>> >> _______________________________________________ >>>> >>> >> Opensim-dev mailing list >>>> >>> >> Opensim-dev at lists.berlios.de >>>> >>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> >>> >> >>>> >>> > >>>> >>> > >>>> >>> > >>>> >>> > >>>> >>> > >>>> >>> > _______________________________________________ >>>> >>> > Opensim-dev mailing list >>>> >>> > Opensim-dev at lists.berlios.de >>>> >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> >>> _______________________________________________ >>>> >>> Opensim-dev mailing list >>>> >>> Opensim-dev at lists.berlios.de >>>> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> >>> >>>> >> >>>> >> >>>> >> >>>> >> -- >>>> >> =================================== >>>> >> http://osgrid.org/ >>>> >> http://simhost.com >>>> >> http://twitter.com/jstallings2 >>>> >> >>>> >> >>>> > >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > Opensim-dev mailing list >>>> > Opensim-dev at lists.berlios.de >>>> > https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> Opensim-dev at lists.berlios.de >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> >>> >>> >>> >>> -- >>> =================================== >>> http://osgrid.org/ >>> http://simhost.com >>> http://twitter.com/jstallings2 >>> >>> >> >> >> -- >> =================================== >> http://osgrid.org/ >> http://simhost.com >> http://twitter.com/jstallings2 >> >> > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev From james.stallings at gmail.com Thu Apr 10 17:02:45 2014 From: james.stallings at gmail.com (James Stallings II) Date: Thu, 10 Apr 2014 12:02:45 -0500 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: <5346CA90.90707@t-data.com> References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> <20140410155900.GA3167@schumann> <5346C6EC.9080906@t-data.com> <5346C8AD.5000809@t-data.com> <5346CA90.90707@t-data.com> Message-ID: I think the default parcel is definitely an edge case. I created a small completely public parcel in the center of the region, and banned the test avatar outside it; everything works pretty much as one would hope, including the forceful banlines (it even displayed banlines, ugh). But, as designed. There was one problem, seems the av will get stuck to the banlines if s/he attempts crossing them; but a relog fixes it. In all honesty, not the very worst thing I ever had happen when hitting a banline. I'll see if I can figure out why, though. PS I was referring to those elves that left with Bilbo and Frodo for the Distant Shores ;) Cheers On Thu, Apr 10, 2014 at 11:45 AM, Melanie wrote: > Why, the elves are still around! I know a couple. > > - Melanie > > On 10/04/2014 18:43, James Stallings II wrote: > > Mel, cant get a grep on allow_f* anywhere in the source tree, looks like > it > > has gone the way of the elves > > > > > > On Thu, Apr 10, 2014 at 11:37 AM, James Stallings II < > > james.stallings at gmail.com> wrote: > > > >> I thought I recalled such a thing, been about as long since I looked at > it > >> ;) > >> > >> Thanks Mel > >> > >> > >> James > >> > >> > >> > >> On Thu, Apr 10, 2014 at 11:37 AM, Melanie wrote: > >> > >>> Yes. allow_forceful_banlines, I believe. Long time since I looked at > it. > >>> > >>> - Melanie > >>> > >>> On 10/04/2014 18:33, James Stallings II wrote: > >>> > Quick question (related) is there a configuration point I'm missing > that > >>> > enables 'forceful bans'? > >>> > > >>> > > >>> > > >>> > On Thu, Apr 10, 2014 at 11:30 AM, James Stallings II < > >>> > james.stallings at gmail.com> wrote: > >>> > > >>> >> I kinder suspected something to that effect. It goes without saying > >>> that a > >>> >> lot occurs during the login process than is immediately apparent > when > >>> one > >>> >> sits and watches the consoles. > >>> >> > >>> >> Right now I'm leaning towards the previously-mentioned edge case. > >>> >> > >>> >> > >>> >> On Thu, Apr 10, 2014 at 11:29 AM, Melanie > wrote: > >>> >> > >>> >>> The QueryAccess is a pre-authorization. So the double call is > >>> >>> intentional and unavoidable. > >>> >>> > >>> >>> - Melanie > >>> >>> > >>> >>> On 10/04/2014 18:14, James Stallings II wrote: > >>> >>> > It would seem that the two invocations of the > TestLandRestrictions > >>> >>> method > >>> >>> > in Scene occur in each of NewUserConnection and > >>> >>> > QueryAccess. EventManagerOnAvatarEnteringNewParcel is, fairly > >>> obviously, > >>> >>> > and event callback method; at this point I don't have but a guess > >>> where > >>> >>> > this might be called excepting from > >>> >>> > within EventManagerOnSignificantClientMovement. > >>> >>> > > >>> >>> > I'd like to think that the two calls to TestLandRestrictions in > >>> Scene > >>> >>> might > >>> >>> > be reduced to one; but I'm not yet convinced it is the way to go. > >>> >>> > > >>> >>> > More to follow. > >>> >>> > > >>> >>> > Cheers > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> > On Thu, Apr 10, 2014 at 10:59 AM, Robert A. Knop Jr. < > >>> rknop at pobox.com > >>> >>> >wrote: > >>> >>> > > >>> >>> >> On Thu, Apr 10, 2014 at 10:25:17AM -0500, James Stallings II > wrote: > >>> >>> >> > And FWIW, last I hear adding log statements to code is a valid > >>> >>> >> > tried and true debugging method. > >>> >>> >> > >>> >>> >> I wish to subscribe all of my students in my programming class > to > >>> your > >>> >>> >> newsletter. > >>> >>> >> > >>> >>> >> (The number of times I told them to print stuff to figure out > >>> where the > >>> >>> >> code was, and the number of times I told them to print in more > >>> places, > >>> >>> >> was phenomenal. They got tired of hearing me say it, but > somehow > >>> still > >>> >>> >> needed to hear it.) > >>> >>> >> > >>> >>> >> (They often needed similar guidance in figuring out how to use > >>> >>> >> breakpoints in debuggers.) > >>> >>> >> > >>> >>> >> -Rob > >>> >>> >> > >>> >>> >> -- > >>> >>> >> --Rob Knop > >>> >>> >> E-mail: rknop at pobox.com > >>> >>> >> Home Page: http://www.pobox.com/~rknop/ > >>> >>> >> Blog: http://www.galacticinteractions.org/ > >>> >>> >> > >>> >>> >> _______________________________________________ > >>> >>> >> Opensim-dev mailing list > >>> >>> >> Opensim-dev at lists.berlios.de > >>> >>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> >>> >> > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> > _______________________________________________ > >>> >>> > Opensim-dev mailing list > >>> >>> > Opensim-dev at lists.berlios.de > >>> >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> >>> _______________________________________________ > >>> >>> Opensim-dev mailing list > >>> >>> Opensim-dev at lists.berlios.de > >>> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> >>> > >>> >> > >>> >> > >>> >> > >>> >> -- > >>> >> =================================== > >>> >> http://osgrid.org/ > >>> >> http://simhost.com > >>> >> http://twitter.com/jstallings2 > >>> >> > >>> >> > >>> > > >>> > > >>> > > >>> > > >>> > _______________________________________________ > >>> > Opensim-dev mailing list > >>> > Opensim-dev at lists.berlios.de > >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> _______________________________________________ > >>> Opensim-dev mailing list > >>> Opensim-dev at lists.berlios.de > >>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> > >> > >> > >> > >> -- > >> =================================== > >> http://osgrid.org/ > >> http://simhost.com > >> http://twitter.com/jstallings2 > >> > >> > > > > > > > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jjustincc at googlemail.com Thu Apr 10 23:52:05 2014 From: jjustincc at googlemail.com (Justin Clark-Casey) Date: Fri, 11 Apr 2014 00:52:05 +0100 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> <20140410155900.GA3167@schumann> <5346C6EC.9080906@t-data.com> <5346C8AD.5000809@t-data.com> <5346CA90.90707@t-data.com> Message-ID: <53472EA5.1060009@googlemail.com> Yeah, there are definitely issues with consistent enforcement of ban lines on avatar movement. I remember looking at that some time ago but unfortunately not a simple thing to properly fix. On 10/04/14 18:02, James Stallings II wrote: > I think the default parcel is definitely an edge case. I created a small completely public parcel in the center of the > region, and banned the test avatar outside it; everything works pretty much as one would hope, including the forceful > banlines (it even displayed banlines, ugh). But, as designed. > > There was one problem, seems the av will get stuck to the banlines if s/he attempts crossing them; but a relog fixes it. > In all honesty, not the very worst thing I ever had happen when hitting a banline. I'll see if I can figure out why, though. > > PS I was referring to those elves that left with Bilbo and Frodo for the Distant Shores ;) > > Cheers > > > > On Thu, Apr 10, 2014 at 11:45 AM, Melanie > wrote: > > Why, the elves are still around! I know a couple. > > - Melanie > > On 10/04/2014 18:43, James Stallings II wrote: > > Mel, cant get a grep on allow_f* anywhere in the source tree, looks like it > > has gone the way of the elves > > > > > > On Thu, Apr 10, 2014 at 11:37 AM, James Stallings II < > > james.stallings at gmail.com > wrote: > > > >> I thought I recalled such a thing, been about as long since I looked at it > >> ;) > >> > >> Thanks Mel > >> > >> > >> James > >> > >> > >> > >> On Thu, Apr 10, 2014 at 11:37 AM, Melanie > wrote: > >> > >>> Yes. allow_forceful_banlines, I believe. Long time since I looked at it. > >>> > >>> - Melanie > >>> > >>> On 10/04/2014 18:33, James Stallings II wrote: > >>> > Quick question (related) is there a configuration point I'm missing that > >>> > enables 'forceful bans'? > >>> > > >>> > > >>> > > >>> > On Thu, Apr 10, 2014 at 11:30 AM, James Stallings II < > >>> > james.stallings at gmail.com > wrote: > >>> > > >>> >> I kinder suspected something to that effect. It goes without saying > >>> that a > >>> >> lot occurs during the login process than is immediately apparent when > >>> one > >>> >> sits and watches the consoles. > >>> >> > >>> >> Right now I'm leaning towards the previously-mentioned edge case. > >>> >> > >>> >> > >>> >> On Thu, Apr 10, 2014 at 11:29 AM, Melanie > wrote: > >>> >> > >>> >>> The QueryAccess is a pre-authorization. So the double call is > >>> >>> intentional and unavoidable. > >>> >>> > >>> >>> - Melanie > >>> >>> > >>> >>> On 10/04/2014 18:14, James Stallings II wrote: > >>> >>> > It would seem that the two invocations of the TestLandRestrictions > >>> >>> method > >>> >>> > in Scene occur in each of NewUserConnection and > >>> >>> > QueryAccess. EventManagerOnAvatarEnteringNewParcel is, fairly > >>> obviously, > >>> >>> > and event callback method; at this point I don't have but a guess > >>> where > >>> >>> > this might be called excepting from > >>> >>> > within EventManagerOnSignificantClientMovement. > >>> >>> > > >>> >>> > I'd like to think that the two calls to TestLandRestrictions in > >>> Scene > >>> >>> might > >>> >>> > be reduced to one; but I'm not yet convinced it is the way to go. > >>> >>> > > >>> >>> > More to follow. > >>> >>> > > >>> >>> > Cheers > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> > On Thu, Apr 10, 2014 at 10:59 AM, Robert A. Knop Jr. < > >>> rknop at pobox.com > >>> >>> >wrote: > >>> >>> > > >>> >>> >> On Thu, Apr 10, 2014 at 10:25:17AM -0500, James Stallings II wrote: > >>> >>> >> > And FWIW, last I hear adding log statements to code is a valid > >>> >>> >> > tried and true debugging method. > >>> >>> >> > >>> >>> >> I wish to subscribe all of my students in my programming class to > >>> your > >>> >>> >> newsletter. > >>> >>> >> > >>> >>> >> (The number of times I told them to print stuff to figure out > >>> where the > >>> >>> >> code was, and the number of times I told them to print in more > >>> places, > >>> >>> >> was phenomenal. They got tired of hearing me say it, but somehow > >>> still > >>> >>> >> needed to hear it.) > >>> >>> >> > >>> >>> >> (They often needed similar guidance in figuring out how to use > >>> >>> >> breakpoints in debuggers.) > >>> >>> >> > >>> >>> >> -Rob > >>> >>> >> > >>> >>> >> -- > >>> >>> >> --Rob Knop > >>> >>> >> E-mail: rknop at pobox.com > >>> >>> >> Home Page: http://www.pobox.com/~rknop/ > >>> >>> >> Blog: http://www.galacticinteractions.org/ > >>> >>> >> > >>> >>> >> _______________________________________________ > >>> >>> >> Opensim-dev mailing list > >>> >>> >> Opensim-dev at lists.berlios.de > >>> >>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> >>> >> > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> > _______________________________________________ > >>> >>> > Opensim-dev mailing list > >>> >>> > Opensim-dev at lists.berlios.de > >>> >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> >>> _______________________________________________ > >>> >>> Opensim-dev mailing list > >>> >>> Opensim-dev at lists.berlios.de > >>> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> >>> > >>> >> > >>> >> > >>> >> > >>> >> -- > >>> >> =================================== > >>> >> http://osgrid.org/ > >>> >> http://simhost.com > >>> >> http://twitter.com/jstallings2 > >>> >> > >>> >> > >>> > > >>> > > >>> > > >>> > > >>> > _______________________________________________ > >>> > Opensim-dev mailing list > >>> > Opensim-dev at lists.berlios.de > >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> _______________________________________________ > >>> Opensim-dev mailing list > >>> Opensim-dev at lists.berlios.de > >>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> > >> > >> > >> > >> -- > >> =================================== > >> http://osgrid.org/ > >> http://simhost.com > >> http://twitter.com/jstallings2 > >> > >> > > > > > > > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > > -- > =================================== > http://osgrid.org/ > http://simhost.com > http://twitter.com/jstallings2 > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- Justin Clark-Casey (justincc) OSVW Consulting http://justincc.org http://twitter.com/justincc From melanie at t-data.com Fri Apr 11 01:03:47 2014 From: melanie at t-data.com (Melanie) Date: Fri, 11 Apr 2014 03:03:47 +0200 Subject: [Opensim-dev] Legacy region XML support - Remove? Message-ID: <53473F73.20409@t-data.com> Hi, the RegionInfo class supports an ancient form of XML, one that is based on attributes rather than tags. At this point, we believe no one uses this format anymore. Further, NINI offers another form of XML that is much more up to date and a better replacement for the ancient XML in any case. The affected installations would be those that use pre-0.6 configuration files (regions.xml) or use web loading. The old config files would need to be redone by hand in .ini format, and people who web-load would need to change the server scripts to provide the same data in the new format, which is not too hard a task. I propose to remove the support for the legacy format, which has last been updated in 2007 and has been unused for two major revisions. Thoughts are welcome. Melanie From james.stallings at gmail.com Fri Apr 11 01:58:13 2014 From: james.stallings at gmail.com (James Stallings II) Date: Thu, 10 Apr 2014 20:58:13 -0500 Subject: [Opensim-dev] Legacy region XML support - Remove? In-Reply-To: <53473F73.20409@t-data.com> References: <53473F73.20409@t-data.com> Message-ID: For my part, I thought it was long gone :) On Thu, Apr 10, 2014 at 8:03 PM, Melanie wrote: > Hi, > > the RegionInfo class supports an ancient form of XML, one that is > based on attributes rather than tags. > > At this point, we believe no one uses this format anymore. Further, > NINI offers another form of XML that is much more up to date and a > better replacement for the ancient XML in any case. > > The affected installations would be those that use pre-0.6 > configuration files (regions.xml) or use web loading. > > The old config files would need to be redone by hand in .ini format, > and people who web-load would need to change the server scripts to > provide the same data in the new format, which is not too hard a task. > > I propose to remove the support for the legacy format, which has > last been updated in 2007 and has been unused for two major revisions. > > Thoughts are welcome. > > Melanie > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From fly.man.opensim at gmail.com Fri Apr 11 09:36:22 2014 From: fly.man.opensim at gmail.com (Fly Man) Date: Fri, 11 Apr 2014 11:36:22 +0200 Subject: [Opensim-dev] Legacy region XML support - Remove? In-Reply-To: References: <53473F73.20409@t-data.com> Message-ID: +1 as long as there's a good wiki page written to convert the old files to the new format 2014-04-11 3:58 GMT+02:00 James Stallings II : > For my part, I thought it was long gone :) > > > On Thu, Apr 10, 2014 at 8:03 PM, Melanie wrote: > >> Hi, >> >> the RegionInfo class supports an ancient form of XML, one that is >> based on attributes rather than tags. >> >> At this point, we believe no one uses this format anymore. Further, >> NINI offers another form of XML that is much more up to date and a >> better replacement for the ancient XML in any case. >> >> The affected installations would be those that use pre-0.6 >> configuration files (regions.xml) or use web loading. >> >> The old config files would need to be redone by hand in .ini format, >> and people who web-load would need to change the server scripts to >> provide the same data in the new format, which is not too hard a task. >> >> I propose to remove the support for the legacy format, which has >> last been updated in 2007 and has been unused for two major revisions. >> >> Thoughts are welcome. >> >> Melanie >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > -- > =================================== > http://osgrid.org/ > http://simhost.com > http://twitter.com/jstallings2 > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rigun at rigutech.nl Fri Apr 11 11:10:57 2014 From: rigun at rigutech.nl (R.Gunther) Date: Fri, 11 Apr 2014 13:10:57 +0200 Subject: [Opensim-dev] Legacy region XML support - Remove? In-Reply-To: <53473F73.20409@t-data.com> References: <53473F73.20409@t-data.com> Message-ID: <5347CDC1.7070102@rigutech.nl> Suprissed its still there, well people did have time enough to change the xml files to ini files on newer versions. For me, using long time ini files so you can remove it. On 2014-04-11 03:03, Melanie wrote: > Hi, > > the RegionInfo class supports an ancient form of XML, one that is > based on attributes rather than tags. > > At this point, we believe no one uses this format anymore. Further, > NINI offers another form of XML that is much more up to date and a > better replacement for the ancient XML in any case. > > The affected installations would be those that use pre-0.6 > configuration files (regions.xml) or use web loading. > > The old config files would need to be redone by hand in .ini format, > and people who web-load would need to change the server scripts to > provide the same data in the new format, which is not too hard a task. > > I propose to remove the support for the legacy format, which has > last been updated in 2007 and has been unused for two major revisions. > > Thoughts are welcome. > > Melanie > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > From abitar.com at gmail.com Fri Apr 11 13:35:04 2014 From: abitar.com at gmail.com (David Saunders) Date: Fri, 11 Apr 2014 09:35:04 -0400 Subject: [Opensim-dev] Legacy region XML support - Remove? In-Reply-To: <5347CDC1.7070102@rigutech.nl> References: <53473F73.20409@t-data.com> <5347CDC1.7070102@rigutech.nl> Message-ID: How does this relate to the XML format for web configuration? On Fri, Apr 11, 2014 at 7:10 AM, R.Gunther wrote: > Suprissed its still there, well people did have time enough to change the > xml files to ini files on newer versions. > For me, using long time ini files so you can remove it. > > > On 2014-04-11 03:03, Melanie wrote: > >> Hi, >> >> the RegionInfo class supports an ancient form of XML, one that is >> based on attributes rather than tags. >> >> At this point, we believe no one uses this format anymore. Further, >> NINI offers another form of XML that is much more up to date and a >> better replacement for the ancient XML in any case. >> >> The affected installations would be those that use pre-0.6 >> configuration files (regions.xml) or use web loading. >> >> The old config files would need to be redone by hand in .ini format, >> and people who web-load would need to change the server scripts to >> provide the same data in the new format, which is not too hard a task. >> >> I propose to remove the support for the legacy format, which has >> last been updated in 2007 and has been unused for two major revisions. >> >> Thoughts are welcome. >> >> Melanie >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From melanie at t-data.com Fri Apr 11 13:42:53 2014 From: melanie at t-data.com (Melanie) Date: Fri, 11 Apr 2014 15:42:53 +0200 Subject: [Opensim-dev] Legacy region XML support - Remove? In-Reply-To: References: <53473F73.20409@t-data.com> <5347CDC1.7070102@rigutech.nl> Message-ID: <5347F15D.108@t-data.com> That format needs to be changed. The old format is: The new format will be:
Server script that generate the old format dynamically need to be changed to generate the new format instead, - Melanie ... On 11/04/2014 15:35, David Saunders wrote: > How does this relate to the XML format for web configuration? > > > On Fri, Apr 11, 2014 at 7:10 AM, R.Gunther wrote: > >> Suprissed its still there, well people did have time enough to change the >> xml files to ini files on newer versions. >> For me, using long time ini files so you can remove it. >> >> >> On 2014-04-11 03:03, Melanie wrote: >> >>> Hi, >>> >>> the RegionInfo class supports an ancient form of XML, one that is >>> based on attributes rather than tags. >>> >>> At this point, we believe no one uses this format anymore. Further, >>> NINI offers another form of XML that is much more up to date and a >>> better replacement for the ancient XML in any case. >>> >>> The affected installations would be those that use pre-0.6 >>> configuration files (regions.xml) or use web loading. >>> >>> The old config files would need to be redone by hand in .ini format, >>> and people who web-load would need to change the server scripts to >>> provide the same data in the new format, which is not too hard a task. >>> >>> I propose to remove the support for the legacy format, which has >>> last been updated in 2007 and has been unused for two major revisions. >>> >>> Thoughts are welcome. >>> >>> Melanie >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev From jjustincc at googlemail.com Sat Apr 12 01:14:39 2014 From: jjustincc at googlemail.com (Justin Clark-Casey) Date: Sat, 12 Apr 2014 02:14:39 +0100 Subject: [Opensim-dev] Legacy region XML support - Remove? In-Reply-To: <53473F73.20409@t-data.com> References: <53473F73.20409@t-data.com> Message-ID: <5348937F.80602@googlemail.com> I don't see any problem with removing this - it's an extremely old format that I'd be surprised if anybody still uses. On 11/04/14 02:03, Melanie wrote: > Hi, > > the RegionInfo class supports an ancient form of XML, one that is > based on attributes rather than tags. > > At this point, we believe no one uses this format anymore. Further, > NINI offers another form of XML that is much more up to date and a > better replacement for the ancient XML in any case. > > The affected installations would be those that use pre-0.6 > configuration files (regions.xml) or use web loading. > > The old config files would need to be redone by hand in .ini format, > and people who web-load would need to change the server scripts to > provide the same data in the new format, which is not too hard a task. > > I propose to remove the support for the legacy format, which has > last been updated in 2007 and has been unused for two major revisions. > > Thoughts are welcome. > > Melanie > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > . > -- Justin Clark-Casey (justincc) OSVW Consulting http://justincc.org http://twitter.com/justincc From nebadon2025 at gmail.com Sat Apr 12 05:36:00 2014 From: nebadon2025 at gmail.com (Michael Emory Cerquoni) Date: Sat, 12 Apr 2014 07:36:00 +0200 Subject: [Opensim-dev] Legacy region XML support - Remove? In-Reply-To: <5348937F.80602@googlemail.com> References: <53473F73.20409@t-data.com> <5348937F.80602@googlemail.com> Message-ID: +1 the only grid I know that probably was using it was Reaction Grid, and they are no longer open so I also doubt anyone else is using it at this point either. On Sat, Apr 12, 2014 at 3:14 AM, Justin Clark-Casey < jjustincc at googlemail.com> wrote: > I don't see any problem with removing this - it's an extremely old format > that I'd be surprised if anybody still uses. > > > On 11/04/14 02:03, Melanie wrote: > >> Hi, >> >> the RegionInfo class supports an ancient form of XML, one that is >> based on attributes rather than tags. >> >> At this point, we believe no one uses this format anymore. Further, >> NINI offers another form of XML that is much more up to date and a >> better replacement for the ancient XML in any case. >> >> The affected installations would be those that use pre-0.6 >> configuration files (regions.xml) or use web loading. >> >> The old config files would need to be redone by hand in .ini format, >> and people who web-load would need to change the server scripts to >> provide the same data in the new format, which is not too hard a task. >> >> I propose to remove the support for the legacy format, which has >> last been updated in 2007 and has been unused for two major revisions. >> >> Thoughts are welcome. >> >> Melanie >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> . >> >> > > -- > Justin Clark-Casey (justincc) > OSVW Consulting > http://justincc.org > http://twitter.com/justincc > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- Michael Emory Cerquoni -------------- next part -------------- An HTML attachment was scrubbed... URL: From abitar.com at gmail.com Sat Apr 12 12:27:54 2014 From: abitar.com at gmail.com (David Saunders) Date: Sat, 12 Apr 2014 08:27:54 -0400 Subject: [Opensim-dev] Legacy region XML support - Remove? In-Reply-To: References: <53473F73.20409@t-data.com> <5348937F.80602@googlemail.com> Message-ID: Hey I Just dug though my web based region file, and its base on a single line XML format Would this be needed to updated with this proposal? On Sat, Apr 12, 2014 at 1:36 AM, Michael Emory Cerquoni < nebadon2025 at gmail.com> wrote: > +1 the only grid I know that probably was using it was Reaction Grid, and > they are no longer open so I also doubt anyone else is using it at this > point either. > > > On Sat, Apr 12, 2014 at 3:14 AM, Justin Clark-Casey < > jjustincc at googlemail.com> wrote: > >> I don't see any problem with removing this - it's an extremely old format >> that I'd be surprised if anybody still uses. >> >> >> On 11/04/14 02:03, Melanie wrote: >> >>> Hi, >>> >>> the RegionInfo class supports an ancient form of XML, one that is >>> based on attributes rather than tags. >>> >>> At this point, we believe no one uses this format anymore. Further, >>> NINI offers another form of XML that is much more up to date and a >>> better replacement for the ancient XML in any case. >>> >>> The affected installations would be those that use pre-0.6 >>> configuration files (regions.xml) or use web loading. >>> >>> The old config files would need to be redone by hand in .ini format, >>> and people who web-load would need to change the server scripts to >>> provide the same data in the new format, which is not too hard a task. >>> >>> I propose to remove the support for the legacy format, which has >>> last been updated in 2007 and has been unused for two major revisions. >>> >>> Thoughts are welcome. >>> >>> Melanie >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> . >>> >>> >> >> -- >> Justin Clark-Casey (justincc) >> OSVW Consulting >> http://justincc.org >> http://twitter.com/justincc >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > -- > Michael Emory Cerquoni > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From melanie at t-data.com Sat Apr 12 12:44:11 2014 From: melanie at t-data.com (Melanie) Date: Sat, 12 Apr 2014 14:44:11 +0200 Subject: [Opensim-dev] Legacy region XML support - Remove? In-Reply-To: References: <53473F73.20409@t-data.com> <5348937F.80602@googlemail.com> Message-ID: <5349351B.6050601@t-data.com> Yes - Melanie On 12/04/2014 14:27, David Saunders wrote: > Hey > I Just dug though my web based region file, and its base on a single > line XML format > > Would this be needed to updated with this proposal? > > > > > > > > On Sat, Apr 12, 2014 at 1:36 AM, Michael Emory Cerquoni < > nebadon2025 at gmail.com> wrote: > >> +1 the only grid I know that probably was using it was Reaction Grid, and >> they are no longer open so I also doubt anyone else is using it at this >> point either. >> >> >> On Sat, Apr 12, 2014 at 3:14 AM, Justin Clark-Casey < >> jjustincc at googlemail.com> wrote: >> >>> I don't see any problem with removing this - it's an extremely old format >>> that I'd be surprised if anybody still uses. >>> >>> >>> On 11/04/14 02:03, Melanie wrote: >>> >>>> Hi, >>>> >>>> the RegionInfo class supports an ancient form of XML, one that is >>>> based on attributes rather than tags. >>>> >>>> At this point, we believe no one uses this format anymore. Further, >>>> NINI offers another form of XML that is much more up to date and a >>>> better replacement for the ancient XML in any case. >>>> >>>> The affected installations would be those that use pre-0.6 >>>> configuration files (regions.xml) or use web loading. >>>> >>>> The old config files would need to be redone by hand in .ini format, >>>> and people who web-load would need to change the server scripts to >>>> provide the same data in the new format, which is not too hard a task. >>>> >>>> I propose to remove the support for the legacy format, which has >>>> last been updated in 2007 and has been unused for two major revisions. >>>> >>>> Thoughts are welcome. >>>> >>>> Melanie >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> Opensim-dev at lists.berlios.de >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> . >>>> >>>> >>> >>> -- >>> Justin Clark-Casey (justincc) >>> OSVW Consulting >>> http://justincc.org >>> http://twitter.com/justincc >>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >> >> >> -- >> Michael Emory Cerquoni >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev From jamesh at bluewallgroup.com Sat Apr 12 16:25:50 2014 From: jamesh at bluewallgroup.com (James Hughes) Date: Sat, 12 Apr 2014 12:25:50 -0400 Subject: [Opensim-dev] Legacy region XML support - Remove? In-Reply-To: <5347F15D.108@t-data.com> References: <53473F73.20409@t-data.com> <5347CDC1.7070102@rigutech.nl> <5347F15D.108@t-data.com> Message-ID: <5349690E.5060106@bluewallgroup.com> On 04/11/2014 09:42 AM, Melanie wrote: > That format needs to be changed. The old format is: > > > > The new format will be: > > >
> > >
> > +1 BlueWall From melanie at t-data.com Sat Apr 12 17:04:22 2014 From: melanie at t-data.com (Melanie) Date: Sat, 12 Apr 2014 19:04:22 +0200 Subject: [Opensim-dev] Legacy region XML support - Removed! In-Reply-To: <5349690E.5060106@bluewallgroup.com> References: <53473F73.20409@t-data.com> <5347CDC1.7070102@rigutech.nl> <5347F15D.108@t-data.com> <5349690E.5060106@bluewallgroup.com> Message-ID: <53497216.4090104@t-data.com> I have now removed support for the legacy format. The new format for XML, both for files and for web loading, is below:
Multiple "Section" statements can be placed within "Nini". - Melanie From fly.man.opensim at gmail.com Sun Apr 13 19:19:21 2014 From: fly.man.opensim at gmail.com (Fly Man) Date: Sun, 13 Apr 2014 21:19:21 +0200 Subject: [Opensim-dev] Legacy region XML support - Remove? In-Reply-To: <5348937F.80602@googlemail.com> References: <53473F73.20409@t-data.com> <5348937F.80602@googlemail.com> Message-ID: Some people still use the old format to load regions, makes it easier to load balance the region server when doing rolling restarts :) 2014-04-12 3:14 GMT+02:00 Justin Clark-Casey : > I don't see any problem with removing this - it's an extremely old format > that I'd be surprised if anybody still uses. > > > On 11/04/14 02:03, Melanie wrote: > >> Hi, >> >> the RegionInfo class supports an ancient form of XML, one that is >> based on attributes rather than tags. >> >> At this point, we believe no one uses this format anymore. Further, >> NINI offers another form of XML that is much more up to date and a >> better replacement for the ancient XML in any case. >> >> The affected installations would be those that use pre-0.6 >> configuration files (regions.xml) or use web loading. >> >> The old config files would need to be redone by hand in .ini format, >> and people who web-load would need to change the server scripts to >> provide the same data in the new format, which is not too hard a task. >> >> I propose to remove the support for the legacy format, which has >> last been updated in 2007 and has been unused for two major revisions. >> >> Thoughts are welcome. >> >> Melanie >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> . >> >> > > -- > Justin Clark-Casey (justincc) > OSVW Consulting > http://justincc.org > http://twitter.com/justincc > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.stallings at gmail.com Wed Apr 16 20:05:09 2014 From: james.stallings at gmail.com (James Stallings II) Date: Wed, 16 Apr 2014 15:05:09 -0500 Subject: [Opensim-dev] Parcel Access Enforcement In-Reply-To: <53472EA5.1060009@googlemail.com> References: <5346B47E.2000204@t-data.com> <5346B766.1050005@t-data.com> <20140410155900.GA3167@schumann> <5346C6EC.9080906@t-data.com> <5346C8AD.5000809@t-data.com> <5346CA90.90707@t-data.com> <53472EA5.1060009@googlemail.com> Message-ID: Follow-up: I never did get this issue resolved; indeed, it only got less predictable in it's manifestation. I was unable to satisfactorily lay the blame at opensim's feet though; there were many other issues, and literally nothing we did in the config files or with the binaries impacted opensim's operation either positively or negatively as far as this suite of parcel-related issues was concerned. At this point, we're shifting back to 'known good configurations' that really don't involve opensim directly (reinstall the boxes, shift to windows). I'm very interested to see whether that impacts the the problem at all. Will update again after the fact. Cheers James On Thu, Apr 10, 2014 at 6:52 PM, Justin Clark-Casey < jjustincc at googlemail.com> wrote: > Yeah, there are definitely issues with consistent enforcement of ban lines > on avatar movement. I remember looking at that some time ago but > unfortunately not a simple thing to properly fix. > > > On 10/04/14 18:02, James Stallings II wrote: > >> I think the default parcel is definitely an edge case. I created a small >> completely public parcel in the center of the >> region, and banned the test avatar outside it; everything works pretty >> much as one would hope, including the forceful >> banlines (it even displayed banlines, ugh). But, as designed. >> >> There was one problem, seems the av will get stuck to the banlines if >> s/he attempts crossing them; but a relog fixes it. >> In all honesty, not the very worst thing I ever had happen when hitting a >> banline. I'll see if I can figure out why, though. >> >> PS I was referring to those elves that left with Bilbo and Frodo for the >> Distant Shores ;) >> >> Cheers >> >> >> >> On Thu, Apr 10, 2014 at 11:45 AM, Melanie > melanie at t-data.com>> wrote: >> >> Why, the elves are still around! I know a couple. >> >> - Melanie >> >> On 10/04/2014 18:43, James Stallings II wrote: >> > Mel, cant get a grep on allow_f* anywhere in the source tree, >> looks like it >> > has gone the way of the elves >> > >> > >> > On Thu, Apr 10, 2014 at 11:37 AM, James Stallings II < >> > james.stallings at gmail.com > >> wrote: >> > >> >> I thought I recalled such a thing, been about as long since I >> looked at it >> >> ;) >> >> >> >> Thanks Mel >> >> >> >> >> >> James >> >> >> >> >> >> >> >> On Thu, Apr 10, 2014 at 11:37 AM, Melanie > melanie at t-data.com>> wrote: >> >> >> >>> Yes. allow_forceful_banlines, I believe. Long time since I >> looked at it. >> >>> >> >>> - Melanie >> >>> >> >>> On 10/04/2014 18:33, James Stallings II wrote: >> >>> > Quick question (related) is there a configuration point I'm >> missing that >> >>> > enables 'forceful bans'? >> >>> > >> >>> > >> >>> > >> >>> > On Thu, Apr 10, 2014 at 11:30 AM, James Stallings II < >> >>> > james.stallings at gmail.com > >> wrote: >> >>> > >> >>> >> I kinder suspected something to that effect. It goes without >> saying >> >>> that a >> >>> >> lot occurs during the login process than is immediately >> apparent when >> >>> one >> >>> >> sits and watches the consoles. >> >>> >> >> >>> >> Right now I'm leaning towards the previously-mentioned edge >> case. >> >>> >> >> >>> >> >> >>> >> On Thu, Apr 10, 2014 at 11:29 AM, Melanie > melanie at t-data.com>> wrote: >> >>> >> >> >>> >>> The QueryAccess is a pre-authorization. So the double call is >> >>> >>> intentional and unavoidable. >> >>> >>> >> >>> >>> - Melanie >> >>> >>> >> >>> >>> On 10/04/2014 18:14, James Stallings II wrote: >> >>> >>> > It would seem that the two invocations of the >> TestLandRestrictions >> >>> >>> method >> >>> >>> > in Scene occur in each of NewUserConnection and >> >>> >>> > QueryAccess. EventManagerOnAvatarEnteringNewParcel is, >> fairly >> >>> obviously, >> >>> >>> > and event callback method; at this point I don't have but >> a guess >> >>> where >> >>> >>> > this might be called excepting from >> >>> >>> > within EventManagerOnSignificantClientMovement. >> >>> >>> > >> >>> >>> > I'd like to think that the two calls to >> TestLandRestrictions in >> >>> Scene >> >>> >>> might >> >>> >>> > be reduced to one; but I'm not yet convinced it is the way >> to go. >> >>> >>> > >> >>> >>> > More to follow. >> >>> >>> > >> >>> >>> > Cheers >> >>> >>> > >> >>> >>> > >> >>> >>> > >> >>> >>> > On Thu, Apr 10, 2014 at 10:59 AM, Robert A. Knop Jr. < >> >>> rknop at pobox.com >> >> >>> >>> >wrote: >> >>> >>> > >> >>> >>> >> On Thu, Apr 10, 2014 at 10:25:17AM -0500, James Stallings >> II wrote: >> >>> >>> >> > And FWIW, last I hear adding log statements to code is >> a valid >> >>> >>> >> > tried and true debugging method. >> >>> >>> >> >> >>> >>> >> I wish to subscribe all of my students in my programming >> class to >> >>> your >> >>> >>> >> newsletter. >> >>> >>> >> >> >>> >>> >> (The number of times I told them to print stuff to figure >> out >> >>> where the >> >>> >>> >> code was, and the number of times I told them to print in >> more >> >>> places, >> >>> >>> >> was phenomenal. They got tired of hearing me say it, but >> somehow >> >>> still >> >>> >>> >> needed to hear it.) >> >>> >>> >> >> >>> >>> >> (They often needed similar guidance in figuring out how >> to use >> >>> >>> >> breakpoints in debuggers.) >> >>> >>> >> >> >>> >>> >> -Rob >> >>> >>> >> >> >>> >>> >> -- >> >>> >>> >> --Rob Knop >> >>> >>> >> E-mail: rknop at pobox.com >> >> >>> >>> >> Home Page: http://www.pobox.com/~rknop/ >> >>> >>> >> Blog: http://www.galacticinteractions.org/ >> >>> >>> >> >> >>> >>> >> _______________________________________________ >> >>> >>> >> Opensim-dev mailing list >> >>> >>> >> Opensim-dev at lists.berlios.de > berlios.de> >> >> >>> >>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >>> >>> >> >> >>> >>> > >> >>> >>> > >> >>> >>> > >> >>> >>> > >> >>> >>> > >> >>> >>> > _______________________________________________ >> >>> >>> > Opensim-dev mailing list >> >>> >>> > Opensim-dev at lists.berlios.de > berlios.de> >> >> >>> >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev >> >>> >>> _______________________________________________ >> >>> >>> Opensim-dev mailing list >> >>> >>> Opensim-dev at lists.berlios.de > berlios.de> >> >> >>> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >>> >>> >> >>> >> >> >>> >> >> >>> >> >> >>> >> -- >> >>> >> =================================== >> >>> >> http://osgrid.org/ >> >>> >> http://simhost.com >> >>> >> http://twitter.com/jstallings2 >> >>> >> >> >>> >> >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > _______________________________________________ >> >>> > Opensim-dev mailing list >> >>> > Opensim-dev at lists.berlios.de > berlios.de> >> >> >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev >> >>> _______________________________________________ >> >>> Opensim-dev mailing list >> >>> Opensim-dev at lists.berlios.de > berlios.de> >> >> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >>> >> >> >> >> >> >> >> >> -- >> >> =================================== >> >> http://osgrid.org/ >> >> http://simhost.com >> >> http://twitter.com/jstallings2 >> >> >> >> >> > >> > >> > >> > >> > _______________________________________________ >> > Opensim-dev mailing list >> > Opensim-dev at lists.berlios.de >> >> > https://lists.berlios.de/mailman/listinfo/opensim-dev >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> >> >> >> -- >> =================================== >> http://osgrid.org/ >> http://simhost.com >> http://twitter.com/jstallings2 >> >> >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> > > -- > Justin Clark-Casey (justincc) > OSVW Consulting > http://justincc.org > http://twitter.com/justincc > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From orenh at kitely.com Fri Apr 18 08:44:29 2014 From: orenh at kitely.com (Oren Hurvitz) Date: Fri, 18 Apr 2014 11:44:29 +0300 Subject: [Opensim-dev] Error detection when storing an asset Message-ID: I have found that when OpenSim tries to store an asset using AssetServicesConnector, it doesn't handle failures well. There are several problems in AssetServicesConnector.Store(), and some of them seem to be based on historical considerations that may no longer be relevant, so I'd like to see if anyone knows about these issues before pushing a change. AssetServicesConnector.Store() uses SynchronousRestObjectRequester to send the request. The first problem is that SynchronousRestObjectRequester.MakeRequest() hides exceptions and just returns null. This is a mistake: MakeRequest() should propagate exceptions, so that callers will know that an error occurred. Store() already catches these exceptions (as it should), so this won't make a big difference in our case. But of course, this change in behavior to MakeRequest() may affect other places in the code as well. It's better to fail-fast when errors occur, and not hide them, because doing so makes the errors much harder to diagnose once they become apparent. This brings me to the next problem... The second problem is that AssetServicesConnector.Store() compares the return value from MakeRequest to string.Empty, but in fact the return value that is returned in case of error is null. So it mistakenly treats 'null' as a valid Asset ID, which causes it to cache the asset. This can cause the operation to appear to have succeeded for a while, since OpenSim will have the asset available, but the moment the asset is loaded from the asset server "the jig is up" and the asset will be missing. This can explain many problems people have had with disappearing assets. The third problem is a comment found in this method, which says that a return value of 'null' is considered to be success because of "old asset servers that don't send any reply back". That's a really old comment (from 2009). Can I assume that we no longer need to support such servers and we can treat 'null' as the error value that it is? Oren -------------- next part -------------- An HTML attachment was scrubbed... URL: From melanie at t-data.com Fri Apr 18 09:39:42 2014 From: melanie at t-data.com (Melanie) Date: Fri, 18 Apr 2014 11:39:42 +0200 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: References: Message-ID: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> Hi Oren, I disagree about propagating exceptions. To the caller, asset calls are opaque and cannot fail. There are too many places where exceptions would cause issues and the focus has always been on keeping the sim up and running at almost any cost. That said, no old asset servers (UGAIM) exist anymore, so the comment and the bad handling of null returns should be fixed. I would like to see assets being cached on asset server failure, but then retried using a disk based queue with exponential back-off. Allowing an asset to fail storing is better than having the sim crash, but of course storing it as soon as the asset server is back is preferable. We have something similar, but memory based, for Avination and it has served us well. I believe even our code may still have the bad return calue checking in it. I will see about putting our asset retry code into core as a starting point, then the rough edges can be smoothed and disk based queueing introduced so that assets can be retried even across a simulator restart. - Melanie On 18 Apr 2014, at 10:44, Oren Hurvitz wrote: I have found that when OpenSim tries to store an asset using AssetServicesConnector, it doesn't handle failures well. There are several problems in AssetServicesConnector.Store(), and some of them seem to be based on historical considerations that may no longer be relevant, so I'd like to see if anyone knows about these issues before pushing a change. AssetServicesConnector.Store() uses SynchronousRestObjectRequester to send the request. The first problem is that SynchronousRestObjectRequester.MakeRequest() hides exceptions and just returns null. This is a mistake: MakeRequest() should propagate exceptions, so that callers will know that an error occurred. Store() already catches these exceptions (as it should), so this won't make a big difference in our case. But of course, this change in behavior to MakeRequest() may affect other places in the code as well. It's better to fail-fast when errors occur, and not hide them, because doing so makes the errors much harder to diagnose once they become apparent. This brings me to the next problem... The second problem is that AssetServicesConnector.Store() compares the return value from MakeRequest to string.Empty, but in fact the return value that is returned in case of error is null. So it mistakenly treats 'null' as a valid Asset ID, which causes it to cache the asset. This can cause the operation to appear to have succeeded for a while, since OpenSim will have the asset available, but the moment the asset is loaded from the asset server "the jig is up" and the asset will be missing. This can explain many problems people have had with disappearing assets. The third problem is a comment found in this method, which says that a return value of 'null' is considered to be success because of "old asset servers that don't send any reply back". That's a really old comment (from 2009). Can I assume that we no longer need to support such servers and we can treat 'null' as the error value that it is? Oren _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev From orenh at kitely.com Fri Apr 18 11:05:45 2014 From: orenh at kitely.com (Oren Hurvitz) Date: Fri, 18 Apr 2014 04:05:45 -0700 (PDT) Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> Message-ID: <1397819145848-7579225.post@n2.nabble.com> Regarding the hiding of exceptions: to be clear, I was already bitten by this behavior; that's why I started to investigate how assets are stored. I have therefore already changed Kitely's version of OpenSim to propagate exceptions, and the question is whether other people would like me to contribute this change. If anyone has an opinion then please reply. Regarding your suggestion to save assets to local disk and retry them later: this is basically what a persistent message queue does. If you're going to go that route then it would be best to add a real message queue rather than a home-grown one. I would LOVE it if OpenSim used a message queue for communications, as it would allow ripping out thousands of lines of homemade communications code, and would be faster and more reliable to boot. But that's a bigger issue and I'll put it aside for now. In this particular case, using a persistent message queue isn't be the right solution: the right solution is to report failures immediately. Otherwise you'd get weird behavior such as a user who thinks they've successfully worn a piece of clothing, but when they teleport to another region it disappears because the other region can't load the asset (because it was never saved). To prevent these problems you need to fail-fast, and tell the user immediately when a problem happens. This doesn't mean to crash the sim; I strongly doubt any asset failure would cause that, it would just fail the specific packet or message that is currently being handled, as it should. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Error-detection-when-storing-an-asset-tp7579223p7579225.html Sent from the opensim-dev mailing list archive at Nabble.com. From mike.chase at alternatemetaverse.com Fri Apr 18 11:28:17 2014 From: mike.chase at alternatemetaverse.com (Mike Chase) Date: Fri, 18 Apr 2014 07:28:17 -0400 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: <1397819145848-7579225.post@n2.nabble.com> References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> Message-ID: <030a01cf5af9$4d8126e0$e88374a0$@alternatemetaverse.com> I'm inclined to agree with Oren. Asset Writes could fail for a variety of reasons and there are lots of use cases where you need to know the asset is on disk. I think propagating exceptions is the more sound approach IMO. I also agree re: the custom comms vs a persistent queue mechanism but I don't want to derail this topic. That can wait for another day. Mike -----Original Message----- From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Oren Hurvitz Sent: Friday, April 18, 2014 7:06 AM To: opensim-dev at lists.berlios.de Subject: Re: [Opensim-dev] Error detection when storing an asset Regarding the hiding of exceptions: to be clear, I was already bitten by this behavior; that's why I started to investigate how assets are stored. I have therefore already changed Kitely's version of OpenSim to propagate exceptions, and the question is whether other people would like me to contribute this change. If anyone has an opinion then please reply. Regarding your suggestion to save assets to local disk and retry them later: this is basically what a persistent message queue does. If you're going to go that route then it would be best to add a real message queue rather than a home-grown one. I would LOVE it if OpenSim used a message queue for communications, as it would allow ripping out thousands of lines of homemade communications code, and would be faster and more reliable to boot. But that's a bigger issue and I'll put it aside for now. In this particular case, using a persistent message queue isn't be the right solution: the right solution is to report failures immediately. Otherwise you'd get weird behavior such as a user who thinks they've successfully worn a piece of clothing, but when they teleport to another region it disappears because the other region can't load the asset (because it was never saved). To prevent these problems you need to fail-fast, and tell the user immediately when a problem happens. This doesn't mean to crash the sim; I strongly doubt any asset failure would cause that, it would just fail the specific packet or message that is currently being handled, as it should. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Error-detection-when-storing-an-ass et-tp7579223p7579225.html Sent from the opensim-dev mailing list archive at Nabble.com. _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev From melanie at t-data.com Fri Apr 18 15:23:18 2014 From: melanie at t-data.com (Melanie) Date: Fri, 18 Apr 2014 17:23:18 +0200 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: <1397819145848-7579225.post@n2.nabble.com> References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> Message-ID: In most cases there is no viable failure path that does not detrimentally affect user experience. The viewer is unable to handle asset upload failure gracefully and transparently to the user. As far as messge queues go, I have in-depth knowledge of MQ Series, IBM's message queue service. I agree that such a framework would be beneficial to many communications tasks in OpenSim, but that is, as you say, a matter for another day. The asset subsystem, however, should present an error-free interface to the upper layers, as there is much code that depends on assets never failing and provides no usable error path. Our retry solution combines a good user experience without user visible error messages with a sound subsystem that can tolerate transient erros like asset server failovers, net glitches or temporary overload conditions. Asset writing, btw, is not related to wearing clothing as baked textures do not go to the asset server, but to the XBakes server. In standalones, they are not persisted but are transferred from one region to another. Your obeservation about message queueing is a good one, I may spend a few cycles to see if an appropriately licensed implementation in C# exists. - Melanie On 18 Apr 2014, at 13:05, Oren Hurvitz wrote: Regarding the hiding of exceptions: to be clear, I was already bitten by this behavior; that's why I started to investigate how assets are stored. I have therefore already changed Kitely's version of OpenSim to propagate exceptions, and the question is whether other people would like me to contribute this change. If anyone has an opinion then please reply. Regarding your suggestion to save assets to local disk and retry them later: this is basically what a persistent message queue does. If you're going to go that route then it would be best to add a real message queue rather than a home-grown one. I would LOVE it if OpenSim used a message queue for communications, as it would allow ripping out thousands of lines of homemade communications code, and would be faster and more reliable to boot. But that's a bigger issue and I'll put it aside for now. In this particular case, using a persistent message queue isn't be the right solution: the right solution is to report failures immediately. Otherwise you'd get weird behavior such as a user who thinks they've successfully worn a piece of clothing, but when they teleport to another region it disappears because the other region can't load the asset (because it was never saved). To prevent these problems you need to fail-fast, and tell the user immediately when a problem happens. This doesn't mean to crash the sim; I strongly doubt any asset failure would cause that, it would just fail the specific packet or message that is currently being handled, as it should. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Error-detection-when-storing-an-asset-tp7579223p7579225.html Sent from the opensim-dev mailing list archive at Nabble.com. _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev From ste at smxy.org Fri Apr 18 17:21:46 2014 From: ste at smxy.org (Shaun T. Erickson) Date: Fri, 18 Apr 2014 13:21:46 -0400 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> Message-ID: <53515F2A.3050600@smxy.org> There's also the free ActiveMQ. On 4/18/14, 11:23 AM, Melanie wrote: > MQ Series, IBM's message queue service From mike.chase at alternatemetaverse.com Fri Apr 18 19:13:44 2014 From: mike.chase at alternatemetaverse.com (Mike Chase) Date: Fri, 18 Apr 2014 15:13:44 -0400 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: <53515F2A.3050600@smxy.org> References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> <53515F2A.3050600@smxy.org> Message-ID: <03c701cf5b3a$52527480$f6f75d80$@alternatemetaverse.com> Or RabbitMQ... Or even ZeroMQ if an external MQ service is deemed too heavy. Mike -----Original Message----- From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Shaun T. Erickson Sent: Friday, April 18, 2014 1:22 PM To: opensim-dev at lists.berlios.de Subject: Re: [Opensim-dev] Error detection when storing an asset There's also the free ActiveMQ. On 4/18/14, 11:23 AM, Melanie wrote: > MQ Series, IBM's message queue service _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev From melanie at t-data.com Fri Apr 18 19:40:56 2014 From: melanie at t-data.com (Melanie) Date: Fri, 18 Apr 2014 21:40:56 +0200 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: <030a01cf5af9$4d8126e0$e88374a0$@alternatemetaverse.com> References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> <030a01cf5af9$4d8126e0$e88374a0$@alternatemetaverse.com> Message-ID: <53517FC8.2@t-data.com> Name one valid use case where current OpenSim is able to handle such an exception gracefully, e.g. without user-visible error. - Melanie On 18/04/2014 13:28, Mike Chase wrote: > I'm inclined to agree with Oren. Asset Writes could fail for a variety of > reasons and there are lots of use cases where you need to know the asset is > on disk. I think propagating exceptions is the more sound approach IMO. > > I also agree re: the custom comms vs a persistent queue mechanism but I > don't want to derail this topic. That can wait for another day. > > Mike > > -----Original Message----- > From: opensim-dev-bounces at lists.berlios.de > [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Oren Hurvitz > Sent: Friday, April 18, 2014 7:06 AM > To: opensim-dev at lists.berlios.de > Subject: Re: [Opensim-dev] Error detection when storing an asset > > Regarding the hiding of exceptions: to be clear, I was already bitten by > this behavior; that's why I started to investigate how assets are stored. I > have therefore already changed Kitely's version of OpenSim to propagate > exceptions, and the question is whether other people would like me to > contribute this change. If anyone has an opinion then please reply. > > Regarding your suggestion to save assets to local disk and retry them later: > this is basically what a persistent message queue does. If you're going to > go that route then it would be best to add a real message queue rather than > a home-grown one. I would LOVE it if OpenSim used a message queue for > communications, as it would allow ripping out thousands of lines of homemade > communications code, and would be faster and more reliable to boot. But > that's a bigger issue and I'll put it aside for now. > > In this particular case, using a persistent message queue isn't be the right > solution: the right solution is to report failures immediately. Otherwise > you'd get weird behavior such as a user who thinks they've successfully worn > a piece of clothing, but when they teleport to another region it disappears > because the other region can't load the asset (because it was never saved). > To prevent these problems you need to fail-fast, and tell the user > immediately when a problem happens. This doesn't mean to crash the sim; I > strongly doubt any asset failure would cause that, it would just fail the > specific packet or message that is currently being handled, as it should. > > > > -- > View this message in context: > http://opensim-dev.2196679.n2.nabble.com/Error-detection-when-storing-an-ass > et-tp7579223p7579225.html > Sent from the opensim-dev mailing list archive at Nabble.com. > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > From orenh at kitely.com Fri Apr 18 20:56:54 2014 From: orenh at kitely.com (Oren Hurvitz) Date: Fri, 18 Apr 2014 23:56:54 +0300 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: <53517FC8.2@t-data.com> References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> <030a01cf5af9$4d8126e0$e88374a0$@alternatemetaverse.com> <53517FC8.2@t-data.com> Message-ID: There seems to be a misunderstanding here. We're talking about a case where the operation has FAILED. The only question is whether to pretend that it succeeded, so that the user will find out that it failed later, to their surprise, or to report failure immediately. Obviously it's better to report failure immediately. On Fri, Apr 18, 2014 at 10:40 PM, Melanie wrote: > Name one valid use case where current OpenSim is able to handle such > an exception gracefully, e.g. without user-visible error. > > - Melanie > > On 18/04/2014 13:28, Mike Chase wrote: > > I'm inclined to agree with Oren. Asset Writes could fail for a variety > of > > reasons and there are lots of use cases where you need to know the asset > is > > on disk. I think propagating exceptions is the more sound approach IMO. > > > > I also agree re: the custom comms vs a persistent queue mechanism but I > > don't want to derail this topic. That can wait for another day. > > > > Mike > > > > -----Original Message----- > > From: opensim-dev-bounces at lists.berlios.de > > [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Oren Hurvitz > > Sent: Friday, April 18, 2014 7:06 AM > > To: opensim-dev at lists.berlios.de > > Subject: Re: [Opensim-dev] Error detection when storing an asset > > > > Regarding the hiding of exceptions: to be clear, I was already bitten by > > this behavior; that's why I started to investigate how assets are > stored. I > > have therefore already changed Kitely's version of OpenSim to propagate > > exceptions, and the question is whether other people would like me to > > contribute this change. If anyone has an opinion then please reply. > > > > Regarding your suggestion to save assets to local disk and retry them > later: > > this is basically what a persistent message queue does. If you're going > to > > go that route then it would be best to add a real message queue rather > than > > a home-grown one. I would LOVE it if OpenSim used a message queue for > > communications, as it would allow ripping out thousands of lines of > homemade > > communications code, and would be faster and more reliable to boot. But > > that's a bigger issue and I'll put it aside for now. > > > > In this particular case, using a persistent message queue isn't be the > right > > solution: the right solution is to report failures immediately. Otherwise > > you'd get weird behavior such as a user who thinks they've successfully > worn > > a piece of clothing, but when they teleport to another region it > disappears > > because the other region can't load the asset (because it was never > saved). > > To prevent these problems you need to fail-fast, and tell the user > > immediately when a problem happens. This doesn't mean to crash the sim; I > > strongly doubt any asset failure would cause that, it would just fail the > > specific packet or message that is currently being handled, as it should. > > > > > > > > -- > > View this message in context: > > > http://opensim-dev.2196679.n2.nabble.com/Error-detection-when-storing-an-ass > > et-tp7579223p7579225.html > > Sent from the opensim-dev mailing list archive at Nabble.com. > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- Oren Hurvitz VP R&D Kitely Ltd. Email: orenh at kitely.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From orenh at kitely.com Fri Apr 18 21:23:47 2014 From: orenh at kitely.com (Oren Hurvitz) Date: Sat, 19 Apr 2014 00:23:47 +0300 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: <03c701cf5b3a$52527480$f6f75d80$@alternatemetaverse.com> References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> <53515F2A.3050600@smxy.org> <03c701cf5b3a$52527480$f6f75d80$@alternatemetaverse.com> Message-ID: There are several popular open-source message queues that we could use. If we're going to do that then we need to have an open discussion about the pros and cons of the various packages in order to decide which one to use. In the past I've used JBoss Messaging, but that's been discontinued so it isn't relevant. A big decision will be whether to use a message queue that's completely embedded in OpenSim, or one that runs standalone. OK, I've already said too much; I'm hijacking my own thread... On Fri, Apr 18, 2014 at 10:13 PM, Mike Chase < mike.chase at alternatemetaverse.com> wrote: > Or RabbitMQ... Or even ZeroMQ if an external MQ service is deemed too > heavy. > > Mike > > -----Original Message----- > From: opensim-dev-bounces at lists.berlios.de > [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Shaun T. > Erickson > Sent: Friday, April 18, 2014 1:22 PM > To: opensim-dev at lists.berlios.de > Subject: Re: [Opensim-dev] Error detection when storing an asset > > There's also the free ActiveMQ. > > On 4/18/14, 11:23 AM, Melanie wrote: > > MQ Series, IBM's message queue service > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- Oren Hurvitz VP R&D Kitely Ltd. Email: orenh at kitely.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From melanie at t-data.com Fri Apr 18 21:43:31 2014 From: melanie at t-data.com (Melanie) Date: Fri, 18 Apr 2014 23:43:31 +0200 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> <030a01cf5af9$4d8126e0$e88374a0$@alternatemetaverse.com> <53517FC8.2@t-data.com> Message-ID: <53519C83.60306@t-data.com> The point is no NOT let it fail. Asset storing never fails permanently if it's retried until successful. The upper layers (all the way to the viewer) are not equipped to handle an asset storing failure. Propagating the exception would just annoy the user with needless messages. Since asset servers can be "gone" for a while, for instance when there is a net failure, there is no way to give it a timeout, either. A sim in OSGrid, if it gets disconnected, could run on locally cached assets and manage to reconnect after 20 minutes and simply upload all new assets since then. Screaming "failure" at the user is pointless in such a scenario. - Melanie On 18/04/2014 22:56, Oren Hurvitz wrote: > There seems to be a misunderstanding here. We're talking about a case where > the operation has FAILED. The only question is whether to pretend that it > succeeded, so that the user will find out that it failed later, to their > surprise, or to report failure immediately. Obviously it's better to report > failure immediately. > > > > On Fri, Apr 18, 2014 at 10:40 PM, Melanie wrote: > >> Name one valid use case where current OpenSim is able to handle such >> an exception gracefully, e.g. without user-visible error. >> >> - Melanie >> >> On 18/04/2014 13:28, Mike Chase wrote: >> > I'm inclined to agree with Oren. Asset Writes could fail for a variety >> of >> > reasons and there are lots of use cases where you need to know the asset >> is >> > on disk. I think propagating exceptions is the more sound approach IMO. >> > >> > I also agree re: the custom comms vs a persistent queue mechanism but I >> > don't want to derail this topic. That can wait for another day. >> > >> > Mike >> > >> > -----Original Message----- >> > From: opensim-dev-bounces at lists.berlios.de >> > [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Oren Hurvitz >> > Sent: Friday, April 18, 2014 7:06 AM >> > To: opensim-dev at lists.berlios.de >> > Subject: Re: [Opensim-dev] Error detection when storing an asset >> > >> > Regarding the hiding of exceptions: to be clear, I was already bitten by >> > this behavior; that's why I started to investigate how assets are >> stored. I >> > have therefore already changed Kitely's version of OpenSim to propagate >> > exceptions, and the question is whether other people would like me to >> > contribute this change. If anyone has an opinion then please reply. >> > >> > Regarding your suggestion to save assets to local disk and retry them >> later: >> > this is basically what a persistent message queue does. If you're going >> to >> > go that route then it would be best to add a real message queue rather >> than >> > a home-grown one. I would LOVE it if OpenSim used a message queue for >> > communications, as it would allow ripping out thousands of lines of >> homemade >> > communications code, and would be faster and more reliable to boot. But >> > that's a bigger issue and I'll put it aside for now. >> > >> > In this particular case, using a persistent message queue isn't be the >> right >> > solution: the right solution is to report failures immediately. Otherwise >> > you'd get weird behavior such as a user who thinks they've successfully >> worn >> > a piece of clothing, but when they teleport to another region it >> disappears >> > because the other region can't load the asset (because it was never >> saved). >> > To prevent these problems you need to fail-fast, and tell the user >> > immediately when a problem happens. This doesn't mean to crash the sim; I >> > strongly doubt any asset failure would cause that, it would just fail the >> > specific packet or message that is currently being handled, as it should. >> > >> > >> > >> > -- >> > View this message in context: >> > >> http://opensim-dev.2196679.n2.nabble.com/Error-detection-when-storing-an-ass >> > et-tp7579223p7579225.html >> > Sent from the opensim-dev mailing list archive at Nabble.com. >> > _______________________________________________ >> > Opensim-dev mailing list >> > Opensim-dev at lists.berlios.de >> > https://lists.berlios.de/mailman/listinfo/opensim-dev >> > >> > _______________________________________________ >> > Opensim-dev mailing list >> > Opensim-dev at lists.berlios.de >> > https://lists.berlios.de/mailman/listinfo/opensim-dev >> > >> > >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev From orenh at kitely.com Fri Apr 18 22:12:07 2014 From: orenh at kitely.com (Oren Hurvitz) Date: Sat, 19 Apr 2014 01:12:07 +0300 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: <53519C83.60306@t-data.com> References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> <030a01cf5af9$4d8126e0$e88374a0$@alternatemetaverse.com> <53517FC8.2@t-data.com> <53519C83.60306@t-data.com> Message-ID: I feel that we've transcended from this mortal coil into heavenly spheres. Such powerful realms require poetry to comprehend, so I must quote from the poem "Eloisa to Abelard": "How happy is the blameless vestal's lot! The world forgetting, by the world forgot. Eternal sunshine of the spotless mind! Each pray'r accepted, and each wish resign'd;" To deny failure is to deny reality. On Sat, Apr 19, 2014 at 12:43 AM, Melanie wrote: > The point is no NOT let it fail. Asset storing never fails > permanently if it's retried until successful. The upper layers (all > the way to the viewer) are not equipped to handle an asset storing > failure. Propagating the exception would just annoy the user with > needless messages. Since asset servers can be "gone" for a while, > for instance when there is a net failure, there is no way to give it > a timeout, either. A sim in OSGrid, if it gets disconnected, could > run on locally cached assets and manage to reconnect after 20 > minutes and simply upload all new assets since then. Screaming > "failure" at the user is pointless in such a scenario. > > - Melanie > > On 18/04/2014 22:56, Oren Hurvitz wrote: > > There seems to be a misunderstanding here. We're talking about a case > where > > the operation has FAILED. The only question is whether to pretend that it > > succeeded, so that the user will find out that it failed later, to their > > surprise, or to report failure immediately. Obviously it's better to > report > > failure immediately. > > > > > > > > On Fri, Apr 18, 2014 at 10:40 PM, Melanie wrote: > > > >> Name one valid use case where current OpenSim is able to handle such > >> an exception gracefully, e.g. without user-visible error. > >> > >> - Melanie > >> > >> On 18/04/2014 13:28, Mike Chase wrote: > >> > I'm inclined to agree with Oren. Asset Writes could fail for a > variety > >> of > >> > reasons and there are lots of use cases where you need to know the > asset > >> is > >> > on disk. I think propagating exceptions is the more sound approach > IMO. > >> > > >> > I also agree re: the custom comms vs a persistent queue mechanism but > I > >> > don't want to derail this topic. That can wait for another day. > >> > > >> > Mike > >> > > >> > -----Original Message----- > >> > From: opensim-dev-bounces at lists.berlios.de > >> > [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Oren > Hurvitz > >> > Sent: Friday, April 18, 2014 7:06 AM > >> > To: opensim-dev at lists.berlios.de > >> > Subject: Re: [Opensim-dev] Error detection when storing an asset > >> > > >> > Regarding the hiding of exceptions: to be clear, I was already bitten > by > >> > this behavior; that's why I started to investigate how assets are > >> stored. I > >> > have therefore already changed Kitely's version of OpenSim to > propagate > >> > exceptions, and the question is whether other people would like me to > >> > contribute this change. If anyone has an opinion then please reply. > >> > > >> > Regarding your suggestion to save assets to local disk and retry them > >> later: > >> > this is basically what a persistent message queue does. If you're > going > >> to > >> > go that route then it would be best to add a real message queue rather > >> than > >> > a home-grown one. I would LOVE it if OpenSim used a message queue for > >> > communications, as it would allow ripping out thousands of lines of > >> homemade > >> > communications code, and would be faster and more reliable to boot. > But > >> > that's a bigger issue and I'll put it aside for now. > >> > > >> > In this particular case, using a persistent message queue isn't be the > >> right > >> > solution: the right solution is to report failures immediately. > Otherwise > >> > you'd get weird behavior such as a user who thinks they've > successfully > >> worn > >> > a piece of clothing, but when they teleport to another region it > >> disappears > >> > because the other region can't load the asset (because it was never > >> saved). > >> > To prevent these problems you need to fail-fast, and tell the user > >> > immediately when a problem happens. This doesn't mean to crash the > sim; I > >> > strongly doubt any asset failure would cause that, it would just fail > the > >> > specific packet or message that is currently being handled, as it > should. > >> > > >> > > >> > > >> > -- > >> > View this message in context: > >> > > >> > http://opensim-dev.2196679.n2.nabble.com/Error-detection-when-storing-an-ass > >> > et-tp7579223p7579225.html > >> > Sent from the opensim-dev mailing list archive at Nabble.com. > >> > _______________________________________________ > >> > Opensim-dev mailing list > >> > Opensim-dev at lists.berlios.de > >> > https://lists.berlios.de/mailman/listinfo/opensim-dev > >> > > >> > _______________________________________________ > >> > Opensim-dev mailing list > >> > Opensim-dev at lists.berlios.de > >> > https://lists.berlios.de/mailman/listinfo/opensim-dev > >> > > >> > > >> _______________________________________________ > >> Opensim-dev mailing list > >> Opensim-dev at lists.berlios.de > >> https://lists.berlios.de/mailman/listinfo/opensim-dev > >> > > > > > > > > > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- Oren Hurvitz VP R&D Kitely Ltd. Email: orenh at kitely.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From diva at metaverseink.com Fri Apr 18 22:23:47 2014 From: diva at metaverseink.com (Diva Canto) Date: Fri, 18 Apr 2014 15:23:47 -0700 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> <030a01cf5af9$4d8126e0$e88374a0$@alternatemetaverse.com> <53517FC8.2@t-data.com> <53519C83.60306@t-data.com> Message-ID: <5351A5F3.700@metaverseink.com> There are, nevertheless, different approaches to failure, which sort of correlate with approaches to life in general too :-) - constructivist (if life gives you lemons, make a lemonade) - tantrum (complain loudly and as often as you can) - passive-aggressive (don't say anything when it happens, but make a scene later) - ... Melanie's suggested approach is more along the constructivist side. Tantrums are annoying. On 4/18/2014 3:12 PM, Oren Hurvitz wrote: > I feel that we've transcended from this mortal coil into heavenly > spheres. Such powerful realms require poetry to comprehend, so I must > quote from the poem "Eloisa to Abelard": > > "How happy is the blameless vestal's lot! > The world forgetting, by the world forgot. > Eternal sunshine of the spotless mind! > Each pray'r accepted, and each wish resign'd;" > > To deny failure is to deny reality. > > > > > On Sat, Apr 19, 2014 at 12:43 AM, Melanie > wrote: > > The point is no NOT let it fail. Asset storing never fails > permanently if it's retried until successful. The upper layers (all > the way to the viewer) are not equipped to handle an asset storing > failure. Propagating the exception would just annoy the user with > needless messages. Since asset servers can be "gone" for a while, > for instance when there is a net failure, there is no way to give it > a timeout, either. A sim in OSGrid, if it gets disconnected, could > run on locally cached assets and manage to reconnect after 20 > minutes and simply upload all new assets since then. Screaming > "failure" at the user is pointless in such a scenario. > > - Melanie > > On 18/04/2014 22:56, Oren Hurvitz wrote: > > There seems to be a misunderstanding here. We're talking about a > case where > > the operation has FAILED. The only question is whether to > pretend that it > > succeeded, so that the user will find out that it failed later, > to their > > surprise, or to report failure immediately. Obviously it's > better to report > > failure immediately. > > > > > > > > On Fri, Apr 18, 2014 at 10:40 PM, Melanie > wrote: > > > >> Name one valid use case where current OpenSim is able to handle > such > >> an exception gracefully, e.g. without user-visible error. > >> > >> - Melanie > >> > >> On 18/04/2014 13:28, Mike Chase wrote: > >> > I'm inclined to agree with Oren. Asset Writes could fail for > a variety > >> of > >> > reasons and there are lots of use cases where you need to > know the asset > >> is > >> > on disk. I think propagating exceptions is the more sound > approach IMO. > >> > > >> > I also agree re: the custom comms vs a persistent queue > mechanism but I > >> > don't want to derail this topic. That can wait for another day. > >> > > >> > Mike > >> > > >> > -----Original Message----- > >> > From: opensim-dev-bounces at lists.berlios.de > > >> > [mailto:opensim-dev-bounces at lists.berlios.de > ] On Behalf Of Oren > Hurvitz > >> > Sent: Friday, April 18, 2014 7:06 AM > >> > To: opensim-dev at lists.berlios.de > > >> > Subject: Re: [Opensim-dev] Error detection when storing an asset > >> > > >> > Regarding the hiding of exceptions: to be clear, I was > already bitten by > >> > this behavior; that's why I started to investigate how assets are > >> stored. I > >> > have therefore already changed Kitely's version of OpenSim to > propagate > >> > exceptions, and the question is whether other people would > like me to > >> > contribute this change. If anyone has an opinion then please > reply. > >> > > >> > Regarding your suggestion to save assets to local disk and > retry them > >> later: > >> > this is basically what a persistent message queue does. If > you're going > >> to > >> > go that route then it would be best to add a real message > queue rather > >> than > >> > a home-grown one. I would LOVE it if OpenSim used a message > queue for > >> > communications, as it would allow ripping out thousands of > lines of > >> homemade > >> > communications code, and would be faster and more reliable to > boot. But > >> > that's a bigger issue and I'll put it aside for now. > >> > > >> > In this particular case, using a persistent message queue > isn't be the > >> right > >> > solution: the right solution is to report failures > immediately. Otherwise > >> > you'd get weird behavior such as a user who thinks they've > successfully > >> worn > >> > a piece of clothing, but when they teleport to another region it > >> disappears > >> > because the other region can't load the asset (because it was > never > >> saved). > >> > To prevent these problems you need to fail-fast, and tell the > user > >> > immediately when a problem happens. This doesn't mean to > crash the sim; I > >> > strongly doubt any asset failure would cause that, it would > just fail the > >> > specific packet or message that is currently being handled, > as it should. > >> > > >> > > >> > > >> > -- > >> > View this message in context: > >> > > >> > http://opensim-dev.2196679.n2.nabble.com/Error-detection-when-storing-an-ass > >> > et-tp7579223p7579225.html > >> > Sent from the opensim-dev mailing list archive at Nabble.com. > >> > _______________________________________________ > >> > Opensim-dev mailing list > >> > Opensim-dev at lists.berlios.de > > >> > https://lists.berlios.de/mailman/listinfo/opensim-dev > >> > > >> > _______________________________________________ > >> > Opensim-dev mailing list > >> > Opensim-dev at lists.berlios.de > > >> > https://lists.berlios.de/mailman/listinfo/opensim-dev > >> > > >> > > >> _______________________________________________ > >> Opensim-dev mailing list > >> Opensim-dev at lists.berlios.de > >> https://lists.berlios.de/mailman/listinfo/opensim-dev > >> > > > > > > > > > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > > -- > Oren Hurvitz > VP R&D > Kitely Ltd. > > Email: orenh at kitely.com > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmickeyb at gmail.com Fri Apr 18 22:35:09 2014 From: cmickeyb at gmail.com (Mic Bowman) Date: Fri, 18 Apr 2014 15:35:09 -0700 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> <53515F2A.3050600@smxy.org> <03c701cf5b3a$52527480$f6f75d80$@alternatemetaverse.com> Message-ID: can we please not introduce yet another dependency on an external package? we already have a multiplicity of communication mechanisms & styles and if we are going to canonicalize the whole mess, i would not be in favor of message queues as the means to do that. it wouldn't be all that hard to make a retry mechanism with a local log that wouldn't require the complexity jump of message queues. --mic On Fri, Apr 18, 2014 at 2:23 PM, Oren Hurvitz wrote: > There are several popular open-source message queues that we could use. If > we're going to do that then we need to have an open discussion about the > pros and cons of the various packages in order to decide which one to use. > In the past I've used JBoss Messaging, but that's been discontinued so it > isn't relevant. > > A big decision will be whether to use a message queue that's completely > embedded in OpenSim, or one that runs standalone. OK, I've already said too > much; I'm hijacking my own thread... > > > > On Fri, Apr 18, 2014 at 10:13 PM, Mike Chase < > mike.chase at alternatemetaverse.com> wrote: > >> Or RabbitMQ... Or even ZeroMQ if an external MQ service is deemed too >> heavy. >> >> >> Mike >> >> -----Original Message----- >> From: opensim-dev-bounces at lists.berlios.de >> [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Shaun T. >> Erickson >> Sent: Friday, April 18, 2014 1:22 PM >> To: opensim-dev at lists.berlios.de >> Subject: Re: [Opensim-dev] Error detection when storing an asset >> >> There's also the free ActiveMQ. >> >> On 4/18/14, 11:23 AM, Melanie wrote: >> > MQ Series, IBM's message queue service >> >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > -- > Oren Hurvitz > VP R&D > Kitely Ltd. > > Email: orenh at kitely.com > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jjustincc at googlemail.com Sat Apr 19 01:56:40 2014 From: jjustincc at googlemail.com (Justin Clark-Casey) Date: Sat, 19 Apr 2014 02:56:40 +0100 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: <53519C83.60306@t-data.com> References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> <030a01cf5af9$4d8126e0$e88374a0$@alternatemetaverse.com> <53517FC8.2@t-data.com> <53519C83.60306@t-data.com> Message-ID: <5351D7D8.6090107@googlemail.com> There are always times when failure is permanent. For instance, at the moment if the asset service is full. Even if store and forward were added, unrecoverable failure can still occur if both sides are full. I have had to spend my scarce time dealing with many bugs where the investigation has led to a piece of code that simply swallows its exception, where signalling or logging the error condition would have made the cause of complex problems obvious. So I think that lower level components should always appropriately signal failure or other relevant conditions. It's a different question as to whether the caller thinks it appropriate to notify the user, log the problem or do nothing (though it should always be possible to tell somehow when there is an issue). But the caller should be given the capability to deal with errors or other conditions as appropriate. As for Oren's second issue (null being mistaken as indicating a valid asset), this sounds like a straightforward bug that should be fixed. The 3rd issue, where very old asset servers sent no reply, I agree sounds like something we can risk fixing, as nobody is using (or could use) the old UGAIM pre 0.7 service processes any more. Regarding message queueing, I agree that this would be a great approach. However, OpenSimulator would still need some kind of sqlite equivalent so that it can work out of the box, whilst still being pluggable if someone wants to use a more heavyweight system. The sqlite equivalent must have equivalent support by OpenSimulator, just as the sqlite database plugin should have that today. On 18/04/14 22:43, Melanie wrote: > The point is no NOT let it fail. Asset storing never fails > permanently if it's retried until successful. The upper layers (all > the way to the viewer) are not equipped to handle an asset storing > failure. Propagating the exception would just annoy the user with > needless messages. Since asset servers can be "gone" for a while, > for instance when there is a net failure, there is no way to give it > a timeout, either. A sim in OSGrid, if it gets disconnected, could > run on locally cached assets and manage to reconnect after 20 > minutes and simply upload all new assets since then. Screaming > "failure" at the user is pointless in such a scenario. > > - Melanie > > On 18/04/2014 22:56, Oren Hurvitz wrote: >> There seems to be a misunderstanding here. We're talking about a case where >> the operation has FAILED. The only question is whether to pretend that it >> succeeded, so that the user will find out that it failed later, to their >> surprise, or to report failure immediately. Obviously it's better to report >> failure immediately. >> >> >> >> On Fri, Apr 18, 2014 at 10:40 PM, Melanie wrote: >> >>> Name one valid use case where current OpenSim is able to handle such >>> an exception gracefully, e.g. without user-visible error. >>> >>> - Melanie >>> >>> On 18/04/2014 13:28, Mike Chase wrote: >>>> I'm inclined to agree with Oren. Asset Writes could fail for a variety >>> of >>>> reasons and there are lots of use cases where you need to know the asset >>> is >>>> on disk. I think propagating exceptions is the more sound approach IMO. >>>> >>>> I also agree re: the custom comms vs a persistent queue mechanism but I >>>> don't want to derail this topic. That can wait for another day. >>>> >>>> Mike >>>> >>>> -----Original Message----- >>>> From: opensim-dev-bounces at lists.berlios.de >>>> [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Oren Hurvitz >>>> Sent: Friday, April 18, 2014 7:06 AM >>>> To: opensim-dev at lists.berlios.de >>>> Subject: Re: [Opensim-dev] Error detection when storing an asset >>>> >>>> Regarding the hiding of exceptions: to be clear, I was already bitten by >>>> this behavior; that's why I started to investigate how assets are >>> stored. I >>>> have therefore already changed Kitely's version of OpenSim to propagate >>>> exceptions, and the question is whether other people would like me to >>>> contribute this change. If anyone has an opinion then please reply. >>>> >>>> Regarding your suggestion to save assets to local disk and retry them >>> later: >>>> this is basically what a persistent message queue does. If you're going >>> to >>>> go that route then it would be best to add a real message queue rather >>> than >>>> a home-grown one. I would LOVE it if OpenSim used a message queue for >>>> communications, as it would allow ripping out thousands of lines of >>> homemade >>>> communications code, and would be faster and more reliable to boot. But >>>> that's a bigger issue and I'll put it aside for now. >>>> >>>> In this particular case, using a persistent message queue isn't be the >>> right >>>> solution: the right solution is to report failures immediately. Otherwise >>>> you'd get weird behavior such as a user who thinks they've successfully >>> worn >>>> a piece of clothing, but when they teleport to another region it >>> disappears >>>> because the other region can't load the asset (because it was never >>> saved). >>>> To prevent these problems you need to fail-fast, and tell the user >>>> immediately when a problem happens. This doesn't mean to crash the sim; I >>>> strongly doubt any asset failure would cause that, it would just fail the >>>> specific packet or message that is currently being handled, as it should. >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>>> >>> http://opensim-dev.2196679.n2.nabble.com/Error-detection-when-storing-an-ass >>>> et-tp7579223p7579225.html >>>> Sent from the opensim-dev mailing list archive at Nabble.com. >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> Opensim-dev at lists.berlios.de >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> Opensim-dev at lists.berlios.de >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> >>>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >> >> >> >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > . > -- Justin Clark-Casey (justincc) OSVW Consulting http://justincc.org http://twitter.com/justincc From melanie at t-data.com Sat Apr 19 02:12:09 2014 From: melanie at t-data.com (Melanie) Date: Sat, 19 Apr 2014 04:12:09 +0200 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: <5351D7D8.6090107@googlemail.com> References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> <030a01cf5af9$4d8126e0$e88374a0$@alternatemetaverse.com> <53517FC8.2@t-data.com> <53519C83.60306@t-data.com> <5351D7D8.6090107@googlemail.com> Message-ID: <5351DB79.5060308@t-data.com> The kind of permanent failure scenarios outlined below are a death knell for the affected grid; if the asset server is full, any reasonably sized grid will be inconsistent and irrecoverably damaged in less than a day. Therefore, I postulate that that condition does not need to be covered by extra code that would impair legibility since the affected grid would have been neglectful in not monitoring disk usage. I'm concerned about having to have exception catching and handling in every place Get() is called because that would certainly make the code a lot bulkier and less readable for no real-life gain. In particular, since in most cases no intelligent response is possible, it just means ignoring the exception in multiple places rather than just one. Reporting that kind of error to the user is pointless. There is nothing the user can do to recover. - Melanie On 19/04/2014 03:56, Justin Clark-Casey wrote: > There are always times when failure is permanent. For instance, at the moment if the asset service is full. Even if > store and forward were added, unrecoverable failure can still occur if both sides are full. > > I have had to spend my scarce time dealing with many bugs where the investigation has led to a piece of code that simply > swallows its exception, where signalling or logging the error condition would have made the cause of complex problems > obvious. So I think that lower level components should always appropriately signal failure or other relevant > conditions. It's a different question as to whether the caller thinks it appropriate to notify the user, log the > problem or do nothing (though it should always be possible to tell somehow when there is an issue). But the caller > should be given the capability to deal with errors or other conditions as appropriate. > > As for Oren's second issue (null being mistaken as indicating a valid asset), this sounds like a straightforward bug > that should be fixed. > > The 3rd issue, where very old asset servers sent no reply, I agree sounds like something we can risk fixing, as nobody > is using (or could use) the old UGAIM pre 0.7 service processes any more. > > Regarding message queueing, I agree that this would be a great approach. However, OpenSimulator would still need some > kind of sqlite equivalent so that it can work out of the box, whilst still being pluggable if someone wants to use a > more heavyweight system. The sqlite equivalent must have equivalent support by OpenSimulator, just as the sqlite > database plugin should have that today. > > On 18/04/14 22:43, Melanie wrote: >> The point is no NOT let it fail. Asset storing never fails >> permanently if it's retried until successful. The upper layers (all >> the way to the viewer) are not equipped to handle an asset storing >> failure. Propagating the exception would just annoy the user with >> needless messages. Since asset servers can be "gone" for a while, >> for instance when there is a net failure, there is no way to give it >> a timeout, either. A sim in OSGrid, if it gets disconnected, could >> run on locally cached assets and manage to reconnect after 20 >> minutes and simply upload all new assets since then. Screaming >> "failure" at the user is pointless in such a scenario. >> >> - Melanie >> >> On 18/04/2014 22:56, Oren Hurvitz wrote: >>> There seems to be a misunderstanding here. We're talking about a case where >>> the operation has FAILED. The only question is whether to pretend that it >>> succeeded, so that the user will find out that it failed later, to their >>> surprise, or to report failure immediately. Obviously it's better to report >>> failure immediately. >>> >>> >>> >>> On Fri, Apr 18, 2014 at 10:40 PM, Melanie wrote: >>> >>>> Name one valid use case where current OpenSim is able to handle such >>>> an exception gracefully, e.g. without user-visible error. >>>> >>>> - Melanie >>>> >>>> On 18/04/2014 13:28, Mike Chase wrote: >>>>> I'm inclined to agree with Oren. Asset Writes could fail for a variety >>>> of >>>>> reasons and there are lots of use cases where you need to know the asset >>>> is >>>>> on disk. I think propagating exceptions is the more sound approach IMO. >>>>> >>>>> I also agree re: the custom comms vs a persistent queue mechanism but I >>>>> don't want to derail this topic. That can wait for another day. >>>>> >>>>> Mike >>>>> >>>>> -----Original Message----- >>>>> From: opensim-dev-bounces at lists.berlios.de >>>>> [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Oren Hurvitz >>>>> Sent: Friday, April 18, 2014 7:06 AM >>>>> To: opensim-dev at lists.berlios.de >>>>> Subject: Re: [Opensim-dev] Error detection when storing an asset >>>>> >>>>> Regarding the hiding of exceptions: to be clear, I was already bitten by >>>>> this behavior; that's why I started to investigate how assets are >>>> stored. I >>>>> have therefore already changed Kitely's version of OpenSim to propagate >>>>> exceptions, and the question is whether other people would like me to >>>>> contribute this change. If anyone has an opinion then please reply. >>>>> >>>>> Regarding your suggestion to save assets to local disk and retry them >>>> later: >>>>> this is basically what a persistent message queue does. If you're going >>>> to >>>>> go that route then it would be best to add a real message queue rather >>>> than >>>>> a home-grown one. I would LOVE it if OpenSim used a message queue for >>>>> communications, as it would allow ripping out thousands of lines of >>>> homemade >>>>> communications code, and would be faster and more reliable to boot. But >>>>> that's a bigger issue and I'll put it aside for now. >>>>> >>>>> In this particular case, using a persistent message queue isn't be the >>>> right >>>>> solution: the right solution is to report failures immediately. Otherwise >>>>> you'd get weird behavior such as a user who thinks they've successfully >>>> worn >>>>> a piece of clothing, but when they teleport to another region it >>>> disappears >>>>> because the other region can't load the asset (because it was never >>>> saved). >>>>> To prevent these problems you need to fail-fast, and tell the user >>>>> immediately when a problem happens. This doesn't mean to crash the sim; I >>>>> strongly doubt any asset failure would cause that, it would just fail the >>>>> specific packet or message that is currently being handled, as it should. >>>>> >>>>> >>>>> >>>>> -- >>>>> View this message in context: >>>>> >>>> http://opensim-dev.2196679.n2.nabble.com/Error-detection-when-storing-an-ass >>>>> et-tp7579223p7579225.html >>>>> Sent from the opensim-dev mailing list archive at Nabble.com. >>>>> _______________________________________________ >>>>> Opensim-dev mailing list >>>>> Opensim-dev at lists.berlios.de >>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>>> >>>>> _______________________________________________ >>>>> Opensim-dev mailing list >>>>> Opensim-dev at lists.berlios.de >>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>>> >>>>> >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> Opensim-dev at lists.berlios.de >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> . >> > > From melanie at t-data.com Sat Apr 19 02:20:03 2014 From: melanie at t-data.com (Melanie) Date: Sat, 19 Apr 2014 04:20:03 +0200 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> <53515F2A.3050600@smxy.org> <03c701cf5b3a$52527480$f6f75d80$@alternatemetaverse.com> Message-ID: <5351DD53.5020702@t-data.com> I believe it's no one's intention to do this except as an optional and possibly out of core module. However, the concept is intriguing. - Melanie On 19/04/2014 00:35, Mic Bowman wrote: > can we please not introduce yet another dependency on an external package? > we already have a multiplicity of communication mechanisms & styles and if > we are going to canonicalize the whole mess, i would not be in favor of > message queues as the means to do that. > > it wouldn't be all that hard to make a retry mechanism with a local log > that wouldn't require the complexity jump of message queues. > > --mic > > > > On Fri, Apr 18, 2014 at 2:23 PM, Oren Hurvitz wrote: > >> There are several popular open-source message queues that we could use. If >> we're going to do that then we need to have an open discussion about the >> pros and cons of the various packages in order to decide which one to use. >> In the past I've used JBoss Messaging, but that's been discontinued so it >> isn't relevant. >> >> A big decision will be whether to use a message queue that's completely >> embedded in OpenSim, or one that runs standalone. OK, I've already said too >> much; I'm hijacking my own thread... >> >> >> >> On Fri, Apr 18, 2014 at 10:13 PM, Mike Chase < >> mike.chase at alternatemetaverse.com> wrote: >> >>> Or RabbitMQ... Or even ZeroMQ if an external MQ service is deemed too >>> heavy. >>> >>> >>> Mike >>> >>> -----Original Message----- >>> From: opensim-dev-bounces at lists.berlios.de >>> [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Shaun T. >>> Erickson >>> Sent: Friday, April 18, 2014 1:22 PM >>> To: opensim-dev at lists.berlios.de >>> Subject: Re: [Opensim-dev] Error detection when storing an asset >>> >>> There's also the free ActiveMQ. >>> >>> On 4/18/14, 11:23 AM, Melanie wrote: >>> > MQ Series, IBM's message queue service >>> >>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >> >> >> -- >> Oren Hurvitz >> VP R&D >> Kitely Ltd. >> >> Email: orenh at kitely.com >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev From orenh at kitely.com Sat Apr 19 06:02:00 2014 From: orenh at kitely.com (Oren Hurvitz) Date: Sat, 19 Apr 2014 09:02:00 +0300 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: <5351DB79.5060308@t-data.com> References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> <030a01cf5af9$4d8126e0$e88374a0$@alternatemetaverse.com> <53517FC8.2@t-data.com> <53519C83.60306@t-data.com> <5351D7D8.6090107@googlemail.com> <5351DB79.5060308@t-data.com> Message-ID: My fix has two parts. The first is that the Store() operation needs to understand failures correctly. There has been a consensus that it should, so I'll add that to Git. The second is that MakeRequest() should propagate exceptions, instead of just returning null (which is what it does now). So far there have been 3 votes for this (me, Mike Chase, and Justin) and 2 against (Melanie, Diva). That's very close; does anyone else want to make their position known? Next, I see that there's confusion in this discussion about what happens in Store() if MakeRequest() throws an exception. And the answer is, nothing will be different, because Store() already correctly catches exceptions. That is precisely how it should work: the low-level communications system reports when it has failed, and higher levels (that know the business value of the call) decide how to handle it. However, MakeRequest() is called from other places as well and they might need to be changed to handle exceptions better. -------------- next part -------------- An HTML attachment was scrubbed... URL: From opensim at signpostmarv.name Sat Apr 19 08:11:13 2014 From: opensim at signpostmarv.name (SignpostMarv Martin) Date: Sat, 19 Apr 2014 09:11:13 +0100 Subject: [Opensim-dev] Opensim-Dev closing at Berlios In-Reply-To: <5351D138.6080905@t-data.com> References: <5351D138.6080905@t-data.com> Message-ID: <53522FA1.4050805@signpostmarv.name> No more silly SSL errors to deal with, I guess :P On 19/04/2014 02:28, Melanie wrote: > Hi everyone, > > since Berlios is closing their mailing lists, we have migrated the > lists to our own server. > > The lists at Berlios are now disabled or will shortly be disabled. > Please use this new list for all future postings. > > - Melanie > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > From sphere1952 at gmail.com Sat Apr 19 08:26:18 2014 From: sphere1952 at gmail.com (Jim Williams) Date: Sat, 19 Apr 2014 04:26:18 -0400 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> <030a01cf5af9$4d8126e0$e88374a0$@alternatemetaverse.com> <53517FC8.2@t-data.com> <53519C83.60306@t-data.com> <5351D7D8.6090107@googlemail.com> <5351DB79.5060308@t-data.com> Message-ID: Exceptions have proved to be one of the worst ideas ever added to C++. It's incredibly expensive code all around, from uwninding the stack to handling the exception. Actually, all code ought to be exceptionless by design, but most people never bothered to learn group theory and once you add a single up-chuck (throw) the whole system immediately becomes a mess. On Sat, Apr 19, 2014 at 2:02 AM, Oren Hurvitz wrote: > My fix has two parts. > > The first is that the Store() operation needs to understand failures > correctly. There has been a consensus that it should, so I'll add that to > Git. > > The second is that MakeRequest() should propagate exceptions, instead of > just returning null (which is what it does now). So far there have been 3 > votes for this (me, Mike Chase, and Justin) and 2 against (Melanie, Diva). > That's very close; does anyone else want to make their position known? > > Next, I see that there's confusion in this discussion about what happens > in Store() if MakeRequest() throws an exception. And the answer is, nothing > will be different, because Store() already correctly catches exceptions. > That is precisely how it should work: the low-level communications system > reports when it has failed, and higher levels (that know the business value > of the call) decide how to handle it. However, MakeRequest() is called from > other places as well and they might need to be changed to handle exceptions > better. > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > -- No essence. No permanence. No perfection. Only action. -------------- next part -------------- An HTML attachment was scrubbed... URL: From melanie at t-data.com Sat Apr 19 09:14:46 2014 From: melanie at t-data.com (Melanie) Date: Sat, 19 Apr 2014 11:14:46 +0200 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> <030a01cf5af9$4d8126e0$e88374a0$@alternatemetaverse.com> <53517FC8.2@t-data.com> <53519C83.60306@t-data.com> <5351D7D8.6090107@googlemail.com> <5351DB79.5060308@t-data.com> Message-ID: <1876ECFD-7ED5-49A8-BE26-FEE4A0C011F6@t-data.com> These "other places" are what I'm worried about. There are a lot of them and each of them would need to have code added. Exception handling code is one of the worst types of code because the "try" is a scope, so locals devlared in the try, like bool result = MethodToTry(); will have to be split up into declaring the bool outside the scope and assigning it inside - incredibly ugly for code that wants to be reference and teaching code as well as a functioning system. - Melanie On 19 Apr 2014, at 08:02, Oren Hurvitz wrote: My fix has two parts. The first is that the Store() operation needs to understand failures correctly. There has been a consensus that it should, so I'll add that to Git. The second is that MakeRequest() should propagate exceptions, instead of just returning null (which is what it does now). So far there have been 3 votes for this (me, Mike Chase, and Justin) and 2 against (Melanie, Diva). That's very close; does anyone else want to make their position known? Next, I see that there's confusion in this discussion about what happens in Store() if MakeRequest() throws an exception. And the answer is, nothing will be different, because Store() already correctly catches exceptions. That is precisely how it should work: the low-level communications system reports when it has failed, and higher levels (that know the business value of the call) decide how to handle it. However, MakeRequest() is called from other places as well and they might need to be changed to handle exceptions better. _______________________________________________ Opensim-dev mailing list Opensim-dev at opensimulator.org http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev From trinity93 at gmail.com Mon Apr 21 04:08:31 2014 From: trinity93 at gmail.com (Trinity) Date: Sun, 20 Apr 2014 23:08:31 -0500 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: <1876ECFD-7ED5-49A8-BE26-FEE4A0C011F6@t-data.com> References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> <030a01cf5af9$4d8126e0$e88374a0$@alternatemetaverse.com> <53517FC8.2@t-data.com> <53519C83.60306@t-data.com> <5351D7D8.6090107@googlemail.com> <5351DB79.5060308@t-data.com> <1876ECFD-7ED5-49A8-BE26-FEE4A0C011F6@t-data.com> Message-ID: Im in mels camp on this one. Trinity Bays On Sat, Apr 19, 2014 at 4:14 AM, Melanie wrote: > These "other places" are what I'm worried about. There are a lot of them > and each of them would need to have code added. Exception handling code is > one of the worst types of code because the "try" is a scope, so locals > devlared in the try, like bool result = MethodToTry(); will have to be > split up into declaring the bool outside the scope and assigning it inside > - incredibly ugly for code that wants to be reference and teaching code as > well as a functioning system. > > - Melanie > > On 19 Apr 2014, at 08:02, Oren Hurvitz wrote: > > My fix has two parts. > > The first is that the Store() operation needs to understand failures > correctly. There has been a consensus that it should, so I'll add that to > Git. > > The second is that MakeRequest() should propagate exceptions, instead of > just returning null (which is what it does now). So far there have been 3 > votes for this (me, Mike Chase, and Justin) and 2 against (Melanie, Diva). > That's very close; does anyone else want to make their position known? > > Next, I see that there's confusion in this discussion about what happens > in Store() if MakeRequest() throws an exception. And the answer is, nothing > will be different, because Store() already correctly catches exceptions. > That is precisely how it should work: the low-level communications system > reports when it has failed, and higher levels (that know the business value > of the call) decide how to handle it. However, MakeRequest() is called from > other places as well and they might need to be changed to handle exceptions > better. > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From orenh at kitely.com Mon Apr 21 06:55:06 2014 From: orenh at kitely.com (Oren Hurvitz) Date: Mon, 21 Apr 2014 09:55:06 +0300 Subject: [Opensim-dev] Duplicate entries for Hypergrid users in GridUser table Message-ID: Is this thing on? OK, trying out the new mailing list... The GridUser table contains some information about users: their Online status (in the grid, not globally); home region; etc. For HG-enabled grids this table can contain entries for Hypergrid users: when a user HG-teleports into the grid, an entry is created for them. That entry is kept up-to-date to show the user as Online or Offline. The problem is that HG users are sometimes identified using a UUID, and sometimes using a UUI (Universal User Identifier). For example: UUID: 00000000-0000-0000-0000-000000000000 UUI: 00000000-0000-0000-0000-000000000000; http://grid.example.com:8002/;First Last The GridUser table allows both entries to exist simultaneously. Actually it allows even more than two entries, because multiple UUI's can refer to the same user. This seems to be a mistake: a user can only be online or offline. Was there a reason that multiple entries were allowed? This duplication has caused problems in the past: e.g., a user's status was updated using one of the entries, but then retrieved from a different entry, which didn't reflect the current status. This problem was partially fixed in a patch to GridUserService.cs (Feb 2014) that attempts to always select the same entry for the user (the one with the longest User ID). But this still doesn't fix the problem completely, as it can still return different entries if requests are made using different UUI's. I think that GridUserService should be changed so that it allows only one entry per UUID. It will still store the full UUI if given, but it won't allow multiple UUI's for the same user. Thoughts? Oren -------------- next part -------------- An HTML attachment was scrubbed... URL: From ste at smxy.org Mon Apr 21 14:13:27 2014 From: ste at smxy.org (Shaun T. Erickson) Date: Mon, 21 Apr 2014 10:13:27 -0400 Subject: [Opensim-dev] Duplicate entries for Hypergrid users in GridUser table In-Reply-To: References: Message-ID: <53552787.8090506@smxy.org> I *think* this has to do with the fact that you *are* allowed to log into a grid, as the same avatar, more than once - they just can't be close enough to each other that their root or child agents overlap, or you get a crash. Melanie will tell you that that is by design, and correct, though I know that many disagree that it should be so. Representing an avatar two different ways (UUID and UUI), seems to be wrong though. -ste On 4/21/14, 2:55 AM, Oren Hurvitz wrote: > ... > I think that GridUserService should be changed so that it allows only > one entry per UUID. It will still store the full UUI if given, but it > won't allow multiple UUI's for the same user. Thoughts? From ste at smxy.org Mon Apr 21 14:26:11 2014 From: ste at smxy.org (Shaun T. Erickson) Date: Mon, 21 Apr 2014 10:26:11 -0400 Subject: [Opensim-dev] Duplicate entries for Hypergrid users in GridUser table In-Reply-To: <53552787.8090506@smxy.org> References: <53552787.8090506@smxy.org> Message-ID: <53552A83.4070703@smxy.org> This may or may not be relevant: http://opensimulator.org/mantis/view.php?id=5969 -ste On 4/21/14, 10:13 AM, Shaun T. Erickson wrote: > I *think* this has to do with the fact that you *are* allowed to log > into a grid, as the same avatar, more than once - they just can't be > close enough to each other that their root or child agents overlap, or > you get a crash. > > Melanie will tell you that that is by design, and correct, though I > know that many disagree that it should be so. > > Representing an avatar two different ways (UUID and UUI), seems to be > wrong though. > > -ste > > On 4/21/14, 2:55 AM, Oren Hurvitz wrote: >> ... >> I think that GridUserService should be changed so that it allows only >> one entry per UUID. It will still store the full UUI if given, but it >> won't allow multiple UUI's for the same user. Thoughts? > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev From diva at metaverseink.com Mon Apr 21 14:39:46 2014 From: diva at metaverseink.com (Diva Canto) Date: Mon, 21 Apr 2014 07:39:46 -0700 Subject: [Opensim-dev] Duplicate entries for Hypergrid users in GridUser table In-Reply-To: <53552787.8090506@smxy.org> References: <53552787.8090506@smxy.org> Message-ID: <53552DB2.6050505@metaverseink.com> No, this has nothing to do with multiple presences of the same user. From the GridUserService perspective, I think the idea was for it to be possible to have hg users with the same UUID as a local user. That situation is prevented by the Gatekeeper. However, entries in GridUser don't come solely from actual visits; they can come from other sources (friends, etc., I think), not necessarily users trying to visit. If we decided that we don't ever want to know about foreign users with the same UUID as a local user, which seems reasonable, then GridUser is unnecessarily complicated. So I'm ok with simplifying it. I've had bug grief because of that design decision. On 4/21/2014 7:13 AM, Shaun T. Erickson wrote: > I *think* this has to do with the fact that you *are* allowed to log > into a grid, as the same avatar, more than once - they just can't be > close enough to each other that their root or child agents overlap, or > you get a crash. > > Melanie will tell you that that is by design, and correct, though I > know that many disagree that it should be so. > > Representing an avatar two different ways (UUID and UUI), seems to be > wrong though. > > -ste > > On 4/21/14, 2:55 AM, Oren Hurvitz wrote: >> ... >> I think that GridUserService should be changed so that it allows only >> one entry per UUID. It will still store the full UUI if given, but it >> won't allow multiple UUI's for the same user. Thoughts? > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > From james.stallings at gmail.com Mon Apr 21 14:43:28 2014 From: james.stallings at gmail.com (James Stallings II) Date: Mon, 21 Apr 2014 09:43:28 -0500 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> <030a01cf5af9$4d8126e0$e88374a0$@alternatemetaverse.com> <53517FC8.2@t-data.com> <53519C83.60306@t-data.com> <5351D7D8.6090107@googlemail.com> <5351DB79.5060308@t-data.com> <1876ECFD-7ED5-49A8-BE26-FEE4A0C011F6@t-data.com> Message-ID: Parhaps it would be interesting to hear whether Oren has obtained to some elegant way of addressing these concerns. Cheers On Sun, Apr 20, 2014 at 11:08 PM, Trinity wrote: > Im in mels camp on this one. > > > Trinity Bays > > > On Sat, Apr 19, 2014 at 4:14 AM, Melanie wrote: > >> These "other places" are what I'm worried about. There are a lot of them >> and each of them would need to have code added. Exception handling code is >> one of the worst types of code because the "try" is a scope, so locals >> devlared in the try, like bool result = MethodToTry(); will have to be >> split up into declaring the bool outside the scope and assigning it inside >> - incredibly ugly for code that wants to be reference and teaching code as >> well as a functioning system. >> >> - Melanie >> >> On 19 Apr 2014, at 08:02, Oren Hurvitz wrote: >> >> My fix has two parts. >> >> The first is that the Store() operation needs to understand failures >> correctly. There has been a consensus that it should, so I'll add that to >> Git. >> >> The second is that MakeRequest() should propagate exceptions, instead of >> just returning null (which is what it does now). So far there have been 3 >> votes for this (me, Mike Chase, and Justin) and 2 against (Melanie, Diva). >> That's very close; does anyone else want to make their position known? >> >> Next, I see that there's confusion in this discussion about what happens >> in Store() if MakeRequest() throws an exception. And the answer is, nothing >> will be different, because Store() already correctly catches exceptions. >> That is precisely how it should work: the low-level communications system >> reports when it has failed, and higher levels (that know the business value >> of the call) decide how to handle it. However, MakeRequest() is called from >> other places as well and they might need to be changed to handle exceptions >> better. >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at opensimulator.org >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at opensimulator.org >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ste at smxy.org Mon Apr 21 14:46:11 2014 From: ste at smxy.org (Shaun T. Erickson) Date: Mon, 21 Apr 2014 10:46:11 -0400 Subject: [Opensim-dev] Duplicate entries for Hypergrid users in GridUser table In-Reply-To: <53552DB2.6050505@metaverseink.com> References: <53552787.8090506@smxy.org> <53552DB2.6050505@metaverseink.com> Message-ID: <53552F33.5090204@smxy.org> Creating a local user, with the UUID of a foreign user, is currently one effective way of keeping the foreign user out. -ste On 4/21/14, 10:39 AM, Diva Canto wrote: > If we decided that we don't ever want to know about foreign users with > the same UUID as a local user From sphere1952 at gmail.com Mon Apr 21 14:50:23 2014 From: sphere1952 at gmail.com (Jim Williams) Date: Mon, 21 Apr 2014 10:50:23 -0400 Subject: [Opensim-dev] Duplicate entries for Hypergrid users in GridUser table In-Reply-To: <53552DB2.6050505@metaverseink.com> References: <53552787.8090506@smxy.org> <53552DB2.6050505@metaverseink.com> Message-ID: I will tell you that from the point of view of someone trying to create complex content (scripts) it would be really great to be able to actually log in more than once. I sometimes fake it now by logging into different grids and hyperjumping about. (Doesn't help with the sorting out privs nightmare though....) I can't say that I buy into the argument that you can't do that in RL... so why not? Griefers would have to have extremely impressive hardware to make use of the ability in any "interesting" way. On Mon, Apr 21, 2014 at 10:39 AM, Diva Canto wrote: > No, this has nothing to do with multiple presences of the same user. > > From the GridUserService perspective, I think the idea was for it to be > possible to have hg users with the same UUID as a local user. That > situation is prevented by the Gatekeeper. However, entries in GridUser > don't come solely from actual visits; they can come from other sources > (friends, etc., I think), not necessarily users trying to visit. > > If we decided that we don't ever want to know about foreign users with the > same UUID as a local user, which seems reasonable, then GridUser is > unnecessarily complicated. So I'm ok with simplifying it. I've had bug > grief because of that design decision. > > On 4/21/2014 7:13 AM, Shaun T. Erickson wrote: > >> I *think* this has to do with the fact that you *are* allowed to log into >> a grid, as the same avatar, more than once - they just can't be close >> enough to each other that their root or child agents overlap, or you get a >> crash. >> >> Melanie will tell you that that is by design, and correct, though I know >> that many disagree that it should be so. >> >> Representing an avatar two different ways (UUID and UUI), seems to be >> wrong though. >> >> -ste >> >> On 4/21/14, 2:55 AM, Oren Hurvitz wrote: >> >>> ... >>> I think that GridUserService should be changed so that it allows only >>> one entry per UUID. It will still store the full UUI if given, but it won't >>> allow multiple UUI's for the same user. Thoughts? >>> >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at opensimulator.org >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> >> >> > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > -- No essence. No permanence. No perfection. Only action. -------------- next part -------------- An HTML attachment was scrubbed... URL: From orenh at kitely.com Mon Apr 21 14:54:25 2014 From: orenh at kitely.com (Oren Hurvitz) Date: Mon, 21 Apr 2014 17:54:25 +0300 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> <030a01cf5af9$4d8126e0$e88374a0$@alternatemetaverse.com> <53517FC8.2@t-data.com> <53519C83.60306@t-data.com> <5351D7D8.6090107@googlemail.com> <5351DB79.5060308@t-data.com> <1876ECFD-7ED5-49A8-BE26-FEE4A0C011F6@t-data.com> Message-ID: James, the only philosophical concern that I've heard is a desire to hide errors and present a false facade of 100% success to users. This was obfuscated by an attempt to claim that the errors could someday be fixed automatically, but that doesn't actually happen in today's OpenSim so it's not a valid point. Since I respect my users and value their time I have to let them know when I've failed to complete an action that they requested, so I reject this approach. A second possible objection is a practical one: will propagating exceptions cause other parts of the code, unrelated to the assets service, to fail? I don't know the answer to that, but I still refuse to pretend success in cases where I've failed. For these reasons, I have changed Kitely to propagate exceptions thrown in the communications system; it is already done. If this causes problems then I will see them and fix them. But in view of the surprising and vigorous opposition to this change I will not be contributing it to OpenSim. Oren On Mon, Apr 21, 2014 at 5:43 PM, James Stallings II < james.stallings at gmail.com> wrote: > Parhaps it would be interesting to hear whether Oren has obtained to some > elegant way of addressing these concerns. > > Cheers > > > On Sun, Apr 20, 2014 at 11:08 PM, Trinity wrote: > >> Im in mels camp on this one. >> >> >> Trinity Bays >> >> >> On Sat, Apr 19, 2014 at 4:14 AM, Melanie wrote: >> >>> These "other places" are what I'm worried about. There are a lot of them >>> and each of them would need to have code added. Exception handling code is >>> one of the worst types of code because the "try" is a scope, so locals >>> devlared in the try, like bool result = MethodToTry(); will have to be >>> split up into declaring the bool outside the scope and assigning it inside >>> - incredibly ugly for code that wants to be reference and teaching code as >>> well as a functioning system. >>> >>> - Melanie >>> >>> On 19 Apr 2014, at 08:02, Oren Hurvitz wrote: >>> >>> My fix has two parts. >>> >>> The first is that the Store() operation needs to understand failures >>> correctly. There has been a consensus that it should, so I'll add that to >>> Git. >>> >>> The second is that MakeRequest() should propagate exceptions, instead of >>> just returning null (which is what it does now). So far there have been 3 >>> votes for this (me, Mike Chase, and Justin) and 2 against (Melanie, Diva). >>> That's very close; does anyone else want to make their position known? >>> >>> Next, I see that there's confusion in this discussion about what happens >>> in Store() if MakeRequest() throws an exception. And the answer is, nothing >>> will be different, because Store() already correctly catches exceptions. >>> That is precisely how it should work: the low-level communications system >>> reports when it has failed, and higher levels (that know the business value >>> of the call) decide how to handle it. However, MakeRequest() is called from >>> other places as well and they might need to be changed to handle exceptions >>> better. >>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at opensimulator.org >>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at opensimulator.org >>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>> >> >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at opensimulator.org >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> >> > > > -- > =================================== > http://osgrid.org/ > http://simhost.com > http://twitter.com/jstallings2 > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > -- Oren Hurvitz VP R&D Kitely Ltd. Email: orenh at kitely.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sphere1952 at gmail.com Mon Apr 21 15:02:36 2014 From: sphere1952 at gmail.com (Jim Williams) Date: Mon, 21 Apr 2014 11:02:36 -0400 Subject: [Opensim-dev] Chatter Message-ID: Isn't there a feature freeze in anticipation of release going on? Or am I just confused about how things work here???? -- No essence. No permanence. No perfection. Only action. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.chase at alternatemetaverse.com Mon Apr 21 15:13:01 2014 From: mike.chase at alternatemetaverse.com (Mike Chase) Date: Mon, 21 Apr 2014 11:13:01 -0400 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> <030a01cf5af9$4d8126e0$e88374a0$@alternatemetaverse.com> <53517FC8.2@t-data.com> <53519C83.60306@t-data.com> <5351D7D8.6090107@googlemail.com> <5351DB79.5060308@t-data.com> <1876ECFD-7ED5-49A8-BE26-FEE4A0C011F6@t-data.com> Message-ID: <003501cf5d74$36bfe950$a43fbbf0$@alternatemetaverse.com> That's a shame but I understand. I don't understand the resistance to what I guess I consider good programming practice because there seems to be concern about "fixing" code that might be effected. IMO lower level code should throw exceptions if something exceptional happens and let the upper levels decide to retry or report the error. Mike From: opensim-dev-bounces at opensimulator.org [mailto:opensim-dev-bounces at opensimulator.org] On Behalf Of Oren Hurvitz Sent: Monday, April 21, 2014 10:54 AM To: opensim-dev at opensimulator.org Subject: Re: [Opensim-dev] Error detection when storing an asset James, the only philosophical concern that I've heard is a desire to hide errors and present a false facade of 100% success to users. This was obfuscated by an attempt to claim that the errors could someday be fixed automatically, but that doesn't actually happen in today's OpenSim so it's not a valid point. Since I respect my users and value their time I have to let them know when I've failed to complete an action that they requested, so I reject this approach. A second possible objection is a practical one: will propagating exceptions cause other parts of the code, unrelated to the assets service, to fail? I don't know the answer to that, but I still refuse to pretend success in cases where I've failed. For these reasons, I have changed Kitely to propagate exceptions thrown in the communications system; it is already done. If this causes problems then I will see them and fix them. But in view of the surprising and vigorous opposition to this change I will not be contributing it to OpenSim. Oren On Mon, Apr 21, 2014 at 5:43 PM, James Stallings II > wrote: Parhaps it would be interesting to hear whether Oren has obtained to some elegant way of addressing these concerns. Cheers On Sun, Apr 20, 2014 at 11:08 PM, Trinity > wrote: Im in mels camp on this one. Trinity Bays On Sat, Apr 19, 2014 at 4:14 AM, Melanie > wrote: These "other places" are what I'm worried about. There are a lot of them and each of them would need to have code added. Exception handling code is one of the worst types of code because the "try" is a scope, so locals devlared in the try, like bool result = MethodToTry(); will have to be split up into declaring the bool outside the scope and assigning it inside - incredibly ugly for code that wants to be reference and teaching code as well as a functioning system. - Melanie On 19 Apr 2014, at 08:02, Oren Hurvitz > wrote: My fix has two parts. The first is that the Store() operation needs to understand failures correctly. There has been a consensus that it should, so I'll add that to Git. The second is that MakeRequest() should propagate exceptions, instead of just returning null (which is what it does now). So far there have been 3 votes for this (me, Mike Chase, and Justin) and 2 against (Melanie, Diva). That's very close; does anyone else want to make their position known? Next, I see that there's confusion in this discussion about what happens in Store() if MakeRequest() throws an exception. And the answer is, nothing will be different, because Store() already correctly catches exceptions. That is precisely how it should work: the low-level communications system reports when it has failed, and higher levels (that know the business value of the call) decide how to handle it. However, MakeRequest() is called from other places as well and they might need to be changed to handle exceptions better. _______________________________________________ Opensim-dev mailing list Opensim-dev at opensimulator.org http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list Opensim-dev at opensimulator.org http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list Opensim-dev at opensimulator.org http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 _______________________________________________ Opensim-dev mailing list Opensim-dev at opensimulator.org http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev -- Oren Hurvitz VP R&D Kitely Ltd. Email: orenh at kitely.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.stallings at gmail.com Mon Apr 21 15:13:46 2014 From: james.stallings at gmail.com (James Stallings II) Date: Mon, 21 Apr 2014 10:13:46 -0500 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> <030a01cf5af9$4d8126e0$e88374a0$@alternatemetaverse.com> <53517FC8.2@t-data.com> <53519C83.60306@t-data.com> <5351D7D8.6090107@googlemail.com> <5351DB79.5060308@t-data.com> <1876ECFD-7ED5-49A8-BE26-FEE4A0C011F6@t-data.com> Message-ID: Hi Oren, FWIW, I agree with you completely wrt propagation of exceptions. I am perhaps less concerned about whether this is ever reported to the user in the viewer; that is a question for viewer developers to deliberate and decide. To paraphrase Justin, whether a given piece of affected code handles or ignores those exceptions is a different question entirely. For me, it's about coding philosophy. I am completely against any strategy that hides an error state. A properly handled error state in the asset service might be the thing that first alerts me to an impacted asset server, perhaps buying me sufficient time to deal with it. In any event, I certainly don't want that call being made for me by the programmer in a decision not to properly report an error condition to the calling code. There are a shit-ton of other reasons why this should never be done; but I'm not going to get crazy and start listing them. Those who recognize the problem with doing things this way already know, and the rest are wearing blinders and pedantically following legacy practices. My greater concern is that you will respond to the volume off these objections rather than the number. There are two core dissenters, and they are not superhuman (so neither correct nor otherwise in a state of grace by default), so I would encourage you, if you really do think you have this architectural issue solved, to pursue your case not for your own sake, but for ours. FYI I am not casting a vote as I am not core and so any vote I might cast is not particularly relevant. Cheers James/Hiro On Mon, Apr 21, 2014 at 9:54 AM, Oren Hurvitz wrote: > James, the only philosophical concern that I've heard is a desire to hide > errors and present a false facade of 100% success to users. This was > obfuscated by an attempt to claim that the errors could someday be fixed > automatically, but that doesn't actually happen in today's OpenSim so it's > not a valid point. Since I respect my users and value their time I have to > let them know when I've failed to complete an action that they requested, > so I reject this approach. > > A second possible objection is a practical one: will propagating > exceptions cause other parts of the code, unrelated to the assets service, > to fail? I don't know the answer to that, but I still refuse to pretend > success in cases where I've failed. > > For these reasons, I have changed Kitely to propagate exceptions thrown in > the communications system; it is already done. If this causes problems then > I will see them and fix them. But in view of the surprising and vigorous > opposition to this change I will not be contributing it to OpenSim. > > Oren > > > > On Mon, Apr 21, 2014 at 5:43 PM, James Stallings II < > james.stallings at gmail.com> wrote: > >> Parhaps it would be interesting to hear whether Oren has obtained to some >> elegant way of addressing these concerns. >> >> Cheers >> >> >> On Sun, Apr 20, 2014 at 11:08 PM, Trinity wrote: >> >>> Im in mels camp on this one. >>> >>> >>> Trinity Bays >>> >>> >>> On Sat, Apr 19, 2014 at 4:14 AM, Melanie wrote: >>> >>>> These "other places" are what I'm worried about. There are a lot of >>>> them and each of them would need to have code added. Exception handling >>>> code is one of the worst types of code because the "try" is a scope, so >>>> locals devlared in the try, like bool result = MethodToTry(); will have to >>>> be split up into declaring the bool outside the scope and assigning it >>>> inside - incredibly ugly for code that wants to be reference and teaching >>>> code as well as a functioning system. >>>> >>>> - Melanie >>>> >>>> On 19 Apr 2014, at 08:02, Oren Hurvitz wrote: >>>> >>>> My fix has two parts. >>>> >>>> The first is that the Store() operation needs to understand failures >>>> correctly. There has been a consensus that it should, so I'll add that to >>>> Git. >>>> >>>> The second is that MakeRequest() should propagate exceptions, instead >>>> of just returning null (which is what it does now). So far there have been >>>> 3 votes for this (me, Mike Chase, and Justin) and 2 against (Melanie, >>>> Diva). That's very close; does anyone else want to make their position >>>> known? >>>> >>>> Next, I see that there's confusion in this discussion about what >>>> happens in Store() if MakeRequest() throws an exception. And the answer is, >>>> nothing will be different, because Store() already correctly catches >>>> exceptions. That is precisely how it should work: the low-level >>>> communications system reports when it has failed, and higher levels (that >>>> know the business value of the call) decide how to handle it. However, >>>> MakeRequest() is called from other places as well and they might need to be >>>> changed to handle exceptions better. >>>> >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> Opensim-dev at opensimulator.org >>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> Opensim-dev at opensimulator.org >>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>>> >>> >>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at opensimulator.org >>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>> >>> >> >> >> -- >> =================================== >> http://osgrid.org/ >> http://simhost.com >> http://twitter.com/jstallings2 >> >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at opensimulator.org >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> >> > > > -- > Oren Hurvitz > VP R&D > Kitely Ltd. > > Email: orenh at kitely.com > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.stallings at gmail.com Mon Apr 21 15:15:11 2014 From: james.stallings at gmail.com (James Stallings II) Date: Mon, 21 Apr 2014 10:15:11 -0500 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> <030a01cf5af9$4d8126e0$e88374a0$@alternatemetaverse.com> <53517FC8.2@t-data.com> <53519C83.60306@t-data.com> <5351D7D8.6090107@googlemail.com> <5351DB79.5060308@t-data.com> <1876ECFD-7ED5-49A8-BE26-FEE4A0C011F6@t-data.com> Message-ID: Bah, too bad I cant edit a sent email, as I mangled the last paragraph. The TL;DR: Don't give up so damned easy Oren ;) On Mon, Apr 21, 2014 at 10:13 AM, James Stallings II < james.stallings at gmail.com> wrote: > Hi Oren, > > > FWIW, I agree with you completely wrt propagation of exceptions. I am > perhaps less concerned about whether this is ever reported to the user in > the viewer; that is a question for viewer developers to deliberate and > decide. To paraphrase Justin, whether a given piece of affected code > handles or ignores those exceptions is a different question entirely. For > me, it's about coding philosophy. > > > I am completely against any strategy that hides an error state. A properly > handled error state in the asset service might be the thing that first > alerts me to an impacted asset server, perhaps buying me sufficient time to > deal with it. In any event, I certainly don't want that call being made for > me by the programmer in a decision not to properly report an error > condition to the calling code. There are a shit-ton of other reasons why > this should never be done; but I'm not going to get crazy and start listing > them. Those who recognize the problem with doing things this way already > know, and the rest are wearing blinders and pedantically following legacy > practices. > > > My greater concern is that you will respond to the volume off these > objections rather than the number. There are two core dissenters, and they > are not superhuman (so neither correct nor otherwise in a state of grace by > default), so I would encourage you, if you really do think you have this > architectural issue solved, to pursue your case not for your own sake, but > for ours. > > > FYI I am not casting a vote as I am not core and so any vote I might cast > is not particularly relevant. > > Cheers > James/Hiro > > > On Mon, Apr 21, 2014 at 9:54 AM, Oren Hurvitz wrote: > >> James, the only philosophical concern that I've heard is a desire to hide >> errors and present a false facade of 100% success to users. This was >> obfuscated by an attempt to claim that the errors could someday be fixed >> automatically, but that doesn't actually happen in today's OpenSim so it's >> not a valid point. Since I respect my users and value their time I have to >> let them know when I've failed to complete an action that they requested, >> so I reject this approach. >> >> A second possible objection is a practical one: will propagating >> exceptions cause other parts of the code, unrelated to the assets service, >> to fail? I don't know the answer to that, but I still refuse to pretend >> success in cases where I've failed. >> >> For these reasons, I have changed Kitely to propagate exceptions thrown >> in the communications system; it is already done. If this causes problems >> then I will see them and fix them. But in view of the surprising and >> vigorous opposition to this change I will not be contributing it to OpenSim. >> >> Oren >> >> >> >> On Mon, Apr 21, 2014 at 5:43 PM, James Stallings II < >> james.stallings at gmail.com> wrote: >> >>> Parhaps it would be interesting to hear whether Oren has obtained to >>> some elegant way of addressing these concerns. >>> >>> Cheers >>> >>> >>> On Sun, Apr 20, 2014 at 11:08 PM, Trinity wrote: >>> >>>> Im in mels camp on this one. >>>> >>>> >>>> Trinity Bays >>>> >>>> >>>> On Sat, Apr 19, 2014 at 4:14 AM, Melanie wrote: >>>> >>>>> These "other places" are what I'm worried about. There are a lot of >>>>> them and each of them would need to have code added. Exception handling >>>>> code is one of the worst types of code because the "try" is a scope, so >>>>> locals devlared in the try, like bool result = MethodToTry(); will have to >>>>> be split up into declaring the bool outside the scope and assigning it >>>>> inside - incredibly ugly for code that wants to be reference and teaching >>>>> code as well as a functioning system. >>>>> >>>>> - Melanie >>>>> >>>>> On 19 Apr 2014, at 08:02, Oren Hurvitz wrote: >>>>> >>>>> My fix has two parts. >>>>> >>>>> The first is that the Store() operation needs to understand failures >>>>> correctly. There has been a consensus that it should, so I'll add that to >>>>> Git. >>>>> >>>>> The second is that MakeRequest() should propagate exceptions, instead >>>>> of just returning null (which is what it does now). So far there have been >>>>> 3 votes for this (me, Mike Chase, and Justin) and 2 against (Melanie, >>>>> Diva). That's very close; does anyone else want to make their position >>>>> known? >>>>> >>>>> Next, I see that there's confusion in this discussion about what >>>>> happens in Store() if MakeRequest() throws an exception. And the answer is, >>>>> nothing will be different, because Store() already correctly catches >>>>> exceptions. That is precisely how it should work: the low-level >>>>> communications system reports when it has failed, and higher levels (that >>>>> know the business value of the call) decide how to handle it. However, >>>>> MakeRequest() is called from other places as well and they might need to be >>>>> changed to handle exceptions better. >>>>> >>>>> _______________________________________________ >>>>> Opensim-dev mailing list >>>>> Opensim-dev at opensimulator.org >>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>>>> _______________________________________________ >>>>> Opensim-dev mailing list >>>>> Opensim-dev at opensimulator.org >>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> Opensim-dev at opensimulator.org >>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>>> >>>> >>> >>> >>> -- >>> =================================== >>> http://osgrid.org/ >>> http://simhost.com >>> http://twitter.com/jstallings2 >>> >>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at opensimulator.org >>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>> >>> >> >> >> -- >> Oren Hurvitz >> VP R&D >> Kitely Ltd. >> >> Email: orenh at kitely.com >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at opensimulator.org >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> >> > > > -- > =================================== > http://osgrid.org/ > http://simhost.com > http://twitter.com/jstallings2 > > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ste at smxy.org Mon Apr 21 15:28:21 2014 From: ste at smxy.org (Shaun T. Erickson) Date: Mon, 21 Apr 2014 11:28:21 -0400 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> <030a01cf5af9$4d8126e0$e88374a0$@alternatemetaverse.com> <53517FC8.2@t-data.com> <53519C83.60306@t-data.com> <5351D7D8.6090107@googlemail.com> <5351DB79.5060308@t-data.com> <1876ECFD-7ED5-49A8-BE26-FEE4A0C011F6@t-data.com> Message-ID: <53553915.4010104@smxy.org> What he said. I'd rather see the errors propagated up, rather than ignored, and if that causes other code to require fixing, so much the better. But I also have no official vote and am just a customer of the code. -ste On 4/21/14, 11:15 AM, James Stallings II wrote: > Bah, too bad I cant edit a sent email, as I mangled the last paragraph. > > The TL;DR: > > Don't give up so damned easy Oren ;) From zadarkportal at gmail.com Mon Apr 21 15:36:56 2014 From: zadarkportal at gmail.com (Zadark Portal) Date: Mon, 21 Apr 2014 16:36:56 +0100 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: <53553915.4010104@smxy.org> References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> <030a01cf5af9$4d8126e0$e88374a0$@alternatemetaverse.com> <53517FC8.2@t-data.com> <53519C83.60306@t-data.com> <5351D7D8.6090107@googlemail.com> <5351DB79.5060308@t-data.com> <1876ECFD-7ED5-49A8-BE26-FEE4A0C011F6@t-data.com> <53553915.4010104@smxy.org> Message-ID: I for one welcome the said proposal. Also, it will signal to a congenial user community a positive message that reliability is a priority. Oren++ On 21 April 2014 16:28, Shaun T. Erickson wrote: > What he said. I'd rather see the errors propagated up, rather than > ignored, and if that causes other code to require fixing, so much the > better. But I also have no official vote and am just a customer of the code. > > -ste > > On 4/21/14, 11:15 AM, James Stallings II wrote: > >> Bah, too bad I cant edit a sent email, as I mangled the last paragraph. >> >> The TL;DR: >> >> Don't give up so damned easy Oren ;) >> > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sphere1952 at gmail.com Mon Apr 21 15:57:05 2014 From: sphere1952 at gmail.com (Jim Williams) Date: Mon, 21 Apr 2014 11:57:05 -0400 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: <003501cf5d74$36bfe950$a43fbbf0$@alternatemetaverse.com> References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> <030a01cf5af9$4d8126e0$e88374a0$@alternatemetaverse.com> <53517FC8.2@t-data.com> <53519C83.60306@t-data.com> <5351D7D8.6090107@googlemail.com> <5351DB79.5060308@t-data.com> <1876ECFD-7ED5-49A8-BE26-FEE4A0C011F6@t-data.com> <003501cf5d74$36bfe950$a43fbbf0$@alternatemetaverse.com> Message-ID: No! The lower level code should return what happened, and there is nothing which is "exceptional" except some children; which is the right way to view the notion of exceptions -- dim-witted. Given that the stupid idea was invented, I must admit that sometimes there is no real choice but to accept the crappy code and propagate the crap -- but there is no reason to do so willingly. The try/catch scheme is bad practice. How to deal with the crap that is out there is a matter which can be discussed, but not with the notion that is was done right to begin with. It goes along with thinking that objects are somehow special. Took me years to figure out that objects were simply good programming practice with a bit of crap tossed in to confuse people. (BTW-- I worked at Object Design. I know what a C++ object is better than you do.) On Mon, Apr 21, 2014 at 11:13 AM, Mike Chase < mike.chase at alternatemetaverse.com> wrote: > That?s a shame but I understand. I don?t understand the resistance to > what I guess I consider good programming practice because there seems to be > concern about ?fixing? code that might be effected. IMO lower level code > should throw exceptions if something exceptional happens and let the upper > levels decide to retry or report the error. > > > > Mike > > > > *From:* opensim-dev-bounces at opensimulator.org [mailto: > opensim-dev-bounces at opensimulator.org] *On Behalf Of *Oren Hurvitz > *Sent:* Monday, April 21, 2014 10:54 AM > *To:* opensim-dev at opensimulator.org > *Subject:* Re: [Opensim-dev] Error detection when storing an asset > > > > James, the only philosophical concern that I've heard is a desire to hide > errors and present a false facade of 100% success to users. This was > obfuscated by an attempt to claim that the errors could someday be fixed > automatically, but that doesn't actually happen in today's OpenSim so it's > not a valid point. Since I respect my users and value their time I have to > let them know when I've failed to complete an action that they requested, > so I reject this approach. > > A second possible objection is a practical one: will propagating > exceptions cause other parts of the code, unrelated to the assets service, > to fail? I don't know the answer to that, but I still refuse to pretend > success in cases where I've failed. > > For these reasons, I have changed Kitely to propagate exceptions thrown in > the communications system; it is already done. If this causes problems then > I will see them and fix them. But in view of the surprising and vigorous > opposition to this change I will not be contributing it to OpenSim. > > Oren > > > > On Mon, Apr 21, 2014 at 5:43 PM, James Stallings II < > james.stallings at gmail.com> wrote: > > Parhaps it would be interesting to hear whether Oren has obtained to some > elegant way of addressing these concerns. > > > > Cheers > > > > On Sun, Apr 20, 2014 at 11:08 PM, Trinity wrote: > > Im in mels camp on this one. > > Trinity Bays > > > > On Sat, Apr 19, 2014 at 4:14 AM, Melanie wrote: > > These "other places" are what I'm worried about. There are a lot of them > and each of them would need to have code added. Exception handling code is > one of the worst types of code because the "try" is a scope, so locals > devlared in the try, like bool result = MethodToTry(); will have to be > split up into declaring the bool outside the scope and assigning it inside > - incredibly ugly for code that wants to be reference and teaching code as > well as a functioning system. > > - Melanie > > > On 19 Apr 2014, at 08:02, Oren Hurvitz wrote: > > My fix has two parts. > > The first is that the Store() operation needs to understand failures > correctly. There has been a consensus that it should, so I'll add that to > Git. > > The second is that MakeRequest() should propagate exceptions, instead of > just returning null (which is what it does now). So far there have been 3 > votes for this (me, Mike Chase, and Justin) and 2 against (Melanie, Diva). > That's very close; does anyone else want to make their position known? > > Next, I see that there's confusion in this discussion about what happens > in Store() if MakeRequest() throws an exception. And the answer is, nothing > will be different, because Store() already correctly catches exceptions. > That is precisely how it should work: the low-level communications system > reports when it has failed, and higher levels (that know the business value > of the call) decide how to handle it. However, MakeRequest() is called from > other places as well and they might need to be changed to handle exceptions > better. > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > > > > > -- > > =================================== > > http://osgrid.org/ > http://simhost.com > http://twitter.com/jstallings2 > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > > > > -- > > Oren Hurvitz > VP R&D > Kitely Ltd. > > Email: orenh at kitely.com > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > -- No essence. No permanence. No perfection. Only action. -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.stallings at gmail.com Mon Apr 21 15:58:44 2014 From: james.stallings at gmail.com (James Stallings II) Date: Mon, 21 Apr 2014 10:58:44 -0500 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> <030a01cf5af9$4d8126e0$e88374a0$@alternatemetaverse.com> <53517FC8.2@t-data.com> <53519C83.60306@t-data.com> <5351D7D8.6090107@googlemail.com> <5351DB79.5060308@t-data.com> <1876ECFD-7ED5-49A8-BE26-FEE4A0C011F6@t-data.com> <003501cf5d74$36bfe950$a43fbbf0$@alternatemetaverse.com> Message-ID: Jim, "I know what a C++ object is better than you do." That may well be the case but OpenSimulator is written in C# not C++ On Mon, Apr 21, 2014 at 10:57 AM, Jim Williams wrote: > No! The lower level code should return what happened, and there is > nothing which is "exceptional" except some children; which is the right way > to view the notion of exceptions -- dim-witted. Given that the stupid idea > was invented, I must admit that sometimes there is no real choice but to > accept the crappy code and propagate the crap -- but there is no reason to > do so willingly. The try/catch scheme is bad practice. How to deal with > the crap that is out there is a matter which can be discussed, but not with > the notion that is was done right to begin with. > > It goes along with thinking that objects are somehow special. Took me > years to figure out that objects were simply good programming practice with > a bit of crap tossed in to confuse people. (BTW-- I worked at Object > Design. I know what a C++ object is better than you do.) > > > > > On Mon, Apr 21, 2014 at 11:13 AM, Mike Chase < > mike.chase at alternatemetaverse.com> wrote: > >> That's a shame but I understand. I don't understand the resistance to >> what I guess I consider good programming practice because there seems to be >> concern about "fixing" code that might be effected. IMO lower level code >> should throw exceptions if something exceptional happens and let the upper >> levels decide to retry or report the error. >> >> >> >> Mike >> >> >> >> *From:* opensim-dev-bounces at opensimulator.org [mailto: >> opensim-dev-bounces at opensimulator.org] *On Behalf Of *Oren Hurvitz >> *Sent:* Monday, April 21, 2014 10:54 AM >> *To:* opensim-dev at opensimulator.org >> *Subject:* Re: [Opensim-dev] Error detection when storing an asset >> >> >> >> James, the only philosophical concern that I've heard is a desire to hide >> errors and present a false facade of 100% success to users. This was >> obfuscated by an attempt to claim that the errors could someday be fixed >> automatically, but that doesn't actually happen in today's OpenSim so it's >> not a valid point. Since I respect my users and value their time I have to >> let them know when I've failed to complete an action that they requested, >> so I reject this approach. >> >> A second possible objection is a practical one: will propagating >> exceptions cause other parts of the code, unrelated to the assets service, >> to fail? I don't know the answer to that, but I still refuse to pretend >> success in cases where I've failed. >> >> For these reasons, I have changed Kitely to propagate exceptions thrown >> in the communications system; it is already done. If this causes problems >> then I will see them and fix them. But in view of the surprising and >> vigorous opposition to this change I will not be contributing it to OpenSim. >> >> Oren >> >> >> >> On Mon, Apr 21, 2014 at 5:43 PM, James Stallings II < >> james.stallings at gmail.com> wrote: >> >> Parhaps it would be interesting to hear whether Oren has obtained to some >> elegant way of addressing these concerns. >> >> >> >> Cheers >> >> >> >> On Sun, Apr 20, 2014 at 11:08 PM, Trinity wrote: >> >> Im in mels camp on this one. >> >> Trinity Bays >> >> >> >> On Sat, Apr 19, 2014 at 4:14 AM, Melanie wrote: >> >> These "other places" are what I'm worried about. There are a lot of them >> and each of them would need to have code added. Exception handling code is >> one of the worst types of code because the "try" is a scope, so locals >> devlared in the try, like bool result = MethodToTry(); will have to be >> split up into declaring the bool outside the scope and assigning it inside >> - incredibly ugly for code that wants to be reference and teaching code as >> well as a functioning system. >> >> - Melanie >> >> >> On 19 Apr 2014, at 08:02, Oren Hurvitz wrote: >> >> My fix has two parts. >> >> The first is that the Store() operation needs to understand failures >> correctly. There has been a consensus that it should, so I'll add that to >> Git. >> >> The second is that MakeRequest() should propagate exceptions, instead of >> just returning null (which is what it does now). So far there have been 3 >> votes for this (me, Mike Chase, and Justin) and 2 against (Melanie, Diva). >> That's very close; does anyone else want to make their position known? >> >> Next, I see that there's confusion in this discussion about what happens >> in Store() if MakeRequest() throws an exception. And the answer is, nothing >> will be different, because Store() already correctly catches exceptions. >> That is precisely how it should work: the low-level communications system >> reports when it has failed, and higher levels (that know the business value >> of the call) decide how to handle it. However, MakeRequest() is called from >> other places as well and they might need to be changed to handle exceptions >> better. >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at opensimulator.org >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at opensimulator.org >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> >> >> >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at opensimulator.org >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> >> >> >> >> >> -- >> >> =================================== >> >> http://osgrid.org/ >> http://simhost.com >> http://twitter.com/jstallings2 >> >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at opensimulator.org >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> >> >> >> >> -- >> >> Oren Hurvitz >> VP R&D >> Kitely Ltd. >> >> Email: orenh at kitely.com >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at opensimulator.org >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> >> > > > -- > No essence. No permanence. No perfection. Only action. > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.chase at alternatemetaverse.com Mon Apr 21 16:05:02 2014 From: mike.chase at alternatemetaverse.com (Mike Chase) Date: Mon, 21 Apr 2014 12:05:02 -0400 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> <030a01cf5af9$4d8126e0$e88374a0$@alternatemetaverse.com> <53517FC8.2@t-data.com> <53519C83.60306@t-data.com> <5351D7D8.6090107@googlemail.com> <5351DB79.5060308@t-data.com> <1876ECFD-7ED5-49A8-BE26-FEE4A0C011F6@t-data.com> <003501cf5d74$36bfe950$a43fbbf0$@alternatemetaverse.com> Message-ID: <00aa01cf5d7b$755d8ee0$6018aca0$@alternatemetaverse.com> See below: From: opensim-dev-bounces at opensimulator.org [mailto:opensim-dev-bounces at opensimulator.org] On Behalf Of Jim Williams Sent: Monday, April 21, 2014 11:57 AM To: opensim-dev at opensimulator.org Subject: Re: [Opensim-dev] Error detection when storing an asset No! The lower level code should return what happened, and there is nothing which is "exceptional" except some children; which is the right way to view the notion of exceptions -- dim-witted. Given that the stupid idea was invented, I must admit that sometimes there is no real choice but to accept the crappy code and propagate the crap -- but there is no reason to do so willingly. The try/catch scheme is bad practice. How to deal with the crap that is out there is a matter which can be discussed, but not with the notion that is was done right to begin with. Then design the api to return success/failure as a return result. Point is, you don?t choose to gleefully ignore error details from a lower level. I get that you don?t like exceptions. And that there is long standing religious debates on how they should be used. My point wasn?t so much about the mechanism as the approach. Lower level code returns success/failure and upper level code decides what to do. It goes along with thinking that objects are somehow special. Took me years to figure out that objects were simply good programming practice with a bit of crap tossed in to confuse people. (BTW-- I worked at Object Design. I know what a C++ object is better than you do.) I wouldn?t necessarily make that assumption. You don?t know what I?ve done in my career. I was a long time user of Object Design though and am well aware of the issues it had with exceptions unwinding the stack. Just because C++ exception handling sucked for many years though doesn?t necessarily mean exceptions==bad. Mike P.S. As Hiro pointed out, I?m not a core member just an interested techie with an opinion who is trying to share it. On Mon, Apr 21, 2014 at 11:13 AM, Mike Chase > wrote: That?s a shame but I understand. I don?t understand the resistance to what I guess I consider good programming practice because there seems to be concern about ?fixing? code that might be effected. IMO lower level code should throw exceptions if something exceptional happens and let the upper levels decide to retry or report the error. Mike From: opensim-dev-bounces at opensimulator.org [mailto:opensim-dev-bounces at opensimulator.org ] On Behalf Of Oren Hurvitz Sent: Monday, April 21, 2014 10:54 AM To: opensim-dev at opensimulator.org Subject: Re: [Opensim-dev] Error detection when storing an asset James, the only philosophical concern that I've heard is a desire to hide errors and present a false facade of 100% success to users. This was obfuscated by an attempt to claim that the errors could someday be fixed automatically, but that doesn't actually happen in today's OpenSim so it's not a valid point. Since I respect my users and value their time I have to let them know when I've failed to complete an action that they requested, so I reject this approach. A second possible objection is a practical one: will propagating exceptions cause other parts of the code, unrelated to the assets service, to fail? I don't know the answer to that, but I still refuse to pretend success in cases where I've failed. For these reasons, I have changed Kitely to propagate exceptions thrown in the communications system; it is already done. If this causes problems then I will see them and fix them. But in view of the surprising and vigorous opposition to this change I will not be contributing it to OpenSim. Oren On Mon, Apr 21, 2014 at 5:43 PM, James Stallings II > wrote: Parhaps it would be interesting to hear whether Oren has obtained to some elegant way of addressing these concerns. Cheers On Sun, Apr 20, 2014 at 11:08 PM, Trinity > wrote: Im in mels camp on this one. Trinity Bays On Sat, Apr 19, 2014 at 4:14 AM, Melanie > wrote: These "other places" are what I'm worried about. There are a lot of them and each of them would need to have code added. Exception handling code is one of the worst types of code because the "try" is a scope, so locals devlared in the try, like bool result = MethodToTry(); will have to be split up into declaring the bool outside the scope and assigning it inside - incredibly ugly for code that wants to be reference and teaching code as well as a functioning system. - Melanie On 19 Apr 2014, at 08:02, Oren Hurvitz > wrote: My fix has two parts. The first is that the Store() operation needs to understand failures correctly. There has been a consensus that it should, so I'll add that to Git. The second is that MakeRequest() should propagate exceptions, instead of just returning null (which is what it does now). So far there have been 3 votes for this (me, Mike Chase, and Justin) and 2 against (Melanie, Diva). That's very close; does anyone else want to make their position known? Next, I see that there's confusion in this discussion about what happens in Store() if MakeRequest() throws an exception. And the answer is, nothing will be different, because Store() already correctly catches exceptions. That is precisely how it should work: the low-level communications system reports when it has failed, and higher levels (that know the business value of the call) decide how to handle it. However, MakeRequest() is called from other places as well and they might need to be changed to handle exceptions better. _______________________________________________ Opensim-dev mailing list Opensim-dev at opensimulator.org http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list Opensim-dev at opensimulator.org http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list Opensim-dev at opensimulator.org http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 _______________________________________________ Opensim-dev mailing list Opensim-dev at opensimulator.org http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev -- Oren Hurvitz VP R&D Kitely Ltd. Email: orenh at kitely.com _______________________________________________ Opensim-dev mailing list Opensim-dev at opensimulator.org http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev -- No essence. No permanence. No perfection. Only action. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sphere1952 at gmail.com Mon Apr 21 16:47:32 2014 From: sphere1952 at gmail.com (Jim Williams) Date: Mon, 21 Apr 2014 12:47:32 -0400 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: <00aa01cf5d7b$755d8ee0$6018aca0$@alternatemetaverse.com> References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> <030a01cf5af9$4d8126e0$e88374a0$@alternatemetaverse.com> <53517FC8.2@t-data.com> <53519C83.60306@t-data.com> <5351D7D8.6090107@googlemail.com> <5351DB79.5060308@t-data.com> <1876ECFD-7ED5-49A8-BE26-FEE4A0C011F6@t-data.com> <003501cf5d74$36bfe950$a43fbbf0$@alternatemetaverse.com> <00aa01cf5d7b$755d8ee0$6018aca0$@alternatemetaverse.com> Message-ID: If throws had file scope and the compiler generated a hard error when you didn't catch your own throws I'd say there might be a small argument for the try/retry mechanism, but it is simply subject to abuse, same as operator overloading. A good theory, but a bad fact. Same with most of the religious wars -- we can look at the results now, from the not too bad Javascript (LISP Family) to the obscenity which is Java (PL/I family). I agree that when you have bad code to work with you might have to compromise, but holding one's nose and dealing with uncaught up-chucks is not "good coding practice." It's muddling through when handed crap. I'm not here to "design the api." I''m here because I want to use the product, and I'm finding it very difficult to use. If Opensim was stable I wouldn't have bothered to come looking. I'm still here because -- well.....aren't you going to stop talking about futures and do something about today? Like maybe a feature freeze for release, maybe????? Someone Took over Firestorm about a year ago, and it looks a whole lot better today for the effort. I'd like to see the same for Opensim. What I see now does not make me feel good about my future writing scripts in the Metaverse. Maybe that new company "High Fidelity" will come up with something... On Mon, Apr 21, 2014 at 12:05 PM, Mike Chase < mike.chase at alternatemetaverse.com> wrote: > See below: > > > > *From:* opensim-dev-bounces at opensimulator.org [mailto: > opensim-dev-bounces at opensimulator.org] *On Behalf Of *Jim Williams > *Sent:* Monday, April 21, 2014 11:57 AM > *To:* opensim-dev at opensimulator.org > *Subject:* Re: [Opensim-dev] Error detection when storing an asset > > > > No! The lower level code should return what happened, and there is > nothing which is "exceptional" except some children; which is the right way > to view the notion of exceptions -- dim-witted. Given that the stupid idea > was invented, I must admit that sometimes there is no real choice but to > accept the crappy code and propagate the crap -- but there is no reason to > do so willingly. The try/catch scheme is bad practice. How to deal with > the crap that is out there is a matter which can be discussed, but not with > the notion that is was done right to begin with. > > > > Then design the api to return success/failure as a return result. Point > is, you don?t choose to gleefully ignore error details from a lower level. > I get that you don?t like exceptions. And that there is long standing > religious debates on how they should be used. My point wasn?t so much > about the mechanism as the approach. Lower level code returns > success/failure and upper level code decides what to do. > > > > It goes along with thinking that objects are somehow special. Took me > years to figure out that objects were simply good programming practice with > a bit of crap tossed in to confuse people. (BTW-- I worked at Object > Design. I know what a C++ object is better than you do.) > > > > I wouldn?t necessarily make that assumption. You don?t know what I?ve > done in my career. I was a long time user of Object Design though and am > well aware of the issues it had with exceptions unwinding the stack. Just > because C++ exception handling sucked for many years though doesn?t > necessarily mean exceptions==bad. > > > > Mike > > > > P.S. As Hiro pointed out, I?m not a core member just an interested techie > with an opinion who is trying to share it. > > > > > > On Mon, Apr 21, 2014 at 11:13 AM, Mike Chase < > mike.chase at alternatemetaverse.com> wrote: > > That?s a shame but I understand. I don?t understand the resistance to > what I guess I consider good programming practice because there seems to be > concern about ?fixing? code that might be effected. IMO lower level code > should throw exceptions if something exceptional happens and let the upper > levels decide to retry or report the error. > > > > Mike > > > > *From:* opensim-dev-bounces at opensimulator.org [mailto: > opensim-dev-bounces at opensimulator.org] *On Behalf Of *Oren Hurvitz > *Sent:* Monday, April 21, 2014 10:54 AM > *To:* opensim-dev at opensimulator.org > *Subject:* Re: [Opensim-dev] Error detection when storing an asset > > > > James, the only philosophical concern that I've heard is a desire to hide > errors and present a false facade of 100% success to users. This was > obfuscated by an attempt to claim that the errors could someday be fixed > automatically, but that doesn't actually happen in today's OpenSim so it's > not a valid point. Since I respect my users and value their time I have to > let them know when I've failed to complete an action that they requested, > so I reject this approach. > > A second possible objection is a practical one: will propagating > exceptions cause other parts of the code, unrelated to the assets service, > to fail? I don't know the answer to that, but I still refuse to pretend > success in cases where I've failed. > > For these reasons, I have changed Kitely to propagate exceptions thrown in > the communications system; it is already done. If this causes problems then > I will see them and fix them. But in view of the surprising and vigorous > opposition to this change I will not be contributing it to OpenSim. > > Oren > > > > On Mon, Apr 21, 2014 at 5:43 PM, James Stallings II < > james.stallings at gmail.com> wrote: > > Parhaps it would be interesting to hear whether Oren has obtained to some > elegant way of addressing these concerns. > > > > Cheers > > > > On Sun, Apr 20, 2014 at 11:08 PM, Trinity wrote: > > Im in mels camp on this one. > > Trinity Bays > > > > On Sat, Apr 19, 2014 at 4:14 AM, Melanie wrote: > > These "other places" are what I'm worried about. There are a lot of them > and each of them would need to have code added. Exception handling code is > one of the worst types of code because the "try" is a scope, so locals > devlared in the try, like bool result = MethodToTry(); will have to be > split up into declaring the bool outside the scope and assigning it inside > - incredibly ugly for code that wants to be reference and teaching code as > well as a functioning system. > > - Melanie > > > On 19 Apr 2014, at 08:02, Oren Hurvitz wrote: > > My fix has two parts. > > The first is that the Store() operation needs to understand failures > correctly. There has been a consensus that it should, so I'll add that to > Git. > > The second is that MakeRequest() should propagate exceptions, instead of > just returning null (which is what it does now). So far there have been 3 > votes for this (me, Mike Chase, and Justin) and 2 against (Melanie, Diva). > That's very close; does anyone else want to make their position known? > > Next, I see that there's confusion in this discussion about what happens > in Store() if MakeRequest() throws an exception. And the answer is, nothing > will be different, because Store() already correctly catches exceptions. > That is precisely how it should work: the low-level communications system > reports when it has failed, and higher levels (that know the business value > of the call) decide how to handle it. However, MakeRequest() is called from > other places as well and they might need to be changed to handle exceptions > better. > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > > > > > -- > > =================================== > > http://osgrid.org/ > http://simhost.com > http://twitter.com/jstallings2 > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > > > > -- > > Oren Hurvitz > VP R&D > Kitely Ltd. > > Email: orenh at kitely.com > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > > > > > -- > No essence. No permanence. No perfection. Only action. > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > -- No essence. No permanence. No perfection. Only action. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sphere1952 at gmail.com Mon Apr 21 17:23:46 2014 From: sphere1952 at gmail.com (Jim Williams) Date: Mon, 21 Apr 2014 13:23:46 -0400 Subject: [Opensim-dev] Error detection when storing an asset In-Reply-To: <003501cf5d74$36bfe950$a43fbbf0$@alternatemetaverse.com> References: <4E4F47CA-6CCD-4296-9615-6BE921FC1349@t-data.com> <1397819145848-7579225.post@n2.nabble.com> <030a01cf5af9$4d8126e0$e88374a0$@alternatemetaverse.com> <53517FC8.2@t-data.com> <53519C83.60306@t-data.com> <5351D7D8.6090107@googlemail.com> <5351DB79.5060308@t-data.com> <1876ECFD-7ED5-49A8-BE26-FEE4A0C011F6@t-data.com> <003501cf5d74$36bfe950$a43fbbf0$@alternatemetaverse.com> Message-ID: " IMO lower level code should throw exceptions if something exceptional happens and let the upper levels decide to retry or report the error." If this was good programming practice then we wouldn't be having this discussion. I'd agree about it if exceptions would only remain exceptional. but programmer's are lazy bastards and will abuse every feature offered to them whenever possible. I'd argue that the code shouldn't know it is lower level, and ought to be written defensively. I watched overspecifed X.400 being blown away by loosy-goosy SMTP precisely because every X.400 vendor thought they were right and every SMTP installation had to deal with whatever came its way. Opensim is very fragile, and up-chucking exceptions is bound to be part of the problem. On Mon, Apr 21, 2014 at 11:13 AM, Mike Chase < mike.chase at alternatemetaverse.com> wrote: > That?s a shame but I understand. I don?t understand the resistance to > what I guess I consider good programming practice because there seems to be > concern about ?fixing? code that might be effected. IMO lower level code > should throw exceptions if something exceptional happens and let the upper > levels decide to retry or report the error. > > > > Mike > > > > *From:* opensim-dev-bounces at opensimulator.org [mailto: > opensim-dev-bounces at opensimulator.org] *On Behalf Of *Oren Hurvitz > *Sent:* Monday, April 21, 2014 10:54 AM > *To:* opensim-dev at opensimulator.org > *Subject:* Re: [Opensim-dev] Error detection when storing an asset > > > > James, the only philosophical concern that I've heard is a desire to hide > errors and present a false facade of 100% success to users. This was > obfuscated by an attempt to claim that the errors could someday be fixed > automatically, but that doesn't actually happen in today's OpenSim so it's > not a valid point. Since I respect my users and value their time I have to > let them know when I've failed to complete an action that they requested, > so I reject this approach. > > A second possible objection is a practical one: will propagating > exceptions cause other parts of the code, unrelated to the assets service, > to fail? I don't know the answer to that, but I still refuse to pretend > success in cases where I've failed. > > For these reasons, I have changed Kitely to propagate exceptions thrown in > the communications system; it is already done. If this causes problems then > I will see them and fix them. But in view of the surprising and vigorous > opposition to this change I will not be contributing it to OpenSim. > > Oren > > > > On Mon, Apr 21, 2014 at 5:43 PM, James Stallings II < > james.stallings at gmail.com> wrote: > > Parhaps it would be interesting to hear whether Oren has obtained to some > elegant way of addressing these concerns. > > > > Cheers > > > > On Sun, Apr 20, 2014 at 11:08 PM, Trinity wrote: > > Im in mels camp on this one. > > Trinity Bays > > > > On Sat, Apr 19, 2014 at 4:14 AM, Melanie wrote: > > These "other places" are what I'm worried about. There are a lot of them > and each of them would need to have code added. Exception handling code is > one of the worst types of code because the "try" is a scope, so locals > devlared in the try, like bool result = MethodToTry(); will have to be > split up into declaring the bool outside the scope and assigning it inside > - incredibly ugly for code that wants to be reference and teaching code as > well as a functioning system. > > - Melanie > > > On 19 Apr 2014, at 08:02, Oren Hurvitz wrote: > > My fix has two parts. > > The first is that the Store() operation needs to understand failures > correctly. There has been a consensus that it should, so I'll add that to > Git. > > The second is that MakeRequest() should propagate exceptions, instead of > just returning null (which is what it does now). So far there have been 3 > votes for this (me, Mike Chase, and Justin) and 2 against (Melanie, Diva). > That's very close; does anyone else want to make their position known? > > Next, I see that there's confusion in this discussion about what happens > in Store() if MakeRequest() throws an exception. And the answer is, nothing > will be different, because Store() already correctly catches exceptions. > That is precisely how it should work: the low-level communications system > reports when it has failed, and higher levels (that know the business value > of the call) decide how to handle it. However, MakeRequest() is called from > other places as well and they might need to be changed to handle exceptions > better. > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > > > > > -- > > =================================== > > http://osgrid.org/ > http://simhost.com > http://twitter.com/jstallings2 > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > > > > -- > > Oren Hurvitz > VP R&D > Kitely Ltd. > > Email: orenh at kitely.com > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > -- No essence. No permanence. No perfection. Only action. -------------- next part -------------- An HTML attachment was scrubbed... URL: From orenh at kitely.com Tue Apr 22 08:16:19 2014 From: orenh at kitely.com (Oren Hurvitz) Date: Tue, 22 Apr 2014 11:16:19 +0300 Subject: [Opensim-dev] Questions about dynamic textures Message-ID: I have a few questions about dynamic textures - see http://opensimulator.org/wiki/Dynamic_textures First, the Wiki says "The textures thus created are temporary". But in DynamicTextureModule.DataReceived(), the asset that is created has Local=false. It has an option to use Temporary=true, but that's not always used (I've got examples that don't use it). Second, I see attempts to delete these dynamic texture. But the asset server doesn't allow deleting assets (except for very specific cases), so these attempts fail. Of course, if the assets were actually temporary then this wouldn't be a problem. So, shouldn't dynamic textures be created with Local=true? Oren -- Oren Hurvitz VP R&D Kitely Ltd. Email: orenh at kitely.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From melanie at t-data.com Tue Apr 22 08:46:36 2014 From: melanie at t-data.com (Melanie) Date: Tue, 22 Apr 2014 10:46:36 +0200 Subject: [Opensim-dev] Questions about dynamic textures In-Reply-To: References: Message-ID: <53562C6C.6060806@t-data.com> Yes, they should be. They're not supposed to ever go to the asset server. - Melanie On 22/04/2014 10:16, Oren Hurvitz wrote: > I have a few questions about dynamic textures - see > http://opensimulator.org/wiki/Dynamic_textures > > First, the Wiki says "The textures thus created are temporary". But in > DynamicTextureModule.DataReceived(), the asset that is created has > Local=false. It has an option to use Temporary=true, but that's not always > used (I've got examples that don't use it). > > Second, I see attempts to delete these dynamic texture. But the asset > server doesn't allow deleting assets (except for very specific cases), so > these attempts fail. Of course, if the assets were actually temporary then > this wouldn't be a problem. > > So, shouldn't dynamic textures be created with Local=true? > > Oren > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev From orenh at kitely.com Tue Apr 22 16:55:46 2014 From: orenh at kitely.com (Oren Hurvitz) Date: Tue, 22 Apr 2014 19:55:46 +0300 Subject: [Opensim-dev] SQLite doen't need Community.CsharpSqlite.dll? Message-ID: I'm working on eliminating warnings. A few of the warnings had to do with SQLite (the precise warnings aren't important, but they had to do with a DLL that reimplements System.Func). I found that I can eliminate the warnings if I remove the following lines from prebuild.xml: This doesn't seem to have broken SQLite, because I ran the unit tests afterwards (which use SQLite), and they still ran fine. By the way, the second of these two lines was *already* in error: because there's no backslash after "bin", the resulting reference was invalid. Does anyone know of a reason why these references should stay? Oren -------------- next part -------------- An HTML attachment was scrubbed... URL: From melanie at t-data.com Tue Apr 22 17:28:00 2014 From: melanie at t-data.com (Melanie) Date: Tue, 22 Apr 2014 19:28:00 +0200 Subject: [Opensim-dev] SQLite doen't need Community.CsharpSqlite.dll? In-Reply-To: References: Message-ID: <5356A6A0.8020303@t-data.com> If OpenSim will compile and run on all supported platforms without it, then it's not needed and can be dropped. In that case the binary should also be removed from bin/ - Melanie On 22/04/2014 18:55, Oren Hurvitz wrote: > I'm working on eliminating warnings. A few of the warnings had to do with > SQLite (the precise warnings aren't important, but they had to do with a > DLL that reimplements System.Func). I found that I can eliminate the > warnings if I remove the following lines from prebuild.xml: > > > > > This doesn't seem to have broken SQLite, because I ran the unit tests > afterwards (which use SQLite), and they still ran fine. > > By the way, the second of these two lines was *already* in error: because > there's no backslash after "bin", the resulting reference was invalid. > > Does anyone know of a reason why these references should stay? > > Oren > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev From jjustincc at googlemail.com Wed Apr 23 19:32:55 2014 From: jjustincc at googlemail.com (Justin Clark-Casey) Date: Wed, 23 Apr 2014 20:32:55 +0100 Subject: [Opensim-dev] SQLite doen't need Community.CsharpSqlite.dll? In-Reply-To: <5356A6A0.8020303@t-data.com> References: <5356A6A0.8020303@t-data.com> Message-ID: <53581567.2060505@googlemail.com> afair, CSharpSQLite was something that Teravus was experimenting with for SQLite support that we did not end up using. So yes, it's quite correct to remove it. On 22/04/14 18:28, Melanie wrote: > If OpenSim will compile and run on all supported platforms without > it, then it's not needed and can be dropped. In that case the binary > should also be removed from bin/ > > - Melanie > > On 22/04/2014 18:55, Oren Hurvitz wrote: >> I'm working on eliminating warnings. A few of the warnings had to do with >> SQLite (the precise warnings aren't important, but they had to do with a >> DLL that reimplements System.Func). I found that I can eliminate the >> warnings if I remove the following lines from prebuild.xml: >> >> >> >> >> This doesn't seem to have broken SQLite, because I ran the unit tests >> afterwards (which use SQLite), and they still ran fine. >> >> By the way, the second of these two lines was *already* in error: because >> there's no backslash after "bin", the resulting reference was invalid. >> >> Does anyone know of a reason why these references should stay? >> >> Oren >> >> >> >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at opensimulator.org >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > -- Justin Clark-Casey (justincc) OSVW Consulting http://justincc.org http://twitter.com/justincc From jjustincc at googlemail.com Thu Apr 24 22:32:49 2014 From: jjustincc at googlemail.com (Justin Clark-Casey) Date: Thu, 24 Apr 2014 23:32:49 +0100 Subject: [Opensim-dev] Negative z values Message-ID: <53599111.8080005@googlemail.com> Hi folks. Historically, whether by accident or design, OpenSimulator has allowed negative Z values for terrain, objects and avatars (e.g. <130, 50, -45>. I have seen people use this facility to build fully underwater or partially underwater structures (e.g. oil rigs, sunken ships, etc.) which are conceptually far below the water line without having to set that water line at a level that may be way above that of surrounding regions. However, at least on Singularity 1.8.5 on Linux, fog effects do not work properly when z < 0, where all view distances have very high fog no matter what the fog settings. This may be a recent change - I remember fog working properly at negative z values in the past, though the fog issue still occurred past a certain -ve z. There may be other issues of which I'm not aware. Arguably, these are not bugs since the Linden Grid does not allow z < 0 (though one could make the same argument for var regions, etc.). With in-world testing of current development code, BulletSim appears to have a hard-coded check where I can't move my avatar below z == 2 whether terrain is z < 0 or not (this should probably at least be fixed so z = 0 is possible). ODE has allowed and still allows the avatar to descend to negative depths. One argument is that in the light of such bugs, it would be better to consistently enforce z >= 0 and require people with -z builds to either move them and the water level up using OpenSimulator commands (e.g. "translate scene") or never update their OpenSimulator installation. However, I think there is a real value in keeping the -ve z ability. It allows people to extend deep water builds without having to adjust any neighbouring sims for consistency (which they may not have control over). I'm sure it's possible to address the viewer-side issues. OpenSimulator could have an allow-negative-z flag which is false by default to make it explicit that using -ve z may have issues at this time. I accept this is a more complicated solution than enforcing z == 0, though enforcing z == 0 will also requires many changes to the current code where bounds are not checked. If my experience is unusual and -z builds are very rare then there's more of a case for enforcing z >= 0. Thoughts? -- Justin Clark-Casey (justincc) OSVW Consulting http://justincc.org http://twitter.com/justincc From melanie at t-data.com Thu Apr 24 22:46:16 2014 From: melanie at t-data.com (Melanie) Date: Fri, 25 Apr 2014 00:46:16 +0200 Subject: [Opensim-dev] Negative z values In-Reply-To: <53599111.8080005@googlemail.com> References: <53599111.8080005@googlemail.com> Message-ID: <53599438.1000400@t-data.com> I have never seen a Z < 0 build. I see lots of problems that may be possible with this, but I think that quite beautiful and interesting builds could make use of this and would support keeping it. The change in the viewer is recent and likely trivial to undo. - Melanie On 25/04/2014 00:32, Justin Clark-Casey wrote: > Hi folks. Historically, whether by accident or design, OpenSimulator has allowed negative Z values for terrain, objects > and avatars (e.g. <130, 50, -45>. I have seen people use this facility to build fully underwater or partially > underwater structures (e.g. oil rigs, sunken ships, etc.) which are conceptually far below the water line without having > to set that water line at a level that may be way above that of surrounding regions. > > However, at least on Singularity 1.8.5 on Linux, fog effects do not work properly when z < 0, where all view distances > have very high fog no matter what the fog settings. This may be a recent change - I remember fog working properly at > negative z values in the past, though the fog issue still occurred past a certain -ve z. There may be other issues of > which I'm not aware. Arguably, these are not bugs since the Linden Grid does not allow z < 0 (though one could make the > same argument for var regions, etc.). > > With in-world testing of current development code, BulletSim appears to have a hard-coded check where I can't move my > avatar below z == 2 whether terrain is z < 0 or not (this should probably at least be fixed so z = 0 is possible). ODE > has allowed and still allows the avatar to descend to negative depths. > > One argument is that in the light of such bugs, it would be better to consistently enforce z >= 0 and require people > with -z builds to either move them and the water level up using OpenSimulator commands (e.g. "translate scene") or never > update their OpenSimulator installation. > > However, I think there is a real value in keeping the -ve z ability. It allows people to extend deep water builds > without having to adjust any neighbouring sims for consistency (which they may not have control over). I'm sure it's > possible to address the viewer-side issues. OpenSimulator could have an allow-negative-z flag which is false by default > to make it explicit that using -ve z may have issues at this time. I accept this is a more complicated solution than > enforcing z == 0, though enforcing z == 0 will also requires many changes to the current code where bounds are not checked. > > If my experience is unusual and -z builds are very rare then there's more of a case for enforcing z >= 0. > > Thoughts? > From sphere1952 at gmail.com Fri Apr 25 00:16:50 2014 From: sphere1952 at gmail.com (Jim Williams) Date: Thu, 24 Apr 2014 20:16:50 -0400 Subject: [Opensim-dev] Negative z values In-Reply-To: <53599438.1000400@t-data.com> References: <53599111.8080005@googlemail.com> <53599438.1000400@t-data.com> Message-ID: Seems to me that 0 is a completely arbitrary number and that a cut-off for any reason other than hardware/mathematical limitations is unwarranted. I could see taking an "oh well" attitude about things that don't work with -z, but declaring the Metaverse to simply end at 0 seems very random. On Thu, Apr 24, 2014 at 6:46 PM, Melanie wrote: > I have never seen a Z < 0 build. I see lots of problems that may be > possible with this, but I think that quite beautiful and interesting > builds could make use of this and would support keeping it. The > change in the viewer is recent and likely trivial to undo. > > - Melanie > > On 25/04/2014 00:32, Justin Clark-Casey wrote: > > Hi folks. Historically, whether by accident or design, OpenSimulator > has allowed negative Z values for terrain, objects > > and avatars (e.g. <130, 50, -45>. I have seen people use this facility > to build fully underwater or partially > > underwater structures (e.g. oil rigs, sunken ships, etc.) which are > conceptually far below the water line without having > > to set that water line at a level that may be way above that of > surrounding regions. > > > > However, at least on Singularity 1.8.5 on Linux, fog effects do not work > properly when z < 0, where all view distances > > have very high fog no matter what the fog settings. This may be a > recent change - I remember fog working properly at > > negative z values in the past, though the fog issue still occurred past > a certain -ve z. There may be other issues of > > which I'm not aware. Arguably, these are not bugs since the Linden Grid > does not allow z < 0 (though one could make the > > same argument for var regions, etc.). > > > > With in-world testing of current development code, BulletSim appears to > have a hard-coded check where I can't move my > > avatar below z == 2 whether terrain is z < 0 or not (this should > probably at least be fixed so z = 0 is possible). ODE > > has allowed and still allows the avatar to descend to negative depths. > > > > One argument is that in the light of such bugs, it would be better to > consistently enforce z >= 0 and require people > > with -z builds to either move them and the water level up using > OpenSimulator commands (e.g. "translate scene") or never > > update their OpenSimulator installation. > > > > However, I think there is a real value in keeping the -ve z ability. It > allows people to extend deep water builds > > without having to adjust any neighbouring sims for consistency (which > they may not have control over). I'm sure it's > > possible to address the viewer-side issues. OpenSimulator could have an > allow-negative-z flag which is false by default > > to make it explicit that using -ve z may have issues at this time. I > accept this is a more complicated solution than > > enforcing z == 0, though enforcing z == 0 will also requires many > changes to the current code where bounds are not checked. > > > > If my experience is unusual and -z builds are very rare then there's > more of a case for enforcing z >= 0. > > > > Thoughts? > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > -- No essence. No permanence. No perfection. Only action. -------------- next part -------------- An HTML attachment was scrubbed... URL: From melanie at t-data.com Fri Apr 25 00:23:01 2014 From: melanie at t-data.com (Melanie) Date: Fri, 25 Apr 2014 02:23:01 +0200 Subject: [Opensim-dev] Negative z values In-Reply-To: References: <53599111.8080005@googlemail.com> <53599438.1000400@t-data.com> Message-ID: <5359AAE5.1080104@t-data.com> There are potential issues with code/tools written with the notion that the metaverse indeed ends at 0, but I believe they can be overcome. In this vein, there is another "feature" we may want to push for: Raw files allow specifying a water height for each 4x4 m square, but currently regions only have a notion of water level for the entire region, taken from the 0,0 coordinate of the water level layer in the raw file. I believe full support for a water height map (including Z < 0 depths) would be an advantage of opensim over SL, as SL currently struggles with basements, subway tunnels and mountain lakes. - Melanie On 25/04/2014 02:16, Jim Williams wrote: > Seems to me that 0 is a completely arbitrary number and that a cut-off for > any reason other than hardware/mathematical limitations is unwarranted. I > could see taking an "oh well" attitude about things that don't work with > -z, but declaring the Metaverse to simply end at 0 seems very random. > > > On Thu, Apr 24, 2014 at 6:46 PM, Melanie wrote: > >> I have never seen a Z < 0 build. I see lots of problems that may be >> possible with this, but I think that quite beautiful and interesting >> builds could make use of this and would support keeping it. The >> change in the viewer is recent and likely trivial to undo. >> >> - Melanie >> >> On 25/04/2014 00:32, Justin Clark-Casey wrote: >> > Hi folks. Historically, whether by accident or design, OpenSimulator >> has allowed negative Z values for terrain, objects >> > and avatars (e.g. <130, 50, -45>. I have seen people use this facility >> to build fully underwater or partially >> > underwater structures (e.g. oil rigs, sunken ships, etc.) which are >> conceptually far below the water line without having >> > to set that water line at a level that may be way above that of >> surrounding regions. >> > >> > However, at least on Singularity 1.8.5 on Linux, fog effects do not work >> properly when z < 0, where all view distances >> > have very high fog no matter what the fog settings. This may be a >> recent change - I remember fog working properly at >> > negative z values in the past, though the fog issue still occurred past >> a certain -ve z. There may be other issues of >> > which I'm not aware. Arguably, these are not bugs since the Linden Grid >> does not allow z < 0 (though one could make the >> > same argument for var regions, etc.). >> > >> > With in-world testing of current development code, BulletSim appears to >> have a hard-coded check where I can't move my >> > avatar below z == 2 whether terrain is z < 0 or not (this should >> probably at least be fixed so z = 0 is possible). ODE >> > has allowed and still allows the avatar to descend to negative depths. >> > >> > One argument is that in the light of such bugs, it would be better to >> consistently enforce z >= 0 and require people >> > with -z builds to either move them and the water level up using >> OpenSimulator commands (e.g. "translate scene") or never >> > update their OpenSimulator installation. >> > >> > However, I think there is a real value in keeping the -ve z ability. It >> allows people to extend deep water builds >> > without having to adjust any neighbouring sims for consistency (which >> they may not have control over). I'm sure it's >> > possible to address the viewer-side issues. OpenSimulator could have an >> allow-negative-z flag which is false by default >> > to make it explicit that using -ve z may have issues at this time. I >> accept this is a more complicated solution than >> > enforcing z == 0, though enforcing z == 0 will also requires many >> changes to the current code where bounds are not checked. >> > >> > If my experience is unusual and -z builds are very rare then there's >> more of a case for enforcing z >= 0. >> > >> > Thoughts? >> > >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at opensimulator.org >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> > > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev From cmickeyb at gmail.com Fri Apr 25 00:30:20 2014 From: cmickeyb at gmail.com (Mic Bowman) Date: Thu, 24 Apr 2014 17:30:20 -0700 Subject: [Opensim-dev] Negative z values In-Reply-To: <5359AAE5.1080104@t-data.com> References: <53599111.8080005@googlemail.com> <53599438.1000400@t-data.com> <5359AAE5.1080104@t-data.com> Message-ID: do the viewers support that granularity of water height? that would be very useful if it could be made to work. --mic On Thu, Apr 24, 2014 at 5:23 PM, Melanie wrote: > There are potential issues with code/tools written with the notion > that the metaverse indeed ends at 0, but I believe they can be overcome. > In this vein, there is another "feature" we may want to push for: > > Raw files allow specifying a water height for each 4x4 m square, but > currently regions only have a notion of water level for the entire > region, taken from the 0,0 coordinate of the water level layer in > the raw file. > > I believe full support for a water height map (including Z < 0 > depths) would be an advantage of opensim over SL, as SL currently > struggles with basements, subway tunnels and mountain lakes. > > - Melanie > > On 25/04/2014 02:16, Jim Williams wrote: > > Seems to me that 0 is a completely arbitrary number and that a cut-off > for > > any reason other than hardware/mathematical limitations is unwarranted. > I > > could see taking an "oh well" attitude about things that don't work with > > -z, but declaring the Metaverse to simply end at 0 seems very random. > > > > > > On Thu, Apr 24, 2014 at 6:46 PM, Melanie wrote: > > > >> I have never seen a Z < 0 build. I see lots of problems that may be > >> possible with this, but I think that quite beautiful and interesting > >> builds could make use of this and would support keeping it. The > >> change in the viewer is recent and likely trivial to undo. > >> > >> - Melanie > >> > >> On 25/04/2014 00:32, Justin Clark-Casey wrote: > >> > Hi folks. Historically, whether by accident or design, OpenSimulator > >> has allowed negative Z values for terrain, objects > >> > and avatars (e.g. <130, 50, -45>. I have seen people use this > facility > >> to build fully underwater or partially > >> > underwater structures (e.g. oil rigs, sunken ships, etc.) which are > >> conceptually far below the water line without having > >> > to set that water line at a level that may be way above that of > >> surrounding regions. > >> > > >> > However, at least on Singularity 1.8.5 on Linux, fog effects do not > work > >> properly when z < 0, where all view distances > >> > have very high fog no matter what the fog settings. This may be a > >> recent change - I remember fog working properly at > >> > negative z values in the past, though the fog issue still occurred > past > >> a certain -ve z. There may be other issues of > >> > which I'm not aware. Arguably, these are not bugs since the Linden > Grid > >> does not allow z < 0 (though one could make the > >> > same argument for var regions, etc.). > >> > > >> > With in-world testing of current development code, BulletSim appears > to > >> have a hard-coded check where I can't move my > >> > avatar below z == 2 whether terrain is z < 0 or not (this should > >> probably at least be fixed so z = 0 is possible). ODE > >> > has allowed and still allows the avatar to descend to negative depths. > >> > > >> > One argument is that in the light of such bugs, it would be better to > >> consistently enforce z >= 0 and require people > >> > with -z builds to either move them and the water level up using > >> OpenSimulator commands (e.g. "translate scene") or never > >> > update their OpenSimulator installation. > >> > > >> > However, I think there is a real value in keeping the -ve z ability. > It > >> allows people to extend deep water builds > >> > without having to adjust any neighbouring sims for consistency (which > >> they may not have control over). I'm sure it's > >> > possible to address the viewer-side issues. OpenSimulator could have > an > >> allow-negative-z flag which is false by default > >> > to make it explicit that using -ve z may have issues at this time. I > >> accept this is a more complicated solution than > >> > enforcing z == 0, though enforcing z == 0 will also requires many > >> changes to the current code where bounds are not checked. > >> > > >> > If my experience is unusual and -z builds are very rare then there's > >> more of a case for enforcing z >= 0. > >> > > >> > Thoughts? > >> > > >> _______________________________________________ > >> Opensim-dev mailing list > >> Opensim-dev at opensimulator.org > >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > >> > > > > > > > > > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev at opensimulator.org > > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From melanie at t-data.com Fri Apr 25 00:34:44 2014 From: melanie at t-data.com (Melanie) Date: Fri, 25 Apr 2014 02:34:44 +0200 Subject: [Opensim-dev] Negative z values In-Reply-To: References: <53599111.8080005@googlemail.com> <53599438.1000400@t-data.com> <5359AAE5.1080104@t-data.com> Message-ID: <5359ADA4.50802@t-data.com> They don't yet, but can be made to. I think SL eschewed that option only because a UI to edit this in -world would be a nightmare.. - Melanie On 25/04/2014 02:30, Mic Bowman wrote: > do the viewers support that granularity of water height? that would be very > useful if it could be made to work. > > --mic > > > > On Thu, Apr 24, 2014 at 5:23 PM, Melanie wrote: > >> There are potential issues with code/tools written with the notion >> that the metaverse indeed ends at 0, but I believe they can be overcome. >> In this vein, there is another "feature" we may want to push for: >> >> Raw files allow specifying a water height for each 4x4 m square, but >> currently regions only have a notion of water level for the entire >> region, taken from the 0,0 coordinate of the water level layer in >> the raw file. >> >> I believe full support for a water height map (including Z < 0 >> depths) would be an advantage of opensim over SL, as SL currently >> struggles with basements, subway tunnels and mountain lakes. >> >> - Melanie >> >> On 25/04/2014 02:16, Jim Williams wrote: >> > Seems to me that 0 is a completely arbitrary number and that a cut-off >> for >> > any reason other than hardware/mathematical limitations is unwarranted. >> I >> > could see taking an "oh well" attitude about things that don't work with >> > -z, but declaring the Metaverse to simply end at 0 seems very random. >> > >> > >> > On Thu, Apr 24, 2014 at 6:46 PM, Melanie wrote: >> > >> >> I have never seen a Z < 0 build. I see lots of problems that may be >> >> possible with this, but I think that quite beautiful and interesting >> >> builds could make use of this and would support keeping it. The >> >> change in the viewer is recent and likely trivial to undo. >> >> >> >> - Melanie >> >> >> >> On 25/04/2014 00:32, Justin Clark-Casey wrote: >> >> > Hi folks. Historically, whether by accident or design, OpenSimulator >> >> has allowed negative Z values for terrain, objects >> >> > and avatars (e.g. <130, 50, -45>. I have seen people use this >> facility >> >> to build fully underwater or partially >> >> > underwater structures (e.g. oil rigs, sunken ships, etc.) which are >> >> conceptually far below the water line without having >> >> > to set that water line at a level that may be way above that of >> >> surrounding regions. >> >> > >> >> > However, at least on Singularity 1.8.5 on Linux, fog effects do not >> work >> >> properly when z < 0, where all view distances >> >> > have very high fog no matter what the fog settings. This may be a >> >> recent change - I remember fog working properly at >> >> > negative z values in the past, though the fog issue still occurred >> past >> >> a certain -ve z. There may be other issues of >> >> > which I'm not aware. Arguably, these are not bugs since the Linden >> Grid >> >> does not allow z < 0 (though one could make the >> >> > same argument for var regions, etc.). >> >> > >> >> > With in-world testing of current development code, BulletSim appears >> to >> >> have a hard-coded check where I can't move my >> >> > avatar below z == 2 whether terrain is z < 0 or not (this should >> >> probably at least be fixed so z = 0 is possible). ODE >> >> > has allowed and still allows the avatar to descend to negative depths. >> >> > >> >> > One argument is that in the light of such bugs, it would be better to >> >> consistently enforce z >= 0 and require people >> >> > with -z builds to either move them and the water level up using >> >> OpenSimulator commands (e.g. "translate scene") or never >> >> > update their OpenSimulator installation. >> >> > >> >> > However, I think there is a real value in keeping the -ve z ability. >> It >> >> allows people to extend deep water builds >> >> > without having to adjust any neighbouring sims for consistency (which >> >> they may not have control over). I'm sure it's >> >> > possible to address the viewer-side issues. OpenSimulator could have >> an >> >> allow-negative-z flag which is false by default >> >> > to make it explicit that using -ve z may have issues at this time. I >> >> accept this is a more complicated solution than >> >> > enforcing z == 0, though enforcing z == 0 will also requires many >> >> changes to the current code where bounds are not checked. >> >> > >> >> > If my experience is unusual and -z builds are very rare then there's >> >> more of a case for enforcing z >= 0. >> >> > >> >> > Thoughts? >> >> > >> >> _______________________________________________ >> >> Opensim-dev mailing list >> >> Opensim-dev at opensimulator.org >> >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> >> >> > >> > >> > >> > >> > >> > _______________________________________________ >> > Opensim-dev mailing list >> > Opensim-dev at opensimulator.org >> > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at opensimulator.org >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev From j.frank.nichols at gmail.com Fri Apr 25 01:37:14 2014 From: j.frank.nichols at gmail.com (Frank Nichols) Date: Thu, 24 Apr 2014 21:37:14 -0400 Subject: [Opensim-dev] Negative z values In-Reply-To: References: <53599111.8080005@googlemail.com> <53599438.1000400@t-data.com> Message-ID: I don't see it as arbitrary at all. OS is a simulator and while it might be "fun" to play with negative magnitudes for dimensions I expect most people (other than mathematicians) would struggle visualizing the concept. If a grid wants to have extremely deep oceans, it is simple enough to establish a grid wide water level at some "arbitrary" higher altitude. Also, I don't expect the dev's plan on implementing infinity as an acceptable magnitude for a dimension either - so, there will in fact be some arbitrary magnitude (usually limited by the size of an integer or floating point accuracy). I expect other than in the code the current limits are not defined, so designers using OS will need to be "careful" no matter what. Frank On Thu, Apr 24, 2014 at 8:16 PM, Jim Williams wrote: > Seems to me that 0 is a completely arbitrary number and that a cut-off for > any reason other than hardware/mathematical limitations is unwarranted. I > could see taking an "oh well" attitude about things that don't work with > -z, but declaring the Metaverse to simply end at 0 seems very random. > > > On Thu, Apr 24, 2014 at 6:46 PM, Melanie wrote: > >> I have never seen a Z < 0 build. I see lots of problems that may be >> possible with this, but I think that quite beautiful and interesting >> builds could make use of this and would support keeping it. The >> change in the viewer is recent and likely trivial to undo. >> >> - Melanie >> >> On 25/04/2014 00:32, Justin Clark-Casey wrote: >> > Hi folks. Historically, whether by accident or design, OpenSimulator >> has allowed negative Z values for terrain, objects >> > and avatars (e.g. <130, 50, -45>. I have seen people use this facility >> to build fully underwater or partially >> > underwater structures (e.g. oil rigs, sunken ships, etc.) which are >> conceptually far below the water line without having >> > to set that water line at a level that may be way above that of >> surrounding regions. >> > >> > However, at least on Singularity 1.8.5 on Linux, fog effects do not >> work properly when z < 0, where all view distances >> > have very high fog no matter what the fog settings. This may be a >> recent change - I remember fog working properly at >> > negative z values in the past, though the fog issue still occurred past >> a certain -ve z. There may be other issues of >> > which I'm not aware. Arguably, these are not bugs since the Linden >> Grid does not allow z < 0 (though one could make the >> > same argument for var regions, etc.). >> > >> > With in-world testing of current development code, BulletSim appears to >> have a hard-coded check where I can't move my >> > avatar below z == 2 whether terrain is z < 0 or not (this should >> probably at least be fixed so z = 0 is possible). ODE >> > has allowed and still allows the avatar to descend to negative depths. >> > >> > One argument is that in the light of such bugs, it would be better to >> consistently enforce z >= 0 and require people >> > with -z builds to either move them and the water level up using >> OpenSimulator commands (e.g. "translate scene") or never >> > update their OpenSimulator installation. >> > >> > However, I think there is a real value in keeping the -ve z ability. >> It allows people to extend deep water builds >> > without having to adjust any neighbouring sims for consistency (which >> they may not have control over). I'm sure it's >> > possible to address the viewer-side issues. OpenSimulator could have >> an allow-negative-z flag which is false by default >> > to make it explicit that using -ve z may have issues at this time. I >> accept this is a more complicated solution than >> > enforcing z == 0, though enforcing z == 0 will also requires many >> changes to the current code where bounds are not checked. >> > >> > If my experience is unusual and -z builds are very rare then there's >> more of a case for enforcing z >= 0. >> > >> > Thoughts? >> > >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at opensimulator.org >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> > > > > -- > No essence. No permanence. No perfection. Only action. > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dahliatrimble at gmail.com Fri Apr 25 02:59:02 2014 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Thu, 24 Apr 2014 19:59:02 -0700 Subject: [Opensim-dev] Negative z values In-Reply-To: References: <53599111.8080005@googlemail.com> <53599438.1000400@t-data.com> Message-ID: The water shaders in the LL viewer are quite outdated. If there was an effort to improve water, I'd personally like to see some more modern improvements such as displacement maps (for surf effects) and better reflection effects. Water could even be a heightfield. One problem with reducing the granularity of the area size affected by water height is that lighting for other objects changes when the pixels are underwater and there may be limitations in how many water heights can be passed to current shaders when rendering a frame which views underneath multiple water heights. I'm not really familiar with the rendering pipeline in the current viewers but I suspect any efforts to reducing water patch size might run into enough difficulties where designing a more modern water rendering system might actually be an easier task to accomplish. Anyway, this is probably a topic which is better discussed with those who are intimately familiar with the viewer pipeline. On Thu, Apr 24, 2014 at 6:37 PM, Frank Nichols wrote: > I don't see it as arbitrary at all. > > OS is a simulator and while it might be "fun" to play with negative > magnitudes for dimensions I expect most people (other than mathematicians) > would struggle visualizing the concept. > > If a grid wants to have extremely deep oceans, it is simple enough to > establish a grid wide water level at some "arbitrary" higher altitude. > > Also, I don't expect the dev's plan on implementing infinity as an > acceptable magnitude for a dimension either - so, there will in fact be > some arbitrary magnitude (usually limited by the size of an integer or > floating point accuracy). > > I expect other than in the code the current limits are not defined, so > designers using OS will need to be "careful" no matter what. > > Frank > > > On Thu, Apr 24, 2014 at 8:16 PM, Jim Williams wrote: > >> Seems to me that 0 is a completely arbitrary number and that a cut-off >> for any reason other than hardware/mathematical limitations is unwarranted. >> I could see taking an "oh well" attitude about things that don't work with >> -z, but declaring the Metaverse to simply end at 0 seems very random. >> >> >> On Thu, Apr 24, 2014 at 6:46 PM, Melanie wrote: >> >>> I have never seen a Z < 0 build. I see lots of problems that may be >>> possible with this, but I think that quite beautiful and interesting >>> builds could make use of this and would support keeping it. The >>> change in the viewer is recent and likely trivial to undo. >>> >>> - Melanie >>> >>> On 25/04/2014 00:32, Justin Clark-Casey wrote: >>> > Hi folks. Historically, whether by accident or design, OpenSimulator >>> has allowed negative Z values for terrain, objects >>> > and avatars (e.g. <130, 50, -45>. I have seen people use this >>> facility to build fully underwater or partially >>> > underwater structures (e.g. oil rigs, sunken ships, etc.) which are >>> conceptually far below the water line without having >>> > to set that water line at a level that may be way above that of >>> surrounding regions. >>> > >>> > However, at least on Singularity 1.8.5 on Linux, fog effects do not >>> work properly when z < 0, where all view distances >>> > have very high fog no matter what the fog settings. This may be a >>> recent change - I remember fog working properly at >>> > negative z values in the past, though the fog issue still occurred >>> past a certain -ve z. There may be other issues of >>> > which I'm not aware. Arguably, these are not bugs since the Linden >>> Grid does not allow z < 0 (though one could make the >>> > same argument for var regions, etc.). >>> > >>> > With in-world testing of current development code, BulletSim appears >>> to have a hard-coded check where I can't move my >>> > avatar below z == 2 whether terrain is z < 0 or not (this should >>> probably at least be fixed so z = 0 is possible). ODE >>> > has allowed and still allows the avatar to descend to negative depths. >>> > >>> > One argument is that in the light of such bugs, it would be better to >>> consistently enforce z >= 0 and require people >>> > with -z builds to either move them and the water level up using >>> OpenSimulator commands (e.g. "translate scene") or never >>> > update their OpenSimulator installation. >>> > >>> > However, I think there is a real value in keeping the -ve z ability. >>> It allows people to extend deep water builds >>> > without having to adjust any neighbouring sims for consistency (which >>> they may not have control over). I'm sure it's >>> > possible to address the viewer-side issues. OpenSimulator could have >>> an allow-negative-z flag which is false by default >>> > to make it explicit that using -ve z may have issues at this time. I >>> accept this is a more complicated solution than >>> > enforcing z == 0, though enforcing z == 0 will also requires many >>> changes to the current code where bounds are not checked. >>> > >>> > If my experience is unusual and -z builds are very rare then there's >>> more of a case for enforcing z >= 0. >>> > >>> > Thoughts? >>> > >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at opensimulator.org >>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>> >> >> >> >> -- >> No essence. No permanence. No perfection. Only action. >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at opensimulator.org >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> >> > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From toni at playsign.net Fri Apr 25 06:13:44 2014 From: toni at playsign.net (Toni Alatalo) Date: Fri, 25 Apr 2014 09:13:44 +0300 Subject: [Opensim-dev] Negative z values Message-ID: This it not about negative magnitudes for dimensions for weird mathematical constructs but simply about allow normal arbitrary positioning. Like Justin said for example an avatar to be at <130, 50, -45>. That is perfectly normal and I think definitely should be allowed. Often it makes sense to have 0 at for example ground or water level and then have underground / underwater builds located at negative altitude coordinates. For example when modeling real world places it can be useful to have a straightforward mapping from geolocation coordinates to the scene coordinates. There the standard says that 0 is at sea level: ?The altitude attribute denotes the height of the position, specified in meters above the [WGS84] ellipsoid." http://www.w3.org/TR/geolocation-API/ . It gets complex as the sea is not at same level everywhere but that's how GPS altitude works anyway, http://www.esri.com/news/arcuser/0703/geoid1of3.html . Is simple to decide that ok let's use sea level as 0 in this scene and just map geoloc altitidudes directly to the scene coords. If all locations would be forced to >0 altitudes you'd get into difficulties for example when have first decided for some scene that ok, let's put 0 at -100m underground, but then some deep mine would need to go below that. What would you do then, move the 0 to -1000m and move the whole scene 900m lower, adjust positions that scripts use for their logic etc? I would not want to do that, for no reason. Google Earth's absolute altitude mode does this too: "The absolute altitude mode measures altitude relative to sea level, regardless of the actual elevation of the terrain beneath the feature. In this way, features can be placed underground, and will not be visible. Portions of a feature can extend underground, as in the example below. Negative values are accepted, to place features below sea level. This altitude mode is useful in situations where the altitude value is known precisely. GPS tracks, for example, can use the absolute altitude mode to display paths created while flying or diving." The other modes are just to clamp to ground or calculate the position relative to sea bottom or ground -- that absolute mode is kind of the real position. https://developers.google.com/kml/documentation/altitudemode There's no technical reason with Bullet to not use also negative coordinates -- we have it integrated also in realXtend Tundra and everything works normally as you'd expect with floats. ~Toni BTW with miniplanets sometimes used in games it is typical to have 0,0,0 at the center of the planet and then use both neg and pos values on all axes. I made that too once in an old game demo, http://www.playsign.net/lunatica-2008/ . There are probably also other cases where negative values are useful also for all coordinates, not just altitude. But I understand that with the SL model with origo at the region corner it is different so that's a different discussion for another time :) On Fri, Apr 25, 2014 at 4:37 AM, Frank Nichols wrote: > I don't see it as arbitrary at all. > > OS is a simulator and while it might be "fun" to play with negative > magnitudes for dimensions I expect most people (other than mathematicians) > would struggle visualizing the concept. > > If a grid wants to have extremely deep oceans, it is simple enough to > establish a grid wide water level at some "arbitrary" higher altitude. > > Also, I don't expect the dev's plan on implementing infinity as an > acceptable magnitude for a dimension either - so, there will in fact be some > arbitrary magnitude (usually limited by the size of an integer or floating > point accuracy). > > I expect other than in the code the current limits are not defined, so > designers using OS will need to be "careful" no matter what. > > Frank > > > On Thu, Apr 24, 2014 at 8:16 PM, Jim Williams wrote: >> >> Seems to me that 0 is a completely arbitrary number and that a cut-off for >> any reason other than hardware/mathematical limitations is unwarranted. I >> could see taking an "oh well" attitude about things that don't work with -z, >> but declaring the Metaverse to simply end at 0 seems very random. >> >> >> On Thu, Apr 24, 2014 at 6:46 PM, Melanie wrote: >>> >>> I have never seen a Z < 0 build. I see lots of problems that may be >>> possible with this, but I think that quite beautiful and interesting >>> builds could make use of this and would support keeping it. The >>> change in the viewer is recent and likely trivial to undo. >>> >>> - Melanie >>> >>> On 25/04/2014 00:32, Justin Clark-Casey wrote: >>> > Hi folks. Historically, whether by accident or design, OpenSimulator >>> > has allowed negative Z values for terrain, objects >>> > and avatars (e.g. <130, 50, -45>. I have seen people use this facility >>> > to build fully underwater or partially >>> > underwater structures (e.g. oil rigs, sunken ships, etc.) which are >>> > conceptually far below the water line without having >>> > to set that water line at a level that may be way above that of >>> > surrounding regions. >>> > >>> > However, at least on Singularity 1.8.5 on Linux, fog effects do not >>> > work properly when z < 0, where all view distances >>> > have very high fog no matter what the fog settings. This may be a >>> > recent change - I remember fog working properly at >>> > negative z values in the past, though the fog issue still occurred past >>> > a certain -ve z. There may be other issues of >>> > which I'm not aware. Arguably, these are not bugs since the Linden >>> > Grid does not allow z < 0 (though one could make the >>> > same argument for var regions, etc.). >>> > >>> > With in-world testing of current development code, BulletSim appears to >>> > have a hard-coded check where I can't move my >>> > avatar below z == 2 whether terrain is z < 0 or not (this should >>> > probably at least be fixed so z = 0 is possible). ODE >>> > has allowed and still allows the avatar to descend to negative depths. >>> > >>> > One argument is that in the light of such bugs, it would be better to >>> > consistently enforce z >= 0 and require people >>> > with -z builds to either move them and the water level up using >>> > OpenSimulator commands (e.g. "translate scene") or never >>> > update their OpenSimulator installation. >>> > >>> > However, I think there is a real value in keeping the -ve z ability. >>> > It allows people to extend deep water builds >>> > without having to adjust any neighbouring sims for consistency (which >>> > they may not have control over). I'm sure it's >>> > possible to address the viewer-side issues. OpenSimulator could have >>> > an allow-negative-z flag which is false by default >>> > to make it explicit that using -ve z may have issues at this time. I >>> > accept this is a more complicated solution than >>> > enforcing z == 0, though enforcing z == 0 will also requires many >>> > changes to the current code where bounds are not checked. >>> > >>> > If my experience is unusual and -z builds are very rare then there's >>> > more of a case for enforcing z >= 0. >>> > >>> > Thoughts? >>> > >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at opensimulator.org >>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> >> >> >> >> -- >> No essence. No permanence. No perfection. Only action. >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at opensimulator.org >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > From ai.ai.austin at gmail.com Fri Apr 25 09:31:06 2014 From: ai.ai.austin at gmail.com (Ai Austin) Date: Fri, 25 Apr 2014 10:31:06 +0100 Subject: [Opensim-dev] Negative z values In-Reply-To: References: Message-ID: <535a2b59.c265b40a.2e59.ffff896f@mx.google.com> At 01:30 25/04/2014, opensim-dev-request at opensimulator.org wrote: >Hi folks. Historically, whether by accident or design, >OpenSimulator has allowed negative Z values for terrain, objects >and avatars (e.g. <130, 50, -45>. I have seen people use this >facility to build fully underwater or partially >underwater structures (e.g. oil rigs, sunken ships, etc.) which are >conceptually far below the water line without having >to set that water line at a level that may be way above that of >surrounding regions. >... Thoughts? I did not know this was possible.. but I think it would be a very useful thing to have since I have some entirely underwater based regions (e.g. see Marineville in OSGrid) where I had to space te region far away from other regions due to the different water heights, and regions where I could use more underwater areas (such as Vue-Rig in OSGrid Does anyone have a terrain height image that sets the sea bed lower than 0m and has a water height of the default 20m to act as the basis for a test? And if anyone has a nice simple test OAR where water level is 20m and there are objects and terrain below 0m it would be useful to act as the basis for experimentation. From sphere1952 at gmail.com Fri Apr 25 10:10:15 2014 From: sphere1952 at gmail.com (Jim Williams) Date: Fri, 25 Apr 2014 06:10:15 -0400 Subject: [Opensim-dev] Negative z values In-Reply-To: <535a2b59.c265b40a.2e59.ffff896f@mx.google.com> References: <535a2b59.c265b40a.2e59.ffff896f@mx.google.com> Message-ID: Well...I just tried "terrain fill -100" and with Firestorm it does make the problem with looking down into the sea while above the water more obvious, but once the camera is below sea level I can't see anything particularly problematic. Doesn't seem to me that there's anything broken, and therefore there is nothing to fix. On Fri, Apr 25, 2014 at 5:31 AM, Ai Austin wrote: > At 01:30 25/04/2014, opensim-dev-request at opensimulator.org wrote: > >> Hi folks. Historically, whether by accident or design, OpenSimulator has >> allowed negative Z values for terrain, objects >> and avatars (e.g. <130, 50, -45>. I have seen people use this facility >> to build fully underwater or partially >> underwater structures (e.g. oil rigs, sunken ships, etc.) which are >> conceptually far below the water line without having >> to set that water line at a level that may be way above that of >> surrounding regions. >> ... Thoughts? >> > > > I did not know this was possible.. but I think it would be a very useful > thing to have since I have some entirely underwater based regions (e.g. see > Marineville in OSGrid) where I had to space te region far away from other > regions due to the different water heights, and regions where I could use > more underwater areas (such as Vue-Rig in OSGrid > > Does anyone have a terrain height image that sets the sea bed lower than > 0m and has a water height of the default 20m to act as the basis for a test? > > And if anyone has a nice simple test OAR where water level is 20m and > there are objects and terrain below 0m it would be useful to act as the > basis for experimentation. > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > -- No essence. No permanence. No perfection. Only action. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ai.ai.austin at gmail.com Fri Apr 25 12:26:11 2014 From: ai.ai.austin at gmail.com (Ai Austin) Date: Fri, 25 Apr 2014 13:26:11 +0100 Subject: [Opensim-dev] Negative z values In-Reply-To: References: Message-ID: <535a5462.e558b40a.5d67.ffffaed3@mx.google.com> At 13:00 25/04/2014, opensim-dev-request at opensimulator.org wrote: >Well...I just tried "terrain fill -100" and with Firestorm it does make the >problem with looking down into the sea while above the water more obvious, >but once the camera is below sea level I can't see anything particularly >problematic. > >Doesn't seem to me that there's anything broken, and therefore there is >nothing to fix. Nice.. and "terrain fill -100" is good way to get a test region. I just tried to see if I can "teleport" to a negative Z in Firestorm 4.6.1 though and it sets -50 to 0 every time I type that in to the map. So I suspect not everything is simple. From sphere1952 at gmail.com Fri Apr 25 13:06:01 2014 From: sphere1952 at gmail.com (Jim Williams) Date: Fri, 25 Apr 2014 09:06:01 -0400 Subject: [Opensim-dev] Negative z values In-Reply-To: <535a5462.e558b40a.5d67.ffffaed3@mx.google.com> References: <535a5462.e558b40a.5d67.ffffaed3@mx.google.com> Message-ID: Maybe not "simple" but that is clearly how Opensim has worked as that is how it works in Metropolis now -- and after I point out how it currently works to a Mer friend of mine I'm pretty sure there will be at least one user who will complain bitterly if that is not how it works in the future. In 20 meters you tend to have a lot of problems with things sticking out that would rather be under water. On Fri, Apr 25, 2014 at 8:26 AM, Ai Austin wrote: > At 13:00 25/04/2014, opensim-dev-request at opensimulator.org wrote: > >> Well...I just tried "terrain fill -100" and with Firestorm it does make >> the >> problem with looking down into the sea while above the water more obvious, >> but once the camera is below sea level I can't see anything particularly >> problematic. >> >> Doesn't seem to me that there's anything broken, and therefore there is >> nothing to fix. >> > > Nice.. and "terrain fill -100" is good way to get a test region. > > I just tried to see if I can "teleport" to a negative Z in Firestorm 4.6.1 > though and it sets -50 to 0 every time I type that in to the map. So I > suspect not everything is simple. > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > -- No essence. No permanence. No perfection. Only action. -------------- next part -------------- An HTML attachment was scrubbed... URL: From drwhiet at spacefriends.de Fri Apr 25 22:01:27 2014 From: drwhiet at spacefriends.de (drWhiet) Date: Sat, 26 Apr 2014 00:01:27 +0200 Subject: [Opensim-dev] Negative z values In-Reply-To: References: <53599111.8080005@googlemail.com><53599438.1000400@t-data.com> Message-ID: <23BA8E9929B54092BFDA47B54DF6F8FC@Cyberdrome> besides everything said, this nails it down : "... but declaring the Metaverse to simply end at 0 seems very random. " I should make this my new email signature .. well said, Jim .. it's the metaverse .. no boundaries ? with future physics not working below -0 ther will be no underwater worlds .. no submarines .. even boat creators must keep an eye that the engine does not move below -0 ; ? best regards Wordfromthe Wise _____ Von: opensim-dev-bounces at opensimulator.org [mailto:opensim-dev-bounces at opensimulator.org] Im Auftrag von Jim Williams Gesendet: Freitag, 25. April 2014 02:17 An: opensim-dev at opensimulator.org Betreff: Re: [Opensim-dev] Negative z values Seems to me that 0 is a completely arbitrary number and that a cut-off for any reason other than hardware/mathematical limitations is unwarranted. I could see taking an "oh well" attitude about things that don't work with -z, but declaring the Metaverse to simply end at 0 seems very random. On Thu, Apr 24, 2014 at 6:46 PM, Melanie wrote: I have never seen a Z < 0 build. I see lots of problems that may be possible with this, but I think that quite beautiful and interesting builds could make use of this and would support keeping it. The change in the viewer is recent and likely trivial to undo. - Melanie On 25/04/2014 00:32, Justin Clark-Casey wrote: > Hi folks. Historically, whether by accident or design, OpenSimulator has allowed negative Z values for terrain, objects > and avatars (e.g. <130, 50, -45>. I have seen people use this facility to build fully underwater or partially > underwater structures (e.g. oil rigs, sunken ships, etc.) which are conceptually far below the water line without having > to set that water line at a level that may be way above that of surrounding regions. > > However, at least on Singularity 1.8.5 on Linux, fog effects do not work properly when z < 0, where all view distances > have very high fog no matter what the fog settings. This may be a recent change - I remember fog working properly at > negative z values in the past, though the fog issue still occurred past a certain -ve z. There may be other issues of > which I'm not aware. Arguably, these are not bugs since the Linden Grid does not allow z < 0 (though one could make the > same argument for var regions, etc.). > > With in-world testing of current development code, BulletSim appears to have a hard-coded check where I can't move my > avatar below z == 2 whether terrain is z < 0 or not (this should probably at least be fixed so z = 0 is possible). ODE > has allowed and still allows the avatar to descend to negative depths. > > One argument is that in the light of such bugs, it would be better to consistently enforce z >= 0 and require people > with -z builds to either move them and the water level up using OpenSimulator commands (e.g. "translate scene") or never > update their OpenSimulator installation. > > However, I think there is a real value in keeping the -ve z ability. It allows people to extend deep water builds > without having to adjust any neighbouring sims for consistency (which they may not have control over). I'm sure it's > possible to address the viewer-side issues. OpenSimulator could have an allow-negative-z flag which is false by default > to make it explicit that using -ve z may have issues at this time. I accept this is a more complicated solution than > enforcing z == 0, though enforcing z == 0 will also requires many changes to the current code where bounds are not checked. > > If my experience is unusual and -z builds are very rare then there's more of a case for enforcing z >= 0. > > Thoughts? > _______________________________________________ Opensim-dev mailing list Opensim-dev at opensimulator.org http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev -- No essence. No permanence. No perfection. Only action. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattlehma at gmail.com Sat Apr 26 02:45:20 2014 From: mattlehma at gmail.com (Matt Lehmann) Date: Fri, 25 Apr 2014 19:45:20 -0700 Subject: [Opensim-dev] Question about the udp receiver algorithm Message-ID: As of the last release, the algorithm for handling udp packets from clients is as so... Start an async read cycle on the socket, adding packets to a blocking queue. Also start a smart thread which waits on the queue and services the packets. Wouldn't it be more efficient to use a single thread that waits on the socket by looping on a socket.poll call, immediately servicing packets? I have tried this locally and I really think it would improve efficiency. If you want I can submit a patch. Thanks Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From dahliatrimble at gmail.com Sat Apr 26 03:09:56 2014 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Fri, 25 Apr 2014 20:09:56 -0700 Subject: [Opensim-dev] Question about the udp receiver algorithm In-Reply-To: References: Message-ID: Depends on what you mean by "services the packets". Decoding and ACKing could probably work well in a socket read loop but dispatching the packet to the proper part of the simulation could incur many delays which can cause a lot of packet loss in the lower level operating system routines as the buffers are only so large and any excessive data is discarded. Putting them in a queue for another thread to service is a good compromise which tends to keep things working under most load conditions. However, if your design seems to improve things under a wide range of operating conditions, feel free to submit a patch! But please don't expect it to be accepted as it may need a *lot* of testing to show it's benefit over the current implementation. On Fri, Apr 25, 2014 at 7:45 PM, Matt Lehmann wrote: > As of the last release, the algorithm for handling udp packets from > clients is as so... > > Start an async read cycle on the socket, adding packets to a blocking > queue. > Also start a smart thread which waits on the queue and services the > packets. > > Wouldn't it be more efficient to use a single thread that waits on the > socket by looping on a socket.poll call, immediately servicing packets? > > I have tried this locally and I really think it would improve > efficiency. If you want I can submit a patch. > > Thanks > > Matt > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattlehma at gmail.com Sat Apr 26 03:17:01 2014 From: mattlehma at gmail.com (Matt Lehmann) Date: Fri, 25 Apr 2014 20:17:01 -0700 Subject: [Opensim-dev] Question about the udp receiver algorithm In-Reply-To: References: Message-ID: That makes sense to me. If I recall, the packet handlers will create more threads if they expect delays, such as when waiting for a client to finish movement into the sim. Considering that I have 65 threads running on my standalone instance, with 4 cores that leaves about 15 threads competing. You have to do the work at some point. Matt On Friday, April 25, 2014, Dahlia Trimble wrote: > Depends on what you mean by "services the packets". Decoding and ACKing > could probably work well in a socket read loop but dispatching the packet > to the proper part of the simulation could incur many delays which can > cause a lot of packet loss in the lower level operating system routines as > the buffers are only so large and any excessive data is discarded. Putting > them in a queue for another thread to service is a good compromise which > tends to keep things working under most load conditions. > > However, if your design seems to improve things under a wide range of > operating conditions, feel free to submit a patch! But please don't expect > it to be accepted as it may need a *lot* of testing to show it's benefit > over the current implementation. > > > > > On Fri, Apr 25, 2014 at 7:45 PM, Matt Lehmann > > wrote: > >> As of the last release, the algorithm for handling udp packets from >> clients is as so... >> >> Start an async read cycle on the socket, adding packets to a blocking >> queue. >> Also start a smart thread which waits on the queue and services the >> packets. >> >> Wouldn't it be more efficient to use a single thread that waits on the >> socket by looping on a socket.poll call, immediately servicing packets? >> >> I have tried this locally and I really think it would improve >> efficiency. If you want I can submit a patch. >> >> Thanks >> >> Matt >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at opensimulator.org >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dahliatrimble at gmail.com Sat Apr 26 03:52:29 2014 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Fri, 25 Apr 2014 20:52:29 -0700 Subject: [Opensim-dev] Question about the udp receiver algorithm In-Reply-To: References: Message-ID: >From my experience there are some things that need to happen as soon as possible and others which can be delayed. What needs to happen ASAP: 1). reading the socket and keeping it emptied. 2) acknowledge any received packets which may require such 3) process any acknowledgements sent by the viewer 4) handle AgentUpdate packets. (these can probably be filtered for uniqueness and mostly discarded if not unique). This list is off the top of my head and may not be complete. Most, if not all, other packets could be put into queues and process as resources permit without negatively affecting the quality of the shared state of the simulation. Please be aware that viewers running on high-end machines can constantly send several hundred packets per second, and that under extreme conditions there can be several hundred viewers connected to a single simulator. Any improvements in the UDP processing portions of the code base should probably take these constraints into consideration. On Fri, Apr 25, 2014 at 8:17 PM, Matt Lehmann wrote: > That makes sense to me. > > If I recall, the packet handlers will create more threads if they expect > delays, such as when waiting for a client to finish movement into the sim. > > Considering that I have 65 threads running on my standalone instance, with > 4 cores that leaves about 15 threads competing. You have to do the work at > some point. > > Matt > > On Friday, April 25, 2014, Dahlia Trimble wrote: > >> Depends on what you mean by "services the packets". Decoding and ACKing >> could probably work well in a socket read loop but dispatching the packet >> to the proper part of the simulation could incur many delays which can >> cause a lot of packet loss in the lower level operating system routines as >> the buffers are only so large and any excessive data is discarded. Putting >> them in a queue for another thread to service is a good compromise which >> tends to keep things working under most load conditions. >> >> However, if your design seems to improve things under a wide range of >> operating conditions, feel free to submit a patch! But please don't expect >> it to be accepted as it may need a *lot* of testing to show it's benefit >> over the current implementation. >> >> >> >> >> On Fri, Apr 25, 2014 at 7:45 PM, Matt Lehmann wrote: >> >>> As of the last release, the algorithm for handling udp packets from >>> clients is as so... >>> >>> Start an async read cycle on the socket, adding packets to a >>> blocking queue. >>> Also start a smart thread which waits on the queue and services the >>> packets. >>> >>> Wouldn't it be more efficient to use a single thread that waits on the >>> socket by looping on a socket.poll call, immediately servicing packets? >>> >>> I have tried this locally and I really think it would improve >>> efficiency. If you want I can submit a patch. >>> >>> Thanks >>> >>> Matt >>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at opensimulator.org >>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>> >>> >> > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattlehma at gmail.com Sat Apr 26 04:01:27 2014 From: mattlehma at gmail.com (Matt Lehmann) Date: Fri, 25 Apr 2014 21:01:27 -0700 Subject: [Opensim-dev] Question about the udp receiver algorithm In-Reply-To: References: Message-ID: Thanks for explaining this to me. Perhaps a layered approach would work for this, much like a Linux device driver is split in half. A second event loop could service the "slower" responses, while a higher priority loop would do the urgent responses. I've found that managing the threading of an app directly is better than creating threads and allowing the scheduler to work things out. Thanks Matt On Friday, April 25, 2014, Dahlia Trimble wrote: > From my experience there are some things that need to happen as soon as > possible and others which can be delayed. What needs to happen ASAP: > 1). reading the socket and keeping it emptied. > 2) acknowledge any received packets which may require such > 3) process any acknowledgements sent by the viewer > 4) handle AgentUpdate packets. (these can probably be filtered for > uniqueness and mostly discarded if not unique). > > This list is off the top of my head and may not be complete. Most, if not > all, other packets could be put into queues and process as resources permit > without negatively affecting the quality of the shared state of the > simulation. > > Please be aware that viewers running on high-end machines can constantly > send several hundred packets per second, and that under extreme conditions > there can be several hundred viewers connected to a single simulator. Any > improvements in the UDP processing portions of the code base should > probably take these constraints into consideration. > > > On Fri, Apr 25, 2014 at 8:17 PM, Matt Lehmann > > wrote: > >> That makes sense to me. >> >> If I recall, the packet handlers will create more threads if they expect >> delays, such as when waiting for a client to finish movement into the sim. >> >> Considering that I have 65 threads running on my standalone instance, >> with 4 cores that leaves about 15 threads competing. You have to do the >> work at some point. >> >> Matt >> >> On Friday, April 25, 2014, Dahlia Trimble > >> wrote: >> >>> Depends on what you mean by "services the packets". Decoding and ACKing >>> could probably work well in a socket read loop but dispatching the packet >>> to the proper part of the simulation could incur many delays which can >>> cause a lot of packet loss in the lower level operating system routines as >>> the buffers are only so large and any excessive data is discarded. Putting >>> them in a queue for another thread to service is a good compromise which >>> tends to keep things working under most load conditions. >>> >>> However, if your design seems to improve things under a wide range of >>> operating conditions, feel free to submit a patch! But please don't expect >>> it to be accepted as it may need a *lot* of testing to show it's benefit >>> over the current implementation. >>> >>> >>> >>> >>> On Fri, Apr 25, 2014 at 7:45 PM, Matt Lehmann wrote: >>> >>>> As of the last release, the algorithm for handling udp packets from >>>> clients is as so... >>>> >>>> Start an async read cycle on the socket, adding packets to a >>>> blocking queue. >>>> Also start a smart thread which waits on the queue and services the >>>> packets. >>>> >>>> Wouldn't it be more efficient to use a single thread that waits on the >>>> socket by looping on a socket.poll call, immediately servicing packets? >>>> >>>> I have tried this locally and I really think it would improve >>>> efficiency. If you want I can submit a patch. >>>> >>>> Thanks >>>> >>>> Matt >>>> >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> Opensim-dev at opensimulator.org >>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>>> >>>> >>> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at opensimulator.org >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattlehma at gmail.com Sat Apr 26 04:29:53 2014 From: mattlehma at gmail.com (Matt Lehmann) Date: Fri, 25 Apr 2014 21:29:53 -0700 Subject: [Opensim-dev] Question about the udp receiver algorithm In-Reply-To: References: Message-ID: One example of what I'm trying to say. In part of the packet handling there is a condition where the server needs to respond to the client, but does not yet know the identity of the client. So the server responds to the client and then spawns a thread which loops and sleeps until it can identify the client.( I don't really understand what's going on here,) Nevertheless in this case you could do without the new thread if you queued a lambda function which would check to see if the client can be identified. A second event loop could periodically poll this function until it completes. You could also queue other contexts which would complete the handling of other types of packets. Matt On Friday, April 25, 2014, Dahlia Trimble wrote: > From my experience there are some things that need to happen as soon as > possible and others which can be delayed. What needs to happen ASAP: > 1). reading the socket and keeping it emptied. > 2) acknowledge any received packets which may require such > 3) process any acknowledgements sent by the viewer > 4) handle AgentUpdate packets. (these can probably be filtered for > uniqueness and mostly discarded if not unique). > > This list is off the top of my head and may not be complete. Most, if not > all, other packets could be put into queues and process as resources permit > without negatively affecting the quality of the shared state of the > simulation. > > Please be aware that viewers running on high-end machines can constantly > send several hundred packets per second, and that under extreme conditions > there can be several hundred viewers connected to a single simulator. Any > improvements in the UDP processing portions of the code base should > probably take these constraints into consideration. > > > On Fri, Apr 25, 2014 at 8:17 PM, Matt Lehmann > > wrote: > >> That makes sense to me. >> >> If I recall, the packet handlers will create more threads if they expect >> delays, such as when waiting for a client to finish movement into the sim. >> >> Considering that I have 65 threads running on my standalone instance, >> with 4 cores that leaves about 15 threads competing. You have to do the >> work at some point. >> >> Matt >> >> On Friday, April 25, 2014, Dahlia Trimble > >> wrote: >> >>> Depends on what you mean by "services the packets". Decoding and ACKing >>> could probably work well in a socket read loop but dispatching the packet >>> to the proper part of the simulation could incur many delays which can >>> cause a lot of packet loss in the lower level operating system routines as >>> the buffers are only so large and any excessive data is discarded. Putting >>> them in a queue for another thread to service is a good compromise which >>> tends to keep things working under most load conditions. >>> >>> However, if your design seems to improve things under a wide range of >>> operating conditions, feel free to submit a patch! But please don't expect >>> it to be accepted as it may need a *lot* of testing to show it's benefit >>> over the current implementation. >>> >>> >>> >>> >>> On Fri, Apr 25, 2014 at 7:45 PM, Matt Lehmann wrote: >>> >>>> As of the last release, the algorithm for handling udp packets from >>>> clients is as so... >>>> >>>> Start an async read cycle on the socket, adding packets to a >>>> blocking queue. >>>> Also start a smart thread which waits on the queue and services the >>>> packets. >>>> >>>> Wouldn't it be more efficient to use a single thread that waits on the >>>> socket by looping on a socket.poll call, immediately servicing packets? >>>> >>>> I have tried this locally and I really think it would improve >>>> efficiency. If you want I can submit a patch. >>>> >>>> Thanks >>>> >>>> Matt >>>> >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> Opensim-dev at opensimulator.org >>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>>> >>>> >>> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at opensimulator.org >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From diva at metaverseink.com Sat Apr 26 04:50:32 2014 From: diva at metaverseink.com (Diva Canto) Date: Fri, 25 Apr 2014 21:50:32 -0700 Subject: [Opensim-dev] Question about the udp receiver algorithm In-Reply-To: References: Message-ID: <535B3B18.6000203@metaverseink.com> That is one very specific and unique case, something that happens in the beginning, and that is necessary, otherwise clients crash. It's an "exception" wrt the bulk of processing UDP packets. The bulk of them are processed as you described in your first message: placed in a queue, consumed by a consumer thread which either processes them directly or spawns threads for processing them. In general, my experience is also that limiting the amount of concurrency is a Good Thing. A couple of years ago we had way too much concurrency; we've been taming that down. As Dahlia said, the packet handling layer of OpenSim is really critical, and the viewers are sensitive to it, so any drastic changes to it need to go through extensive testing. The current async reading is not bad, as it empties the socket queue almost immediately. The threads that are spawn from the consumer thread, though, could use some rethinking. On 4/25/2014 9:29 PM, Matt Lehmann wrote: > One example of what I'm trying to say. > > In part of the packet handling there is a condition where the server > needs to respond to the client, but does not yet know the identity of > the client. So the server responds to the client and then spawns a > thread which loops and sleeps until it can identify the client.( I > don't really understand what's going on here,) > > Nevertheless in this case you could do without the new thread if you > queued a lambda function which would check to see if the client can be > identified. A second event loop could periodically poll this function > until it completes. > > You could also queue other contexts which would complete the handling > of other types of packets. > > Matt > > On Friday, April 25, 2014, Dahlia Trimble > wrote: > > From my experience there are some things that need to happen as > soon as possible and others which can be delayed. What needs to > happen ASAP: > 1). reading the socket and keeping it emptied. > 2) acknowledge any received packets which may require such > 3) process any acknowledgements sent by the viewer > 4) handle AgentUpdate packets. (these can probably be filtered for > uniqueness and mostly discarded if not unique). > > This list is off the top of my head and may not be complete. Most, > if not all, other packets could be put into queues and process as > resources permit without negatively affecting the quality of the > shared state of the simulation. > > Please be aware that viewers running on high-end machines can > constantly send several hundred packets per second, and that under > extreme conditions there can be several hundred viewers connected > to a single simulator. Any improvements in the UDP processing > portions of the code base should probably take these constraints > into consideration. > > > On Fri, Apr 25, 2014 at 8:17 PM, Matt Lehmann > wrote: > > That makes sense to me. > > If I recall, the packet handlers will create more threads if > they expect delays, such as when waiting for a client to > finish movement into the sim. > > Considering that I have 65 threads running on my standalone > instance, with 4 cores that leaves about 15 threads competing. > You have to do the work at some point. > > Matt > > On Friday, April 25, 2014, Dahlia Trimble > > wrote: > > Depends on what you mean by "services the packets". > Decoding and ACKing could probably work well in a socket > read loop but dispatching the packet to the proper part of > the simulation could incur many delays which can cause a > lot of packet loss in the lower level operating system > routines as the buffers are only so large and any > excessive data is discarded. Putting them in a queue for > another thread to service is a good compromise which tends > to keep things working under most load conditions. > > However, if your design seems to improve things under a > wide range of operating conditions, feel free to submit a > patch! But please don't expect it to be accepted as it may > need a *lot* of testing to show it's benefit over the > current implementation. > > > > > On Fri, Apr 25, 2014 at 7:45 PM, Matt Lehmann > wrote: > > As of the last release, the algorithm for handling udp > packets from clients is as so... > > Start an async read cycle on the socket, adding > packets to a blocking queue. > Also start a smart thread which waits on the queue > and services the packets. > > Wouldn't it be more efficient to use a single thread > that waits on the socket by looping on a socket.poll > call, immediately servicing packets? > > I have tried this locally and I really think it would > improve efficiency. If you want I can submit a patch. > > Thanks > > Matt > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattlehma at gmail.com Sat Apr 26 05:03:48 2014 From: mattlehma at gmail.com (Matt Lehmann) Date: Fri, 25 Apr 2014 22:03:48 -0700 Subject: [Opensim-dev] Question about the udp receiver algorithm In-Reply-To: <535B3B18.6000203@metaverseink.com> References: <535B3B18.6000203@metaverseink.com> Message-ID: Yes I agree that the udp service is critical and would need extensive testing. I wouldn't expect you all to make any changes. Still it's an interesting topic. The networking world seems to be moving towards smaller virtualized servers with less resources, so I think it's an important discussion. At my work we are deploying an opensim cluster which is why I have become so interested. Thanks Matt On Friday, April 25, 2014, Diva Canto wrote: > That is one very specific and unique case, something that happens in the > beginning, and that is necessary, otherwise clients crash. It's an > "exception" wrt the bulk of processing UDP packets. The bulk of them are > processed as you described in your first message: placed in a queue, > consumed by a consumer thread which either processes them directly or > spawns threads for processing them. > > In general, my experience is also that limiting the amount of concurrency > is a Good Thing. A couple of years ago we had way too much concurrency; > we've been taming that down. > > As Dahlia said, the packet handling layer of OpenSim is really critical, > and the viewers are sensitive to it, so any drastic changes to it need to > go through extensive testing. The current async reading is not bad, as it > empties the socket queue almost immediately. The threads that are spawn > from the consumer thread, though, could use some rethinking. > > On 4/25/2014 9:29 PM, Matt Lehmann wrote: > > One example of what I'm trying to say. > > In part of the packet handling there is a condition where the server > needs to respond to the client, but does not yet know the identity of the > client. So the server responds to the client and then spawns a thread which > loops and sleeps until it can identify the client.( I don't really > understand what's going on here,) > > Nevertheless in this case you could do without the new thread if you > queued a lambda function which would check to see if the client can be > identified. A second event loop could periodically poll this function > until it completes. > > You could also queue other contexts which would complete the handling of other > types of packets. > > Matt > > On Friday, April 25, 2014, Dahlia Trimble wrote: > > From my experience there are some things that need to happen as soon > as possible and others which can be delayed. What needs to happen ASAP: > 1). reading the socket and keeping it emptied. > 2) acknowledge any received packets which may require such > 3) process any acknowledgements sent by the viewer > 4) handle AgentUpdate packets. (these can probably be filtered for > uniqueness and mostly discarded if not unique). > > This list is off the top of my head and may not be complete. Most, if not > all, other packets could be put into queues and process as resources permit > without negatively affecting the quality of the shared state of the > simulation. > > Please be aware that viewers running on high-end machines can constantly > send several hundred packets per second, and that under extreme conditions > there can be several hundred viewers connected to a single simulator. Any > improvements in the UDP processing portions of the code base should > probably take these constraints into consideration. > > > On Fri, Apr 25, 2014 at 8:17 PM, Matt Lehmann wrote: > > That makes sense to me. > > If I recall, the packet handlers will create more threads if they expect > delays, such as when waiting for a client to finish movement into the sim. > > Considering that I have 65 threads running on my standalone instance, > with 4 cores that leaves about 15 threads competing. You have to do the > work at some point. > > Matt > > On Friday, April 25, 2014, Dahlia Trimble wrote: > > Depends on what you mean by "services the packets". Decoding and ACKing > could probably work well in a socket read loop but dispatching the packet > to the proper part of the simulation could incur many delays which can > cause a lot of packet loss in the lower level operating system routines as > the buffers are only so large and any excessive data is discarded. Putting > them in a queue > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ai.ai.austin at gmail.com Sat Apr 26 08:18:19 2014 From: ai.ai.austin at gmail.com (Ai Austin) Date: Sat, 26 Apr 2014 09:18:19 +0100 Subject: [Opensim-dev] Negative z values In-Reply-To: References: Message-ID: <535b6bcb.25efc20a.0a11.ffffd0a0@mx.google.com> At 04:09 26/04/2014, drWhiet wrote: >even boat creators must keep an eye that the engine does not move below -0 Remember the default water level is +20m (adjustable on a per region basis)... with a "normal" terrain base of 0m. Maybe its global warming in the metaverse that raised the sea level :-) From mattlehma at gmail.com Sat Apr 26 12:53:39 2014 From: mattlehma at gmail.com (Matt Lehmann) Date: Sat, 26 Apr 2014 05:53:39 -0700 Subject: [Opensim-dev] Question about the udp receiver algorithm In-Reply-To: References: <535B3B18.6000203@metaverseink.com> Message-ID: I looked at this a bit more this morning. So, as I understand, the handling looks like this--> --async read cycle which drops packet into a blocking queue --smart thread which services the blocking queue, and calls the LLClientView method ProcessInPacket LLClientView sorts the packets according to whether the handler should be called asynchronously or not. If async is needed, LLClientView will create a smart thread for the handler, and start the thread. ...the handlers basically signal the events defined in LLClientView which are listened to by one or more other callbacks. If async is not needed/desired, then LLClientView will process the packet directly. So there is one additional thread being created for each async handler, with the original smart thread running all the non-async packet handlers. The question is *can these async threads can be replaced by a second smart thread, which services a queue of async handlers*? Do the handlers require some sort of blocking I/O? Can we rearrange the handlers to operate under these conditions? If the answer is yes, then a great deal of compute cycles can be saved by consolidating all the spawned threads into one single thread loop. Matt On Fri, Apr 25, 2014 at 10:03 PM, Matt Lehmann wrote: > Yes I agree that the udp service is critical and would need extensive > testing. > > I wouldn't expect you all to make any changes. > > Still it's an interesting topic. The networking world seems to be moving > towards smaller virtualized servers with less resources, so I think it's an > important discussion. At my work we are deploying an opensim cluster which > is why I have become so interested. > > > Thanks > > Matt > > > On Friday, April 25, 2014, Diva Canto wrote: > >> That is one very specific and unique case, something that happens in >> the beginning, and that is necessary, otherwise clients crash. It's an >> "exception" wrt the bulk of processing UDP packets. The bulk of them are >> processed as you described in your first message: placed in a queue, >> consumed by a consumer thread which either processes them directly or >> spawns threads for processing them. >> >> In general, my experience is also that limiting the amount of concurrency >> is a Good Thing. A couple of years ago we had way too much concurrency; >> we've been taming that down. >> >> As Dahlia said, the packet handling layer of OpenSim is really critical, >> and the viewers are sensitive to it, so any drastic changes to it need to >> go through extensive testing. The current async reading is not bad, as it >> empties the socket queue almost immediately. The threads that are spawn >> from the consumer thread, though, could use some rethinking. >> >> On 4/25/2014 9:29 PM, Matt Lehmann wrote: >> >> One example of what I'm trying to say. >> >> In part of the packet handling there is a condition where the server >> needs to respond to the client, but does not yet know the identity of the >> client. So the server responds to the client and then spawns a thread which >> loops and sleeps until it can identify the client.( I don't really >> understand what's going on here,) >> >> Nevertheless in this case you could do without the new thread if you >> queued a lambda function which would check to see if the client can be >> identified. A second event loop could periodically poll this function >> until it completes. >> >> You could also queue other contexts which would complete the handling >> of other types of packets. >> >> Matt >> >> On Friday, April 25, 2014, Dahlia Trimble >> wrote: >> >> From my experience there are some things that need to happen as soon >> as possible and others which can be delayed. What needs to happen ASAP: >> 1). reading the socket and keeping it emptied. >> 2) acknowledge any received packets which may require such >> 3) process any acknowledgements sent by the viewer >> 4) handle AgentUpdate packets. (these can probably be filtered for >> uniqueness and mostly discarded if not unique). >> >> This list is off the top of my head and may not be complete. Most, if >> not all, other packets could be put into queues and process as resources >> permit without negatively affecting the quality of the shared state of the >> simulation. >> >> Please be aware that viewers running on high-end machines can constantly >> send several hundred packets per second, and that under extreme conditions >> there can be several hundred viewers connected to a single simulator. Any >> improvements in the UDP processing portions of the code base should >> probably take these constraints into consideration. >> >> >> On Fri, Apr 25, 2014 at 8:17 PM, Matt Lehmann wrote: >> >> That makes sense to me. >> >> If I recall, the packet handlers will create more threads if they >> expect delays, such as when waiting for a client to finish movement into >> the sim. >> >> Considering that I have 65 threads running on my standalone instance, >> with 4 cores that leaves about 15 threads competing. You have to do the >> work at some point. >> >> Matt >> >> On Friday, April 25, 2014, Dahlia Trimble >> wrote: >> >> Depends on what you mean by "services the packets". Decoding and ACKing >> could probably work well in a socket read loop but dispatching the packet >> to the proper part of the simulation could incur many delays which can >> cause a lot of packet loss in the lower level operating system routines as >> the buffers are only so large and any excessive data is discarded. Putting >> them in a queue >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From abitar.com at gmail.com Sat Apr 26 14:52:20 2014 From: abitar.com at gmail.com (David Saunders) Date: Sat, 26 Apr 2014 10:52:20 -0400 Subject: [Opensim-dev] Negative z values In-Reply-To: <535b6bcb.25efc20a.0a11.ffffd0a0@mx.google.com> References: <535b6bcb.25efc20a.0a11.ffffd0a0@mx.google.com> Message-ID: I wounder how hard it would be to modify varasm to allow a start and end to the Z axes so we can stack a deep ocean and a space sim to the normal sim :) But then again would the client handle all these changes? (partly do) So the solution is to make deep water simulators, But any test this? I never been asked to set up any sims with deep water so I not experience with "outside the box" water :) I was drawn to opensim with the idea of making "pure" space sims where you can float around in real space but I dug into it and I would have to rewrite so much code to do this and after that would the client handle it? So I stuck with making Moon simulators, Low gravity fixed sky.... This was a long time ago, back in the early days of opensim. Now times are changing, I think I might dig into doing it again since varasim allow you to make a 4096x4096x4096 regions :) On Sat, Apr 26, 2014 at 4:18 AM, Ai Austin wrote: > At 04:09 26/04/2014, drWhiet wrote: > >> even boat creators must keep an eye that the engine does not move below -0 >> > > Remember the default water level is +20m (adjustable on a per region > basis)... with a "normal" terrain base of 0m. > > Maybe its global warming in the metaverse that raised the sea level :-) > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cinder.roxley at phoenixviewer.com Sat Apr 26 15:11:59 2014 From: cinder.roxley at phoenixviewer.com (Cinder Roxley) Date: Sat, 26 Apr 2014 09:11:59 -0600 Subject: [Opensim-dev] Negative z values In-Reply-To: References: <535b6bcb.25efc20a.0a11.ffffd0a0@mx.google.com> Message-ID: Given reasonable constraints, I don't see why viewers wouldn't be able to adapt to support variable depth. I'd certainly be willing to write a viewer patch if support cropped up. On Sat, Apr 26, 2014 at 8:52 AM, David Saunders wrote: > I wounder how hard it would be to modify varasm to allow a start and end > to the Z axes so we can stack a deep ocean and a space sim to the normal > sim :) > > But then again would the client handle all these changes? (partly do) > > So the solution is to make deep water simulators, But any test this? I > never been asked to set up any sims with deep water so I not experience > with "outside the box" water :) > > I was drawn to opensim with the idea of making "pure" space sims where you > can float around in real space but I dug into it and I would have to > rewrite so much code to do this and after that would the client handle it? > So I stuck with making Moon simulators, Low gravity fixed sky.... This > was a long time ago, back in the early days of opensim. > > Now times are changing, I think I might dig into doing it again since > varasim allow you to make a 4096x4096x4096 regions :) > > > > On Sat, Apr 26, 2014 at 4:18 AM, Ai Austin wrote: > >> At 04:09 26/04/2014, drWhiet wrote: >> >>> even boat creators must keep an eye that the engine does not move below >>> -0 >>> >> >> Remember the default water level is +20m (adjustable on a per region >> basis)... with a "normal" terrain base of 0m. >> >> Maybe its global warming in the metaverse that raised the sea level :-) >> >> >> >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at opensimulator.org >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From misterblue at misterblue.com Sun Apr 27 17:13:34 2014 From: misterblue at misterblue.com (Mister Blue) Date: Sun, 27 Apr 2014 10:13:34 -0700 Subject: [Opensim-dev] Negative z values In-Reply-To: References: <535b6bcb.25efc20a.0a11.ffffd0a0@mx.google.com> Message-ID: When I built BulletSim, I build for positive only altitudes because I thought that was the rule. The only implementation reason I see for not allowing negative terrain altitudes would be finding all the random places where code makes sign assumptions. If negative altitudes are needed, it would not be too hard to make it happen. I can see the geographically oriented people wanting zero to be sea level and allowing land to be above and below that. -- mb On Sat, Apr 26, 2014 at 8:11 AM, Cinder Roxley < cinder.roxley at phoenixviewer.com> wrote: > Given reasonable constraints, I don't see why viewers wouldn't be able to > adapt to support variable depth. I'd certainly be willing to write a viewer > patch if support cropped up. > > > On Sat, Apr 26, 2014 at 8:52 AM, David Saunders wrote: > >> I wounder how hard it would be to modify varasm to allow a start and end >> to the Z axes so we can stack a deep ocean and a space sim to the normal >> sim :) >> >> But then again would the client handle all these changes? (partly do) >> >> So the solution is to make deep water simulators, But any test this? I >> never been asked to set up any sims with deep water so I not experience >> with "outside the box" water :) >> >> I was drawn to opensim with the idea of making "pure" space sims where >> you can float around in real space but I dug into it and I would have to >> rewrite so much code to do this and after that would the client handle it? >> So I stuck with making Moon simulators, Low gravity fixed sky.... This >> was a long time ago, back in the early days of opensim. >> >> Now times are changing, I think I might dig into doing it again since >> varasim allow you to make a 4096x4096x4096 regions :) >> >> >> >> On Sat, Apr 26, 2014 at 4:18 AM, Ai Austin wrote: >> >>> At 04:09 26/04/2014, drWhiet wrote: >>> >>>> even boat creators must keep an eye that the engine does not move below >>>> -0 >>>> >>> >>> Remember the default water level is +20m (adjustable on a per region >>> basis)... with a "normal" terrain base of 0m. >>> >>> Maybe its global warming in the metaverse that raised the sea level :-) >>> >>> >>> >>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at opensimulator.org >>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>> >> >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at opensimulator.org >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> >> > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nebadon2025 at gmail.com Sun Apr 27 17:16:06 2014 From: nebadon2025 at gmail.com (Michael Emory Cerquoni) Date: Sun, 27 Apr 2014 19:16:06 +0200 Subject: [Opensim-dev] Negative z values In-Reply-To: References: <535b6bcb.25efc20a.0a11.ffffd0a0@mx.google.com> Message-ID: I do a lot of GIS data related things, and technically 21m is sea level in OpenSImulator, not 0, this is very much a problem as I have to offset everything by 21 meters, not the end of the world, but 0 is 21 meters below the water surface so its technically not sea level in opensimulator. On Sun, Apr 27, 2014 at 7:13 PM, Mister Blue wrote: > When I built BulletSim, I build for positive only altitudes because I > thought that was the rule. The only implementation reason I see for not > allowing negative terrain altitudes would be finding all the random places > where code makes sign assumptions. > > If negative altitudes are needed, it would not be too hard to make it > happen. I can see the geographically oriented people wanting zero to be sea > level and allowing land to be above and below that. > > -- mb > > > On Sat, Apr 26, 2014 at 8:11 AM, Cinder Roxley < > cinder.roxley at phoenixviewer.com> wrote: > >> Given reasonable constraints, I don't see why viewers wouldn't be able to >> adapt to support variable depth. I'd certainly be willing to write a viewer >> patch if support cropped up. >> >> >> On Sat, Apr 26, 2014 at 8:52 AM, David Saunders wrote: >> >>> I wounder how hard it would be to modify varasm to allow a start and end >>> to the Z axes so we can stack a deep ocean and a space sim to the normal >>> sim :) >>> >>> But then again would the client handle all these changes? (partly do) >>> >>> So the solution is to make deep water simulators, But any test this? I >>> never been asked to set up any sims with deep water so I not experience >>> with "outside the box" water :) >>> >>> I was drawn to opensim with the idea of making "pure" space sims where >>> you can float around in real space but I dug into it and I would have to >>> rewrite so much code to do this and after that would the client handle it? >>> So I stuck with making Moon simulators, Low gravity fixed sky.... This >>> was a long time ago, back in the early days of opensim. >>> >>> Now times are changing, I think I might dig into doing it again since >>> varasim allow you to make a 4096x4096x4096 regions :) >>> >>> >>> >>> On Sat, Apr 26, 2014 at 4:18 AM, Ai Austin wrote: >>> >>>> At 04:09 26/04/2014, drWhiet wrote: >>>> >>>>> even boat creators must keep an eye that the engine does not move >>>>> below -0 >>>>> >>>> >>>> Remember the default water level is +20m (adjustable on a per region >>>> basis)... with a "normal" terrain base of 0m. >>>> >>>> Maybe its global warming in the metaverse that raised the sea level :-) >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> Opensim-dev at opensimulator.org >>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>>> >>> >>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at opensimulator.org >>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>> >>> >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at opensimulator.org >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> >> > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > -- Michael Emory Cerquoni -------------- next part -------------- An HTML attachment was scrubbed... URL: From misterblue at misterblue.com Sun Apr 27 17:24:23 2014 From: misterblue at misterblue.com (Mister Blue) Date: Sun, 27 Apr 2014 10:24:23 -0700 Subject: [Opensim-dev] Negative z values In-Reply-To: References: <535b6bcb.25efc20a.0a11.ffffd0a0@mx.google.com> Message-ID: While not on the same topic... Justin, I see that you changed the shorts into ints in the HeightMapTerrainData subclass of TerrainData. This is problematic for several reasons: -- you specified 'int' and not 'int32'. I'm not totally sure about the .NET definition but I'd expect some systems to choose 64 bit ints which would create GIGANTIC terrain arrays. -- going to 32bit heightmap values is going to create database blobs that are 100s of megabytes for varregions; -- if a more flexible internal terrain representation was needed, another sub-class of TerrainData should have been created ("LargeRangeHeightmapTerrainData"). That's why it is subclassable. That would also let it have a special database blob format that could be much smaller than simple integer arrays -- If you just needed a large range for terrain (you talked about getting to +500 to be SL compatible), the compression factor could have been reduced from 100. Maybe a compression factor of 20 would give enough range for +-500 altitudes. Anyway, I think the change it ints is a bad idea. -- ra On Sun, Apr 27, 2014 at 10:13 AM, Mister Blue wrote: > When I built BulletSim, I build for positive only altitudes because I > thought that was the rule. The only implementation reason I see for not > allowing negative terrain altitudes would be finding all the random places > where code makes sign assumptions. > > If negative altitudes are needed, it would not be too hard to make it > happen. I can see the geographically oriented people wanting zero to be sea > level and allowing land to be above and below that. > > -- mb > > > On Sat, Apr 26, 2014 at 8:11 AM, Cinder Roxley < > cinder.roxley at phoenixviewer.com> wrote: > >> Given reasonable constraints, I don't see why viewers wouldn't be able to >> adapt to support variable depth. I'd certainly be willing to write a viewer >> patch if support cropped up. >> >> >> On Sat, Apr 26, 2014 at 8:52 AM, David Saunders wrote: >> >>> I wounder how hard it would be to modify varasm to allow a start and end >>> to the Z axes so we can stack a deep ocean and a space sim to the normal >>> sim :) >>> >>> But then again would the client handle all these changes? (partly do) >>> >>> So the solution is to make deep water simulators, But any test this? I >>> never been asked to set up any sims with deep water so I not experience >>> with "outside the box" water :) >>> >>> I was drawn to opensim with the idea of making "pure" space sims where >>> you can float around in real space but I dug into it and I would have to >>> rewrite so much code to do this and after that would the client handle it? >>> So I stuck with making Moon simulators, Low gravity fixed sky.... This >>> was a long time ago, back in the early days of opensim. >>> >>> Now times are changing, I think I might dig into doing it again since >>> varasim allow you to make a 4096x4096x4096 regions :) >>> >>> >>> >>> On Sat, Apr 26, 2014 at 4:18 AM, Ai Austin wrote: >>> >>>> At 04:09 26/04/2014, drWhiet wrote: >>>> >>>>> even boat creators must keep an eye that the engine does not move >>>>> below -0 >>>>> >>>> >>>> Remember the default water level is +20m (adjustable on a per region >>>> basis)... with a "normal" terrain base of 0m. >>>> >>>> Maybe its global warming in the metaverse that raised the sea level :-) >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> Opensim-dev at opensimulator.org >>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>>> >>> >>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at opensimulator.org >>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>> >>> >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at opensimulator.org >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ai.ai.austin at gmail.com Sun Apr 27 17:38:23 2014 From: ai.ai.austin at gmail.com (Ai Austin) Date: Sun, 27 Apr 2014 18:38:23 +0100 Subject: [Opensim-dev] Negative z values In-Reply-To: <7.1.0.9.2.20140426091537.050c1c30@ed.ac.uk> References: <7.1.0.9.2.20140426091537.050c1c30@ed.ac.uk> Message-ID: <535d408e.c265b40a.4dba.5b12@mx.google.com> I was just testing this on the Marineville region on OSGrid which is almost entirely an underwater build with the water surface set at 40m. The tools to translate this up and down seem to work really well... all I did was a) Backup the data base and create an OAR!!! b) terrain lower 20 c) translate scene 0 0 -20 Except that it gave no feedback that it was operating or had completed and when I did a region "backup" or "shutdown" it was clear that the persisting of the changes was taking a long time. So wait for that. 600 objects translated took around 25 minutes or so to persist. d) set region water level to default 20m And all LOOKS great with visible terrain down to -20m below my avatar. BUT... with the default physics engine of Bulletsim, the avatar cannot go down below 2m. Changing to ODE I was able to descend to the new negative value sea floor and the avatar showed a position (in Firestorm 4.6.1) of -18m. We ought to establish if BulletSim will remove that restriction so we know how to proceed in establishing deep water regions? I note that there is a transition in the lighting when the avatar moves from just above 0m to just below.. the water gets murkier below 0m as JustinCC mentioned. The transition is quite sudden though.. but the "underwater gloom" effect is not bad anyway. I should add that objects can be placed below 0m in Firestorm 4.6.1, BUT if you edit them via the tool X,Y,Z facility they zap to 0m. We may need to chat about that to the viewer developers if we want negative building to be easy. You can though MOVE an object up and down in Firestorm 4.6.1. From dahliatrimble at gmail.com Sun Apr 27 18:24:18 2014 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Sun, 27 Apr 2014 11:24:18 -0700 Subject: [Opensim-dev] Negative z values In-Reply-To: References: <535b6bcb.25efc20a.0a11.ffffd0a0@mx.google.com> Message-ID: Make zero sea level? Wouldn't that change the definition of zero for everything else? Not sure that's a good idea... I'd think just enabling negative zero would be a better choice. On Sun, Apr 27, 2014 at 10:13 AM, Mister Blue wrote: > When I built BulletSim, I build for positive only altitudes because I > thought that was the rule. The only implementation reason I see for not > allowing negative terrain altitudes would be finding all the random places > where code makes sign assumptions. > > If negative altitudes are needed, it would not be too hard to make it > happen. I can see the geographically oriented people wanting zero to be sea > level and allowing land to be above and below that. > > -- mb > > > On Sat, Apr 26, 2014 at 8:11 AM, Cinder Roxley < > cinder.roxley at phoenixviewer.com> wrote: > >> Given reasonable constraints, I don't see why viewers wouldn't be able to >> adapt to support variable depth. I'd certainly be willing to write a viewer >> patch if support cropped up. >> >> >> On Sat, Apr 26, 2014 at 8:52 AM, David Saunders wrote: >> >>> I wounder how hard it would be to modify varasm to allow a start and end >>> to the Z axes so we can stack a deep ocean and a space sim to the normal >>> sim :) >>> >>> But then again would the client handle all these changes? (partly do) >>> >>> So the solution is to make deep water simulators, But any test this? I >>> never been asked to set up any sims with deep water so I not experience >>> with "outside the box" water :) >>> >>> I was drawn to opensim with the idea of making "pure" space sims where >>> you can float around in real space but I dug into it and I would have to >>> rewrite so much code to do this and after that would the client handle it? >>> So I stuck with making Moon simulators, Low gravity fixed sky.... This >>> was a long time ago, back in the early days of opensim. >>> >>> Now times are changing, I think I might dig into doing it again since >>> varasim allow you to make a 4096x4096x4096 regions :) >>> >>> >>> >>> On Sat, Apr 26, 2014 at 4:18 AM, Ai Austin wrote: >>> >>>> At 04:09 26/04/2014, drWhiet wrote: >>>> >>>>> even boat creators must keep an eye that the engine does not move >>>>> below -0 >>>>> >>>> >>>> Remember the default water level is +20m (adjustable on a per region >>>> basis)... with a "normal" terrain base of 0m. >>>> >>>> Maybe its global warming in the metaverse that raised the sea level :-) >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> Opensim-dev at opensimulator.org >>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>>> >>> >>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at opensimulator.org >>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>> >>> >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at opensimulator.org >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> >> > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abitar.com at gmail.com Sun Apr 27 19:39:40 2014 From: abitar.com at gmail.com (David Saunders) Date: Sun, 27 Apr 2014 15:39:40 -0400 Subject: [Opensim-dev] Negative z values In-Reply-To: References: <535b6bcb.25efc20a.0a11.ffffd0a0@mx.google.com> Message-ID: The best way I can think of is to keep the default at 20m, but allow it to be set to zero. HAve the ability to to use negative numbers for height. 1> This will allow a standard of 20m with the current opensim. 2> Grid owners can decide if they want to change this default ro say 0m. Or set up areas of regions that have it set, would look silly if one region was 20m and the other was 0m unless you make some kind of land transition but the hardest part would be i think is have itne clients work with negative numbers. I remember back with the build ceilings that where built into the clients and how long that was removed :) It would also require OS code testing to find all those places where negative numbers are assumed does not exists. But leaving hte default water level to where it is now would make it more SL like for people coming over :) . . On Sun, Apr 27, 2014 at 2:24 PM, Dahlia Trimble wrote: > Make zero sea level? Wouldn't that change the definition of zero for > everything else? Not sure that's a good idea... I'd think just enabling > negative zero would be a better choice. > > > On Sun, Apr 27, 2014 at 10:13 AM, Mister Blue wrote: > >> When I built BulletSim, I build for positive only altitudes because I >> thought that was the rule. The only implementation reason I see for not >> allowing negative terrain altitudes would be finding all the random places >> where code makes sign assumptions. >> >> If negative altitudes are needed, it would not be too hard to make it >> happen. I can see the geographically oriented people wanting zero to be sea >> level and allowing land to be above and below that. >> >> -- mb >> >> >> On Sat, Apr 26, 2014 at 8:11 AM, Cinder Roxley < >> cinder.roxley at phoenixviewer.com> wrote: >> >>> Given reasonable constraints, I don't see why viewers wouldn't be able >>> to adapt to support variable depth. I'd certainly be willing to write a >>> viewer patch if support cropped up. >>> >>> >>> On Sat, Apr 26, 2014 at 8:52 AM, David Saunders wrote: >>> >>>> I wounder how hard it would be to modify varasm to allow a start and >>>> end to the Z axes so we can stack a deep ocean and a space sim to the >>>> normal sim :) >>>> >>>> But then again would the client handle all these changes? (partly do) >>>> >>>> So the solution is to make deep water simulators, But any test this? I >>>> never been asked to set up any sims with deep water so I not experience >>>> with "outside the box" water :) >>>> >>>> I was drawn to opensim with the idea of making "pure" space sims where >>>> you can float around in real space but I dug into it and I would have to >>>> rewrite so much code to do this and after that would the client handle it? >>>> So I stuck with making Moon simulators, Low gravity fixed sky.... This >>>> was a long time ago, back in the early days of opensim. >>>> >>>> Now times are changing, I think I might dig into doing it again since >>>> varasim allow you to make a 4096x4096x4096 regions :) >>>> >>>> >>>> >>>> On Sat, Apr 26, 2014 at 4:18 AM, Ai Austin wrote: >>>> >>>>> At 04:09 26/04/2014, drWhiet wrote: >>>>> >>>>>> even boat creators must keep an eye that the engine does not move >>>>>> below -0 >>>>>> >>>>> >>>>> Remember the default water level is +20m (adjustable on a per region >>>>> basis)... with a "normal" terrain base of 0m. >>>>> >>>>> Maybe its global warming in the metaverse that raised the sea level :-) >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Opensim-dev mailing list >>>>> Opensim-dev at opensimulator.org >>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> Opensim-dev at opensimulator.org >>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>>> >>>> >>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at opensimulator.org >>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>> >>> >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at opensimulator.org >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> >> > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sphere1952 at gmail.com Sun Apr 27 20:03:25 2014 From: sphere1952 at gmail.com (Jim Williams) Date: Sun, 27 Apr 2014 16:03:25 -0400 Subject: [Opensim-dev] Negative z values In-Reply-To: References: <535b6bcb.25efc20a.0a11.ffffd0a0@mx.google.com> Message-ID: May I suggest just publicizing the fact that Opensim has historically allowed negative numbers and that there are no plans to make any changes to this? That is: Do Nothing about it. The one thing I am proposing is that we make no changes for Bullet's benefit here. If the Bullet developers don't want to deal with negative terrain heights that is fine with me, but I don't think Opensim should be changed to accommodate it. Same with the viewers. Either they work right with negative heights or they do not. It isn't a bug for Opensim to allow negative heights, and it shouldn't disallow them -- other than taking note of it I don't think there is anything to do here. On Sun, Apr 27, 2014 at 3:39 PM, David Saunders wrote: > The best way I can think of is to keep the default at 20m, but allow it to > be set to zero. HAve the ability to to use negative numbers for height. > > 1> This will allow a standard of 20m with the current opensim. > 2> Grid owners can decide if they want to change this default ro say 0m. > Or set up areas of regions that have it set, would look silly if one > region was 20m and the other was 0m unless you make some kind of land > transition > > but the hardest part would be i think is have itne clients work with > negative numbers. I remember back with the build ceilings that where built > into the clients and how long that was removed :) > It would also require OS code testing to find all those places where > negative numbers are assumed does not exists. > > But leaving hte default water level to where it is now would make it more > SL like for people coming over :) > . . > > > On Sun, Apr 27, 2014 at 2:24 PM, Dahlia Trimble wrote: > >> Make zero sea level? Wouldn't that change the definition of zero for >> everything else? Not sure that's a good idea... I'd think just enabling >> negative zero would be a better choice. >> >> >> On Sun, Apr 27, 2014 at 10:13 AM, Mister Blue wrote: >> >>> When I built BulletSim, I build for positive only altitudes because I >>> thought that was the rule. The only implementation reason I see for not >>> allowing negative terrain altitudes would be finding all the random places >>> where code makes sign assumptions. >>> >>> If negative altitudes are needed, it would not be too hard to make it >>> happen. I can see the geographically oriented people wanting zero to be sea >>> level and allowing land to be above and below that. >>> >>> -- mb >>> >>> >>> On Sat, Apr 26, 2014 at 8:11 AM, Cinder Roxley < >>> cinder.roxley at phoenixviewer.com> wrote: >>> >>>> Given reasonable constraints, I don't see why viewers wouldn't be able >>>> to adapt to support variable depth. I'd certainly be willing to write a >>>> viewer patch if support cropped up. >>>> >>>> >>>> On Sat, Apr 26, 2014 at 8:52 AM, David Saunders wrote: >>>> >>>>> I wounder how hard it would be to modify varasm to allow a start and >>>>> end to the Z axes so we can stack a deep ocean and a space sim to the >>>>> normal sim :) >>>>> >>>>> But then again would the client handle all these changes? (partly do) >>>>> >>>>> So the solution is to make deep water simulators, But any test this? I >>>>> never been asked to set up any sims with deep water so I not experience >>>>> with "outside the box" water :) >>>>> >>>>> I was drawn to opensim with the idea of making "pure" space sims where >>>>> you can float around in real space but I dug into it and I would have to >>>>> rewrite so much code to do this and after that would the client handle it? >>>>> So I stuck with making Moon simulators, Low gravity fixed sky.... This >>>>> was a long time ago, back in the early days of opensim. >>>>> >>>>> Now times are changing, I think I might dig into doing it again since >>>>> varasim allow you to make a 4096x4096x4096 regions :) >>>>> >>>>> >>>>> >>>>> On Sat, Apr 26, 2014 at 4:18 AM, Ai Austin wrote: >>>>> >>>>>> At 04:09 26/04/2014, drWhiet wrote: >>>>>> >>>>>>> even boat creators must keep an eye that the engine does not move >>>>>>> below -0 >>>>>>> >>>>>> >>>>>> Remember the default water level is +20m (adjustable on a per region >>>>>> basis)... with a "normal" terrain base of 0m. >>>>>> >>>>>> Maybe its global warming in the metaverse that raised the sea level >>>>>> :-) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Opensim-dev mailing list >>>>>> Opensim-dev at opensimulator.org >>>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Opensim-dev mailing list >>>>> Opensim-dev at opensimulator.org >>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> Opensim-dev at opensimulator.org >>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>>> >>>> >>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at opensimulator.org >>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>> >>> >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at opensimulator.org >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> >> > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > -- No essence. No permanence. No perfection. Only action. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ai.ai.austin at gmail.com Mon Apr 28 10:54:50 2014 From: ai.ai.austin at gmail.com (Ai Austin) Date: Mon, 28 Apr 2014 11:54:50 +0100 Subject: [Opensim-dev] Negative z values Message-ID: <535e337f.0a68c20a.05c0.0789@mx.google.com> I thought we meant leaving the default water height at 20m (adjustable on a region basis) but allow terrain levels that can go negative (and now be fixed at no lower than 0m. BulletSim though is the default physics engine, so it would be good to establish/know if BulletSim can easily be amended to cope with -ve terrain levels or if it must stay at the current 0m as the lowest level possible. I just raised a mantis issue to establish that. http://opensimulator.org/mantis/view.php?id=7140 There are a few places in viewers editing dialogues where an assumption of z=0m base is assumed... but with OpenSim variants of modern viewers those may be able to be fixed. One I just reported is at http://jira.phoenixviewer.com/browse/FIRE-13582 From sphere1952 at gmail.com Mon Apr 28 11:03:26 2014 From: sphere1952 at gmail.com (Jim Williams) Date: Mon, 28 Apr 2014 07:03:26 -0400 Subject: [Opensim-dev] Negative z values In-Reply-To: <535e337f.0a68c20a.05c0.0789@mx.google.com> References: <535e337f.0a68c20a.05c0.0789@mx.google.com> Message-ID: I will be advocating that Bullet not be the default physics engine outside of OSG until it works. On Mon, Apr 28, 2014 at 6:54 AM, Ai Austin wrote: > I thought we meant leaving the default water height at 20m (adjustable on > a region basis) but allow terrain levels that can go negative (and now be > fixed at no lower than 0m. > > BulletSim though is the default physics engine, so it would be good to > establish/know if BulletSim can easily be amended to cope with -ve terrain > levels or if it must stay at the current 0m as the lowest level possible. I > just raised a mantis issue to establish that. > > http://opensimulator.org/mantis/view.php?id=7140 > > There are a few places in viewers editing dialogues where an assumption of > z=0m base is assumed... but with OpenSim variants of modern viewers those > may be able to be fixed. One I just reported is at > > http://jira.phoenixviewer.com/browse/FIRE-13582 > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > -- No essence. No permanence. No perfection. Only action. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marceled9 at gmail.com Mon Apr 28 18:47:57 2014 From: marceled9 at gmail.com (M.E. Verhagen) Date: Mon, 28 Apr 2014 20:47:57 +0200 Subject: [Opensim-dev] Negative z values In-Reply-To: References: <535e337f.0a68c20a.05c0.0789@mx.google.com> Message-ID: To me it feels a bit strange that builds can go up thousends of meters in the sky, but just 20 meter under the water. If it is the case that the 0 meter would become absolute under limit (wich is new to me) than the 20 meter level should rise to a 1000 meter ? Or is it maybe time for a complete review of the coordinate system ? (why is 0,0,0 in a corner ?, why can't we use multiple terrains above each other on the same sim ? why is the opensim world flat and not sherical ?) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jjustincc at googlemail.com Mon Apr 28 21:55:48 2014 From: jjustincc at googlemail.com (Justin Clark-Casey) Date: Mon, 28 Apr 2014 22:55:48 +0100 Subject: [Opensim-dev] Negative z values In-Reply-To: References: <535b6bcb.25efc20a.0a11.ffffd0a0@mx.google.com> Message-ID: <535ECE64.8070105@googlemail.com> Hi Robert, On 27/04/14 18:24, Mister Blue wrote: > While not on the same topic... Justin, I see that you changed the shorts into ints in the HeightMapTerrainData subclass > of TerrainData. This is problematic for several reasons: > -- you specified 'int' and not 'int32'. I'm not totally sure about the .NET definition but I'd expect some systems to > choose 64 bit ints which would create GIGANTIC terrain arrays. An int in the CLR is always System.Int32 [1] > -- going to 32bit heightmap values is going to create database blobs that are 100s of megabytes for varregions; In my calculations, and consistent with my actual memory measurements (though I didn't measure blob storage size), the increase for an 8192 x 8192 variable region (equiv to 1024 'normal' regions, is 128mb which I thought was reasonable for such a massive region, where even that memory use looks fairly small percentage of other uses (e.g. physics). But I guess it may be blob size that you're more worried about. In fact, I neglected to change this at the database layer so the change is not actually yet in effect there. > -- if a more flexible internal terrain representation was needed, another sub-class of TerrainData should have been > created ("LargeRangeHeightmapTerrainData"). That's why it is subclassable. That would also let it have a special > database blob format that could be much smaller than simple integer arrays but wouldn't that mean then having a range of possible storage choices with all the complexity of customization that this entails? In this case, I really want to retain compatibility with LL bounds by default. > -- If you just needed a large range for terrain (you talked about getting to +500 to be SL compatible), the compression > factor could have been reduced from 100. Maybe a compression factor of 20 would give enough range for +-500 altitudes. Yes, that's exactly what I was after, whilst preserving the ability to have -z (otherwise I would have considered ushort). A compression factor of 20 would work for this. > > Anyway, I think the change it ints is a bad idea. I didn't particularly like it but it didn't look to me like the memory requirements were unreasonable, and they were still half of those in 0.7.6. I would have thought disk is less of an issue than this, unless you have concerns with maximum database packet sizes (a var region with shorts already requires an increase from the defaults) or some other db issue. Apart from any of this, it looks like there's a lot of room for database storage improvement - one could gzip the terrain bytes rather than writing them raw. In memory is a bit trickier whilst preserving quick access. If you think changing the compression factor is okay then I'm happy to do this instead. It looks like the terrain blob storage also stores/retrieves the compression factor? So in this case there would be no need to bump DBTerrainRevision or anything similarly messy? Dev Random also pointed out that terrain formats like terragen take a base height and a scale instead of storing a full range [2]. That might also be an idea though it would be more difficult to fit into the LL system (can't be done via viewer UI atm) and I want to avoid complex change this close to a release. [1] http://msdn.microsoft.com/en-us/library/5kzh1b5w.aspx [2] http://www.planetside.co.uk/terragen/dev/tgterrain.html > > -- ra > > > On Sun, Apr 27, 2014 at 10:13 AM, Mister Blue > wrote: > > When I built BulletSim, I build for positive only altitudes because I thought that was the rule. The only > implementation reason I see for not allowing negative terrain altitudes would be finding all the random places where > code makes sign assumptions. > > If negative altitudes are needed, it would not be too hard to make it happen. I can see the geographically oriented > people wanting zero to be sea level and allowing land to be above and below that. > > -- mb > > > On Sat, Apr 26, 2014 at 8:11 AM, Cinder Roxley > wrote: > > Given reasonable constraints, I don't see why viewers wouldn't be able to adapt to support variable depth. I'd > certainly be willing to write a viewer patch if support cropped up. > > > On Sat, Apr 26, 2014 at 8:52 AM, David Saunders > wrote: > > I wounder how hard it would be to modify varasm to allow a start and end to the Z axes so we can stack a > deep ocean and a space sim to the normal sim :) > > But then again would the client handle all these changes? (partly do) > > So the solution is to make deep water simulators, But any test this? I never been asked to set up any sims > with deep water so I not experience with "outside the box" water :) > > I was drawn to opensim with the idea of making "pure" space sims where you can float around in real space > but I dug into it and I would have to rewrite so much code to do this and after that would the client > handle it? So I stuck with making Moon simulators, Low gravity fixed sky.... This was a long time ago, > back in the early days of opensim. > > Now times are changing, I think I might dig into doing it again since varasim allow you to make a > 4096x4096x4096 regions :) > > > > On Sat, Apr 26, 2014 at 4:18 AM, Ai Austin > wrote: > > At 04:09 26/04/2014, drWhiet wrote: > > even boat creators must keep an eye that the engine does not move below -0 > > > Remember the default water level is +20m (adjustable on a per region basis)... with a "normal" terrain > base of 0m. > > Maybe its global warming in the metaverse that raised the sea level :-) > > > > > _________________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-__bin/mailman/listinfo/opensim-__dev > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > -- Justin Clark-Casey (justincc) OSVW Consulting http://justincc.org http://twitter.com/justincc From jjustincc at googlemail.com Mon Apr 28 22:05:15 2014 From: jjustincc at googlemail.com (Justin Clark-Casey) Date: Mon, 28 Apr 2014 23:05:15 +0100 Subject: [Opensim-dev] Negative z values In-Reply-To: References: <535b6bcb.25efc20a.0a11.ffffd0a0@mx.google.com> Message-ID: <535ED09B.2020404@googlemail.com> I don't think there should be too many places. I know there are a few on teleport and MakeRootAgent (as Austin pointed out) but it looks like it should be fairly simple to check real terrain height, which might already be done anyway and be masked by the zero check. It does work in general as it has been possible with ODE. On 27/04/14 18:13, Mister Blue wrote: > When I built BulletSim, I build for positive only altitudes because I thought that was the rule. The only implementation > reason I see for not allowing negative terrain altitudes would be finding all the random places where code makes sign > assumptions. > > If negative altitudes are needed, it would not be too hard to make it happen. I can see the geographically oriented > people wanting zero to be sea level and allowing land to be above and below that. > > -- mb > > > On Sat, Apr 26, 2014 at 8:11 AM, Cinder Roxley > wrote: > > Given reasonable constraints, I don't see why viewers wouldn't be able to adapt to support variable depth. I'd > certainly be willing to write a viewer patch if support cropped up. > > > On Sat, Apr 26, 2014 at 8:52 AM, David Saunders > wrote: > > I wounder how hard it would be to modify varasm to allow a start and end to the Z axes so we can stack a deep > ocean and a space sim to the normal sim :) > > But then again would the client handle all these changes? (partly do) > > So the solution is to make deep water simulators, But any test this? I never been asked to set up any sims with > deep water so I not experience with "outside the box" water :) > > I was drawn to opensim with the idea of making "pure" space sims where you can float around in real space but I > dug into it and I would have to rewrite so much code to do this and after that would the client handle it? So I > stuck with making Moon simulators, Low gravity fixed sky.... This was a long time ago, back in the early days > of opensim. > > Now times are changing, I think I might dig into doing it again since varasim allow you to make a > 4096x4096x4096 regions :) > > > > On Sat, Apr 26, 2014 at 4:18 AM, Ai Austin > wrote: > > At 04:09 26/04/2014, drWhiet wrote: > > even boat creators must keep an eye that the engine does not move below -0 > > > Remember the default water level is +20m (adjustable on a per region basis)... with a "normal" terrain base > of 0m. > > Maybe its global warming in the metaverse that raised the sea level :-) > > > > > _________________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-__bin/mailman/listinfo/opensim-__dev > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > -- Justin Clark-Casey (justincc) OSVW Consulting http://justincc.org http://twitter.com/justincc From jjustincc at googlemail.com Mon Apr 28 23:01:02 2014 From: jjustincc at googlemail.com (Justin Clark-Casey) Date: Tue, 29 Apr 2014 00:01:02 +0100 Subject: [Opensim-dev] Question about the udp receiver algorithm In-Reply-To: References: <535B3B18.6000203@metaverseink.com> Message-ID: <535EDDAE.4090500@googlemail.com> That's correct. I added some high level summary to [1]. My expectation is that in many situations, the async packets are indeed handled pretty quickly with very often only a single thread from the pool used. I've seen this when analyzing threadpool data from the crude stats recording mechanism [2]. However, blocking IO can indeed be a problem, often due to heavy load on services. For instance, it used to be the case that some asset fetches were performed asynchronously, so if the asset service was slow, processing triggered by inbound packet handling would be held up. If one were running the two tier system that you described, then this would hold up processing of all second tier packets more than the current system. Perhaps one could forensically identify which handlers could be subject to this problem and handle those differently from others. It's a complex topic as OpenSimulator is very much an evolved (and evolving codebase), where delays can occur in unexpected places and there's a huge variance in network and hardware conditions. In this case, I can imagine that our async handling is more resilient in cases where only a few requests are slow. I believe the key is trying to measure the performance change of a second-tier loop to see if the potential gains are worth the potential problems. [1] http://opensimulator.org/wiki/LLUDP_ClientStack#Inbound_UDP [2] http://opensimulator.org/wiki/Show_stats#stats_record On 26/04/14 13:53, Matt Lehmann wrote: > I looked at this a bit more this morning. > > So, as I understand, the handling looks like this--> > > --async read cycle which drops packet into a blocking queue > --smart thread which services the blocking queue, and calls the LLClientView method ProcessInPacket > > LLClientView sorts the packets according to whether the handler should be called asynchronously or not. > > If async is needed, LLClientView will create a smart thread for the handler, and start the thread. > ...the handlers basically signal the events defined in LLClientView which are listened to by one or more other callbacks. > If async is not needed/desired, then LLClientView will process the packet directly. > > So there is one additional thread being created for each async handler, with the original smart thread running all the > non-async packet handlers. > > The question is /can these async threads can be replaced by a second smart thread, which services a queue of async > handlers/? Do the handlers require some sort of blocking I/O? Can we rearrange the handlers to operate under these > conditions? > > If the answer is yes, then a great deal of compute cycles can be saved by consolidating all the spawned threads into one > single thread loop. > > Matt > > > > > On Fri, Apr 25, 2014 at 10:03 PM, Matt Lehmann > wrote: > > Yes I agree that the udp service is critical and would need extensive testing. > > I wouldn't expect you all to make any changes. > > Still it's an interesting topic. The networking world seems to be moving towards smaller virtualized servers with > less resources, so I think it's an important discussion. At my work we are deploying an opensim cluster which is > why I have become so interested. > > > Thanks > > Matt > > > On Friday, April 25, 2014, Diva Canto > wrote: > > That is one very specific and unique case, something that happens in the beginning, and that is necessary, > otherwise clients crash. It's an "exception" wrt the bulk of processing UDP packets. The bulk of them are > processed as you described in your first message: placed in a queue, consumed by a consumer thread which either > processes them directly or spawns threads for processing them. > > In general, my experience is also that limiting the amount of concurrency is a Good Thing. A couple of years ago > we had way too much concurrency; we've been taming that down. > > As Dahlia said, the packet handling layer of OpenSim is really critical, and the viewers are sensitive to it, so > any drastic changes to it need to go through extensive testing. The current async reading is not bad, as it > empties the socket queue almost immediately. The threads that are spawn from the consumer thread, though, could > use some rethinking. > > On 4/25/2014 9:29 PM, Matt Lehmann wrote: >> One example of what I'm trying to say. >> >> In part of the packet handling there is a condition where the server needs to respond to the client, but does >> not yet know the identity of the client. So the server responds to the client and then spawns a thread which >> loops and sleeps until it can identify the client.( I don't really understand what's going on here,) >> >> Nevertheless in this case you could do without the new thread if you queued a lambda function which would >> check to see if the client can be identified. A second event loop could periodically poll this function until >> it completes. >> >> You could also queue other contexts which would complete the handling of other types of packets. >> >> Matt >> >> On Friday, April 25, 2014, Dahlia Trimble wrote: >> >> From my experience there are some things that need to happen as soon as possible and others which can be >> delayed. What needs to happen ASAP: >> 1). reading the socket and keeping it emptied. >> 2) acknowledge any received packets which may require such >> 3) process any acknowledgements sent by the viewer >> 4) handle AgentUpdate packets. (these can probably be filtered for uniqueness and mostly discarded if not >> unique). >> >> This list is off the top of my head and may not be complete. Most, if not all, other packets could be put >> into queues and process as resources permit without negatively affecting the quality of the shared state >> of the simulation. >> >> Please be aware that viewers running on high-end machines can constantly send several hundred packets per >> second, and that under extreme conditions there can be several hundred viewers connected to a single >> simulator. Any improvements in the UDP processing portions of the code base should probably take these >> constraints into consideration. >> >> >> On Fri, Apr 25, 2014 at 8:17 PM, Matt Lehmann wrote: >> >> That makes sense to me. >> >> If I recall, the packet handlers will create more threads if they expect delays, such as when waiting >> for a client to finish movement into the sim. >> >> Considering that I have 65 threads running on my standalone instance, with 4 cores that leaves about >> 15 threads competing. You have to do the work at some point. >> >> Matt >> >> On Friday, April 25, 2014, Dahlia Trimble wrote: >> >> Depends on what you mean by "services the packets". Decoding and ACKing could probably work well >> in a socket read loop but dispatching the packet to the proper part of the simulation could incur >> many delays which can cause a lot of packet loss in the lower level operating system routines as >> the buffers are only so large and any excessive data is discarded. Putting them in a queue > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > -- Justin Clark-Casey (justincc) OSVW Consulting http://justincc.org http://twitter.com/justincc From mattlehma at gmail.com Mon Apr 28 23:49:44 2014 From: mattlehma at gmail.com (Matt Lehmann) Date: Mon, 28 Apr 2014 16:49:44 -0700 Subject: [Opensim-dev] Question about the udp receiver algorithm In-Reply-To: <535EDDAE.4090500@googlemail.com> References: <535B3B18.6000203@metaverseink.com> <535EDDAE.4090500@googlemail.com> Message-ID: Thanks so much for the explanation Justin. I agree that Networking issues like this are hard to measure. I guess my concern is that, after reading alot of the opensim code, there seems to be a prevalent notion that concurrency will solve issues with responsiveness. It's treated like a magic box where you can 'fireandforget.' If a computation is going to lag your system, then it is going to lag your system whether you do it now or later. What's more is that all the spawning of threads will definitely cause its own problems. I do agree though that a database call might be made in its own thread, so that the cpu can do other things while the disk is spinning. In this case it might be prudent to implement a more complicated scheme involving cached database management. Anyways, thanks so much for the work you all do on opensim. It's a great system. On Apr 28, 2014 4:01 PM, "Justin Clark-Casey" wrote: > That's correct. I added some high level summary to [1]. > > My expectation is that in many situations, the async packets are indeed > handled pretty quickly with very often only a single thread from the pool > used. I've seen this when analyzing threadpool data from the crude stats > recording mechanism [2]. > > However, blocking IO can indeed be a problem, often due to heavy load on > services. For instance, it used to be the case that some asset fetches > were performed asynchronously, so if the asset service was slow, processing > triggered by inbound packet handling would be held up. > > If one were running the two tier system that you described, then this > would hold up processing of all second tier packets more than the current > system. Perhaps one could forensically identify which handlers could be > subject to this problem and handle those differently from others. > > It's a complex topic as OpenSimulator is very much an evolved (and > evolving codebase), where delays can occur in unexpected places and there's > a huge variance in network and hardware conditions. In this case, I can > imagine that our async handling is more resilient in cases where only a few > requests are slow. > > I believe the key is trying to measure the performance change of a > second-tier loop to see if the potential gains are worth the potential > problems. > > [1] http://opensimulator.org/wiki/LLUDP_ClientStack#Inbound_UDP > [2] http://opensimulator.org/wiki/Show_stats#stats_record > > On 26/04/14 13:53, Matt Lehmann wrote: > >> I looked at this a bit more this morning. >> >> So, as I understand, the handling looks like this--> >> >> --async read cycle which drops packet into a blocking queue >> --smart thread which services the blocking queue, and calls the >> LLClientView method ProcessInPacket >> >> LLClientView sorts the packets according to whether the handler should be >> called asynchronously or not. >> >> If async is needed, LLClientView will create a smart thread for the >> handler, and start the thread. >> ...the handlers basically signal the events defined in LLClientView which >> are listened to by one or more other callbacks. >> If async is not needed/desired, then LLClientView will process the packet >> directly. >> >> So there is one additional thread being created for each async handler, >> with the original smart thread running all the >> non-async packet handlers. >> >> The question is /can these async threads can be replaced by a second >> smart thread, which services a queue of async >> handlers/? Do the handlers require some sort of blocking I/O? Can we >> rearrange the handlers to operate under these >> conditions? >> >> If the answer is yes, then a great deal of compute cycles can be saved by >> consolidating all the spawned threads into one >> single thread loop. >> >> Matt >> >> >> >> >> On Fri, Apr 25, 2014 at 10:03 PM, Matt Lehmann > mattlehma at gmail.com>> wrote: >> >> Yes I agree that the udp service is critical and would need extensive >> testing. >> >> I wouldn't expect you all to make any changes. >> >> Still it's an interesting topic. The networking world seems to be >> moving towards smaller virtualized servers with >> less resources, so I think it's an important discussion. At my work >> we are deploying an opensim cluster which is >> why I have become so interested. >> >> >> Thanks >> >> Matt >> >> >> On Friday, April 25, 2014, Diva Canto > diva at metaverseink.com>> wrote: >> >> That is one very specific and unique case, something that happens >> in the beginning, and that is necessary, >> otherwise clients crash. It's an "exception" wrt the bulk of >> processing UDP packets. The bulk of them are >> processed as you described in your first message: placed in a >> queue, consumed by a consumer thread which either >> processes them directly or spawns threads for processing them. >> >> In general, my experience is also that limiting the amount of >> concurrency is a Good Thing. A couple of years ago >> we had way too much concurrency; we've been taming that down. >> >> As Dahlia said, the packet handling layer of OpenSim is really >> critical, and the viewers are sensitive to it, so >> any drastic changes to it need to go through extensive testing. >> The current async reading is not bad, as it >> empties the socket queue almost immediately. The threads that are >> spawn from the consumer thread, though, could >> use some rethinking. >> >> On 4/25/2014 9:29 PM, Matt Lehmann wrote: >> >>> One example of what I'm trying to say. >>> >>> In part of the packet handling there is a condition where the >>> server needs to respond to the client, but does >>> not yet know the identity of the client. So the server responds >>> to the client and then spawns a thread which >>> loops and sleeps until it can identify the client.( I don't >>> really understand what's going on here,) >>> >>> Nevertheless in this case you could do without the new thread if >>> you queued a lambda function which would >>> check to see if the client can be identified. A second event >>> loop could periodically poll this function until >>> it completes. >>> >>> You could also queue other contexts which would complete the >>> handling of other types of packets. >>> >>> Matt >>> >>> On Friday, April 25, 2014, Dahlia Trimble < >>> dahliatrimble at gmail.com> wrote: >>> >>> From my experience there are some things that need to happen >>> as soon as possible and others which can be >>> delayed. What needs to happen ASAP: >>> 1). reading the socket and keeping it emptied. >>> 2) acknowledge any received packets which may require such >>> 3) process any acknowledgements sent by the viewer >>> 4) handle AgentUpdate packets. (these can probably be >>> filtered for uniqueness and mostly discarded if not >>> unique). >>> >>> This list is off the top of my head and may not be complete. >>> Most, if not all, other packets could be put >>> into queues and process as resources permit without >>> negatively affecting the quality of the shared state >>> of the simulation. >>> >>> Please be aware that viewers running on high-end machines >>> can constantly send several hundred packets per >>> second, and that under extreme conditions there can be >>> several hundred viewers connected to a single >>> simulator. Any improvements in the UDP processing portions >>> of the code base should probably take these >>> constraints into consideration. >>> >>> >>> On Fri, Apr 25, 2014 at 8:17 PM, Matt Lehmann < >>> mattlehma at gmail.com> wrote: >>> >>> That makes sense to me. >>> >>> If I recall, the packet handlers will create more >>> threads if they expect delays, such as when waiting >>> for a client to finish movement into the sim. >>> >>> Considering that I have 65 threads running on my >>> standalone instance, with 4 cores that leaves about >>> 15 threads competing. You have to do the work at some >>> point. >>> >>> Matt >>> >>> On Friday, April 25, 2014, Dahlia Trimble < >>> dahliatrimble at gmail.com> wrote: >>> >>> Depends on what you mean by "services the packets". >>> Decoding and ACKing could probably work well >>> in a socket read loop but dispatching the packet to >>> the proper part of the simulation could incur >>> many delays which can cause a lot of packet loss in >>> the lower level operating system routines as >>> the buffers are only so large and any excessive data >>> is discarded. Putting them in a queue >>> >> >> >> >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at opensimulator.org >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> >> > > -- > Justin Clark-Casey (justincc) > OSVW Consulting > http://justincc.org > http://twitter.com/justincc > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dahliatrimble at gmail.com Tue Apr 29 01:19:13 2014 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Mon, 28 Apr 2014 18:19:13 -0700 Subject: [Opensim-dev] Question about the udp receiver algorithm In-Reply-To: References: <535B3B18.6000203@metaverseink.com> <535EDDAE.4090500@googlemail.com> Message-ID: I agree the present use of threads is far from optimal but I believe it to be more a matter of convenience which was overused, partially due to the origins of the codebase being from many diverse contributors with diverse goals and a naive, but evolving, initial design. Such is probably unavoidable in open source programs of this size. However, threadpool threads are not necessarily as inefficient as some of the messages in this thread might imply. They end up using very few operating system threads and share these among many tasks and do context switching in user space rather than requiring kernel traps. This reduces the normal cost s associated with using threads and can provide an efficient means of multitasking within a process if used correctly. A discussion of recommend ways of performing asynchronous IO with a threadpool can be found here: http://msdn.microsoft.com/en-us/library/ms973903.aspx#threadpool_topic6 On Mon, Apr 28, 2014 at 4:49 PM, Matt Lehmann wrote: > Thanks so much for the explanation Justin. > > I agree that Networking issues like this are hard to measure. > > I guess my concern is that, after reading alot of the opensim code, > there seems to be a prevalent notion that concurrency will solve issues > with responsiveness. It's treated like a magic box where you can > 'fireandforget.' > > If a computation is going to lag your system, then it is going to lag > your system whether you do it now or later. What's more is that all the > spawning of threads will definitely cause its own problems. > > I do agree though that a database call might be made in its own thread, > so that the cpu can do other things while the disk is spinning. In this > case it might be prudent to implement a more complicated scheme involving > cached database management. > > Anyways, thanks so much for the work you all do on opensim. It's a > great system. > On Apr 28, 2014 4:01 PM, "Justin Clark-Casey" > wrote: > >> That's correct. I added some high level summary to [1]. >> >> My expectation is that in many situations, the async packets are indeed >> handled pretty quickly with very often only a single thread from the pool >> used. I've seen this when analyzing threadpool data from the crude stats >> recording mechanism [2]. >> >> However, blocking IO can indeed be a problem, often due to heavy load on >> services. For instance, it used to be the case that some asset fetches >> were performed asynchronously, so if the asset service was slow, processing >> triggered by inbound packet handling would be held up. >> >> If one were running the two tier system that you described, then this >> would hold up processing of all second tier packets more than the current >> system. Perhaps one could forensically identify which handlers could be >> subject to this problem and handle those differently from others. >> >> It's a complex topic as OpenSimulator is very much an evolved (and >> evolving codebase), where delays can occur in unexpected places and there's >> a huge variance in network and hardware conditions. In this case, I can >> imagine that our async handling is more resilient in cases where only a few >> requests are slow. >> >> I believe the key is trying to measure the performance change of a >> second-tier loop to see if the potential gains are worth the potential >> problems. >> >> [1] http://opensimulator.org/wiki/LLUDP_ClientStack#Inbound_UDP >> [2] http://opensimulator.org/wiki/Show_stats#stats_record >> >> On 26/04/14 13:53, Matt Lehmann wrote: >> >>> I looked at this a bit more this morning. >>> >>> So, as I understand, the handling looks like this--> >>> >>> --async read cycle which drops packet into a blocking queue >>> --smart thread which services the blocking queue, and calls the >>> LLClientView method ProcessInPacket >>> >>> LLClientView sorts the packets according to whether the handler should >>> be called asynchronously or not. >>> >>> If async is needed, LLClientView will create a smart thread for the >>> handler, and start the thread. >>> ...the handlers basically signal the events defined in LLClientView >>> which are listened to by one or more other callbacks. >>> If async is not needed/desired, then LLClientView will process the >>> packet directly. >>> >>> So there is one additional thread being created for each async handler, >>> with the original smart thread running all the >>> non-async packet handlers. >>> >>> The question is /can these async threads can be replaced by a second >>> smart thread, which services a queue of async >>> handlers/? Do the handlers require some sort of blocking I/O? Can we >>> rearrange the handlers to operate under these >>> conditions? >>> >>> If the answer is yes, then a great deal of compute cycles can be saved >>> by consolidating all the spawned threads into one >>> single thread loop. >>> >>> Matt >>> >>> >>> >>> >>> On Fri, Apr 25, 2014 at 10:03 PM, Matt Lehmann >> mattlehma at gmail.com>> wrote: >>> >>> Yes I agree that the udp service is critical and would need >>> extensive testing. >>> >>> I wouldn't expect you all to make any changes. >>> >>> Still it's an interesting topic. The networking world seems to be >>> moving towards smaller virtualized servers with >>> less resources, so I think it's an important discussion. At my work >>> we are deploying an opensim cluster which is >>> why I have become so interested. >>> >>> >>> Thanks >>> >>> Matt >>> >>> >>> On Friday, April 25, 2014, Diva Canto >> diva at metaverseink.com>> wrote: >>> >>> That is one very specific and unique case, something that >>> happens in the beginning, and that is necessary, >>> otherwise clients crash. It's an "exception" wrt the bulk of >>> processing UDP packets. The bulk of them are >>> processed as you described in your first message: placed in a >>> queue, consumed by a consumer thread which either >>> processes them directly or spawns threads for processing them. >>> >>> In general, my experience is also that limiting the amount of >>> concurrency is a Good Thing. A couple of years ago >>> we had way too much concurrency; we've been taming that down. >>> >>> As Dahlia said, the packet handling layer of OpenSim is really >>> critical, and the viewers are sensitive to it, so >>> any drastic changes to it need to go through extensive testing. >>> The current async reading is not bad, as it >>> empties the socket queue almost immediately. The threads that >>> are spawn from the consumer thread, though, could >>> use some rethinking. >>> >>> On 4/25/2014 9:29 PM, Matt Lehmann wrote: >>> >>>> One example of what I'm trying to say. >>>> >>>> In part of the packet handling there is a condition where the >>>> server needs to respond to the client, but does >>>> not yet know the identity of the client. So the server responds >>>> to the client and then spawns a thread which >>>> loops and sleeps until it can identify the client.( I don't >>>> really understand what's going on here,) >>>> >>>> Nevertheless in this case you could do without the new thread >>>> if you queued a lambda function which would >>>> check to see if the client can be identified. A second event >>>> loop could periodically poll this function until >>>> it completes. >>>> >>>> You could also queue other contexts which would complete the >>>> handling of other types of packets. >>>> >>>> Matt >>>> >>>> On Friday, April 25, 2014, Dahlia Trimble < >>>> dahliatrimble at gmail.com> wrote: >>>> >>>> From my experience there are some things that need to >>>> happen as soon as possible and others which can be >>>> delayed. What needs to happen ASAP: >>>> 1). reading the socket and keeping it emptied. >>>> 2) acknowledge any received packets which may require such >>>> 3) process any acknowledgements sent by the viewer >>>> 4) handle AgentUpdate packets. (these can probably be >>>> filtered for uniqueness and mostly discarded if not >>>> unique). >>>> >>>> This list is off the top of my head and may not be >>>> complete. Most, if not all, other packets could be put >>>> into queues and process as resources permit without >>>> negatively affecting the quality of the shared state >>>> of the simulation. >>>> >>>> Please be aware that viewers running on high-end machines >>>> can constantly send several hundred packets per >>>> second, and that under extreme conditions there can be >>>> several hundred viewers connected to a single >>>> simulator. Any improvements in the UDP processing portions >>>> of the code base should probably take these >>>> constraints into consideration. >>>> >>>> >>>> On Fri, Apr 25, 2014 at 8:17 PM, Matt Lehmann < >>>> mattlehma at gmail.com> wrote: >>>> >>>> That makes sense to me. >>>> >>>> If I recall, the packet handlers will create more >>>> threads if they expect delays, such as when waiting >>>> for a client to finish movement into the sim. >>>> >>>> Considering that I have 65 threads running on my >>>> standalone instance, with 4 cores that leaves about >>>> 15 threads competing. You have to do the work at some >>>> point. >>>> >>>> Matt >>>> >>>> On Friday, April 25, 2014, Dahlia Trimble < >>>> dahliatrimble at gmail.com> wrote: >>>> >>>> Depends on what you mean by "services the packets". >>>> Decoding and ACKing could probably work well >>>> in a socket read loop but dispatching the packet to >>>> the proper part of the simulation could incur >>>> many delays which can cause a lot of packet loss in >>>> the lower level operating system routines as >>>> the buffers are only so large and any excessive >>>> data is discarded. Putting them in a queue >>>> >>> >>> >>> >>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev at opensimulator.org >>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>> >>> >> >> -- >> Justin Clark-Casey (justincc) >> OSVW Consulting >> http://justincc.org >> http://twitter.com/justincc >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at opensimulator.org >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From misterblue at misterblue.com Tue Apr 29 02:29:51 2014 From: misterblue at misterblue.com (Mister Blue) Date: Mon, 28 Apr 2014 19:29:51 -0700 Subject: [Opensim-dev] Negative z values In-Reply-To: <535ED09B.2020404@googlemail.com> References: <535b6bcb.25efc20a.0a11.ffffd0a0@mx.google.com> <535ED09B.2020404@googlemail.com> Message-ID: I checked in changes to BulletSim which default the ground plane to -500 instead of zero. There is a new BulletSim parameter of "[BulletSim]TerrainGroundPlane = -500" which allows that to change. I haven't yet finished looking through the terrain loading and storing code so there could still be problems with loading and restoring negative terrain heights, but it looks like the code will work once you get the terrain negative. Please test. If found in my testing that there are checks for zero scattered around OpenSimulator. For instance, LowerSphere.cs (the terrain brush used for lowering terrain) will not lower terrain below zero. -- mb On Mon, Apr 28, 2014 at 3:05 PM, Justin Clark-Casey < jjustincc at googlemail.com> wrote: > I don't think there should be too many places. I know there are a few on > teleport and MakeRootAgent (as Austin pointed out) but it looks like it > should be fairly simple to check real terrain height, which might already > be done anyway and be masked by the zero check. > > It does work in general as it has been possible with ODE. > > > On 27/04/14 18:13, Mister Blue wrote: > >> When I built BulletSim, I build for positive only altitudes because I >> thought that was the rule. The only implementation >> reason I see for not allowing negative terrain altitudes would be finding >> all the random places where code makes sign >> assumptions. >> >> If negative altitudes are needed, it would not be too hard to make it >> happen. I can see the geographically oriented >> people wanting zero to be sea level and allowing land to be above and >> below that. >> >> -- mb >> >> >> On Sat, Apr 26, 2014 at 8:11 AM, Cinder Roxley < >> cinder.roxley at phoenixviewer.com >> > wrote: >> >> Given reasonable constraints, I don't see why viewers wouldn't be >> able to adapt to support variable depth. I'd >> certainly be willing to write a viewer patch if support cropped up. >> >> >> On Sat, Apr 26, 2014 at 8:52 AM, David Saunders > abitar.com at gmail.com>> wrote: >> >> I wounder how hard it would be to modify varasm to allow a start >> and end to the Z axes so we can stack a deep >> ocean and a space sim to the normal sim :) >> >> But then again would the client handle all these changes? (partly >> do) >> >> So the solution is to make deep water simulators, But any test >> this? I never been asked to set up any sims with >> deep water so I not experience with "outside the box" water :) >> >> I was drawn to opensim with the idea of making "pure" space sims >> where you can float around in real space but I >> dug into it and I would have to rewrite so much code to do this >> and after that would the client handle it? So I >> stuck with making Moon simulators, Low gravity fixed sky.... >> This was a long time ago, back in the early days >> of opensim. >> >> Now times are changing, I think I might dig into doing it again >> since varasim allow you to make a >> 4096x4096x4096 regions :) >> >> >> >> On Sat, Apr 26, 2014 at 4:18 AM, Ai Austin < >> ai.ai.austin at gmail.com > wrote: >> >> At 04:09 26/04/2014, drWhiet wrote: >> >> even boat creators must keep an eye that the engine does >> not move below -0 >> >> >> Remember the default water level is +20m (adjustable on a per >> region basis)... with a "normal" terrain base >> of 0m. >> >> Maybe its global warming in the metaverse that raised the sea >> level :-) >> >> >> >> >> _________________________________________________ >> Opensim-dev mailing list >> Opensim-dev at opensimulator.org > opensimulator.org> >> http://opensimulator.org/cgi-__bin/mailman/listinfo/opensim- >> __dev >> > dev> >> >> >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at opensimulator.org > opensimulator.org> >> >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> >> >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at opensimulator.org >> >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> >> >> >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at opensimulator.org >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> >> > > -- > Justin Clark-Casey (justincc) > OSVW Consulting > http://justincc.org > http://twitter.com/justincc > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ai.ai.austin at gmail.com Tue Apr 29 10:16:22 2014 From: ai.ai.austin at gmail.com (Ai Austin) Date: Tue, 29 Apr 2014 11:16:22 +0100 Subject: [Opensim-dev] Negative z values In-Reply-To: References: Message-ID: <535f7bf7.a762b40a.43c5.75ad@mx.google.com> >Cinder Roxley Sat Apr 26 15:11:59 UTC 2014 >Given reasonable constraints, I don't see why viewers wouldn't be able to >adapt to support variable depth. I'd certainly be willing to write a viewer >patch if support cropped up. Cinder, there is one little thing I spotted in Firestorm 4.6.1 in testing negative terrain regions... http://jira.phoenixviewer.com/browse/FIRE-13582 From douglas.b.maxwell at us.army.mil Tue Apr 29 17:53:49 2014 From: douglas.b.maxwell at us.army.mil (Maxwell, Douglas) Date: Tue, 29 Apr 2014 13:53:49 -0400 Subject: [Opensim-dev] Job Opportunity on the MOSES Team Message-ID: <82C3F748B35E7C47A716D708A2894F2B012CCB9721ED@STRI011C8EVS1.peostri.army.mil> Good Morning All, there is an open Post Doctoral position on the MOSES Team. I have identified two areas of research for this position and applicants must specify which research topic they wish to concentrate on. The Post Doc funding and HR will be handled by Oak Ridge Nat'l Labs, but the work will be performed onsite in Orlando, Fl. This is a paid position, relocation assistance may be approved, and insurance benefits are provided. The position also includes travel responsibilities. Both areas of research are related to technology advanced needed to support distributed simulation based training applications. Specifically with automated load balancing and independently running collaborative clusters. Topic 1 deals with an investigation of the creation of a physics cluster that can automatically detect and reallocate computing resources based on demand. This cluster is envisioned to be a pooled resource, rather than coupled with a specific simulator instance. Topic 2 is a more generic and involved total simulation load balancing. Currently the simulators require scenario examination and resource planning before deployment. Also many system including Open Simulator have static terrain limits. I'm looking for automation of the allocation of resources based on user behaviors. In practical terms, imagine having a distributed scene graph that can automatically reconfigure itself by adding or reallocating computing resources based on user behaviors. We'll also need a good name for this new system. Skynet has a nice ring to it.... Useful URLs: Oak Ridge Institute for Science and Education https://www.orau.org/maryland/default.html Topic 1 Distributed Physics Integration http://goo.gl/1tki0x Topic 2 Dynamic Allocation of Compute Cluster Resources http://goo.gl/d4MZ5c If you'd like a better idea of what we do in the Orlando Research Park, a consortium of Military/Industry/Academic partners called "Team Orlando" has produced a short 6 minute video on our activities. This video may be useful to you in the future. http://youtu.be/IxHlEN0KjXc Please feel free to forward this message to anyone interested in applying. Good Luck! v/r -douglas Douglas Maxwell, MSME Science and Technology Manager Virtual World Strategic Applications U.S. Army Research Lab Simulation & Training Technology Center (STTC) (c) (407) 242-0209 NEW DoD Email: Douglas.Maxwell3.civ at mail.mil From jjustincc at googlemail.com Tue Apr 29 19:39:25 2014 From: jjustincc at googlemail.com (Justin Clark-Casey) Date: Tue, 29 Apr 2014 20:39:25 +0100 Subject: [Opensim-dev] Negative z values In-Reply-To: References: <535b6bcb.25efc20a.0a11.ffffd0a0@mx.google.com> <535ED09B.2020404@googlemail.com> Message-ID: <535FFFED.9070107@googlemail.com> Sounds good. On another topic, any further thoughts about using a compression factor of 200 on terrain for this release? On 29/04/14 03:29, Mister Blue wrote: > I checked in changes to BulletSim which default the ground plane to -500 instead of zero. There is a new BulletSim > parameter of "[BulletSim]TerrainGroundPlane = -500" which allows that to change. > > I haven't yet finished looking through the terrain loading and storing code so there could still be problems with > loading and restoring negative terrain heights, but it looks like the code will work once you get the terrain negative. > Please test. > > If found in my testing that there are checks for zero scattered around OpenSimulator. For instance, LowerSphere.cs (the > terrain brush used for lowering terrain) will not lower terrain below zero. > > -- mb > > > On Mon, Apr 28, 2014 at 3:05 PM, Justin Clark-Casey > wrote: > > I don't think there should be too many places. I know there are a few on teleport and MakeRootAgent (as Austin > pointed out) but it looks like it should be fairly simple to check real terrain height, which might already be done > anyway and be masked by the zero check. > > It does work in general as it has been possible with ODE. > > > On 27/04/14 18:13, Mister Blue wrote: > > When I built BulletSim, I build for positive only altitudes because I thought that was the rule. The only > implementation > reason I see for not allowing negative terrain altitudes would be finding all the random places where code makes > sign > assumptions. > > If negative altitudes are needed, it would not be too hard to make it happen. I can see the geographically oriented > people wanting zero to be sea level and allowing land to be above and below that. > > -- mb > > > On Sat, Apr 26, 2014 at 8:11 AM, Cinder Roxley > >> wrote: > > Given reasonable constraints, I don't see why viewers wouldn't be able to adapt to support variable depth. I'd > certainly be willing to write a viewer patch if support cropped up. > > > On Sat, Apr 26, 2014 at 8:52 AM, David Saunders > >> wrote: > > I wounder how hard it would be to modify varasm to allow a start and end to the Z axes so we can stack > a deep > ocean and a space sim to the normal sim :) > > But then again would the client handle all these changes? (partly do) > > So the solution is to make deep water simulators, But any test this? I never been asked to set up any > sims with > deep water so I not experience with "outside the box" water :) > > I was drawn to opensim with the idea of making "pure" space sims where you can float around in real > space but I > dug into it and I would have to rewrite so much code to do this and after that would the client handle > it? So I > stuck with making Moon simulators, Low gravity fixed sky.... This was a long time ago, back in the > early days > of opensim. > > Now times are changing, I think I might dig into doing it again since varasim allow you to make a > 4096x4096x4096 regions :) > > > > On Sat, Apr 26, 2014 at 4:18 AM, Ai Austin > __>> wrote: > > At 04:09 26/04/2014, drWhiet wrote: > > even boat creators must keep an eye that the engine does not move below -0 > > > Remember the default water level is +20m (adjustable on a per region basis)... with a "normal" > terrain base > of 0m. > > Maybe its global warming in the metaverse that raised the sea level :-) > > > > > ___________________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > > http://opensimulator.org/cgi-____bin/mailman/listinfo/opensim-____dev > > > > > > > _________________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > > > http://opensimulator.org/cgi-__bin/mailman/listinfo/opensim-__dev > > > > > _________________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > > > http://opensimulator.org/cgi-__bin/mailman/listinfo/opensim-__dev > > > > > > _________________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-__bin/mailman/listinfo/opensim-__dev > > > > > -- > Justin Clark-Casey (justincc) > OSVW Consulting > http://justincc.org > http://twitter.com/justincc > _________________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-__bin/mailman/listinfo/opensim-__dev > > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > -- Justin Clark-Casey (justincc) OSVW Consulting http://justincc.org http://twitter.com/justincc From misterblue at misterblue.com Tue Apr 29 22:53:42 2014 From: misterblue at misterblue.com (Mister Blue) Date: Tue, 29 Apr 2014 15:53:42 -0700 Subject: [Opensim-dev] Negative z values In-Reply-To: <535FFFED.9070107@googlemail.com> References: <535b6bcb.25efc20a.0a11.ffffd0a0@mx.google.com> <535ED09B.2020404@googlemail.com> <535FFFED.9070107@googlemail.com> Message-ID: if the variables are going to stay ints, then 200 would just mean more detail. Actually, if you are going to use ints, might as well go to floats and use a compression factor of one. That would give the range people want and use the same memory as ints. -- mb On Tue, Apr 29, 2014 at 12:39 PM, Justin Clark-Casey < jjustincc at googlemail.com> wrote: > Sounds good. On another topic, any further thoughts about using a > compression factor of 200 on terrain for this release? > > > On 29/04/14 03:29, Mister Blue wrote: > >> I checked in changes to BulletSim which default the ground plane to -500 >> instead of zero. There is a new BulletSim >> parameter of "[BulletSim]TerrainGroundPlane = -500" which allows that to >> change. >> >> I haven't yet finished looking through the terrain loading and storing >> code so there could still be problems with >> loading and restoring negative terrain heights, but it looks like the >> code will work once you get the terrain negative. >> Please test. >> >> If found in my testing that there are checks for zero scattered around >> OpenSimulator. For instance, LowerSphere.cs (the >> terrain brush used for lowering terrain) will not lower terrain below >> zero. >> >> -- mb >> >> >> On Mon, Apr 28, 2014 at 3:05 PM, Justin Clark-Casey < >> jjustincc at googlemail.com > wrote: >> >> I don't think there should be too many places. I know there are a >> few on teleport and MakeRootAgent (as Austin >> pointed out) but it looks like it should be fairly simple to check >> real terrain height, which might already be done >> anyway and be masked by the zero check. >> >> It does work in general as it has been possible with ODE. >> >> >> On 27/04/14 18:13, Mister Blue wrote: >> >> When I built BulletSim, I build for positive only altitudes >> because I thought that was the rule. The only >> implementation >> reason I see for not allowing negative terrain altitudes would be >> finding all the random places where code makes >> sign >> assumptions. >> >> If negative altitudes are needed, it would not be too hard to >> make it happen. I can see the geographically oriented >> people wanting zero to be sea level and allowing land to be above >> and below that. >> >> -- mb >> >> >> On Sat, Apr 26, 2014 at 8:11 AM, Cinder Roxley >> > >> >> > phoenixviewer.com>>> wrote: >> >> Given reasonable constraints, I don't see why viewers >> wouldn't be able to adapt to support variable depth. I'd >> certainly be willing to write a viewer patch if support >> cropped up. >> >> >> On Sat, Apr 26, 2014 at 8:52 AM, David Saunders < >> abitar.com at gmail.com >> >> >> wrote: >> >> I wounder how hard it would be to modify varasm to allow >> a start and end to the Z axes so we can stack >> a deep >> ocean and a space sim to the normal sim :) >> >> But then again would the client handle all these >> changes? (partly do) >> >> So the solution is to make deep water simulators, But >> any test this? I never been asked to set up any >> sims with >> deep water so I not experience with "outside the box" >> water :) >> >> I was drawn to opensim with the idea of making "pure" >> space sims where you can float around in real >> space but I >> dug into it and I would have to rewrite so much code to >> do this and after that would the client handle >> it? So I >> stuck with making Moon simulators, Low gravity fixed >> sky.... This was a long time ago, back in the >> early days >> of opensim. >> >> Now times are changing, I think I might dig into doing >> it again since varasim allow you to make a >> 4096x4096x4096 regions :) >> >> >> >> On Sat, Apr 26, 2014 at 4:18 AM, Ai Austin < >> ai.ai.austin at gmail.com >> __>> >> wrote: >> >> At 04:09 26/04/2014, drWhiet wrote: >> >> even boat creators must keep an eye that the >> engine does not move below -0 >> >> >> Remember the default water level is +20m (adjustable >> on a per region basis)... with a "normal" >> terrain base >> of 0m. >> >> Maybe its global warming in the metaverse that >> raised the sea level :-) >> >> >> >> >> ___________________________________________________ >> Opensim-dev mailing list >> Opensim-dev at opensimulator.org > opensimulator.org> > > >> http://opensimulator.org/cgi-____bin/mailman/listinfo/ >> opensim-____dev >> > opensim-__dev> >> > __bin/mailman/listinfo/opensim-__dev >> > >> >> >> >> _________________________________________________ >> Opensim-dev mailing list >> Opensim-dev at opensimulator.org > opensimulator.org> > >> > >> >> http://opensimulator.org/cgi-__bin/mailman/listinfo/opensim-__dev >> >> >> >> >> _________________________________________________ >> Opensim-dev mailing list >> Opensim-dev at opensimulator.org > opensimulator.org> > >> > >> >> http://opensimulator.org/cgi-__bin/mailman/listinfo/opensim-__dev >> >> >> >> >> >> _________________________________________________ >> Opensim-dev mailing list >> Opensim-dev at opensimulator.org > opensimulator.org> >> http://opensimulator.org/cgi-__bin/mailman/listinfo/opensim-__dev >> >> >> >> >> -- >> Justin Clark-Casey (justincc) >> OSVW Consulting >> http://justincc.org >> http://twitter.com/justincc >> _________________________________________________ >> Opensim-dev mailing list >> Opensim-dev at opensimulator.org >> http://opensimulator.org/cgi-__bin/mailman/listinfo/opensim-__dev >> >> >> >> >> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev at opensimulator.org >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> >> > > -- > Justin Clark-Casey (justincc) > OSVW Consulting > http://justincc.org > http://twitter.com/justincc > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jjustincc at googlemail.com Wed Apr 30 18:10:39 2014 From: jjustincc at googlemail.com (Justin Clark-Casey) Date: Wed, 30 Apr 2014 19:10:39 +0100 Subject: [Opensim-dev] Negative z values In-Reply-To: References: <535b6bcb.25efc20a.0a11.ffffd0a0@mx.google.com> <535ED09B.2020404@googlemail.com> <535FFFED.9070107@googlemail.com> Message-ID: <53613C9F.4090704@googlemail.com> Yes sorry, I meant 50 - I get confused since the lower number is more compression. I would like to revert my in-memory short -> int change and double the compression instead. However, this would mean a terrain height resolution of 2cm. Even though the weakest terrain tool changes in my testing are orders of magnitude greater than this resolution, I'm still concerned about the effect on existing terrains where objects may have been positioned very accurately or where physics may be a factor. At this point, >327m heights will now work again on 256x256 regions because of their legacy approach of storing terrain data in doubles. However, varregions will still not work with >327m heights because they use Int16 for storage and I haven't changed that. As varregions are new in this release and have never previously worked with >327m heights, I propose to leave that as the case for now. I do think this is less than ideal, as it means different limits on 256 and varregions (not that we actually police limits), but changing the storage format is not something that I want to do at this release stage and I know quite a few of your concerns centred around this. It also struck me that if one is using ints then it would make more sense just to use floats. However, I'm trying to do the minimal code changes necessary right now and I was concerned about introducing bugs on double -> float conversions (e.g. [1]). Also, I want to apologise if you're unhappy that I went and introduced this change without talking with you further. Ordinarily, I would have done this but I was under the impression that you would be away for a while and not picking up e-mail. I was anxious to get the remaining major issues squashed to make the first release candidate possible so just took the plunge. Possibly this was the wrong decision. [1] http://stackoverflow.com/questions/6640742/convert-double-to-float-without-infinity Regards, Justin On 29/04/14 23:53, Mister Blue wrote: > if the variables are going to stay ints, then 200 would just mean more detail. > > Actually, if you are going to use ints, might as well go to floats and use a compression factor of one. That would give > the range people want and use the same memory as ints. > > -- mb > > > On Tue, Apr 29, 2014 at 12:39 PM, Justin Clark-Casey > wrote: > > Sounds good. On another topic, any further thoughts about using a compression factor of 200 on terrain for this > release? > > > On 29/04/14 03:29, Mister Blue wrote: > > I checked in changes to BulletSim which default the ground plane to -500 instead of zero. There is a new BulletSim > parameter of "[BulletSim]TerrainGroundPlane = -500" which allows that to change. > > I haven't yet finished looking through the terrain loading and storing code so there could still be problems with > loading and restoring negative terrain heights, but it looks like the code will work once you get the terrain > negative. > Please test. > > If found in my testing that there are checks for zero scattered around OpenSimulator. For instance, > LowerSphere.cs (the > terrain brush used for lowering terrain) will not lower terrain below zero. > > -- mb > > > On Mon, Apr 28, 2014 at 3:05 PM, Justin Clark-Casey > >> wrote: > > I don't think there should be too many places. I know there are a few on teleport and MakeRootAgent (as Austin > pointed out) but it looks like it should be fairly simple to check real terrain height, which might already > be done > anyway and be masked by the zero check. > > It does work in general as it has been possible with ODE. > > > On 27/04/14 18:13, Mister Blue wrote: > > When I built BulletSim, I build for positive only altitudes because I thought that was the rule. The only > implementation > reason I see for not allowing negative terrain altitudes would be finding all the random places where > code makes > sign > assumptions. > > If negative altitudes are needed, it would not be too hard to make it happen. I can see the > geographically oriented > people wanting zero to be sea level and allowing land to be above and below that. > > -- mb > > > On Sat, Apr 26, 2014 at 8:11 AM, Cinder Roxley > > > __phoeni__xviewer.com > >>> wrote: > > Given reasonable constraints, I don't see why viewers wouldn't be able to adapt to support > variable depth. I'd > certainly be willing to write a viewer patch if support cropped up. > > > On Sat, Apr 26, 2014 at 8:52 AM, David Saunders > > >>__> wrote: > > I wounder how hard it would be to modify varasm to allow a start and end to the Z axes so we > can stack > a deep > ocean and a space sim to the normal sim :) > > But then again would the client handle all these changes? (partly do) > > So the solution is to make deep water simulators, But any test this? I never been asked to set > up any > sims with > deep water so I not experience with "outside the box" water :) > > I was drawn to opensim with the idea of making "pure" space sims where you can float around in > real > space but I > dug into it and I would have to rewrite so much code to do this and after that would the > client handle > it? So I > stuck with making Moon simulators, Low gravity fixed sky.... This was a long time ago, back > in the > early days > of opensim. > > Now times are changing, I think I might dig into doing it again since varasim allow you to make a > 4096x4096x4096 regions :) > > > > On Sat, Apr 26, 2014 at 4:18 AM, Ai Austin __> > __>__>> wrote: > > At 04:09 26/04/2014, drWhiet wrote: > > even boat creators must keep an eye that the engine does not move below -0 > > > Remember the default water level is +20m (adjustable on a per region basis)... with a "normal" > terrain base > of 0m. > > Maybe its global warming in the metaverse that raised the sea level :-) > > > > > _____________________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > __opensimu__lator.org > > >> > http://opensimulator.org/cgi-______bin/mailman/listinfo/__opensim-____dev > > > > > >> > > > > ___________________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > __opensimu__lator.org > > > >> > > http://opensimulator.org/cgi-____bin/mailman/listinfo/opensim-____dev > > > > > > > ___________________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > __opensimu__lator.org > > > >> > > http://opensimulator.org/cgi-____bin/mailman/listinfo/opensim-____dev > > > > > > > > ___________________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > > http://opensimulator.org/cgi-____bin/mailman/listinfo/opensim-____dev > > > > > > > -- > Justin Clark-Casey (justincc) > OSVW Consulting > http://justincc.org > http://twitter.com/justincc > ___________________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > > http://opensimulator.org/cgi-____bin/mailman/listinfo/opensim-____dev > > > > > > > > _________________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-__bin/mailman/listinfo/opensim-__dev > > > > > -- > Justin Clark-Casey (justincc) > OSVW Consulting > http://justincc.org > http://twitter.com/justincc > _________________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-__bin/mailman/listinfo/opensim-__dev > > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > -- Justin Clark-Casey (justincc) OSVW Consulting http://justincc.org http://twitter.com/justincc From mlehmann8 at hotmail.com Thu Apr 24 16:30:11 2014 From: mlehmann8 at hotmail.com (matt lehmann) Date: Thu, 24 Apr 2014 16:30:11 -0000 Subject: [Opensim-dev] Using Socket polling for UDP receive handlers Message-ID: Hello, The current implementation of UDP reception ( as of the latest release ) is as follows. -- create an async read cycle on the socket, adding packets to a blocking queue -- create a smart thread which waits on the blocking queue, servicing new packets as the occur I propose a simpler solution, which will give more control over rate of reception, and also eliminate the need for two separate threads in reception. This solution involves polling the udp socket, from within the smart thread. The function IncomingPacketHandler, from within the LLUDPServer class changes to this: private void IncomingPacketHandler() { .... IncomingPacket incomingPacket = null; base.pollReceive(); while(packetInbox.Count > 0) { incomingPacket = packetInbox.Dequeue(); ProcessInPacket(incomingPacket);//, incomingPacket); Util.FireAndForget(ProcessInPacket, incomingPacket); if (UsePools) m_incomingPacketPool.ReturnObject(incomingPacket); } .... } packetInbox is now a standard .NET queue. The method, pollReceive on the base class looks like this: public bool pollReceive() { if (m_udpSocket.Poll(100, SelectMode.SelectRead)) { UDPPacketBuffer buf = new UDPPacketBuffer(); buf.DataLength = m_udpSocket.ReceiveFrom(buf.Data, 0, UDPPacketBuffer.BUFFER_SIZE, SocketFlags.None, ref buf.RemoteEndPoint); PacketReceived(buf); return true; } return false; } This setup should allow for better throughput, as there will be less context switching and reliance on the .NET threading runtime to service the async requests. Also, it would now be possible to throttle incoming packets under heavy loads. Matt Lehmann -------------- next part -------------- An HTML attachment was scrubbed... URL: