Re: [Opensim-dev] Older region databases incompatible with the latest SVN

[Diva Canto]

Yes, I've seen this too. In fact, one of our regions in OSGrid is still 
suffering from it.
I'm not sure where the bug is, except that it happened around the 3rd 
week of January.
We've been able to get around it by removing the local OpenSim.db, and 
loading all the objects from backups we had (in xml or oar format, not 
sure which).



Mircea Kitsune wrote:
I hope this mailing list is a good place to ask for help with such 
issues, though I believe this to be an OpenSim bug as well. I keep 
having this problem for more then a week now and I'm starting to get 
more and more worried as I don't want to loose all the sims I have 
been working on till now.


I reported this on Mantis over here 
 a few days ago 
which includes more info. Basically since updating to a certain 
revision a few days ago, whenever I startup my sim only half of the 
primitives or linksets there load while the rest don't, visually nor 
collisions (mainly the linksets which don't contain scripts refuse to 
load). After I updated my opensim.ini.example, Opensim attempts to 
convert the database to a newer version but whenever it gets started 
on converting every linkset to a newer format it also says "[REGION 
DB]: System.FormatException: Guid should contain 32 digits with 4 
dashes (----)" and when I go in-world 
I have almost no primitives showing there like before.


What's wrong with my storage, why doesn't it work with the latest SVN? 
How can I recover my sims to get them working correctly again? Is 
anyone else experiencing this issue as well? Here's a screenshot 
 of how 
broken buildings look on one of my sims, basically less then half of 
them load. Any help would be very appreciated. Thanks.



Invite your mail contacts to join your friends list with Windows Live 
Spaces. It's easy! Try it! 
 




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


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

Re: [Opensim-dev] AssetServer Observations and Suggestions

[Justin Clark-Casey]

cmick...@gmail.com wrote:
> The short term solution is to use the "last access" field for each of 
> the assets and archive ones that haven't been used recently . So long as 
> inventory is in one place (that is, you aren't splitting inventory 
> across servers) you should be able to do some "simple" mysql magic to 
> update the last access on anything referenced in the inventory 
> (basically update last access time for any asset in the inventory 
> table). that combination should pick up most everything given that 
> textures on prims are reloaded from the asset server every 24 hours, 
> scripts need to be recompiled on server restart... etc.

One would need to carry out deep inspection of inventory contents (e.g. 
inspecting all the assets used by objects within 
objects, etc.).  The code for this could be extracted from the archiving 
module.  However, doing such a sweep could take 
a long time.

This still doesn't account for objects on regions.  Although perhaps one could 
start storing assets that relate to 
object on regions on that region itself.  This might better allow reaping of 
the central asset server since you no 
longer have to worry about assets used by objects within objects on a region.

A messier solution which I think has been said already is simply to remove any 
assets that haven't been accessed since 
the access_time has been put in place.  As long as you keep a backup of the db 
before the cleanup, you could still 
retrieve and reinstate selected assets as necessary.

An even more radical solution would be to switch osgrid to a pure Hypergrid 
model.  The osgrid UAI services could still 
act as the home services for many people who don't want to run their own 
regions, but the responsibilty for maintaining 
region-side assets would shift to other OpenSim instances (and some people 
would also use them for their home services 
instead of osgrid).

> 
> --mic
> 
> 
> On Feb 8, 2009 6:18pm, Charles Krinke  wrote:
>  > Dear Mike:
>  >
>  > What you say seems reasonable and I applaud you.
>  >
>  > On the related subject of mutability, I have a tough time imagining 
> that each edit of the terrain of a region is useful. I would suggest 
> that only the last "terrainImage" is useful and cannot imagine any 
> reference to any obsolete terrainImage by any object anywhere.
>  >
>  > There are a significant number of items in OpenSim mysql databases 
> such as the various edits of a script where we appear to be storing a 
> new UUID for each edit. In a similar manner, I would think that such 
> obsolete edits are not useful.
>  >
>  > So, half of the problem is a strategy to slow down the bloat of our 
> assetServers with perhaps additional references to additional 
> assetServers and half is to perhaps re-consider all the orphaned items 
> we are leaving in our
>  > mysql database and find a way to stop doing that.
>  >
>  > Charles
>  >
>  >
>  > From: Mike Mazur mma...@gmail.com>
>  > To: opensim-dev@lists.berlios.de
>  > Sent: Sunday, February 8, 2009 6:11:46 PM
>  > Subject: Re: [Opensim-dev] AssetServer Observations and Suggestions
>  >
>  >
>  > Hi,
>  >
>  > On Sun, 8 Feb 2009 10:13:45 -0800 (PST)
>  > Charles Krinke c...@pacbell.net> wrote:
>  >
>  > > We have been studying the assets table on OSGrid as it heads toward
>  > > the "disk full" stage and I have a couple of observations and am
>  > > heading towards a suggestion. Maybe this is already accounted for in
>  > > the "Cable Beach" project, at which point, this will only indicate
>  > > that I did not read all the exchanges carefully enough.
>  > >
>  > > It appears to me that we are storing on the MySQL data store at the
>  > > assetServer on a grid every edit of every script, terrainImage and
>  > > clothingItem amongst other things. So, my first observation is that
>  > > we appear to be storing all the older, obsolete items that can no
>  > > longer be accessed.
>  >
>  > This ever-expanding asset database is a consequence of how assets are
>  > handled by
>  > SL, the SL viewer and, since OpenSim was first developed
>  > against the SL viewer, by OpenSim as well. The premise is that no asset
>  > is mutable, because any asset may be referenced by its UUID. The
>  > reference may exist in a script or on the back of a napkin. There are
>  > more details (the way I understand them) in a previous email[1] I sent
>  > to the list.
>  >
>  > Cable Beach will not solve this problem.
>  >
>  > > Now, to the beginnings of a suggestion. It seems to me that each
>  > > avatar will have a "home" region. And that perhaps that is the place
>  > > to store the items in an avatars inventory. Things like scripts,
>  > > notecards, textures and the like.
>  >
>  > I'm not sure this is the right way forward. It requires that the user's
>  > home region is up anytime they wish to use their avatar and access
>  > their inventory. The user's home region becomes a single point of
>  > failure.
>  >
>  > > At that point, the assetServer on a g

Re: [Opensim-dev] AssetServer Observations and Suggestions

[Diva Canto]

Justin Clark-Casey wrote:
> An even more radical solution would be to switch osgrid to a pure Hypergrid 
> model.  The osgrid UAI services could still 
> act as the home services for many people who don't want to run their own 
> regions, but the responsibilty for maintaining 
> region-side assets would shift to other OpenSim instances (and some people 
> would also use them for their home services 
> instead of osgrid).
>
>   
I've been thinking about this too. I think it should be possible, 
although we need to rethink a little bit the association between users 
and UGAIM servers. Right now it's sort of bundled; we need to unbundle. 
We could make an interface for the User server that would allow users to 
set their servers.

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

Re: [Opensim-dev] AssetServer Observations and Suggestions

[Diva Canto]

Diva Canto wrote:

Justin Clark-Casey wrote:
  
An even more radical solution would be to switch osgrid to a pure Hypergrid model.  The osgrid UAI services could still 
act as the home services for many people who don't want to run their own regions, but the responsibilty for maintaining 
region-side assets would shift to other OpenSim instances (and some people would also use them for their home services 
instead of osgrid).


  

I've been thinking about this too. I think it should be possible, 
although we need to rethink a little bit the association between users 
and UGAIM servers. Right now it's sort of bundled; we need to unbundle. 
We could make an interface for the User server that would allow users to 
set their servers.
  
Actually, we don't even need to change the user base data. The inventory 
assets are only a [relatively small?] percentage of all the assets in 
the grid asset server. Most of the assets, I would say, are inworld 
things that aren't on any inventory. They are on the "region's 
inventory" so to speak. So we could move all regions into HG mode, 
setting the proper local servers in their OpenSim.ini's. The users 
inventory would still be OSGrid's Inventory server.


Even so, there are a few things that need changing/improving for this to 
happen. But it's not that far out.


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

Re: [Opensim-dev] AssetServer Observations and Suggestions

[Melanie]

All assets have, at some point, been on a user's inventory. There is 
no way to upload anything without having it in inventory at some point.
The largest assets are textures, and they will always pass through 
user inventories. Also, they will remain in user inventories despite 
_also_ being on region objects. Making regions hold their own assets 
authoritatively would cause massive data duplication, albeit 
distributed, and not really unclutter the central database.

I believe a tag and reap mechanism that slow-scans all assets for 
contained assets and all inventories for referencs and tags all 
referenced assets, as well as regions transmitting "asset lists" of 
assets currently referenced inworld, and the last use flag. Let that 
run for 6 months, then reap all unflagged, reset all flags, and 
start a new cycle.

This doesn't have to be mutually exclusive, in fact it can be 
combined with persistent local asset caching (e.g. local texture 
storage for inworld objects) as well as a HG model.

Melanie

Diva Canto wrote:
> Diva Canto wrote:
>> Justin Clark-Casey wrote:
>>   
>>> An even more radical solution would be to switch osgrid to a pure Hypergrid 
>>> model.  The osgrid UAI services could still 
>>> act as the home services for many people who don't want to run their own 
>>> regions, but the responsibilty for maintaining 
>>> region-side assets would shift to other OpenSim instances (and some people 
>>> would also use them for their home services 
>>> instead of osgrid).
>>>
>>>   
>>> 
>> I've been thinking about this too. I think it should be possible, 
>> although we need to rethink a little bit the association between users 
>> and UGAIM servers. Right now it's sort of bundled; we need to unbundle. 
>> We could make an interface for the User server that would allow users to 
>> set their servers.
>>   
> Actually, we don't even need to change the user base data. The inventory 
> assets are only a [relatively small?] percentage of all the assets in 
> the grid asset server. Most of the assets, I would say, are inworld 
> things that aren't on any inventory. They are on the "region's 
> inventory" so to speak. So we could move all regions into HG mode, 
> setting the proper local servers in their OpenSim.ini's. The users 
> inventory would still be OSGrid's Inventory server.
> 
> Even so, there are a few things that need changing/improving for this to 
> happen. But it's not that far out.
> 
> 
> 
> 
> 
> 
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] AssetServer Observations and Suggestions

[Justin Clark-Casey]

Melanie wrote:
> All assets have, at some point, been on a user's inventory. There is 
> no way to upload anything without having it in inventory at some point.
> The largest assets are textures, and they will always pass through 
> user inventories. Also, they will remain in user inventories despite 
> _also_ being on region objects. Making regions hold their own assets 
> authoritatively would cause massive data duplication, albeit 
> distributed, and not really unclutter the central database.

Assets can be loaded via OAR and other mechanisms that never flow through 
inventory.  Also, I believe it's quite 
possible to completely delete items from user inventory.

> 
> I believe a tag and reap mechanism that slow-scans all assets for 
> contained assets and all inventories for referencs and tags all 
> referenced assets, as well as regions transmitting "asset lists" of 
> assets currently referenced inworld, and the last use flag. Let that 
> run for 6 months, then reap all unflagged, reset all flags, and 
> start a new cycle.
> 
> This doesn't have to be mutually exclusive, in fact it can be 
> combined with persistent local asset caching (e.g. local texture 
> storage for inworld objects) as well as a HG model.
> 
> Melanie
> 
> Diva Canto wrote:
>> Diva Canto wrote:
>>> Justin Clark-Casey wrote:
>>>   
 An even more radical solution would be to switch osgrid to a pure 
 Hypergrid model.  The osgrid UAI services could still 
 act as the home services for many people who don't want to run their own 
 regions, but the responsibilty for maintaining 
 region-side assets would shift to other OpenSim instances (and some people 
 would also use them for their home services 
 instead of osgrid).

   
 
>>> I've been thinking about this too. I think it should be possible, 
>>> although we need to rethink a little bit the association between users 
>>> and UGAIM servers. Right now it's sort of bundled; we need to unbundle. 
>>> We could make an interface for the User server that would allow users to 
>>> set their servers.
>>>   
>> Actually, we don't even need to change the user base data. The inventory 
>> assets are only a [relatively small?] percentage of all the assets in 
>> the grid asset server. Most of the assets, I would say, are inworld 
>> things that aren't on any inventory. They are on the "region's 
>> inventory" so to speak. So we could move all regions into HG mode, 
>> setting the proper local servers in their OpenSim.ini's. The users 
>> inventory would still be OSGrid's Inventory server.
>>
>> Even so, there are a few things that need changing/improving for this to 
>> happen. But it's not that far out.
>>
>>
>>
>>
>> 
>>
>> ___
>> Opensim-dev mailing list
>> Opensim-dev@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> 


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

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

