[Opensim-dev] Let's post-tag 0.6.3 [Was: some instability ahead r8399+]
Um, that's basically what the 'stable' and 'post-fixes' should be considered - so basically, we should have found a good rev and bumped up to 0.6.3 before doing any destabilizing work. Good fixes still can go into the corresponding post-fixes branch, so basically, the post-fixes should be considered your best bet. Let's do that ASAP. Is there a good 0.6.3 candidate rev? Best regards, Stefan Andersson Tribal Media AB Date: Sun, 15 Feb 2009 14:31:39 -0800 From: aerow...@gmail.com To: opensim-us...@lists.berlios.de Subject: Re: [Opensim-users] some instability ahead r8399+ I wonder. What would it take to have tags associated with certain revisions, like latest-recommended-stable? At the least, this could be something that would allow people to get the latest SVN that is believed to not have as many issues? -Kyle H On Sun, Feb 15, 2009 at 2:00 PM, Diva Canto d...@metaverseink.com wrote: Before issue reports start flying, just wanted to let everyone know that starting in r8399, svn head is a bit unstable with respect to avatar crossings/TPs. Mileage may vary depending on many things. LL viewer seems more solid than the Hippo. Please bear with us while we clean up a lot of old assumptions out of the code. If you want something recent and relatively stable, stick to r8398 for the next few days. Please refrain from submitting crossing/TP-related mantis for the next week or so -- we know there are problems. Progress is two steps forward, one step back. As usual, we value the brave of heart who go with svn head no matter what, and provide valuable informal feedback on how things are looking. Thanks, Crista ___ Opensim-users mailing list opensim-us...@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-users ___ Opensim-users mailing list opensim-us...@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-users ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Please do not revert fixes without careful comtemplation
Hi, One example is here http://realxtendserver.svn.sourceforge.net/. Choose Authentication. There is NHibernateHandler and under that is Bulk. Best, - Antti 2009/2/16 Tommi Laukkanen tommi.s.e.laukka...@gmail.com Hello It would be nice to have somekind of short term solution to fix the current nhibernate asset store implementation so that it works and when cable beach is finalized we can see if we need to do something extra to support that fully. Antti: Can you elaborate with examples or link me to some nhibernate documentation which explains bulk object concept in detail. I don't get the exact implementation details from your mail. By implementation I mean what kind of mapping files you are proposing we would need and how they would be used from code. regards, Tommi ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Please do not revert fixes without careful comtemplation
Again, I'd like to stress that I believe this is too dangerous to do for anything other than textures. It is also not really needed for things other than textures, since the other assets are comparatively small, textural data. I would not want to risk even the smallest chance of a hash collision on script source. Melanie Stefan Andersson wrote: Coming in a bit from the side here, we have, for some time, discussed to separate out the binary blog out of the metadata for an entirely different reason, namely to be able to weed out binary duplicates. If there was a way for us to separate out the binary parts, into something like 'binaryassetId, hashData[256], binarydata' and then just have the asset table referencing that row, I think it would help a lot. I realize it's a separate discussion, just chipping in my two cents. Best regards, Stefan Andersson Tribal Media AB Date: Sat, 14 Feb 2009 17:49:22 +0200 From: tommi.s.e.laukka...@gmail.com To: mma...@gmail.com CC: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Please do not revert fixes without careful comtemplation Hello, On second though we could keep the current structure and expose all fields also through AssetBase properties. Then we could save / load the AssetBase with nhibernate as a single object and leave out the Metadata property from NHibernate mapping. Does this sound good? regards, Tommi On Sat, Feb 14, 2009 at 5:06 PM, Mike Mazur mma...@gmail.com wrote: Hi, On Sat, Feb 14, 2009 at 4:05 PM, Tommi Laukkanen tommi.s.e.laukka...@gmail.com wrote: I was talking with mikkopa and he suggested we should create two tables to cover AssetBase to solve this issue properly. Namely AssetMetadata for metadata information and AssetData for blobs to avoid situation where we end up accessing also the blob data just to read metadata. I was hoping not to have to do that. It should be straightforward to support the current AssetBase/AssetMetadata composition in the existing OpenSim data layers, but as sdague warned me earlier, by mapping multiple classes to one table I was entering a world of pain. Seems that's exactly what's happening with NHibernate. The reason I introduced the AssetMetadata class is to supply metadata information only for some requests that Cable Beach, the new asset server, supports. Now I realize that this was probably a premature optimization. Instead of modifying the DB schema, we could have AssetBase inherit from AssetMetadata, as I outlined before[1]. Alternatively, we could get rid of AssetMetadata altogether and store everything in AssetBase as before, splitting out the metadata sometime in the future when a use case warrants it. What do you think? Thanks, Mike [1] https://lists.berlios.de/pipermail/opensim-dev/2009-February/004918.html ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Please do not revert fixes without careful comtemplation
Hence me suggesting stronger hashes - there's no known attacks on anything above or equal to 160bit, plus to calculate an attack you'd have to have the hash of the original to begin with, which shouldn't be something revealed to an end user. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Melanie Sent: Monday, 16 February 2009 5:26 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Please do not revert fixes without careful comtemplation I see the potential of targeted MD5 collisions as a way to obtain script sources. A saves a script. B creates a targeted collision, which will result in creation of an inventory item refering to A. The data B saves is ignored because of hash equality B then reopens the object and receives A's script source. Melanie Frisby, Adam wrote: You do realise you could just not update the asset. If the hash is the same, then you can just completely ignore the save/update request. That being said, even a targeted collision on MD5 is a 2^58 chance, on SHA256 it's well over 2^128 which makes it pretty much impossible. Frankly it's not something worth concerning oneself over. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Melanie Sent: Monday, 16 February 2009 4:45 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Please do not revert fixes without careful comtemplation Again, I'd like to stress that I believe this is too dangerous to do for anything other than textures. It is also not really needed for things other than textures, since the other assets are comparatively small, textural data. I would not want to risk even the smallest chance of a hash collision on script source. Melanie Stefan Andersson wrote: Coming in a bit from the side here, we have, for some time, discussed to separate out the binary blog out of the metadata for an entirely different reason, namely to be able to weed out binary duplicates. If there was a way for us to separate out the binary parts, into something like 'binaryassetId, hashData[256], binarydata' and then just have the asset table referencing that row, I think it would help a lot. I realize it's a separate discussion, just chipping in my two cents. Best regards, Stefan Andersson Tribal Media AB Date: Sat, 14 Feb 2009 17:49:22 +0200 From: tommi.s.e.laukka...@gmail.com To: mma...@gmail.com CC: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Please do not revert fixes without careful comtemplation Hello, On second though we could keep the current structure and expose all fields also through AssetBase properties. Then we could save / load the AssetBase with nhibernate as a single object and leave out the Metadata property from NHibernate mapping. Does this sound good? regards, Tommi On Sat, Feb 14, 2009 at 5:06 PM, Mike Mazur mma...@gmail.com wrote: Hi, On Sat, Feb 14, 2009 at 4:05 PM, Tommi Laukkanen tommi.s.e.laukka...@gmail.com wrote: I was talking with mikkopa and he suggested we should create two tables to cover AssetBase to solve this issue properly. Namely AssetMetadata for metadata information and AssetData for blobs to avoid situation where we end up accessing also the blob data just to read metadata. I was hoping not to have to do that. It should be straightforward to support the current AssetBase/AssetMetadata composition in the existing OpenSim data layers, but as sdague warned me earlier, by mapping multiple classes to one table I was entering a world of pain. Seems that's exactly what's happening with NHibernate. The reason I introduced the AssetMetadata class is to supply metadata information only for some requests that Cable Beach, the new asset server, supports. Now I realize that this was probably a premature optimization. Instead of modifying the DB schema, we could have AssetBase inherit from AssetMetadata, as I outlined before[1]. Alternatively, we could get rid of AssetMetadata altogether and store everything in AssetBase as before, splitting out the metadata sometime in the future when a use case warrants it. What do you think? Thanks, Mike [1] https://lists.berlios.de/pipermail/opensim-dev/2009- February/004918.html -- --- --- ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de
Re: [Opensim-dev] Groups in OpenSim
Hi Ruud, Here are some of the features currently set in stone for development.. DeepThink seems to be setting the foundation for groups.. making sure it functions correctly ... If any developers would like to add on to this, that would be great. Groups Group Chat Group Permissions Group Titles Group Ownership Group Payments (optional I'm sure) On Mon, Feb 16, 2009 at 8:25 AM, Ruud Lathrop ruud.lath...@gmail.comwrote: Its great to hear that something is done about a missing but very important feature. I love to work on it to. But if somebody wants to sponsor a company to do it, that is fine with me. I do like to see what they are doing and maybe add something to it (Make the implementation to MSSQL). Foremost I like to see the following things implemented in groups: - Of course create/edit/invite etc for groups - Set permissions to groups of land/objects, work together on projects. - Create group chats. Hope to see the project started soon. And maybe in release 0.7 we have groups :) Ruud On Mon, Feb 16, 2009 at 10:39 AM, Frisby, Adam a...@deepthink.com.auwrote: The only concern I have here is that a good deal of this work is being done by our Shanghai office and me and Mike are the only guys with commit rights, so doing the morning checkin to core is a bit of a chore. (Whereas I can give everyone svn access on the forge) Adam *From:* opensim-dev-boun...@lists.berlios.de [mailto: opensim-dev-boun...@lists.berlios.de] *On Behalf Of *Stefan Andersson *Sent:* Monday, 16 February 2009 1:03 AM *To:* opensim-dev@lists.berlios.de *Subject:* Re: [Opensim-dev] Groups in OpenSim Yeah, I think 'groups' in terms of minimal implementations of functions as defined by our reference client the official Second Life(tm) virtual worlds viewer, is definitively a core module. I believe that if this central work is done in core instead of on forge, it will give us lots of valuable opportunity to help, discuss and react to changes, instead of it being a 'mushroom' in a corner of the room. Best regards, Stefan Andersson Tribal Media AB -- Date: Sun, 15 Feb 2009 11:49:14 -0800 From: c...@pacbell.net To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Groups in OpenSim Personally, I would suggest that groups is an enabling technology and I would concur that seperating economy notions from groups is a good thing. For groups functionality, the ability to form groups and have group communicaton similar to our IRC channels currently would go a long ways to fleshing out and testing additional functionality under load. We need to use our sims more to understand where the limits are. Additionally, adding the logic for group ownership of land and objects will help us get closer to a reasonable permissions model and thence closer to 0.7 for OpenSim. Charles -- *From:* Justin Clark-Casey jjusti...@googlemail.com *To:* opensim-dev@lists.berlios.de *Sent:* Sunday, February 15, 2009 10:52:06 AM *Subject:* Re: [Opensim-dev] Groups in OpenSim Frisby, Adam wrote: My personal thoughts would be definitely host on the gforge until completion, then decide on whether it goes into core or not (same as hypergrid). Personally, considering the modules that are in OpenSim core at the moment, I think that a groups module could definitely be considered a core module from the outset (and so be developed in core). It's by far the biggest piece of missing functionality for both an SL-like environment and many of the other virtual environments that one can imagine. However, having said that it's not as if people have been rushing to implement groups code in core - it has been a requested piece of unimplemented functionality for a long time. So it might be more convenient to develop it outside core if non-core developers are going to be working on it. I guess the situation might be somewhat different again if the groups module also implements integration to other systems (perhaps commercial ones) which would be more controversial to place in core. Though then again I would hope that such functionality could be split into further modules, with just the main groups code going into core. btw, Mike - very glad to see your sponsorship of this as public domain code. And I very much understand your reluctance to talk about sponsored development that hasn't yet been agreed. All I would say is that the more open everything is, the more smoothly everything seems to go in terms of getting code adopted and in terms of interacting with the wider OpenSim community. Regards, Adam *From:* opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] *On Behalf Of *Michael Huntington *Sent:* Friday, 13 February 2009 12:55 PM *To:* opensim-dev@lists.berlios.de *Subject:* Re: [Opensim-dev] Groups in OpenSim Well, I don't mind
Re: [Opensim-dev] Please do not revert fixes without careful comtemplation
Hello
That works if we have property accessors directly exposed from AssetBase to
all metadata fields. Then we can write mapping with those accessors and
ignore the metadata aggregate.
regards,
Tommi
On Mon, Feb 16, 2009 at 1:54 PM, Mike Mazur mma...@gmail.com wrote:
Hi,
On Mon, Feb 16, 2009 at 8:38 PM, Tommi Laukkanen
tommi.s.e.laukka...@gmail.com wrote:
It would be nice to have somekind of short term solution to fix the
current
nhibernate asset store implementation so that it works and when cable
beach
is finalized we can see if we need to do something extra to support that
fully.
How would this work as a temporary measure:
class AssetBase
{
private byte [] m_data;
private AssetMetadata m_metadata;
public UUID FullID
{
get { return m_metadata.FullID; }
set { m_metadata.FullID = value; }
}
// etc for the rest of the properties
// we have a method to retrieve the AssetMetadata object
// so we don't also serialize it when sending assets over the wire
public AssetMetadata getMetadata()
{
return m_metadata;
}
public void setMetadata(AssetMetadata metadata)
{
m_metadata = metadata;
}
}
Is there a better way to stop the metadata (property) from being
serialized instead of using the C++-style accessor and mutator?
I can commit this in about 12 hours if it would work. Comments welcome.
Thanks,
Mike
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Please do not revert fixes without careful comtemplation
Plus you could use those hashes to distribute the assets to several backed databases in similar manner as hashmap works. If a database becomes too full you can always split it to sub databases and move assets there in analogy with hashmap internal datastructure. Basicly all hashmap performance math and algorithms should apply. Do you think this could be workable way of doing asset storage distribution? regards, Tommi On Mon, Feb 16, 2009 at 3:21 PM, Frisby, Adam a...@deepthink.com.au wrote: Hence me suggesting stronger hashes - there's no known attacks on anything above or equal to 160bit, plus to calculate an attack you'd have to have the hash of the original to begin with, which shouldn't be something revealed to an end user. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Melanie Sent: Monday, 16 February 2009 5:26 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Please do not revert fixes without careful comtemplation I see the potential of targeted MD5 collisions as a way to obtain script sources. A saves a script. B creates a targeted collision, which will result in creation of an inventory item refering to A. The data B saves is ignored because of hash equality B then reopens the object and receives A's script source. Melanie Frisby, Adam wrote: You do realise you could just not update the asset. If the hash is the same, then you can just completely ignore the save/update request. That being said, even a targeted collision on MD5 is a 2^58 chance, on SHA256 it's well over 2^128 which makes it pretty much impossible. Frankly it's not something worth concerning oneself over. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Melanie Sent: Monday, 16 February 2009 4:45 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Please do not revert fixes without careful comtemplation Again, I'd like to stress that I believe this is too dangerous to do for anything other than textures. It is also not really needed for things other than textures, since the other assets are comparatively small, textural data. I would not want to risk even the smallest chance of a hash collision on script source. Melanie Stefan Andersson wrote: Coming in a bit from the side here, we have, for some time, discussed to separate out the binary blog out of the metadata for an entirely different reason, namely to be able to weed out binary duplicates. If there was a way for us to separate out the binary parts, into something like 'binaryassetId, hashData[256], binarydata' and then just have the asset table referencing that row, I think it would help a lot. I realize it's a separate discussion, just chipping in my two cents. Best regards, Stefan Andersson Tribal Media AB Date: Sat, 14 Feb 2009 17:49:22 +0200 From: tommi.s.e.laukka...@gmail.com To: mma...@gmail.com CC: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Please do not revert fixes without careful comtemplation Hello, On second though we could keep the current structure and expose all fields also through AssetBase properties. Then we could save / load the AssetBase with nhibernate as a single object and leave out the Metadata property from NHibernate mapping. Does this sound good? regards, Tommi On Sat, Feb 14, 2009 at 5:06 PM, Mike Mazur mma...@gmail.com wrote: Hi, On Sat, Feb 14, 2009 at 4:05 PM, Tommi Laukkanen tommi.s.e.laukka...@gmail.com wrote: I was talking with mikkopa and he suggested we should create two tables to cover AssetBase to solve this issue properly. Namely AssetMetadata for metadata information and AssetData for blobs to avoid situation where we end up accessing also the blob data just to read metadata. I was hoping not to have to do that. It should be straightforward to support the current AssetBase/AssetMetadata composition in the existing OpenSim data layers, but as sdague warned me earlier, by mapping multiple classes to one table I was entering a world of pain. Seems that's exactly what's happening with NHibernate. The reason I introduced the AssetMetadata class is to supply metadata information only for some requests that Cable Beach, the new asset server, supports. Now I realize that this was probably a premature optimization. Instead of modifying the DB schema, we could have AssetBase inherit from AssetMetadata, as I outlined before[1]. Alternatively, we could get rid of AssetMetadata altogether
Re: [Opensim-dev] Please do not revert fixes without careful comtemplation
Hello, that was a typo. The correct word was textual. All asset types besides textures are text. Melanie Charles Krinke wrote: Sorry, the other assets are not just small texture data. We have terrainImages, amongst other things. Our assets table in OpenSim contains lots of things including the infamouse blank, so lets look at it in total and not just from the script viewpoint. Course with scripts themselves, we have every edited version of every edited script in addition to every change of every other asset complicating the problem. Charles From: Melanie mela...@t-data.com To: opensim-dev@lists.berlios.de Sent: Monday, February 16, 2009 4:44:56 AM Subject: Re: [Opensim-dev] Please do not revert fixes without careful comtemplation Again, I'd like to stress that I believe this is too dangerous to do for anything other than textures. It is also not really needed for things other than textures, since the other assets are comparatively small, textural data. I would not want to risk even the smallest chance of a hash collision on script source. Melanie Stefan Andersson wrote: Coming in a bit from the side here, we have, for some time, discussed to separate out the binary blog out of the metadata for an entirely different reason, namely to be able to weed out binary duplicates. If there was a way for us to separate out the binary parts, into something like 'binaryassetId, hashData[256], binarydata' and then just have the asset table referencing that row, I think it would help a lot. I realize it's a separate discussion, just chipping in my two cents. Best regards, Stefan Andersson Tribal Media AB Date: Sat, 14 Feb 2009 17:49:22 +0200 From: tommi.s.e.laukka...@gmail.com To: mma...@gmail.com CC: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Please do not revert fixes without careful comtemplation Hello, On second though we could keep the current structure and expose all fields also through AssetBase properties. Then we could save / load the AssetBase with nhibernate as a single object and leave out the Metadata property from NHibernate mapping. Does this sound good? regards, Tommi On Sat, Feb 14, 2009 at 5:06 PM, Mike Mazur mma...@gmail.com wrote: Hi, On Sat, Feb 14, 2009 at 4:05 PM, Tommi Laukkanen tommi.s.e.laukka...@gmail.com wrote: I was talking with mikkopa and he suggested we should create two tables to cover AssetBase to solve this issue properly. Namely AssetMetadata for metadata information and AssetData for blobs to avoid situation where we end up accessing also the blob data just to read metadata. I was hoping not to have to do that. It should be straightforward to support the current AssetBase/AssetMetadata composition in the existing OpenSim data layers, but as sdague warned me earlier, by mapping multiple classes to one table I was entering a world of pain. Seems that's exactly what's happening with NHibernate. The reason I introduced the AssetMetadata class is to supply metadata information only for some requests that Cable Beach, the new asset server, supports. Now I realize that this was probably a premature optimization. Instead of modifying the DB schema, we could have AssetBase inherit from AssetMetadata, as I outlined before[1]. Alternatively, we could get rid of AssetMetadata altogether and store everything in AssetBase as before, splitting out the metadata sometime in the future when a use case warrants it. What do you think? Thanks, Mike [1] https://lists.berlios.de/pipermail/opensim-dev/2009-February/004918.html ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Groups in OpenSim
This is a great thread y'all keep up the great work :) Mike, all I have to say to you about this is *Thank you SO much* :) Cheers On Mon, Feb 16, 2009 at 8:39 AM, Michael Huntington mellom...@gmail.comwrote: Hi Ruud, Here are some of the features currently set in stone for development.. DeepThink seems to be setting the foundation for groups.. making sure it functions correctly ... If any developers would like to add on to this, that would be great. Groups Group Chat Group Permissions Group Titles Group Ownership Group Payments (optional I'm sure) On Mon, Feb 16, 2009 at 8:25 AM, Ruud Lathrop ruud.lath...@gmail.comwrote: Its great to hear that something is done about a missing but very important feature. I love to work on it to. But if somebody wants to sponsor a company to do it, that is fine with me. I do like to see what they are doing and maybe add something to it (Make the implementation to MSSQL). Foremost I like to see the following things implemented in groups: - Of course create/edit/invite etc for groups - Set permissions to groups of land/objects, work together on projects. - Create group chats. Hope to see the project started soon. And maybe in release 0.7 we have groups :) Ruud On Mon, Feb 16, 2009 at 10:39 AM, Frisby, Adam a...@deepthink.com.auwrote: The only concern I have here is that a good deal of this work is being done by our Shanghai office and me and Mike are the only guys with commit rights, so doing the morning checkin to core is a bit of a chore. (Whereas I can give everyone svn access on the forge) Adam *From:* opensim-dev-boun...@lists.berlios.de [mailto: opensim-dev-boun...@lists.berlios.de] *On Behalf Of *Stefan Andersson *Sent:* Monday, 16 February 2009 1:03 AM *To:* opensim-dev@lists.berlios.de *Subject:* Re: [Opensim-dev] Groups in OpenSim Yeah, I think 'groups' in terms of minimal implementations of functions as defined by our reference client the official Second Life(tm) virtual worlds viewer, is definitively a core module. I believe that if this central work is done in core instead of on forge, it will give us lots of valuable opportunity to help, discuss and react to changes, instead of it being a 'mushroom' in a corner of the room. Best regards, Stefan Andersson Tribal Media AB -- Date: Sun, 15 Feb 2009 11:49:14 -0800 From: c...@pacbell.net To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Groups in OpenSim Personally, I would suggest that groups is an enabling technology and I would concur that seperating economy notions from groups is a good thing. For groups functionality, the ability to form groups and have group communicaton similar to our IRC channels currently would go a long ways to fleshing out and testing additional functionality under load. We need to use our sims more to understand where the limits are. Additionally, adding the logic for group ownership of land and objects will help us get closer to a reasonable permissions model and thence closer to 0.7 for OpenSim. Charles -- *From:* Justin Clark-Casey jjusti...@googlemail.com *To:* opensim-dev@lists.berlios.de *Sent:* Sunday, February 15, 2009 10:52:06 AM *Subject:* Re: [Opensim-dev] Groups in OpenSim Frisby, Adam wrote: My personal thoughts would be definitely host on the gforge until completion, then decide on whether it goes into core or not (same as hypergrid). Personally, considering the modules that are in OpenSim core at the moment, I think that a groups module could definitely be considered a core module from the outset (and so be developed in core). It's by far the biggest piece of missing functionality for both an SL-like environment and many of the other virtual environments that one can imagine. However, having said that it's not as if people have been rushing to implement groups code in core - it has been a requested piece of unimplemented functionality for a long time. So it might be more convenient to develop it outside core if non-core developers are going to be working on it. I guess the situation might be somewhat different again if the groups module also implements integration to other systems (perhaps commercial ones) which would be more controversial to place in core. Though then again I would hope that such functionality could be split into further modules, with just the main groups code going into core. btw, Mike - very glad to see your sponsorship of this as public domain code. And I very much understand your reluctance to talk about sponsored development that hasn't yet been agreed. All I would say is that the more open everything is, the more smoothly everything seems to go in terms of getting code adopted and in terms of interacting with the wider OpenSim community. Regards, Adam *From:* opensim-dev-boun...@lists.berlios.de
Re: [Opensim-dev] Please do not revert fixes without careful comtemplation
No. Terrain images are textures. They are assets referring to jp2 streams. That makes them textures. And, AFAIK, all other assets are text. Melanie Charles Krinke wrote: I am so sorry that we are having communications difficulties. Terrain Images, are, I believe, neither textual nor text. That was just an example. The point is that we need to be careful and consider all the various assets which include a lot more then textures and scripts. Charles From: Melanie mela...@t-data.com To: opensim-dev@lists.berlios.de Sent: Monday, February 16, 2009 8:23:16 AM Subject: Re: [Opensim-dev] Please do not revert fixes without careful comtemplation Hello, that was a typo. The correct word was textual. All asset types besides textures are text. Melanie Charles Krinke wrote: Sorry, the other assets are not just small texture data. We have terrainImages, amongst other things. Our assets table in OpenSim contains lots of things including the infamouse blank, so lets look at it in total and not just from the script viewpoint. Course with scripts themselves, we have every edited version of every edited script in addition to every change of every other asset complicating the problem. Charles From: Melanie mela...@t-data.com To: opensim-dev@lists.berlios.de Sent: Monday, February 16, 2009 4:44:56 AM Subject: Re: [Opensim-dev] Please do not revert fixes without careful comtemplation Again, I'd like to stress that I believe this is too dangerous to do for anything other than textures. It is also not really needed for things other than textures, since the other assets are comparatively small, textural data. I would not want to risk even the smallest chance of a hash collision on script source. Melanie Stefan Andersson wrote: Coming in a bit from the side here, we have, for some time, discussed to separate out the binary blog out of the metadata for an entirely different reason, namely to be able to weed out binary duplicates. If there was a way for us to separate out the binary parts, into something like 'binaryassetId, hashData[256], binarydata' and then just have the asset table referencing that row, I think it would help a lot. I realize it's a separate discussion, just chipping in my two cents. Best regards, Stefan Andersson Tribal Media AB Date: Sat, 14 Feb 2009 17:49:22 +0200 From: tommi.s.e.laukka...@gmail.com To: mma...@gmail.com CC: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Please do not revert fixes without careful comtemplation Hello, On second though we could keep the current structure and expose all fields also through AssetBase properties. Then we could save / load the AssetBase with nhibernate as a single object and leave out the Metadata property from NHibernate mapping. Does this sound good? regards, Tommi On Sat, Feb 14, 2009 at 5:06 PM, Mike Mazur mma...@gmail.com wrote: Hi, On Sat, Feb 14, 2009 at 4:05 PM, Tommi Laukkanen tommi.s.e.laukka...@gmail.com wrote: I was talking with mikkopa and he suggested we should create two tables to cover AssetBase to solve this issue properly. Namely AssetMetadata for metadata information and AssetData for blobs to avoid situation where we end up accessing also the blob data just to read metadata. I was hoping not to have to do that. It should be straightforward to support the current AssetBase/AssetMetadata composition in the existing OpenSim data layers, but as sdague warned me earlier, by mapping multiple classes to one table I was entering a world of pain. Seems that's exactly what's happening with NHibernate. The reason I introduced the AssetMetadata class is to supply metadata information only for some requests that Cable Beach, the new asset server, supports. Now I realize that this was probably a premature optimization. Instead of modifying the DB schema, we could have AssetBase inherit from AssetMetadata, as I outlined before[1]. Alternatively, we could get rid of AssetMetadata altogether and store everything in AssetBase as before, splitting out the metadata sometime in the future when a use case warrants it. What do you think? Thanks, Mike [1] https://lists.berlios.de/pipermail/opensim-dev/2009-February/004918.html ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev
[Opensim-dev] Any OpenSim viewers being built from scratch?
I know this isn't a viewer related dev group... but...I was wondering if anyone was building a viewer that wasn't so tied down to SecondLife? Basically a viewer that has been built from the ground up with OpenSim in mind. The viewers so far have been the biggest OpenSim eyesore for me... if anyone knows of a viewer project targeted for OpenSim or knows someone interested in starting that kind of project please let me know or forward my email to them. Thanks! ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Any OpenSim viewers being built from scratch?
Dear Mike: As Dahlia said, the IdealistViewer is a good candidate as it begins to add features. Many of us have high hopes for IdealistViewer during the course of this year. As OpenSim, we have decided to stay in SecondLife viewer compatible so we are measuring the operation and performance of OpenSim against the current SecondLife official viewer, currently 1.21.6. This does change from time to time and when it changes, we strive to stay compatible. This SecondLife viewer represents the largest set of users for OpenSim, so this seems like a reasonable decision. It is entirely probable that other viewers such as Hippo, IdealistViewer, OpenViewer, Xenkii, Rex and others will become widely adopted and we hope that will happen. We also hope that they will stay compatible with the SecondLife viewer, but as 2009 unfolds, it will be very interesting to see what happens. Charles From: Michael Huntington mellom...@gmail.com To: opensim-dev@lists.berlios.de Sent: Monday, February 16, 2009 1:44:04 PM Subject: [Opensim-dev] Any OpenSim viewers being built from scratch? I know this isn't a viewer related dev group... but...I was wondering if anyone was building a viewer that wasn't so tied down to SecondLife? Basically a viewer that has been built from the ground up with OpenSim in mind. The viewers so far have been the biggest OpenSim eyesore for me... if anyone knows of a viewer project targeted for OpenSim or knows someone interested in starting that kind of project please let me know or forward my email to them. Thanks!___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Please do not revert fixes without careful comtemplation
Yes, I did forget sounds. Probably because they never reached critical mass on any system I have anything to do with. Though, a lot seem to exist, judged by the number of gestures. As for images, I call them all textures, because any image could be used as a texture. They are all jp2 steams, so even though they may have a different purpose from covering prims, they are technically identical in storage format and type of content, and would be handled the same. Melanie Justin Clark-Casey wrote: Melanie wrote: No. Terrain images are textures. They are assets referring to jp2 streams. That makes them textures. And, AFAIK, all other assets are text. Other non-text assets are images that aren't textures and sounds. Melanie Charles Krinke wrote: I am so sorry that we are having communications difficulties. Terrain Images, are, I believe, neither textual nor text. That was just an example. The point is that we need to be careful and consider all the various assets which include a lot more then textures and scripts. Charles From: Melanie mela...@t-data.com To: opensim-dev@lists.berlios.de Sent: Monday, February 16, 2009 8:23:16 AM Subject: Re: [Opensim-dev] Please do not revert fixes without careful comtemplation Hello, that was a typo. The correct word was textual. All asset types besides textures are text. Melanie Charles Krinke wrote: Sorry, the other assets are not just small texture data. We have terrainImages, amongst other things. Our assets table in OpenSim contains lots of things including the infamouse blank, so lets look at it in total and not just from the script viewpoint. Course with scripts themselves, we have every edited version of every edited script in addition to every change of every other asset complicating the problem. Charles From: Melanie mela...@t-data.com To: opensim-dev@lists.berlios.de Sent: Monday, February 16, 2009 4:44:56 AM Subject: Re: [Opensim-dev] Please do not revert fixes without careful comtemplation Again, I'd like to stress that I believe this is too dangerous to do for anything other than textures. It is also not really needed for things other than textures, since the other assets are comparatively small, textural data. I would not want to risk even the smallest chance of a hash collision on script source. Melanie Stefan Andersson wrote: Coming in a bit from the side here, we have, for some time, discussed to separate out the binary blog out of the metadata for an entirely different reason, namely to be able to weed out binary duplicates. If there was a way for us to separate out the binary parts, into something like 'binaryassetId, hashData[256], binarydata' and then just have the asset table referencing that row, I think it would help a lot. I realize it's a separate discussion, just chipping in my two cents. Best regards, Stefan Andersson Tribal Media AB Date: Sat, 14 Feb 2009 17:49:22 +0200 From: tommi.s.e.laukka...@gmail.com To: mma...@gmail.com CC: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Please do not revert fixes without careful comtemplation Hello, On second though we could keep the current structure and expose all fields also through AssetBase properties. Then we could save / load the AssetBase with nhibernate as a single object and leave out the Metadata property from NHibernate mapping. Does this sound good? regards, Tommi On Sat, Feb 14, 2009 at 5:06 PM, Mike Mazur mma...@gmail.com wrote: Hi, On Sat, Feb 14, 2009 at 4:05 PM, Tommi Laukkanen tommi.s.e.laukka...@gmail.com wrote: I was talking with mikkopa and he suggested we should create two tables to cover AssetBase to solve this issue properly. Namely AssetMetadata for metadata information and AssetData for blobs to avoid situation where we end up accessing also the blob data just to read metadata. I was hoping not to have to do that. It should be straightforward to support the current AssetBase/AssetMetadata composition in the existing OpenSim data layers, but as sdague warned me earlier, by mapping multiple classes to one table I was entering a world of pain. Seems that's exactly what's happening with NHibernate. The reason I introduced the AssetMetadata class is to supply metadata information only for some requests that Cable Beach, the new asset server, supports. Now I realize that this was probably a premature optimization. Instead of modifying the DB schema, we could have AssetBase inherit from AssetMetadata, as I outlined before[1]. Alternatively, we could get rid of AssetMetadata altogether and store everything in AssetBase as before, splitting out the metadata sometime in the future when a use case warrants it. What do you think? Thanks, Mike [1]
Re: [Opensim-dev] Please do not revert fixes without careful comtemplation
And that I am in 100% agreement on. Melanie Charles Krinke wrote: Well, it really doesnt matter what one calls them. Binary data, text, whatever. The point is that we have a number of issues with our assets table in OpenSim that a bit of thought would help. 1. We have a significant number of assets whose name is blank that are created with a default constructor. And I suspect are never accessible. 2. We have a significant number of assets of each and every edit of terrain, where only the very last one is accessible. 3. We have a significant number of assets of each and every text edit for each and every textual assets. Where only the last one should be accessible. Its a bit like collecting every scrap of paper ever written with either text or binary glyphs and putting them in a big filing cabinet. After a while, finding the ones that are interesting in a timely manner starts to get a little challenging. Charles From: Melanie mela...@t-data.com To: opensim-dev@lists.berlios.de Sent: Monday, February 16, 2009 4:43:53 PM Subject: Re: [Opensim-dev] Please do not revert fixes without careful comtemplation Yes, I did forget sounds. Probably because they never reached critical mass on any system I have anything to do with. Though, a lot seem to exist, judged by the number of gestures. As for images, I call them all textures, because any image could be used as a texture. They are all jp2 steams, so even though they may have a different purpose from covering prims, they are technically identical in storage format and type of content, and would be handled the same. Melanie Justin Clark-Casey wrote: Melanie wrote: No. Terrain images are textures. They are assets referring to jp2 streams. That makes them textures. And, AFAIK, all other assets are text. Other non-text assets are images that aren't textures and sounds. Melanie Charles Krinke wrote: I am so sorry that we are having communications difficulties. Terrain Images, are, I believe, neither textual nor text. That was just an example. The point is that we need to be careful and consider all the various assets which include a lot more then textures and scripts. Charles From: Melanie mela...@t-data.com To: opensim-dev@lists.berlios.de Sent: Monday, February 16, 2009 8:23:16 AM Subject: Re: [Opensim-dev] Please do not revert fixes without careful comtemplation Hello, that was a typo. The correct word was textual. All asset types besides textures are text. Melanie Charles Krinke wrote: Sorry, the other assets are not just small texture data. We have terrainImages, amongst other things. Our assets table in OpenSim contains lots of things including the infamouse blank, so lets look at it in total and not just from the script viewpoint. Course with scripts themselves, we have every edited version of every edited script in addition to every change of every other asset complicating the problem. Charles From: Melanie mela...@t-data.com To: opensim-dev@lists.berlios.de Sent: Monday, February 16, 2009 4:44:56 AM Subject: Re: [Opensim-dev] Please do not revert fixes without careful comtemplation Again, I'd like to stress that I believe this is too dangerous to do for anything other than textures. It is also not really needed for things other than textures, since the other assets are comparatively small, textural data. I would not want to risk even the smallest chance of a hash collision on script source. Melanie Stefan Andersson wrote: Coming in a bit from the side here, we have, for some time, discussed to separate out the binary blog out of the metadata for an entirely different reason, namely to be able to weed out binary duplicates. If there was a way for us to separate out the binary parts, into something like 'binaryassetId, hashData[256], binarydata' and then just have the asset table referencing that row, I think it would help a lot. I realize it's a separate discussion, just chipping in my two cents. Best regards, Stefan Andersson Tribal Media AB Date: Sat, 14 Feb 2009 17:49:22 +0200 From: tommi.s.e.laukka...@gmail.com To: mma...@gmail.com CC: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Please do not revert fixes without careful comtemplation Hello, On second though we could keep the current structure and expose all fields also through AssetBase properties. Then we could save / load the AssetBase with nhibernate as a single object and leave out the Metadata property from NHibernate mapping. Does this sound good? regards, Tommi On Sat, Feb 14, 2009 at 5:06 PM, Mike Mazur mma...@gmail.com wrote: Hi, On Sat, Feb 14, 2009 at 4:05 PM, Tommi Laukkanen tommi.s.e.laukka...@gmail.com wrote: I was talking with mikkopa and he suggested