[Dr Scofield]

i'm now working on step 2 of the OpenSim.Region.Environment refactor.
here is a list of CoreModules and OptionalModules. clearly the later
ones are candidates for moving to forge. any comments on the contents of
these two lists? any modules that should not be in CoreModules (and any
modules that should be in CoreModules)?

Core region modules:

CoreModules/Communications/REST
CoreModules/Communications/Local
CoreModules/Hypergrid
CoreModules/World/TreePopulator
CoreModules/World/Sound
CoreModules/World/Land
CoreModules/World/Terrain
CoreModules/World/Terrain/FloodBrushes
CoreModules/World/Terrain/FileLoaders
CoreModules/World/Terrain/PaintBrushes
CoreModules/World/Terrain/Effects
CoreModules/World/Terrain/Tests
CoreModules/World/Estate
CoreModules/World/Wind
CoreModules/World/Vegetation
CoreModules/World/Sun
CoreModules/World/Permissions
CoreModules/World/WorldMap
CoreModules/World/Archiver
CoreModules/World/Archiver/Tests
CoreModules/World/Serialiser
CoreModules/Agent/TextureDownload
CoreModules/Agent/Capabilities
CoreModules/Agent/TextureSender
CoreModules/Agent/TextureSender/Tests
CoreModules/Agent/AssetTransaction
CoreModules/Agent/Xfer
CoreModules/Framework/EventQueue
CoreModules/Framework/InterfaceCommander
CoreModules/Scripting/XMLRPC
CoreModules/Scripting/LoadImageURL
CoreModules/Scripting/DynamicTexture
CoreModules/Scripting/EMailModules
CoreModules/Scripting/VectorRender
CoreModules/Scripting/WorldComm
CoreModules/Scripting/HttpRequest
CoreModules/Grid/Interregion
CoreModules/Avatar/Groups
CoreModules/Avatar/Lure
CoreModules/Avatar/InstantMessage
CoreModules/Avatar/AvatarFactory
CoreModules/Avatar/Inventory/Transfer
CoreModules/Avatar/Inventory/Archiver
CoreModules/Avatar/Profiles
CoreModules/Avatar/Gestures
CoreModules/Avatar/Friends
CoreModules/Avatar/ObjectCaps
CoreModules/Avatar/Chat
CoreModules/Avatar/Currency/SampleMoney
CoreModules/Avatar/Dialog

Optional region modules:

OptionalModules/World/NPC
OptionalModules/Avatar/Voice
OptionalModules/Avatar/Voice/AsterixVoice
OptionalModules/Avatar/Voice/SIPVoice
OptionalModules/Avatar/Concierge
OptionalModules/Avatar/Combat
OptionalModules/Avatar/Chat
OptionalModules/ContentManagementSystem
OptionalModules/InterGrid

-- 
dr dirk husemann  virtual worlds research  ibm zurich research lab
SL: dr scofield  drscofi...@xyzzyxyzzy.net  http://xyzzyxyzzy.net/
RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/

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

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

[Justin Clark-Casey]

Dr Scofield wrote:
> i'm now working on step 2 of the OpenSim.Region.Environment refactor.
> here is a list of CoreModules and OptionalModules. clearly the later
> ones are candidates for moving to forge. any comments on the contents of
> these two lists? any modules that should not be in CoreModules (and any
> modules that should be in CoreModules)?

Could you tell us what criteria you're using for this?

> 
> Core region modules:
> 
> CoreModules/Communications/REST
> CoreModules/Communications/Local
> CoreModules/Hypergrid
> CoreModules/World/TreePopulator
> CoreModules/World/Sound
> CoreModules/World/Land
> CoreModules/World/Terrain
> CoreModules/World/Terrain/FloodBrushes
> CoreModules/World/Terrain/FileLoaders
> CoreModules/World/Terrain/PaintBrushes
> CoreModules/World/Terrain/Effects
> CoreModules/World/Terrain/Tests
> CoreModules/World/Estate
> CoreModules/World/Wind
> CoreModules/World/Vegetation
> CoreModules/World/Sun
> CoreModules/World/Permissions
> CoreModules/World/WorldMap
> CoreModules/World/Archiver
> CoreModules/World/Archiver/Tests
> CoreModules/World/Serialiser
> CoreModules/Agent/TextureDownload
> CoreModules/Agent/Capabilities
> CoreModules/Agent/TextureSender
> CoreModules/Agent/TextureSender/Tests
> CoreModules/Agent/AssetTransaction
> CoreModules/Agent/Xfer
> CoreModules/Framework/EventQueue
> CoreModules/Framework/InterfaceCommander
> CoreModules/Scripting/XMLRPC
> CoreModules/Scripting/LoadImageURL
> CoreModules/Scripting/DynamicTexture
> CoreModules/Scripting/EMailModules
> CoreModules/Scripting/VectorRender
> CoreModules/Scripting/WorldComm
> CoreModules/Scripting/HttpRequest
> CoreModules/Grid/Interregion
> CoreModules/Avatar/Groups
> CoreModules/Avatar/Lure
> CoreModules/Avatar/InstantMessage
> CoreModules/Avatar/AvatarFactory
> CoreModules/Avatar/Inventory/Transfer
> CoreModules/Avatar/Inventory/Archiver
> CoreModules/Avatar/Profiles
> CoreModules/Avatar/Gestures
> CoreModules/Avatar/Friends
> CoreModules/Avatar/ObjectCaps
> CoreModules/Avatar/Chat
> CoreModules/Avatar/Currency/SampleMoney
> CoreModules/Avatar/Dialog
> 
> Optional region modules:
> 
> OptionalModules/World/NPC
> OptionalModules/Avatar/Voice
> OptionalModules/Avatar/Voice/AsterixVoice
> OptionalModules/Avatar/Voice/SIPVoice
> OptionalModules/Avatar/Concierge
> OptionalModules/Avatar/Combat
> OptionalModules/Avatar/Chat
> OptionalModules/ContentManagementSystem
> OptionalModules/InterGrid
> 


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

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

[Dr Scofield]

Dr Scofield wrote:
> i'm now working on step 2 of the OpenSim.Region.Environment refactor.
> here is a list of CoreModules and OptionalModules. clearly the later
> ones are candidates for moving to forge. any comments on the contents of
> these two lists? any modules that should not be in CoreModules (and any
> modules that should be in CoreModules)?

oh...and forgot OpenSim.Region.Modules! -> OptionalModules?
> 
> Core region modules:
> 
> CoreModules/Communications/REST
> CoreModules/Communications/Local
> CoreModules/Hypergrid
> CoreModules/World/TreePopulator
> CoreModules/World/Sound
> CoreModules/World/Land
> CoreModules/World/Terrain
> CoreModules/World/Terrain/FloodBrushes
> CoreModules/World/Terrain/FileLoaders
> CoreModules/World/Terrain/PaintBrushes
> CoreModules/World/Terrain/Effects
> CoreModules/World/Terrain/Tests
> CoreModules/World/Estate
> CoreModules/World/Wind
> CoreModules/World/Vegetation
> CoreModules/World/Sun
> CoreModules/World/Permissions
> CoreModules/World/WorldMap
> CoreModules/World/Archiver
> CoreModules/World/Archiver/Tests
> CoreModules/World/Serialiser
> CoreModules/Agent/TextureDownload
> CoreModules/Agent/Capabilities
> CoreModules/Agent/TextureSender
> CoreModules/Agent/TextureSender/Tests
> CoreModules/Agent/AssetTransaction
> CoreModules/Agent/Xfer
> CoreModules/Framework/EventQueue
> CoreModules/Framework/InterfaceCommander
> CoreModules/Scripting/XMLRPC
> CoreModules/Scripting/LoadImageURL
> CoreModules/Scripting/DynamicTexture
> CoreModules/Scripting/EMailModules
> CoreModules/Scripting/VectorRender
> CoreModules/Scripting/WorldComm
> CoreModules/Scripting/HttpRequest
> CoreModules/Grid/Interregion
> CoreModules/Avatar/Groups
> CoreModules/Avatar/Lure
> CoreModules/Avatar/InstantMessage
> CoreModules/Avatar/AvatarFactory
> CoreModules/Avatar/Inventory/Transfer
> CoreModules/Avatar/Inventory/Archiver
> CoreModules/Avatar/Profiles
> CoreModules/Avatar/Gestures
> CoreModules/Avatar/Friends
> CoreModules/Avatar/ObjectCaps
> CoreModules/Avatar/Chat
> CoreModules/Avatar/Currency/SampleMoney
> CoreModules/Avatar/Dialog
> 
> Optional region modules:
> 
> OptionalModules/World/NPC
> OptionalModules/Avatar/Voice
> OptionalModules/Avatar/Voice/AsterixVoice
> OptionalModules/Avatar/Voice/SIPVoice
> OptionalModules/Avatar/Concierge
> OptionalModules/Avatar/Combat
> OptionalModules/Avatar/Chat
> OptionalModules/ContentManagementSystem
> OptionalModules/InterGrid
> 


-- 
dr dirk husemann  virtual worlds research  ibm zurich research lab
SL: dr scofield  drscofi...@xyzzyxyzzy.net  http://xyzzyxyzzy.net/
RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

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

[Dr Scofield]

Justin Clark-Casey wrote:
> Dr Scofield wrote:
>> i'm now working on step 2 of the OpenSim.Region.Environment refactor.
>> here is a list of CoreModules and OptionalModules. clearly the later
>> ones are candidates for moving to forge. any comments on the contents of
>> these two lists? any modules that should not be in CoreModules (and any
>> modules that should be in CoreModules)?
> 
> Could you tell us what criteria you're using for this?

the following: Core should be anything that is

(a) referenced directly or indirectly from outside CoreModules/OptionalModules
(b) is necessary to provide the base 3D/VW user experience

and, admittedly, this is a rough view and i'm the first to admit that i
misclassified, hence my request for comments! :-)

> 
>> Core region modules:
>>
>> CoreModules/Communications/REST
>> CoreModules/Communications/Local

referenced directly.

>> CoreModules/Hypergrid

dito.

>> CoreModules/World/TreePopulator
>> CoreModules/World/Sound
>> CoreModules/World/Land
>> CoreModules/World/Terrain
>> CoreModules/World/Terrain/FloodBrushes
>> CoreModules/World/Terrain/FileLoaders
>> CoreModules/World/Terrain/PaintBrushes
>> CoreModules/World/Terrain/Effects
>> CoreModules/World/Terrain/Tests
>> CoreModules/World/Estate
>> CoreModules/World/Wind
>> CoreModules/World/Vegetation
>> CoreModules/World/Sun
>> CoreModules/World/Permissions
>> CoreModules/World/WorldMap
>> CoreModules/World/Archiver
>> CoreModules/World/Archiver/Tests
>> CoreModules/World/Serialiser

not sure whether ALL of these are core. so in dubio pro reo.

>> CoreModules/Agent/TextureDownload
>> CoreModules/Agent/Capabilities
>> CoreModules/Agent/TextureSender
>> CoreModules/Agent/TextureSender/Tests
>> CoreModules/Agent/AssetTransaction
>> CoreModules/Agent/Xfer

those seem to contribute essential services.

>> CoreModules/Framework/EventQueue
>> CoreModules/Framework/InterfaceCommander

dito.

>> CoreModules/Scripting/XMLRPC
>> CoreModules/Scripting/LoadImageURL
>> CoreModules/Scripting/DynamicTexture
>> CoreModules/Scripting/EMailModules
>> CoreModules/Scripting/VectorRender
>> CoreModules/Scripting/WorldComm
>> CoreModules/Scripting/HttpRequest

required for script engines, i guess. in dubio pro reo.

>> CoreModules/Grid/Interregion

required for Grid mode, i guess.

>> CoreModules/Avatar/Groups

rudimentary group support.

>> CoreModules/Avatar/Lure

teleport lures.

>> CoreModules/Avatar/InstantMessage

i consider this core functionality.

>> CoreModules/Avatar/AvatarFactory

referenced directly.

>> CoreModules/Avatar/Inventory/Transfer
>> CoreModules/Avatar/Inventory/Archiver

i consider this core functionality.

>> CoreModules/Avatar/Profiles
>> CoreModules/Avatar/Gestures
>> CoreModules/Avatar/Friends
>> CoreModules/Avatar/ObjectCaps
>> CoreModules/Avatar/Chat/ChatModule

dito.

>> CoreModules/Avatar/Currency/SampleMoney

i don't consider this core functionality, but it's referenced.

>> CoreModules/Avatar/Dialog

core functionality.

>>
>> Optional region modules:
>>
>> OptionalModules/World/NPC
>> OptionalModules/Avatar/Voice
>> OptionalModules/Avatar/Voice/AsterixVoice
>> OptionalModules/Avatar/Voice/SIPVoice

none of the voice modules has working client counter part so far. so, definitely
optional.

>> OptionalModules/Avatar/Concierge

definitely optional.

>> OptionalModules/Avatar/Combat

where does this come from and how is it being used?

>> OptionalModules/Avatar/Chat/IRC-stuff

i'd consider this optional.

>> OptionalModules/ContentManagementSystem

same here.

>> OptionalModules/InterGrid

ok, this could be a CoreModule on the same level as HyperGrid...it's just that
HyperGrid seems to be much more advanced and we made the decision to move it
from forge to core.


as i said, i'd LOVE to hear on this and get this sorted.

-- 
dr dirk husemann  virtual worlds research  ibm zurich research lab
SL: dr scofield  drscofi...@xyzzyxyzzy.net  http://xyzzyxyzzy.net/
RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] AssetServer Observations and Suggestions

[Melanie]

In a normal grid use scenario (OSGRID) I believe that most assets 
are _initially_ created by uploading them through the viewer. Even 
though they can be deleted, few people delete their textures, since 
they are always needed for further building. The savings would be 
minuscule, IMHO. Assets being implicitly shared, any textures passed 
to another user will link to the same inventory item, so that 
deleting something from one user's inventory doesn't mean that it is 
deleted from all users' inventories. There is no way to determine a 
reference but by scanning all inventories and all object assets.

Melanie

Justin Clark-Casey wrote:
> Melanie wrote:
>> All assets have, at some point, been on a user's inventory. There is 
>> no way to upload anything without having it in inventory at some point.
>> The largest assets are textures, and they will always pass through 
>> user inventories. Also, they will remain in user inventories despite 
>> _also_ being on region objects. Making regions hold their own assets 
>> authoritatively would cause massive data duplication, albeit 
>> distributed, and not really unclutter the central database.
> 
> Assets can be loaded via OAR and other mechanisms that never flow through 
> inventory.  Also, I believe it's quite 
> possible to completely delete items from user inventory.
> 
>> 
>> I believe a tag and reap mechanism that slow-scans all assets for 
>> contained assets and all inventories for referencs and tags all 
>> referenced assets, as well as regions transmitting "asset lists" of 
>> assets currently referenced inworld, and the last use flag. Let that 
>> run for 6 months, then reap all unflagged, reset all flags, and 
>> start a new cycle.
>> 
>> This doesn't have to be mutually exclusive, in fact it can be 
>> combined with persistent local asset caching (e.g. local texture 
>> storage for inworld objects) as well as a HG model.
>> 
>> Melanie
>> 
>> Diva Canto wrote:
>>> Diva Canto wrote:
 Justin Clark-Casey wrote:
   
> An even more radical solution would be to switch osgrid to a pure 
> Hypergrid model.  The osgrid UAI services could still 
> act as the home services for many people who don't want to run their own 
> regions, but the responsibilty for maintaining 
> region-side assets would shift to other OpenSim instances (and some 
> people would also use them for their home services 
> instead of osgrid).
>
>   
> 
 I've been thinking about this too. I think it should be possible, 
 although we need to rethink a little bit the association between users 
 and UGAIM servers. Right now it's sort of bundled; we need to unbundle. 
 We could make an interface for the User server that would allow users to 
 set their servers.
   
>>> Actually, we don't even need to change the user base data. The inventory 
>>> assets are only a [relatively small?] percentage of all the assets in 
>>> the grid asset server. Most of the assets, I would say, are inworld 
>>> things that aren't on any inventory. They are on the "region's 
>>> inventory" so to speak. So we could move all regions into HG mode, 
>>> setting the proper local servers in their OpenSim.ini's. The users 
>>> inventory would still be OSGrid's Inventory server.
>>>
>>> Even so, there are a few things that need changing/improving for this to 
>>> happen. But it's not that far out.
>>>
>>>
>>>
>>>
>>> 
>>>
>>> ___
>>> Opensim-dev mailing list
>>> Opensim-dev@lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>> ___
>> Opensim-dev mailing list
>> Opensim-dev@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>> 
> 
> 
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

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

[Melanie]

Hi,

I believe TreePopulator should be an optional module. Conversely, 
Combat is required to be present for the llSetDamage() and related 
functions as well as the damage setting in the viewer to work 
properly and should therefore be core.

Melanie


Dr Scofield wrote:
> i'm now working on step 2 of the OpenSim.Region.Environment refactor.
> here is a list of CoreModules and OptionalModules. clearly the later
> ones are candidates for moving to forge. any comments on the contents of
> these two lists? any modules that should not be in CoreModules (and any
> modules that should be in CoreModules)?
> 
> Core region modules:
> 
> CoreModules/Communications/REST
> CoreModules/Communications/Local
> CoreModules/Hypergrid
> CoreModules/World/TreePopulator
> CoreModules/World/Sound
> CoreModules/World/Land
> CoreModules/World/Terrain
> CoreModules/World/Terrain/FloodBrushes
> CoreModules/World/Terrain/FileLoaders
> CoreModules/World/Terrain/PaintBrushes
> CoreModules/World/Terrain/Effects
> CoreModules/World/Terrain/Tests
> CoreModules/World/Estate
> CoreModules/World/Wind
> CoreModules/World/Vegetation
> CoreModules/World/Sun
> CoreModules/World/Permissions
> CoreModules/World/WorldMap
> CoreModules/World/Archiver
> CoreModules/World/Archiver/Tests
> CoreModules/World/Serialiser
> CoreModules/Agent/TextureDownload
> CoreModules/Agent/Capabilities
> CoreModules/Agent/TextureSender
> CoreModules/Agent/TextureSender/Tests
> CoreModules/Agent/AssetTransaction
> CoreModules/Agent/Xfer
> CoreModules/Framework/EventQueue
> CoreModules/Framework/InterfaceCommander
> CoreModules/Scripting/XMLRPC
> CoreModules/Scripting/LoadImageURL
> CoreModules/Scripting/DynamicTexture
> CoreModules/Scripting/EMailModules
> CoreModules/Scripting/VectorRender
> CoreModules/Scripting/WorldComm
> CoreModules/Scripting/HttpRequest
> CoreModules/Grid/Interregion
> CoreModules/Avatar/Groups
> CoreModules/Avatar/Lure
> CoreModules/Avatar/InstantMessage
> CoreModules/Avatar/AvatarFactory
> CoreModules/Avatar/Inventory/Transfer
> CoreModules/Avatar/Inventory/Archiver
> CoreModules/Avatar/Profiles
> CoreModules/Avatar/Gestures
> CoreModules/Avatar/Friends
> CoreModules/Avatar/ObjectCaps
> CoreModules/Avatar/Chat
> CoreModules/Avatar/Currency/SampleMoney
> CoreModules/Avatar/Dialog
> 
> Optional region modules:
> 
> OptionalModules/World/NPC
> OptionalModules/Avatar/Voice
> OptionalModules/Avatar/Voice/AsterixVoice
> OptionalModules/Avatar/Voice/SIPVoice
> OptionalModules/Avatar/Concierge
> OptionalModules/Avatar/Combat
> OptionalModules/Avatar/Chat
> OptionalModules/ContentManagementSystem
> OptionalModules/InterGrid
> 
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

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

[Melanie]

Two chat modules? The chat module should certainly be core.

Melanie


Dr Scofield wrote:
> Dr Scofield wrote:
>> i'm now working on step 2 of the OpenSim.Region.Environment refactor.
>> here is a list of CoreModules and OptionalModules. clearly the later
>> ones are candidates for moving to forge. any comments on the contents of
>> these two lists? any modules that should not be in CoreModules (and any
>> modules that should be in CoreModules)?
> 
> oh...and forgot OpenSim.Region.Modules! -> OptionalModules?
>> 
>> Core region modules:
>> 
>> CoreModules/Communications/REST
>> CoreModules/Communications/Local
>> CoreModules/Hypergrid
>> CoreModules/World/TreePopulator
>> CoreModules/World/Sound
>> CoreModules/World/Land
>> CoreModules/World/Terrain
>> CoreModules/World/Terrain/FloodBrushes
>> CoreModules/World/Terrain/FileLoaders
>> CoreModules/World/Terrain/PaintBrushes
>> CoreModules/World/Terrain/Effects
>> CoreModules/World/Terrain/Tests
>> CoreModules/World/Estate
>> CoreModules/World/Wind
>> CoreModules/World/Vegetation
>> CoreModules/World/Sun
>> CoreModules/World/Permissions
>> CoreModules/World/WorldMap
>> CoreModules/World/Archiver
>> CoreModules/World/Archiver/Tests
>> CoreModules/World/Serialiser
>> CoreModules/Agent/TextureDownload
>> CoreModules/Agent/Capabilities
>> CoreModules/Agent/TextureSender
>> CoreModules/Agent/TextureSender/Tests
>> CoreModules/Agent/AssetTransaction
>> CoreModules/Agent/Xfer
>> CoreModules/Framework/EventQueue
>> CoreModules/Framework/InterfaceCommander
>> CoreModules/Scripting/XMLRPC
>> CoreModules/Scripting/LoadImageURL
>> CoreModules/Scripting/DynamicTexture
>> CoreModules/Scripting/EMailModules
>> CoreModules/Scripting/VectorRender
>> CoreModules/Scripting/WorldComm
>> CoreModules/Scripting/HttpRequest
>> CoreModules/Grid/Interregion
>> CoreModules/Avatar/Groups
>> CoreModules/Avatar/Lure
>> CoreModules/Avatar/InstantMessage
>> CoreModules/Avatar/AvatarFactory
>> CoreModules/Avatar/Inventory/Transfer
>> CoreModules/Avatar/Inventory/Archiver
>> CoreModules/Avatar/Profiles
>> CoreModules/Avatar/Gestures
>> CoreModules/Avatar/Friends
>> CoreModules/Avatar/ObjectCaps
>> CoreModules/Avatar/Chat
>> CoreModules/Avatar/Currency/SampleMoney
>> CoreModules/Avatar/Dialog
>> 
>> Optional region modules:
>> 
>> OptionalModules/World/NPC
>> OptionalModules/Avatar/Voice
>> OptionalModules/Avatar/Voice/AsterixVoice
>> OptionalModules/Avatar/Voice/SIPVoice
>> OptionalModules/Avatar/Concierge
>> OptionalModules/Avatar/Combat
>> OptionalModules/Avatar/Chat
>> OptionalModules/ContentManagementSystem
>> OptionalModules/InterGrid
>> 
> 
> 
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

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

[Dr Scofield]

Melanie wrote:
> Two chat modules? The chat module should certainly be core.

sorry. typo. one ChatModule in Core and IRC stuff (which lived in Chat module
subdir) which i'd like to move to Optional.

DrS/dirk

> 
> Melanie
> 
> 
> Dr Scofield wrote:
>> Dr Scofield wrote:
>>> i'm now working on step 2 of the OpenSim.Region.Environment refactor.
>>> here is a list of CoreModules and OptionalModules. clearly the later
>>> ones are candidates for moving to forge. any comments on the contents of
>>> these two lists? any modules that should not be in CoreModules (and any
>>> modules that should be in CoreModules)?
>> oh...and forgot OpenSim.Region.Modules! -> OptionalModules?
>>> Core region modules:
>>>
>>> CoreModules/Communications/REST
>>> CoreModules/Communications/Local
>>> CoreModules/Hypergrid
>>> CoreModules/World/TreePopulator
>>> CoreModules/World/Sound
>>> CoreModules/World/Land
>>> CoreModules/World/Terrain
>>> CoreModules/World/Terrain/FloodBrushes
>>> CoreModules/World/Terrain/FileLoaders
>>> CoreModules/World/Terrain/PaintBrushes
>>> CoreModules/World/Terrain/Effects
>>> CoreModules/World/Terrain/Tests
>>> CoreModules/World/Estate
>>> CoreModules/World/Wind
>>> CoreModules/World/Vegetation
>>> CoreModules/World/Sun
>>> CoreModules/World/Permissions
>>> CoreModules/World/WorldMap
>>> CoreModules/World/Archiver
>>> CoreModules/World/Archiver/Tests
>>> CoreModules/World/Serialiser
>>> CoreModules/Agent/TextureDownload
>>> CoreModules/Agent/Capabilities
>>> CoreModules/Agent/TextureSender
>>> CoreModules/Agent/TextureSender/Tests
>>> CoreModules/Agent/AssetTransaction
>>> CoreModules/Agent/Xfer
>>> CoreModules/Framework/EventQueue
>>> CoreModules/Framework/InterfaceCommander
>>> CoreModules/Scripting/XMLRPC
>>> CoreModules/Scripting/LoadImageURL
>>> CoreModules/Scripting/DynamicTexture
>>> CoreModules/Scripting/EMailModules
>>> CoreModules/Scripting/VectorRender
>>> CoreModules/Scripting/WorldComm
>>> CoreModules/Scripting/HttpRequest
>>> CoreModules/Grid/Interregion
>>> CoreModules/Avatar/Groups
>>> CoreModules/Avatar/Lure
>>> CoreModules/Avatar/InstantMessage
>>> CoreModules/Avatar/AvatarFactory
>>> CoreModules/Avatar/Inventory/Transfer
>>> CoreModules/Avatar/Inventory/Archiver
>>> CoreModules/Avatar/Profiles
>>> CoreModules/Avatar/Gestures
>>> CoreModules/Avatar/Friends
>>> CoreModules/Avatar/ObjectCaps
>>> CoreModules/Avatar/Chat
>>> CoreModules/Avatar/Currency/SampleMoney
>>> CoreModules/Avatar/Dialog
>>>
>>> Optional region modules:
>>>
>>> OptionalModules/World/NPC
>>> OptionalModules/Avatar/Voice
>>> OptionalModules/Avatar/Voice/AsterixVoice
>>> OptionalModules/Avatar/Voice/SIPVoice
>>> OptionalModules/Avatar/Concierge
>>> OptionalModules/Avatar/Combat
>>> OptionalModules/Avatar/Chat
>>> OptionalModules/ContentManagementSystem
>>> OptionalModules/InterGrid
>>>
>>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> 


-- 
dr dirk husemann  virtual worlds research  ibm zurich research lab
SL: dr scofield  drscofi...@xyzzyxyzzy.net  http://xyzzyxyzzy.net/
RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

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

[Justin Clark-Casey]

Dr Scofield wrote:
> Justin Clark-Casey wrote:
>> Dr Scofield wrote:
>>> i'm now working on step 2 of the OpenSim.Region.Environment refactor.
>>> here is a list of CoreModules and OptionalModules. clearly the later
>>> ones are candidates for moving to forge. any comments on the contents of
>>> these two lists? any modules that should not be in CoreModules (and any
>>> modules that should be in CoreModules)?
>> Could you tell us what criteria you're using for this?
> 
> the following: Core should be anything that is
> 
> (a) referenced directly or indirectly from outside CoreModules/OptionalModules
> (b) is necessary to provide the base 3D/VW user experience
> 
> and, admittedly, this is a rough view and i'm the first to admit that i
> misclassified, hence my request for comments! :-)

These criteria seem fair enough to me, though (b) has a wide interpretation.  
Quite a few of the 'Core Modules' are 
centered around the Second Life experience (e.g. wind, sun, combat) but that 
seems perfectly reasonable to me at this 
stage (though probably not in the super long term).

If we follow these criteria then we will need to look to maintain them in the 
future.

I pretty much agree with you except for a couple of points below.

I also largely agree with you about the stuff in OpenSim.Region.Modules 
namespaces, though maybe having Python as a 
scripting language could be considered core (although I don't believe that 
module has ever been plugged in (?) so it 
could be removed from now.  I'm actually neutral on having Python in core but I 
know that a lot of people like it as a 
scripting language.

> 
>>> Core region modules:
>>>
>>> CoreModules/Communications/REST
>>> CoreModules/Communications/Local
> 
> referenced directly.
> 
>>> CoreModules/Hypergrid
> 
> dito.
> 
>>> CoreModules/World/TreePopulator

Is TreePopulator really core?

>>> CoreModules/World/Sound
>>> CoreModules/World/Land
>>> CoreModules/World/Terrain
>>> CoreModules/World/Terrain/FloodBrushes
>>> CoreModules/World/Terrain/FileLoaders
>>> CoreModules/World/Terrain/PaintBrushes
>>> CoreModules/World/Terrain/Effects
>>> CoreModules/World/Terrain/Tests
>>> CoreModules/World/Estate
>>> CoreModules/World/Wind
>>> CoreModules/World/Vegetation
>>> CoreModules/World/Sun
>>> CoreModules/World/Permissions
>>> CoreModules/World/WorldMap
>>> CoreModules/World/Archiver
>>> CoreModules/World/Archiver/Tests
>>> CoreModules/World/Serialiser
> 
> not sure whether ALL of these are core. so in dubio pro reo.
> 
>>> CoreModules/Agent/TextureDownload
>>> CoreModules/Agent/Capabilities
>>> CoreModules/Agent/TextureSender
>>> CoreModules/Agent/TextureSender/Tests
>>> CoreModules/Agent/AssetTransaction
>>> CoreModules/Agent/Xfer
> 
> those seem to contribute essential services.
> 
>>> CoreModules/Framework/EventQueue
>>> CoreModules/Framework/InterfaceCommander
> 
> dito.
> 
>>> CoreModules/Scripting/XMLRPC
>>> CoreModules/Scripting/LoadImageURL
>>> CoreModules/Scripting/DynamicTexture
>>> CoreModules/Scripting/EMailModules
>>> CoreModules/Scripting/VectorRender
>>> CoreModules/Scripting/WorldComm
>>> CoreModules/Scripting/HttpRequest
> 
> required for script engines, i guess. in dubio pro reo.
> 
>>> CoreModules/Grid/Interregion
> 
> required for Grid mode, i guess.

I don't think that module is actually used.

> 
>>> CoreModules/Avatar/Groups
> 
> rudimentary group support.
> 
>>> CoreModules/Avatar/Lure
> 
> teleport lures.
> 
>>> CoreModules/Avatar/InstantMessage
> 
> i consider this core functionality.
> 
>>> CoreModules/Avatar/AvatarFactory
> 
> referenced directly.
> 
>>> CoreModules/Avatar/Inventory/Transfer
>>> CoreModules/Avatar/Inventory/Archiver
> 
> i consider this core functionality.
> 
>>> CoreModules/Avatar/Profiles
>>> CoreModules/Avatar/Gestures
>>> CoreModules/Avatar/Friends
>>> CoreModules/Avatar/ObjectCaps
>>> CoreModules/Avatar/Chat/ChatModule
> 
> dito.
> 
>>> CoreModules/Avatar/Currency/SampleMoney
> 
> i don't consider this core functionality, but it's referenced.
> 
>>> CoreModules/Avatar/Dialog
> 
> core functionality.
> 
>>> Optional region modules:
>>>
>>> OptionalModules/World/NPC
>>> OptionalModules/Avatar/Voice
>>> OptionalModules/Avatar/Voice/AsterixVoice
>>> OptionalModules/Avatar/Voice/SIPVoice
> 
> none of the voice modules has working client counter part so far. so, 
> definitely
> optional.
> 
>>> OptionalModules/Avatar/Concierge
> 
> definitely optional.
> 
>>> OptionalModules/Avatar/Combat
> 
> where does this come from and how is it being used?
> 
>>> OptionalModules/Avatar/Chat/IRC-stuff
> 
> i'd consider this optional.
> 
>>> OptionalModules/ContentManagementSystem
> 
> same here.
> 
>>> OptionalModules/InterGrid
> 
> ok, this could be a CoreModule on the same level as HyperGrid...it's just that
> HyperGrid seems to be much more advanced and we made the decision to move it
> from forge to core.
> 
> 
> as i said, i'd LOVE to hear on this and get this sorted.
> 


-- 
justincc
Justin Clark-Casey
http://justincc.wordpress.co

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

[Dr Scofield]

Melanie wrote:
> Hi,
> 
> I believe TreePopulator should be an optional module.

k.
> Conversely, 
> Combat is required to be present for the llSetDamage() and related 
> functions as well as the damage setting in the viewer to work 
> properly and should therefore be core.

ah. ok, makes sense.

updated list to follow.
> 
> Melanie
> 
> 
> Dr Scofield wrote:
>> i'm now working on step 2 of the OpenSim.Region.Environment refactor.
>> here is a list of CoreModules and OptionalModules. clearly the later
>> ones are candidates for moving to forge. any comments on the contents of
>> these two lists? any modules that should not be in CoreModules (and any
>> modules that should be in CoreModules)?
>>
>> Core region modules:
>>
>> CoreModules/Communications/REST
>> CoreModules/Communications/Local
>> CoreModules/Hypergrid
>> CoreModules/World/TreePopulator
>> CoreModules/World/Sound
>> CoreModules/World/Land
>> CoreModules/World/Terrain
>> CoreModules/World/Terrain/FloodBrushes
>> CoreModules/World/Terrain/FileLoaders
>> CoreModules/World/Terrain/PaintBrushes
>> CoreModules/World/Terrain/Effects
>> CoreModules/World/Terrain/Tests
>> CoreModules/World/Estate
>> CoreModules/World/Wind
>> CoreModules/World/Vegetation
>> CoreModules/World/Sun
>> CoreModules/World/Permissions
>> CoreModules/World/WorldMap
>> CoreModules/World/Archiver
>> CoreModules/World/Archiver/Tests
>> CoreModules/World/Serialiser
>> CoreModules/Agent/TextureDownload
>> CoreModules/Agent/Capabilities
>> CoreModules/Agent/TextureSender
>> CoreModules/Agent/TextureSender/Tests
>> CoreModules/Agent/AssetTransaction
>> CoreModules/Agent/Xfer
>> CoreModules/Framework/EventQueue
>> CoreModules/Framework/InterfaceCommander
>> CoreModules/Scripting/XMLRPC
>> CoreModules/Scripting/LoadImageURL
>> CoreModules/Scripting/DynamicTexture
>> CoreModules/Scripting/EMailModules
>> CoreModules/Scripting/VectorRender
>> CoreModules/Scripting/WorldComm
>> CoreModules/Scripting/HttpRequest
>> CoreModules/Grid/Interregion
>> CoreModules/Avatar/Groups
>> CoreModules/Avatar/Lure
>> CoreModules/Avatar/InstantMessage
>> CoreModules/Avatar/AvatarFactory
>> CoreModules/Avatar/Inventory/Transfer
>> CoreModules/Avatar/Inventory/Archiver
>> CoreModules/Avatar/Profiles
>> CoreModules/Avatar/Gestures
>> CoreModules/Avatar/Friends
>> CoreModules/Avatar/ObjectCaps
>> CoreModules/Avatar/Chat
>> CoreModules/Avatar/Currency/SampleMoney
>> CoreModules/Avatar/Dialog
>>
>> Optional region modules:
>>
>> OptionalModules/World/NPC
>> OptionalModules/Avatar/Voice
>> OptionalModules/Avatar/Voice/AsterixVoice
>> OptionalModules/Avatar/Voice/SIPVoice
>> OptionalModules/Avatar/Concierge
>> OptionalModules/Avatar/Combat
>> OptionalModules/Avatar/Chat
>> OptionalModules/ContentManagementSystem
>> OptionalModules/InterGrid
>>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> 


-- 
dr dirk husemann  virtual worlds research  ibm zurich research lab
SL: dr scofield  drscofi...@xyzzyxyzzy.net  http://xyzzyxyzzy.net/
RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

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

[Dr Scofield]

[update following input from melanie]

i'm now working on step 2 of the OpenSim.Region.Environment refactor.
here is a list of CoreModules and OptionalModules. clearly the later
ones are candidates for moving to forge. any comments on the contents of
these two lists? any modules that should not be in CoreModules (and any
modules that should be in CoreModules)?

== proposed list of CORE region modules: ==

CoreModules/Agent/AssetTransaction
CoreModules/Agent/Capabilities
CoreModules/Agent/TextureDownload
CoreModules/Agent/TextureSender
CoreModules/Agent/TextureSender/Tests
CoreModules/Agent/Xfer

CoreModules/Avatar/AvatarFactory
CoreModules/Avatar/Chat/ChatModule
CoreModules/Avatar/Combat
CoreModules/Avatar/Currency/SampleMoney
CoreModules/Avatar/Dialog
CoreModules/Avatar/Friends
CoreModules/Avatar/Gestures
CoreModules/Avatar/Groups
CoreModules/Avatar/InstantMessage
CoreModules/Avatar/Inventory/Archiver
CoreModules/Avatar/Inventory/Transfer
CoreModules/Avatar/Lure
CoreModules/Avatar/ObjectCaps
CoreModules/Avatar/Profiles

CoreModules/Communications/Local
CoreModules/Communications/REST

CoreModules/Framework/EventQueue
CoreModules/Framework/InterfaceCommander

CoreModules/Grid/Interregion

CoreModules/Hypergrid

CoreModules/Scripting/DynamicTexture
CoreModules/Scripting/EMailModules
CoreModules/Scripting/HttpRequest
CoreModules/Scripting/LoadImageURL
CoreModules/Scripting/VectorRender
CoreModules/Scripting/WorldComm
CoreModules/Scripting/XMLRPC

CoreModules/World/Archiver
CoreModules/World/Archiver/Tests
CoreModules/World/Estate
CoreModules/World/Land
CoreModules/World/Permissions
CoreModules/World/Serialiser
CoreModules/World/Sound
CoreModules/World/Sun
CoreModules/World/Terrain
CoreModules/World/Terrain/Effects
CoreModules/World/Terrain/FileLoaders
CoreModules/World/Terrain/FloodBrushes
CoreModules/World/Terrain/PaintBrushes
CoreModules/World/Terrain/Tests
CoreModules/World/Vegetation
CoreModules/World/Wind
CoreModules/World/WorldMap


== proposed list of OPTIONAL region modules (forge candidates): ==

OptionalModules/Avatar/Chat/IRC-stuff
OptionalModules/Avatar/Concierge
OptionalModules/Avatar/Voice
OptionalModules/Avatar/Voice/AsterixVoice
OptionalModules/Avatar/Voice/SIPVoice

OptionalModules/ContentManagementSystem

OptionalModules/InterGrid

OptionalModules/World/NPC
OptionalModules/World/TreePopulator

-- 
dr dirk husemann  virtual worlds research  ibm zurich research lab
SL: dr scofield  drscofi...@xyzzyxyzzy.net  http://xyzzyxyzzy.net/
RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

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

[Dr Scofield]

[update following input from melanie, justincc]

i'm now working on step 2 of the OpenSim.Region.Environment refactor.
here is a list of CoreModules and OptionalModules. clearly the later
ones are candidates for moving to forge. any comments on the contents of
these two lists? any modules that should not be in CoreModules (and any
modules that should be in CoreModules)?

anyone know about Modules/Python and/or Environment/Modules/Grid/Interregion???

== proposed list of CORE region modules: ==

CoreModules/Agent/AssetTransaction
CoreModules/Agent/Capabilities
CoreModules/Agent/TextureDownload
CoreModules/Agent/TextureSender
CoreModules/Agent/TextureSender/Tests
CoreModules/Agent/Xfer

CoreModules/Avatar/AvatarFactory
CoreModules/Avatar/Chat/ChatModule
CoreModules/Avatar/Combat
CoreModules/Avatar/Currency/SampleMoney
CoreModules/Avatar/Dialog
CoreModules/Avatar/Friends
CoreModules/Avatar/Gestures
CoreModules/Avatar/Groups
CoreModules/Avatar/InstantMessage
CoreModules/Avatar/Inventory/Archiver
CoreModules/Avatar/Inventory/Transfer
CoreModules/Avatar/Lure
CoreModules/Avatar/ObjectCaps
CoreModules/Avatar/Profiles

CoreModules/Communications/Local
CoreModules/Communications/REST

CoreModules/Framework/EventQueue
CoreModules/Framework/InterfaceCommander

CoreModules/Hypergrid

CoreModules/Scripting/DynamicTexture
CoreModules/Scripting/EMailModules
CoreModules/Scripting/HttpRequest
CoreModules/Scripting/LoadImageURL
CoreModules/Scripting/VectorRender
CoreModules/Scripting/WorldComm
CoreModules/Scripting/XMLRPC

CoreModules/World/Archiver
CoreModules/World/Archiver/Tests
CoreModules/World/Estate
CoreModules/World/Land
CoreModules/World/Permissions
CoreModules/World/Serialiser
CoreModules/World/Sound
CoreModules/World/Sun
CoreModules/World/Terrain
CoreModules/World/Terrain/Effects
CoreModules/World/Terrain/FileLoaders
CoreModules/World/Terrain/FloodBrushes
CoreModules/World/Terrain/PaintBrushes
CoreModules/World/Terrain/Tests
CoreModules/World/Vegetation
CoreModules/World/Wind
CoreModules/World/WorldMap


== proposed list of OPTIONAL region modules (forge candidates): ==

OptionalModules/Avatar/Chat/IRC-stuff
OptionalModules/Avatar/Concierge
OptionalModules/Avatar/Voice
OptionalModules/Avatar/Voice/AsterixVoice
OptionalModules/Avatar/Voice/SIPVoice

OptionalModules/ContentManagementSystem

OptionalModules/InterGrid

OptionalModules/World/NPC
OptionalModules/World/TreePopulator


== proposed list of DEAD region modules: ==

Modules/Python
Environment/Modules/Grid/Interregion



-- 
dr dirk husemann  virtual worlds research  ibm zurich research lab
SL: dr scofield  drscofi...@xyzzyxyzzy.net  http://xyzzyxyzzy.net/
RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/

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

Re: [Opensim-dev] AssetServer Observations and Suggestions

[Alan M Webb]

A newly created region contains no assets (except for terrain?). Objects 
get rezzed from OAR files and by avatars moving things from their 
inventories, right? These objects reference other objects and assets 
(textures et al) either directly or via object inventory.

In principle, it is sufficient for the asset database to reflect only 
those assets required to support the set of objects considered to be part 
of the permanent region state at any given point in time. Of course, I'm 
assuming here that the assets needed by an objects that are subsequently 
rezzed can be resolved somehow. The approach we have been experimenting 
with locally is to extend the "Not Found" handling to search for an asset 
in a static/dynamic set of other known asset repositories. This should 
make the process transparent to all.

Weeding out abandoned assets can, as everyone has said, by examining the 
point-in-time configuration of the region's permanent state. This could be 
done by a separate process or low-priority thread. As part of this 
approach it would seem logical to have a secondary asset database. Moving 
the unreferenced assets to this "apparently unused asset" database. If an 
asset is not resolved in the local asset database then the first 
alternative location checked is the "apparently unused asset" database. 
The search continues with other independent asset servers according  to 
whatever search algorithm is in effect.

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



From:
Melanie 
To:
opensim-dev@lists.berlios.de
Date:
02/09/2009 10:33 AM
Subject:
Re: [Opensim-dev] AssetServer Observations and Suggestions



In a normal grid use scenario (OSGRID) I believe that most assets 
are _initially_ created by uploading them through the viewer. Even 
though they can be deleted, few people delete their textures, since 
they are always needed for further building. The savings would be 
minuscule, IMHO. Assets being implicitly shared, any textures passed 
to another user will link to the same inventory item, so that 
deleting something from one user's inventory doesn't mean that it is 
deleted from all users' inventories. There is no way to determine a 
reference but by scanning all inventories and all object assets.

Melanie

Justin Clark-Casey wrote:
> Melanie wrote:
>> All assets have, at some point, been on a user's inventory. There is 
>> no way to upload anything without having it in inventory at some point.
>> The largest assets are textures, and they will always pass through 
>> user inventories. Also, they will remain in user inventories despite 
>> _also_ being on region objects. Making regions hold their own assets 
>> authoritatively would cause massive data duplication, albeit 
>> distributed, and not really unclutter the central database.
> 
> Assets can be loaded via OAR and other mechanisms that never flow 
through inventory.  Also, I believe it's quite 
> possible to completely delete items from user inventory.
> 
>> 
>> I believe a tag and reap mechanism that slow-scans all assets for 
>> contained assets and all inventories for referencs and tags all 
>> referenced assets, as well as regions transmitting "asset lists" of 
>> assets currently referenced inworld, and the last use flag. Let that 
>> run for 6 months, then reap all unflagged, reset all flags, and 
>> start a new cycle.
>> 
>> This doesn't have to be mutually exclusive, in fact it can be 
>> combined with persistent local asset caching (e.g. local texture 
>> storage for inworld objects) as well as a HG model.
>> 
>> Melanie
>> 
>> Diva Canto wrote:
>>> Diva Canto wrote:
 Justin Clark-Casey wrote:
 
> An even more radical solution would be to switch osgrid to a pure 
Hypergrid model.  The osgrid UAI services could still 
> act as the home services for many people who don't want to run their 
own regions, but the responsibilty for maintaining 
> region-side assets would shift to other OpenSim instances (and some 
people would also use them for their home services 
> instead of osgrid).
>
> 
> 
 I've been thinking about this too. I think it should be possible, 
 although we need to rethink a little bit the association between 
users 
 and UGAIM servers. Right now it's sort of bundled; we need to 
unbundle. 
 We could make an interface for the User server that would allow users 
to 
 set their servers.
 
>>> Actually, we don't even need to change the user base data. The 
inventory 
>>> assets are only a [relatively small?] percentage of all the assets in 
>>> the grid asset server. Most of the assets, I would say, are inworld 
>>> things that aren't on any inventory. They are on the "region's 
>>> inventory" so to speak. So we could move all regions into HG mode, 
>>> setting the proper local servers in their OpenSim.ini's. The users 
>>> inventory would still be OSGrid's Inventory server.
>>>
>>> Even so, there

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

[Alan M Webb]

Based upon Melanie's remarks, it would seem useful to annotate each of 
these with the core functionality that they support - as in Melanie's 
example. With that annotation, the reasoning for the grouping would be 
evident.

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



From:
Dr Scofield 
To:
opensim-dev@lists.berlios.de
Date:
02/09/2009 11:14 AM
Subject:
[Opensim-dev] UPDATE[2]: Re: what are the core region modules? which are 
not?



[update following input from melanie, justincc]

i'm now working on step 2 of the OpenSim.Region.Environment refactor.
here is a list of CoreModules and OptionalModules. clearly the later
ones are candidates for moving to forge. any comments on the contents of
these two lists? any modules that should not be in CoreModules (and any
modules that should be in CoreModules)?

anyone know about Modules/Python and/or 
Environment/Modules/Grid/Interregion???

== proposed list of CORE region modules: ==

CoreModules/Agent/AssetTransaction
CoreModules/Agent/Capabilities
CoreModules/Agent/TextureDownload
CoreModules/Agent/TextureSender
CoreModules/Agent/TextureSender/Tests
CoreModules/Agent/Xfer

CoreModules/Avatar/AvatarFactory
CoreModules/Avatar/Chat/ChatModule
CoreModules/Avatar/Combat
CoreModules/Avatar/Currency/SampleMoney
CoreModules/Avatar/Dialog
CoreModules/Avatar/Friends
CoreModules/Avatar/Gestures
CoreModules/Avatar/Groups
CoreModules/Avatar/InstantMessage
CoreModules/Avatar/Inventory/Archiver
CoreModules/Avatar/Inventory/Transfer
CoreModules/Avatar/Lure
CoreModules/Avatar/ObjectCaps
CoreModules/Avatar/Profiles

CoreModules/Communications/Local
CoreModules/Communications/REST

CoreModules/Framework/EventQueue
CoreModules/Framework/InterfaceCommander

CoreModules/Hypergrid

CoreModules/Scripting/DynamicTexture
CoreModules/Scripting/EMailModules
CoreModules/Scripting/HttpRequest
CoreModules/Scripting/LoadImageURL
CoreModules/Scripting/VectorRender
CoreModules/Scripting/WorldComm
CoreModules/Scripting/XMLRPC

CoreModules/World/Archiver
CoreModules/World/Archiver/Tests
CoreModules/World/Estate
CoreModules/World/Land
CoreModules/World/Permissions
CoreModules/World/Serialiser
CoreModules/World/Sound
CoreModules/World/Sun
CoreModules/World/Terrain
CoreModules/World/Terrain/Effects
CoreModules/World/Terrain/FileLoaders
CoreModules/World/Terrain/FloodBrushes
CoreModules/World/Terrain/PaintBrushes
CoreModules/World/Terrain/Tests
CoreModules/World/Vegetation
CoreModules/World/Wind
CoreModules/World/WorldMap


== proposed list of OPTIONAL region modules (forge candidates): ==

OptionalModules/Avatar/Chat/IRC-stuff
OptionalModules/Avatar/Concierge
OptionalModules/Avatar/Voice
OptionalModules/Avatar/Voice/AsterixVoice
OptionalModules/Avatar/Voice/SIPVoice

OptionalModules/ContentManagementSystem

OptionalModules/InterGrid

OptionalModules/World/NPC
OptionalModules/World/TreePopulator


== proposed list of DEAD region modules: ==

Modules/Python
Environment/Modules/Grid/Interregion



-- 
dr dirk husemann  virtual worlds research  ibm zurich research lab
SL: dr scofield  drscofi...@xyzzyxyzzy.net  http://xyzzyxyzzy.net/
RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/

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


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

Re: [Opensim-dev] AssetServer Observations and Suggestions

[Melanie]

Hi,

again, i believe three criteria need to be met for an asset to be 
reaped:

- It must not be referenced by user inventory directly or indirectly
- It must not be referenced by an inworld object, or anything in it
- It must be unaccessed for a certain period of time (6 months being 
my suggestioin)

This last case covers references by UUID. UUIDs can reference 
textures and sounds only. So, all assets satisfying criteria 1 and 2 
can be removed immediately, unless they are textures or sounds, in 
which case criterion 3, 6 months without access, would apply.

UUIDs can not reference object assets, animations or wearables, even 
though their UUID can be obtained, it can't be used in any LSL 
function call.
UUIDs can also not reference script source, as that is specifically 
blocked, you can't view script source unless the script is in your 
or the object's inventory with proper permissions.

Therefore, unreferenced object, script, animation and wearables 
assets can be removed immediately upon detecting that they are 
totally unreferenced.

Further, texture assets with the temporary flag set can be removed 
immediately when unreferenced, unless referenced by the regions table.

Melanie


Alan M Webb wrote:
> A newly created region contains no assets (except for terrain?). Objects 
> get rezzed from OAR files and by avatars moving things from their 
> inventories, right? These objects reference other objects and assets 
> (textures et al) either directly or via object inventory.
> 
> In principle, it is sufficient for the asset database to reflect only 
> those assets required to support the set of objects considered to be part 
> of the permanent region state at any given point in time. Of course, I'm 
> assuming here that the assets needed by an objects that are subsequently 
> rezzed can be resolved somehow. The approach we have been experimenting 
> with locally is to extend the "Not Found" handling to search for an asset 
> in a static/dynamic set of other known asset repositories. This should 
> make the process transparent to all.
> 
> Weeding out abandoned assets can, as everyone has said, by examining the 
> point-in-time configuration of the region's permanent state. This could be 
> done by a separate process or low-priority thread. As part of this 
> approach it would seem logical to have a secondary asset database. Moving 
> the unreferenced assets to this "apparently unused asset" database. If an 
> asset is not resolved in the local asset database then the first 
> alternative location checked is the "apparently unused asset" database. 
> The search continues with other independent asset servers according  to 
> whatever search algorithm is in effect.
> 
> Best regards
> Alan
> ---
> T.J. Watson Research Center, Hawthorne, NY
> 1-914-784-7286
> alan_w...@us.ibm.com
> 
> 
> 
> From:
> Melanie 
> To:
> opensim-dev@lists.berlios.de
> Date:
> 02/09/2009 10:33 AM
> Subject:
> Re: [Opensim-dev] AssetServer Observations and Suggestions
> 
> 
> 
> In a normal grid use scenario (OSGRID) I believe that most assets 
> are _initially_ created by uploading them through the viewer. Even 
> though they can be deleted, few people delete their textures, since 
> they are always needed for further building. The savings would be 
> minuscule, IMHO. Assets being implicitly shared, any textures passed 
> to another user will link to the same inventory item, so that 
> deleting something from one user's inventory doesn't mean that it is 
> deleted from all users' inventories. There is no way to determine a 
> reference but by scanning all inventories and all object assets.
> 
> Melanie
> 
> Justin Clark-Casey wrote:
>> Melanie wrote:
>>> All assets have, at some point, been on a user's inventory. There is 
>>> no way to upload anything without having it in inventory at some point.
>>> The largest assets are textures, and they will always pass through 
>>> user inventories. Also, they will remain in user inventories despite 
>>> _also_ being on region objects. Making regions hold their own assets 
>>> authoritatively would cause massive data duplication, albeit 
>>> distributed, and not really unclutter the central database.
>> 
>> Assets can be loaded via OAR and other mechanisms that never flow 
> through inventory.  Also, I believe it's quite 
>> possible to completely delete items from user inventory.
>> 
>>> 
>>> I believe a tag and reap mechanism that slow-scans all assets for 
>>> contained assets and all inventories for referencs and tags all 
>>> referenced assets, as well as regions transmitting "asset lists" of 
>>> assets currently referenced inworld, and the last use flag. Let that 
>>> run for 6 months, then reap all unflagged, reset all flags, and 
>>> start a new cycle.
>>> 
>>> This doesn't have to be mutually exclusive, in fact it can be 
>>> combined with persistent local asset caching (e.g. local texture 
>>> storage for inworld objects) as well as a HG model.
>>> 
>>> Melanie

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

[Dr Scofield]

Alan M Webb wrote:
> 
> Based upon Melanie's remarks, it would seem useful to annotate each of
> these with the core functionality that they support - as in Melanie's
> example. With that annotation, the reasoning for the grouping would be
> evident.

sigh. guess a wiki page would be better?
> 
> Best regards
> Alan
> ---
> T.J. Watson Research Center, Hawthorne, NY
> 1-914-784-7286
> alan_w...@us.ibm.com
> 
> 
> From: Dr Scofield 
> To:   opensim-dev@lists.berlios.de
> Date: 02/09/2009 11:14 AM
> Subject:  [Opensim-dev] UPDATE[2]: Re: what are the core region modules?
> which are not?
> 
> 
> 
> 
> 
> 
> [update following input from melanie, justincc]
> 
> i'm now working on step 2 of the OpenSim.Region.Environment refactor.
> here is a list of CoreModules and OptionalModules. clearly the later
> ones are candidates for moving to forge. any comments on the contents of
> these two lists? any modules that should not be in CoreModules (and any
> modules that should be in CoreModules)?
> 
> anyone know about Modules/Python and/or
> Environment/Modules/Grid/Interregion???
> 
> == proposed list of CORE region modules: ==
> 
> CoreModules/Agent/AssetTransaction
> CoreModules/Agent/Capabilities
> CoreModules/Agent/TextureDownload
> CoreModules/Agent/TextureSender
> CoreModules/Agent/TextureSender/Tests
> CoreModules/Agent/Xfer
> 
> CoreModules/Avatar/AvatarFactory
> CoreModules/Avatar/Chat/ChatModule
> CoreModules/Avatar/Combat
> CoreModules/Avatar/Currency/SampleMoney
> CoreModules/Avatar/Dialog
> CoreModules/Avatar/Friends
> CoreModules/Avatar/Gestures
> CoreModules/Avatar/Groups
> CoreModules/Avatar/InstantMessage
> CoreModules/Avatar/Inventory/Archiver
> CoreModules/Avatar/Inventory/Transfer
> CoreModules/Avatar/Lure
> CoreModules/Avatar/ObjectCaps
> CoreModules/Avatar/Profiles
> 
> CoreModules/Communications/Local
> CoreModules/Communications/REST
> 
> CoreModules/Framework/EventQueue
> CoreModules/Framework/InterfaceCommander
> 
> CoreModules/Hypergrid
> 
> CoreModules/Scripting/DynamicTexture
> CoreModules/Scripting/EMailModules
> CoreModules/Scripting/HttpRequest
> CoreModules/Scripting/LoadImageURL
> CoreModules/Scripting/VectorRender
> CoreModules/Scripting/WorldComm
> CoreModules/Scripting/XMLRPC
> 
> CoreModules/World/Archiver
> CoreModules/World/Archiver/Tests
> CoreModules/World/Estate
> CoreModules/World/Land
> CoreModules/World/Permissions
> CoreModules/World/Serialiser
> CoreModules/World/Sound
> CoreModules/World/Sun
> CoreModules/World/Terrain
> CoreModules/World/Terrain/Effects
> CoreModules/World/Terrain/FileLoaders
> CoreModules/World/Terrain/FloodBrushes
> CoreModules/World/Terrain/PaintBrushes
> CoreModules/World/Terrain/Tests
> CoreModules/World/Vegetation
> CoreModules/World/Wind
> CoreModules/World/WorldMap
> 
> 
> == proposed list of OPTIONAL region modules (forge candidates): ==
> 
> OptionalModules/Avatar/Chat/IRC-stuff
> OptionalModules/Avatar/Concierge
> OptionalModules/Avatar/Voice
> OptionalModules/Avatar/Voice/AsterixVoice
> OptionalModules/Avatar/Voice/SIPVoice
> 
> OptionalModules/ContentManagementSystem
> 
> OptionalModules/InterGrid
> 
> OptionalModules/World/NPC
> OptionalModules/World/TreePopulator
> 
> 
> == proposed list of DEAD region modules: ==
> 
> Modules/Python
> Environment/Modules/Grid/Interregion
> 
> 
> 
> -- 
> dr dirk husemann  virtual worlds research  ibm zurich research lab
> SL: dr scofield  drscofi...@xyzzyxyzzy.net  http://xyzzyxyzzy.net/
> RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/
> 
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> 
> 
> 
> 
> 
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev


-- 
dr dirk husemann  virtual worlds research  ibm zurich research lab
SL: dr scofield  drscofi...@xyzzyxyzzy.net  http://xyzzyxyzzy.net/
RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] [Opensim-commits] r8236 - in trunk/OpenSim: ApplicationPlugins/Rest/Inventory Data/MSSQL Data/MySQL Data/NHibernate Data/SQLite Data/Tests Framework Framework/AssetLoader/Filesystem

[Sean Dague]

Mike Mazur wrote:
> Hi,
> 
> On Sat, Feb 7, 2009 at 12:59 AM, Justin Clark-Casey
>  wrote:
>> What would happen if some future plugin to OpenSim wanted to add extra 
>> metadata fields?  Would then need to extend the
>> AssetBase class?  This seems a little icky to me (as opposed to extending a 
>> separate AssetMetadata class) but maybe
>> that's just me.
> 
> Good question. I guess there's a benefit of having the Metadata class
> separate from the Asset class hierarchy.
> 
>> Also to be penickity, could we prefix non-public fields with m_ rather than 
>> just _ ?  I think this is the standard that
>> we're following, though I have no desire to get religious about it.
> 
> I was just following the existing code in AssetBase. When I make the
> next changes in there I'll prefix the attributes with m_.

Yeh, that's my bad.  The automatic refactor tools in monodevelop go with
 _ for privates, which I used to get us there.  Being able to
alphabetically sort all the attributes and have privates show up first
was a nice side effect.  I should have made things work with the
existing convention, just fell off the queue.

-Sean

-- 
Sean Dague / Neas Bade
sda...@gmail.com
http://dague.net




signature.asc
Description: OpenPGP digital signature
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Older region databases incompatible with the latest SVN

[Sean Dague]

Diva Canto wrote:
> Yes, I've seen this too. In fact, one of our regions in OSGrid is still
> suffering from it.
> I'm not sure where the bug is, except that it happened around the 3rd
> week of January.
> We've been able to get around it by removing the local OpenSim.db, and
> loading all the objects from backups we had (in xml or oar format, not
> sure which).

Did someone mess up a migration?  If there was a format change on the db
there should have been a migration to fix existing data.

-Sean

-- 
Sean Dague / Neas Bade
sda...@gmail.com
http://dague.net




signature.asc
Description: OpenPGP digital signature
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

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

[Dahlia Trimble]

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

On Mon, Feb 9, 2009 at 7:25 AM, Dr Scofield wrote:

> Justin Clark-Casey wrote:
> > Dr Scofield wrote:
> >> i'm now working on step 2 of the OpenSim.Region.Environment refactor.
> >> here is a list of CoreModules and OptionalModules. clearly the later
> >> ones are candidates for moving to forge. any comments on the contents of
> >> these two lists? any modules that should not be in CoreModules (and any
> >> modules that should be in CoreModules)?
> >
> > Could you tell us what criteria you're using for this?
>
> the following: Core should be anything that is
>
> (a) referenced directly or indirectly from outside
> CoreModules/OptionalModules
> (b) is necessary to provide the base 3D/VW user experience
>
> and, admittedly, this is a rough view and i'm the first to admit that i
> misclassified, hence my request for comments! :-)
>
> >
> >> Core region modules:
> >>
> >> CoreModules/Communications/REST
> >> CoreModules/Communications/Local
>
> referenced directly.
>
> >> CoreModules/Hypergrid
>
> dito.
>
> >> CoreModules/World/TreePopulator
> >> CoreModules/World/Sound
> >> CoreModules/World/Land
> >> CoreModules/World/Terrain
> >> CoreModules/World/Terrain/FloodBrushes
> >> CoreModules/World/Terrain/FileLoaders
> >> CoreModules/World/Terrain/PaintBrushes
> >> CoreModules/World/Terrain/Effects
> >> CoreModules/World/Terrain/Tests
> >> CoreModules/World/Estate
> >> CoreModules/World/Wind
> >> CoreModules/World/Vegetation
> >> CoreModules/World/Sun
> >> CoreModules/World/Permissions
> >> CoreModules/World/WorldMap
> >> CoreModules/World/Archiver
> >> CoreModules/World/Archiver/Tests
> >> CoreModules/World/Serialiser
>
> not sure whether ALL of these are core. so in dubio pro reo.
>
> >> CoreModules/Agent/TextureDownload
> >> CoreModules/Agent/Capabilities
> >> CoreModules/Agent/TextureSender
> >> CoreModules/Agent/TextureSender/Tests
> >> CoreModules/Agent/AssetTransaction
> >> CoreModules/Agent/Xfer
>
> those seem to contribute essential services.
>
> >> CoreModules/Framework/EventQueue
> >> CoreModules/Framework/InterfaceCommander
>
> dito.
>
> >> CoreModules/Scripting/XMLRPC
> >> CoreModules/Scripting/LoadImageURL
> >> CoreModules/Scripting/DynamicTexture
> >> CoreModules/Scripting/EMailModules
> >> CoreModules/Scripting/VectorRender
> >> CoreModules/Scripting/WorldComm
> >> CoreModules/Scripting/HttpRequest
>
> required for script engines, i guess. in dubio pro reo.
>
> >> CoreModules/Grid/Interregion
>
> required for Grid mode, i guess.
>
> >> CoreModules/Avatar/Groups
>
> rudimentary group support.
>
> >> CoreModules/Avatar/Lure
>
> teleport lures.
>
> >> CoreModules/Avatar/InstantMessage
>
> i consider this core functionality.
>
> >> CoreModules/Avatar/AvatarFactory
>
> referenced directly.
>
> >> CoreModules/Avatar/Inventory/Transfer
> >> CoreModules/Avatar/Inventory/Archiver
>
> i consider this core functionality.
>
> >> CoreModules/Avatar/Profiles
> >> CoreModules/Avatar/Gestures
> >> CoreModules/Avatar/Friends
> >> CoreModules/Avatar/ObjectCaps
> >> CoreModules/Avatar/Chat/ChatModule
>
> dito.
>
> >> CoreModules/Avatar/Currency/SampleMoney
>
> i don't consider this core functionality, but it's referenced.
>
> >> CoreModules/Avatar/Dialog
>
> core functionality.
>
> >>
> >> Optional region modules:
> >>
> >> OptionalModules/World/NPC
> >> OptionalModules/Avatar/Voice
> >> OptionalModules/Avatar/Voice/AsterixVoice
> >> OptionalModules/Avatar/Voice/SIPVoice
>
> none of the voice modules has working client counter part so far. so,
> definitely
> optional.
>
> >> OptionalModules/Avatar/Concierge
>
> definitely optional.
>
> >> OptionalModules/Avatar/Combat
>
> where does this come from and how is it being used?
>
> >> OptionalModules/Avatar/Chat/IRC-stuff
>
> i'd consider this optional.
>
> >> OptionalModules/ContentManagementSystem
>
> same here.
>
> >> OptionalModules/InterGrid
>
> ok, this could be a CoreModule on the same level as HyperGrid...it's just
> that
> HyperGrid seems to be much more advanced and we made the decision to move
> it
> from forge to core.
>
>
> as i said, i'd LOVE to hear on this and get this sorted.
>
> --
> dr dirk husemann  virtual worlds research  ibm zurich research lab
> SL: dr scofield  drscofi...@xyzzyxyzzy.net  http://xyzzyxyzzy.net/
> RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>

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

[Dahlia Trimble]

What I was trying to say was taking a region module out core would allow
core to deviate in compatibility from those modules and not provide any
feedback to core developers that a deviation had occurred, nor would it
enforce any responsibility to maintain compatibility. In my case I would
have to divert my efforts from core development to maintaining a module that
others could break without their knowledge, and I feel that the time spent
could be enough to significantly reduce the functionality I could contribute
to core. In the case of the IRC module in particular, I would then propose
it be moved out of core at a later date when core had stabilized
sufficiently to mitigate the risk of future incompatibility.

(from off list)
On Mon, Feb 9, 2009 at 10:30 AM,  wrote:

> Is the issue here that there isn't a good "standard" (?) way to build
> region modules that aren't in the dev tree? I mean... you can certainly
> build modules outside the dev tree by copying some set of files over... but
> there aren't any tools to make it easier and no good way to keep it up to
> date.
>
> We've been talking about our ScienceSim binaries as a "distribution"
> because we're starting to include some additional region modules. And that
> means, of course, that we have to make some effort to keep those region
> modules functioning.
>
> --mic
>
>
>
> On Feb 9, 2009 10:16am, Dahlia Trimble  wrote:
> > When a module moves out of core and to forge, what process would be in
> place to make sure these modules remain compatible when possibly breaking
> changes are made to core? I use the IRC module in some of my regions and I
> wouldn't want to see it broken, and I like to stay close to head in all of
> my regions so I can be more aware of how development progresses. As such I
> would potentially vote -1 on taking IRC out of core until there is some way
> to maintain functionality as core evolves.
> >
> >
> > On Mon, Feb 9, 2009 at 7:25 AM, Dr Scofield drscofi...@xyzzyxyzzy.net>
> wrote:
> >
> > Justin Clark-Casey wrote:
> >
> > > Dr Scofield wrote:
> >
> > >> i'm now working on step 2 of the OpenSim.Region.Environment refactor.
> >
> > >> here is a list of CoreModules and OptionalModules. clearly the later
> >
> > >> ones are candidates for moving to forge. any comments on the contents
> of
> >
> > >> these two lists? any modules that should not be in CoreModules (and
> any
> >
> > >> modules that should be in CoreModules)?
> >
> > >
> >
> > > Could you tell us what criteria you're using for this?
> >
> >
> >
> >
> > the following: Core should be anything that is
> >
> >
> >
> > (a) referenced directly or indirectly from outside
> CoreModules/OptionalModules
> >
> > (b) is necessary to provide the base 3D/VW user experience
> >
> >
> >
> > and, admittedly, this is a rough view and i'm the first to admit that i
> >
> > misclassified, hence my request for comments! :-)
> >
> >
> >
> > >
> >
> > >> Core region modules:
> >
> > >>
> >
> > >> CoreModules/Communications/REST
> >
> > >> CoreModules/Communications/Local
> >
> >
> >
> >
> > referenced directly.
> >
> >
> >
> > >> CoreModules/Hypergrid
> >
> >
> >
> > dito.
> >
> >
> >
> > >> CoreModules/World/TreePopulator
> >
> > >> CoreModules/World/Sound
> >
> > >> CoreModules/World/Land
> >
> > >> CoreModules/World/Terrain
> >
> > >> CoreModules/World/Terrain/FloodBrushes
> >
> > >> CoreModules/World/Terrain/FileLoaders
> >
> > >> CoreModules/World/Terrain/PaintBrushes
> >
> > >> CoreModules/World/Terrain/Effects
> >
> > >> CoreModules/World/Terrain/Tests
> >
> > >> CoreModules/World/Estate
> >
> > >> CoreModules/World/Wind
> >
> > >> CoreModules/World/Vegetation
> >
> > >> CoreModules/World/Sun
> >
> > >> CoreModules/World/Permissions
> >
> > >> CoreModules/World/WorldMap
> >
> > >> CoreModules/World/Archiver
> >
> > >> CoreModules/World/Archiver/Tests
> >
> > >> CoreModules/World/Serialiser
> >
> >
> >
> >
> > not sure whether ALL of these are core. so in dubio pro reo.
> >
> >
> >
> > >> CoreModules/Agent/TextureDownload
> >
> > >> CoreModules/Agent/Capabilities
> >
> > >> CoreModules/Agent/TextureSender
> >
> > >> CoreModules/Agent/TextureSender/Tests
> >
> > >> CoreModules/Agent/AssetTransaction
> >
> > >> CoreModules/Agent/Xfer
> >
> >
> >
> >
> > those seem to contribute essential services.
> >
> >
> >
> > >> CoreModules/Framework/EventQueue
> >
> > >> CoreModules/Framework/InterfaceCommander
> >
> >
> >
> >
> > dito.
> >
> >
> >
> > >> CoreModules/Scripting/XMLRPC
> >
> > >> CoreModules/Scripting/LoadImageURL
> >
> > >> CoreModules/Scripting/DynamicTexture
> >
> > >> CoreModules/Scripting/EMailModules
> >
> > >> CoreModules/Scripting/VectorRender
> >
> > >> CoreModules/Scripting/WorldComm
> >
> > >> CoreModules/Scripting/HttpRequest
> >
> >
> >
> >
> > required for script engines, i guess. in dubio pro reo.
> >
> >
> >
> > >> CoreModules/Grid/Interregion
> >
> >
> >
> > required for Grid mode, i guess.
> >
> >
> >
> > >> CoreModules/Avatar/Groups
> >
> >
> >
> > rudimentary grou

[Opensim-dev] Blockers for unit testing physics modules

[Tommi Laukkanen]

Hello

I was writing some unit tests for physics modules and I collided with the
following problem with prebuild and nant:

Currently physics modules are stored in bin/Physics and because of this you
can not reference them in further steps of the build as you can define only
one reference directory for a project. I have referenced ode plugin dll from
test dll but because of the reference problem the nant build fails. The test
itself builds and works well in visual studio.

I dont see any way around this. We would need to move the physics plugin
dlls to bin directory like rest of the dlls or forget doing separate unit
test dlls which refer to these plugins.

This limitation is good to know for all prebuild work we do. Do not place
the build output to any other directory than OpenSim/bin or you cannot
reference that in other projects of nant build.

If someone knows how to fix this easily please let me know.

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

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

[Sean Dague]

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

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

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

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

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

-Sean

-- 
Sean Dague / Neas Bade
sda...@gmail.com
http://dague.net




signature.asc
Description: OpenPGP digital signature
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

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

[Charles Krinke]

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

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

Charles




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

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

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

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

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

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

-Sean

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

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

[Stefan Andersson]

Some ideas and suggestions on 
 
Instead of a one-off sweep, can't we just have this as some kind of regular 
scrutiny of what merits to be 'core' modules? Start with the obvious 
abandonware, then do sweeps every two version ups.
 
I'm actually very much for us concentrating more of our efforts into getting 
the 'basics' tightened up, so I'm very much for cleaning out unused or poorly 
implemented concepts.
 
That said, I would also suggest we set up a forge build server - something that 
would synthesize, build and runt tests on an 'extended' build file - containing 
all non-core, but 'approved extended modules'.
 
If there is a build error, there should be some kind of notification going out 
to that forge dev project group, and if nobody remedies the build error, that 
module is put up for removal from the 'approved' list (maybe simply by 
exclusion from the build server script) 
Now, if an 'extension' module stops _functioning_ I believe that situation is 
exactly as it would be if it was included in core - the only thing having a 
module in core guarantees is that it's built, not that it is tested by the 
committer - so that would mean the module users would have to mantis a failure.
 
It would probably be a good thing if the module sub-projects would keep track 
of some kind of 'last known good' revision.
 
And, lastly, I believe that by grouping several modules into one or a small 
number of 'packages' the impact of core deviation would lessen, as more devs 
would have to configure less to have it installed.
 
By the way, I was thinking that we could have a in-place bogus project in 
Prebuild.xml called OpenSim.Modules.External residictng in 
/OpenSim/Modules/External, which prebuild would include /*.cs recursively.
 
That would mean that you could just check out a set of forge module sources 
into that directory - which prebuild would then just bundle together into one 
big fat glorious module dll, custom to your environment.
Best regards,Stefan AnderssonTribal Media AB



Date: Mon, 9 Feb 2009 11:42:31 -0800From: c...@pacbell.netto: 
opensim-...@lists.berlios.desubject: Re: [Opensim-dev] what are the core region 
modules? which are not?




SDague has a good point. And it gets a bit more interesting when one considers 
the OSSearch module, which did become non-functional a few days ago and folks 
have been scrambling and struggling to get their regions back in operation.It 
could be argued that bringing that active module, which is one small C# file 
into SVN might be to our advantage for the same reasons we are discussing 
here.Charles


From: Sean Dague To: opensim-...@lists.berlios.desent: 
Monday, February 9, 2009 11:30:59 AMSubject: Re: [Opensim-dev] what are the 
core region modules? which are not?Dahlia Trimble wrote:> When a module moves 
out of core and to forge, what process would be in place> to make sure these 
modules remain compatible when possibly breaking changes> are made to core? I 
use the IRC module in some of my regions and I wouldn't> want to see it broken, 
and I like to stay close to head in all of my regions> so I can be more aware 
of how development progresses. As such I would> potentially vote -1 on taking 
IRC out of core until there is some way to> maintain functionality as core 
evolves.I'm personally all for moving thinks to an Optional space, but we 
haveto be honest with ourselves, moving a module to the forge means thatthere 
is a better than 50% chance it's unusable in 2 weeks time.  Ithink for things 
we've considered "dead" that's fine, but I'd bereluctant to push bits out that 
people do regularly use (like the ircbridge).  At least until we have:1. an 
easy way to build an out of core module build tree2. network repository support 
for modules (ala what's in mono addins)3. some type of versioning on module 
interfaces, so we can know if aplugin thinks it can work with the current 
buildOtherwise we are more or less jetisoning a lot of features and reducingthe 
number of users that we can serve out of the box.  The same logicthat would 
leave these modules in the tree is the same logic that keepsall the extra stuff 
in bin/, to make it easy for the new user to getstarted.This shouldn't stop 
this current level of reorganization, which I thinkis very useful.  But is just 
a warning on next steps of removing thingsfrom the tree.-Sean-- Sean Dague 
/ Neas badesda...@gmail.comhttp://dague.net___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

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

[Justin Clark-Casey]

Sean Dague wrote:
> Dahlia Trimble wrote:
>> When a module moves out of core and to forge, what process would be in place
>> to make sure these modules remain compatible when possibly breaking changes
>> are made to core? I use the IRC module in some of my regions and I wouldn't
>> want to see it broken, and I like to stay close to head in all of my regions
>> so I can be more aware of how development progresses. As such I would
>> potentially vote -1 on taking IRC out of core until there is some way to
>> maintain functionality as core evolves.
> 
> I'm personally all for moving thinks to an Optional space, but we have
> to be honest with ourselves, moving a module to the forge means that
> there is a better than 50% chance it's unusable in 2 weeks time.  I
> think for things we've considered "dead" that's fine, but I'd be
> reluctant to push bits out that people do regularly use (like the irc
> bridge).  At least until we have:

I don't think that this is going to be so true in the future.  I've recently 
written and published an external module 
and though it has been a little painful with the recent reorganization, I don't 
anticipate all that much breakage in the 
months ahead.  IRC is something else that I think should see reasonable 
stability.

Admittedly it's much more difficult for modules that get intimate with Scene.  
What we need to do in the medium term is 
separate out more interfaces and start to think properly about what should be 
in them.

However, if we don't suffer the pain of moving some modules out of the tree now 
then there is little impetus for us to 
get our act together to make all the steps you describe below actually happen.

The alternative to moving stuff out is that we continue to salt up the OpenSim 
core with our own modules, which makes 
things nice and easy for us, but provides little push for improvement for 
anybody who isn't in the hallowed circle.

> 
> 1. an easy way to build an out of core module build tree

Actually, this isn't too bad right now.  If you look at the PSMB module you'll 
see that it's possible to do this with a 
couple of OpenSim dlls (admittedly a couple more than there should be).  
There's no need to embed it in the whole 
OpenSim build process.

> 2. network repository support for modules (ala what's in mono addins)

I do think that this is very important in order to produce a good 'almost out 
of the box' experience, but I don't think 
that it's crucial.

> 3. some type of versioning on module interfaces, so we can know if a
> plugin thinks it can work with the current build

I also think this is very important but not utterly crucial

> 
> Otherwise we are more or less jetisoning a lot of features and reducing
> the number of users that we can serve out of the box.  The same logic
> that would leave these modules in the tree is the same logic that keeps
> all the extra stuff in bin/, to make it easy for the new user to get
> started.
> 
> This shouldn't stop this current level of reorganization, which I think
> is very useful.  But is just a warning on next steps of removing things
> from the tree.
> 
>   -Sean
> 
> 
> 
> 
> 
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev


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

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

[Melanie]

Currently, each module comes with a patch for prebuild.xml.

The extras directory won't fly because different modules need 
different references and even external stuff. I have a Linux build 
script I use that will combine selected modules with my tree. I can 
donate that.

Melanie


Stefan Andersson wrote:
> Some ideas and suggestions on 
>  
> Instead of a one-off sweep, can't we just have this as some kind of regular 
> scrutiny of what merits to be 'core' modules? Start with the obvious 
> abandonware, then do sweeps every two version ups.
>  
> I'm actually very much for us concentrating more of our efforts into getting 
> the 'basics' tightened up, so I'm very much for cleaning out unused or poorly 
> implemented concepts.
>  
> That said, I would also suggest we set up a forge build server - something 
> that would synthesize, build and runt tests on an 'extended' build file - 
> containing all non-core, but 'approved extended modules'.
>  
> If there is a build error, there should be some kind of notification going 
> out to that forge dev project group, and if nobody remedies the build error, 
> that module is put up for removal from the 'approved' list (maybe simply by 
> exclusion from the build server script) 
> Now, if an 'extension' module stops _functioning_ I believe that situation is 
> exactly as it would be if it was included in core - the only thing having a 
> module in core guarantees is that it's built, not that it is tested by the 
> committer - so that would mean the module users would have to mantis a 
> failure.
>  
> It would probably be a good thing if the module sub-projects would keep track 
> of some kind of 'last known good' revision.
>  
> And, lastly, I believe that by grouping several modules into one or a small 
> number of 'packages' the impact of core deviation would lessen, as more devs 
> would have to configure less to have it installed.
>  
> By the way, I was thinking that we could have a in-place bogus project in 
> Prebuild.xml called OpenSim.Modules.External residictng in 
> /OpenSim/Modules/External, which prebuild would include /*.cs recursively.
>  
> That would mean that you could just check out a set of forge module sources 
> into that directory - which prebuild would then just bundle together into one 
> big fat glorious module dll, custom to your environment.
> Best regards,Stefan AnderssonTribal Media AB
> 
> 
> 
> Date: Mon, 9 Feb 2009 11:42:31 -0800From: c...@pacbell.netto: 
> opensim-...@lists.berlios.desubject: Re: [Opensim-dev] what are the core 
> region modules? which are not?
> 
> 
> 
> 
> SDague has a good point. And it gets a bit more interesting when one 
> considers the OSSearch module, which did become non-functional a few days ago 
> and folks have been scrambling and struggling to get their regions back in 
> operation.It could be argued that bringing that active module, which is one 
> small C# file into SVN might be to our advantage for the same reasons we are 
> discussing here.Charles
> 
> 
> From: Sean Dague To: opensim-...@lists.berlios.desent: 
> Monday, February 9, 2009 11:30:59 AMSubject: Re: [Opensim-dev] what are the 
> core region modules? which are not?Dahlia Trimble wrote:> When a module moves 
> out of core and to forge, what process would be in place> to make sure these 
> modules remain compatible when possibly breaking changes> are made to core? I 
> use the IRC module in some of my regions and I wouldn't> want to see it 
> broken, and I like to stay close to head in all of my regions> so I can be 
> more aware of how development progresses. As such I would> potentially vote 
> -1 on taking IRC out of core until there is some way to> maintain 
> functionality as core evolves.I'm personally all for moving thinks to an 
> Optional space, but we haveto be honest with ourselves, moving a module to 
> the forge means thatthere is a better than 50% chance it's unusable in 2 
> weeks time.  Ithink for things we've considered "dead" that's fine, but I'd 
> bereluctant to push 
bits out that people do regularly use (like the ircbridge).  At least until we 
have:1. an easy way to build an out of core module build tree2. network 
repository support for modules (ala what's in mono addins)3. some type of 
versioning on module interfaces, so we can know if aplugin thinks it can work 
with the current buildOtherwise we are more or less jetisoning a lot of 
features and reducingthe number of users that we can serve out of the box.  The 
same logicthat would leave these modules in the tree is the same logic that 
keepsall the extra stuff in bin/, to make it easy for the new user to 
getstarted.This shouldn't stop this current level of reorganization, which I 
thinkis very useful.  But is just a warning on next steps of removing 
thingsfrom the tree.-Sean-- Sean Dague / Neas 
badesda...@gmail.comhttp://dague.net
> 
> 
> 
> 
> 

[Opensim-dev] Setting default locale for opensim processes

[Tommi Laukkanen]

Hello

Should we set default locale programmatically when we launch the exe
files as there are various functions which will get mixed results if system
locale has different decimal separator defined?

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

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

[Toni Alatalo]

Stefan Andersson wrote:

> That said, I would also suggest we set up a forge build server - something 
> that would synthesize, build and runt tests on an 'extended' build file - 
> containing all non-core, but 'approved extended modules'.
>   
(...)
> Now, if an 'extension' module stops _functioning_ I believe that situation is 
> exactly as it would be if it was included in core - the only thing having a 
> module in core guarantees is that it's built, not that it is tested by the 
> committer

well if there are indeed tests for that functionality, they ought to be 
run by committers (and are run and reported by the server too), so that 
breaking things without knowing would not happen.

i figure running tests of the non-core but living modules might work 
well if it can be setup somehow. one neat feature in svn is external 
repos that let you combine many repos into one so that you get them all 
with one update command.

Melanie wrote:
> The extras directory won't fly because different modules need 
> different references and even external stuff. I have a Linux build 
> script I use that will combine selected modules with my tree. I can 
>   

i wonder if you could help keeping such modules functioning by writing 
tests for the parts of the api that they depend on .. perhaps you can 
test what they assume from opensim without having the external stuff.

versioning sounded like a good idea too, but don't know whether it's the 
time for that and would it be practical really.

this is an issue for modrex too, where already the guys had to do some 
refactor now due to changes in the core. hopefully the situation can be 
helped with tests there for the future.

> Melanie
>   

~Toni

>> It would probably be a good thing if the module sub-projects would keep 
>> track of some kind of 'last known good' revision.
>>  
>> And, lastly, I believe that by grouping several modules into one or a small 
>> number of 'packages' the impact of core deviation would lessen, as more devs 
>> would have to configure less to have it installed.
>>  
>> By the way, I was thinking that we could have a in-place bogus project in 
>> Prebuild.xml called OpenSim.Modules.External residictng in 
>> /OpenSim/Modules/External, which prebuild would include /*.cs recursively.
>>  
>> That would mean that you could just check out a set of forge module sources 
>> into that directory - which prebuild would then just bundle together into 
>> one big fat glorious module dll, custom to your environment.
>> Best regards,Stefan AnderssonTribal Media AB
>>
>>
>>
>> Date: Mon, 9 Feb 2009 11:42:31 -0800From: c...@pacbell.netto: 
>> opensim-...@lists.berlios.desubject: Re: [Opensim-dev] what are the core 
>> region modules? which are not?
>>
>>
>>
>>
>> SDague has a good point. And it gets a bit more interesting when one 
>> considers the OSSearch module, which did become non-functional a few days 
>> ago and folks have been scrambling and struggling to get their regions back 
>> in operation.It could be argued that bringing that active module, which is 
>> one small C# file into SVN might be to our advantage for the same reasons we 
>> are discussing here.Charles
>>
>>
>> From: Sean Dague To: opensim-...@lists.berlios.desent: 
>> Monday, February 9, 2009 11:30:59 AMSubject: Re: [Opensim-dev] what are the 
>> core region modules? which are not?Dahlia Trimble wrote:> When a module 
>> moves out of core and to forge, what process would be in place> to make sure 
>> these modules remain compatible when possibly breaking changes> are made to 
>> core? I use the IRC module in some of my regions and I wouldn't> want to see 
>> it broken, and I like to stay close to head in all of my regions> so I can 
>> be more aware of how development progresses. As such I would> potentially 
>> vote -1 on taking IRC out of core until there is some way to> maintain 
>> functionality as core evolves.I'm personally all for moving thinks to an 
>> Optional space, but we haveto be honest with ourselves, moving a module to 
>> the forge means thatthere is a better than 50% chance it's unusable in 2 
>> weeks time.  Ithink for things we've considered "dead" that's fine, but I'd 
>> bereluctant to push
  
>> 
> bits out that people do regularly use (like the ircbridge).  At least until 
> we have:1. an easy way to build an out of core module build tree2. network 
> repository support for modules (ala what's in mono addins)3. some type of 
> versioning on module interfaces, so we can know if aplugin thinks it can work 
> with the current buildOtherwise we are more or less jetisoning a lot of 
> features and reducingthe number of users that we can serve out of the box.  
> The same logicthat would leave these modules in the tree is the same logic 
> that keepsall the extra stuff in bin/, to make it easy for the new user to 
> getstarted.This shouldn't stop this current level of reorganization, which I 
> thinkis very useful.  But is just a warning on next steps of removing