Re: [Opensim-dev] Refactoring IClientAPI.Close and Friends
I know that part of why the Close() thing is so tangly is because we need to make sure certain packets have been sent before just killing the connection, and that some of them might need to wait for a response from the client. So it's a difference between Close() as in Dispose() and Close() as in 'shut down user connection correctly' afaicanrecall. Also, I think part of the confusion is a somewhat fuzzy diversion of responsibility between the client itself and the client manager. Ideally, all core code outside the manager and its clients should ask the Client Manager to close a Client correctly (as it should know how to remove references to clients, but also to interact with other system management resources) - the emptying of queues and actual closing down should probably be a private matter for the client class. The Client Thus probably would need to have a 'shutting down' flag, throwing non-essential packets, and it would signal to the client manager when it's done with its internal closing down work, so the manager can remove the references from the system. I believe that can be the origin of the event vs dispose bool. Which is ugly as hell, and I'm probably the one to introduce it. Best regards, Stefan Andersson Tribal Media AB From: a...@deepthink.com.au To: opensim-dev@lists.berlios.de Date: Sun, 22 Feb 2009 02:21:05 -0500 Subject: [Opensim-dev] Refactoring IClientAPI.Close and Friends Right now, we have four separate close methods for clients, enumerated they are (for LLClientView): - Close(bool circuit) o Either fires an event, or closes the connection depending on parameter[!?] - Kick(string msg) o Asks the client politely to quit. [!?] - Stop() o Initialises some shutdown cleanup - Restart() o Undo-‘s the above - Terminate() o Stops processing packets for the user and removes their entry in the packet server I would like to propose changing this into three methods. - Close(string msg) – Combines Kick, Terminate and Close into one method. We need to find out why Close branches onto the event when the parameter is true, or closes when false, and streamline it. Kick should automatically terminate the connection – there should be no ‘requests’ involved, it should be a very straight forward ‘You are the weakest link. Goodbye.’ - Pause() – Equivilent to Stop() as it is now. Function described as ‘Suspend Packet Processing’ - Resume() – Equivilent to Restart() as it is now. Function described as ‘Resume Packet Processing’ Adam___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] ProcessInPacket - Can this be moved out of IClientAPI?
+1, does seem like an archaic remnant. Best regards, Stefan Andersson Tribal Media AB Date: Sun, 22 Feb 2009 11:39:18 + From: mela...@t-data.com To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] ProcessInPacket - Can this be moved out of IClientAPI? I guess originally a greater sparateion of the packet stack and client logic was anticipated. It has now show itself to be untrue. SHould be no problem to take that out of the API if it has no external callers. Nothing dealing with Packets should be in the API in the first place. Melanie Frisby, Adam wrote: Quick question for folks, can we move ProcessInPacket out of ClientAPI, and onto LLClientView directly? It's only ever called from within LLClientStack so we already know it's a LLClientView class and should be able to just call it from there. Adam ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] oddities with asset storage
i thought the reasoning goes also the other way around: if someone has a use case where they'd benefit from using Tahoe with OpenSim, they are free to do it if it doesn't give much benefit for OpenSim otherwise, that doesn't matter, as long as people who want to use it can, without hurting OpenSim (by requiring a lot of / strange, otherwise unbeneficial changes in the core). +1 As Stefan said, we're a general platform that should allow people to plugin the modules that they want. OpenSim should benefit the people using it, not those people primarily benefiting OpenSim. I think we have a general confusion here over whether we're discussing the technonolgy for inclusion in core, or whether the technology would be a cool thing in general. We would probably never include that kind of experimental code in core without it being tried out first - that's what the forge is for. But OpenSim as a platform should always strive to make third party implementations like this as easy as possible (examples in point, hypergrid, Cable Beach) and listen carefully to the suggestions and wishes of plugin implementators. Ok well so be it for OSGrid. But perhaps some other user, maybe e.g. some intranet somewhere, has it differently. +1 again So write it. It's that simple. We promise to be there to help anyone wanting to have a go with documentation and general advice. Feel free, but there is a wealth of good software as GPL, and I sure hope to be able to use those too. Like I'm happy to use Linux to run our company servers, and it being GPL is just fine for me. But I'm also happy that Ogre is BSD so we are free to license our games however we need. +1 I have no problems with the GPL general, just this particular project is BSD and I think BSD is better here. If other people prefer BSD always than that is their own personal opinion. Again, that is partly what the forge is for. You can have GPL modules on the forge. It's actually a quite good way to sidestep the whole issue. but can a 3rd party plugin for using them together still exist? I'm sure it can it an at least internally if I don't tell anyone! :p Yes, I'm guessing this is what Adam meant - we couldn't bundle Tahoe plugins with OpenSim, not that you wouldn't be free to write a third party plugin for using it. *looks at the forge* I sure hope this doesn't explose to a huge license discussion, please just point to a better place or reply in private if that would happen. Again, we are working to get a better structure with regards to what is included in the core distribution and what is not. That is an ongoing process, but: * Experimental modules not implementing reference client behaviour should be tried out on the forge first. This has the added benefit of boosting the API thru external change request sources. * Modules that rely on linking resources under non-compatible licenses should be developed and maintained on the forge. * We are constantly thinking about how to better integrate the forge projects and the core distro. That is also an ongoing process. Please, feel free to start hacking away on an customized and prototypical IAssetDataPlugin on the forge. I'm looking forward to seeing it! /Stefan ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] oddities with asset storage
Initiatives like this is why I'm a hardcore proponent of keeping the services encapsulated, indirected, modular and flexible, ie, not tie core to any given technology or assumptions about data storage configuration. Best regards, Stefan Andersson Tribal Media AB Date: Thu, 19 Feb 2009 10:29:10 +0100 From: eu...@leitl.org To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] oddities with asset storage On Thu, Feb 19, 2009 at 10:24:40AM +0100, Dirk Krause wrote: As soon as you buy it, the asset gets copied to your regions asset repository (if it is something that persists while you are not online, like a house maybe) and it goes into your personal repository when it's an attachement (like clothing). Speaking about asset repository, Tahoe v1.3 has recently been released (see below). Are there any show-stoppers against using Tahoe for asset storage? http://allmydata.org/trac/tahoe/browser/relnotes.txt?rev=20090214000500-92b7f-26d07f519c69a3e086ee4599620f6d2c0c9b2fcd ANNOUNCING allmydata.org Tahoe, the Least-Authority Filesystem, v1.3 We are pleased to announce the release of version 1.3.0 of Tahoe, the Least Authority Filesystem. Tahoe-LAFS is a secure, decentralized, fault-tolerant filesystem. All of the source code is available under a choice of two Free Software, Open Source licences. This filesystem is encrypted and distributed over multiple peers in such a way it continues to function even when some of the peers are unavailable, malfunctioning, or malicious. Here is the one-page explanation of the security and fault-tolerance properties that it offers: http://allmydata.org/source/tahoe/trunk/docs/about.html This is the successor to v1.2, which was released July 21, 2008 [1]. This is a major new release, adding a repairer, an efficient backup command, support for large files, an (S)FTP server, and much more. See the NEWS file [2] and the known_issues.txt file [3] for more information. In addition to the many new features of Tahoe itself, a crop of related projects have sprung up, including Tahoe frontends for Windows and Macintosh, two front-ends written in JavaScript, a Tahoe plugin for duplicity, a Tahoe plugin for TiddlyWiki, a project to create a new backup tool, CIFS/SMB integration, an iPhone app, and three incomplete Tahoe frontends for FUSE. See Related Projects on the wiki: [4]. COMPATIBILITY The version 1 branch of Tahoe is the basis of the consumer backup product from Allmydata, Inc. -- http://allmydata.com . Tahoe v1.3 is fully compatible with the version 1 branch of Tahoe. Files written by v1.3 clients can be read by clients of all versions back to v1.0 unless the file is too large -- files greater than about 12 GiB (depending on the configuration) can't be read by older clients. v1.3 clients can read files produced by clients of all versions since v1.0. v1.3 servers can serve clients of all versions back to v1.0 and v1.3 clients can use servers of all versions back to v1.0 (but can't upload large files to them). This is the fourth release in the version 1 series. We believe that this version of Tahoe is stable enough to rely on as a permanent store of valuable data. The version 1 branch of Tahoe will be actively supported and maintained for the forseeable future, and future versions of Tahoe will retain the ability to read files and directories produced by Tahoe v1 for the forseeable future. WHAT IS IT GOOD FOR? With Tahoe, you can distribute your filesystem across a set of computers, such that if some of the computers fail or turn out to be malicious, the entire filesystem continues to be available, thanks to the remaining computers. You can also share your files with other users, using a simple and flexible access control scheme. Because this software is new, we do not categorically recommend it as the sole repository of data which is extremely confidential or precious. However, we believe that erasure coding, strong encryption, Free/Open Source Software and careful engineering make Tahoe safer than common alternatives, such as RAID, removable drive, tape, or on-line storage or Cloud storage systems. This software comes with extensive unit tests [5], and there are no known security flaws which would compromise confidentiality or data integrity. (For all currently known issues please see the known_issues.txt file [2].) This release of Tahoe is suitable for the friendnet use case [6] -- it is easy to create a filesystem spread over the computers of you and your friends so that you can share disk space and files. LICENCE You may use this package under the GNU General Public License, version 2 or, at your option, any later version. See the file COPYING.GPL [7] for the terms of the GNU General Public License, version 2. You may use this package under the Transitive Grace Period Public Licence, version 1.0. The Transitive Grace Period Public
Re: [Opensim-dev] Heads Up: Updating Prebuild to Upstream
First of all, sorry for the cross-post, just felt the 'users' (whatever that means) should be aware of this as well: I have now updated Prebuild from upstream. Please, try the latest rev out and report to me if I have caused any breakage or regressions. Thank you to Kunnis and JHurliman for back-porting the OpenSim fixes into Prebuild upstream. This is the commit log entry for the update: === PREBUILD UPSTREAMS UPDATE : POTENTIAL BREAKAGE === * Applied upstreams changes to allow for auditing and debugging in our various environments. * This should, in theory, bring back 'multiple ref dirs'. * Temporarily Removed xmlns because prebuild-1.7 schema does not allow for multiple solutions per prebuild node (This will be a moot issue once the Prebuild node is moved out of prebuild.xml) * Autotools target: Various minor fixes * MonoDevelop Target : No changes. * Nant Target: Various minor fixes, support for net-3.5 and mono-2.0/3.5 targets * Sharpdevelop targets: No changes. * VS Targets: Refactored into using VSGenericTarget, and supports 2.0-3.5 * XCode Target: No changes. --- Regressions and outstanding issues --- * The Solution is assigned a random Guid - will lead to unnecessary reloads and loss of user settings. [in Visual Studio, that is] --- New features of Prebuild 2.0.4 --- * (Better) support for Web, WinForms and Database Projects and build actions * Conditional Framework Version compilation support (1.1, 2.0-3.5) * ArrayList - List, ICollection - IList (this means Prebuild can generate 1.1 solutions, but can't itself be built under 1.1 - how very meta) * Added ?include file=sub_prebuild.xml ? preprocessor directive. Best regards, Stefan Andersson Tribal Media AB From: ste...@tribalmedia.se To: opensim-dev@lists.berlios.de Subject: Heads Up: Updating Prebuild to Upstream Date: Wed, 18 Feb 2009 22:14:43 +0100 Dear colleagues, Kunnis and JHurliman has been working to incorporate our Prebuild customizations into the upstream source, and we're now at the point where we can do an upstream update and subsequentially move the Prebuild source out of the trunk and into opensim-libs. (Or should it go on the forge?) Since the code hasn't changed that much, I believe we should simply go ahead and do the switch, and if any cross-environment breakage would happen, work together to solve it. So please help us troubleshoot Prebuild on your environment. Best regards, Stefan Andersson Tribal Media AB ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] oddities with asset storage
Dirk,
I think you are on the right track here - concentrating on one use case at a
time. That is probably the way to move forward on this issue.
BUT do keep in mind that the overshadowing, out-there-right-now, case is the
'Linden Viewer Compatible Social World'.
So whatever we discuss, that case has to be one of the supported ones.
That said, optionality and configuration is (as in, should be) our forte.
Best regards,
Stefan Andersson
Tribal Media AB
Date: Thu, 19 Feb 2009 13:40:14 +0100
From: dirk.kra...@pixelpark.com
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] oddities with asset storage
Ok, then in my naive little world this would be the cloning business case
with some kind of quality of service.
Basically you only sell me a link to your variety of assets. Then we have
three cases:
- you keep this in your personal assets store, which might be something like
a stand-alone cable beach server. When this server is unavailable, I cannot
access your item.
- you run or rent some 'home/office space' on a particular region; if the
region is unavailable, I again cannot access your item.
- you run your own grid or rent some 'grid space' on a particular grid; if
the grid is unavailable, I again cannot access your item. Assuming that grid
uptimes are good, this would be the best option in terms of accessibility.
In all three cases you yourself are a customer of either a region or a grid,
because you need some level of QOS, which they provide unless you don't want
to do this yourself.
If a grid owner is nice she gives you free access to, say, 20MB of personal
inventory.
-Ursprüngliche Nachricht-
Von: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Melanie
Gesendet: Donnerstag, 19. Februar 2009 12:58
An: opensim-dev@lists.berlios.de
Betreff: Re: [Opensim-dev] oddities with asset storage
The issue I have with the concept is one of copyright. I may not
grant the right to keep a local copy of an asset, because I may not
want it to work on local installations or another grid, I may not
want to give up my script source.
Melanie
Dr Scofield wrote:
Dirk Krause wrote:
Glad you asked :-).
I would do a mixture of the following (and admit that I didn't think it
all through to the very end).
- introduce grid wide, region wide and personal (user) asset domains
- introduce quotas for these
- allow clones ('byref') assets, and copies that go into one of the
domains, resp.
I then would expect to have grid wide assets that are 'always on', region
wide assets that only are important when the region is connected, and
personal assets that are only visible when the user is online (could even
be an FTP server behind a cable beach server).
It boils down to: if someone treasures something, she better keeps it in
her treasure chest, in her responsibility (and maintenance cost).
ok. so i now buy something in your region, take it with me, rezz it on my
region. how would that work and how would that address your concerns? oh,
and my
region is rather volatile, it might be there one moment, it might be
off-line
the next.
DrS/dirk
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] oddities with asset storage
Um. Having immutable assets do bring a number of optimization shortcuts. I'm not saying it's all good - merely that it's not all bad. The OpenSim solution, as always, is to address each case by itself, and to make divergence optional. So, maybe region map textures should be overwriteable. Maybe some scripts should be overwriteable as well, maybe only on some type of scripts. Maybe we should have a table enumerating what assetIds now point to newer assetIds. Maybe the real problem is that we are talking about 'assets' and 'textures' instead of 'prim face textures', 'sculptie maps', 'photos', 'region map images', 'script sources', 'sounds', 'prims in inventory', 'notecards', 'animations' - my point being that we can probably implement various configurable strategies for each of them, linden viewer or no linden viewer. Best regards, Stefan Andersson Tribal Media AB Date: Wed, 18 Feb 2009 16:37:12 +0100 From: dirk.kra...@pixelpark.com To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] oddities with asset storage ... This would mean that any grid runs into a severe problem over time. Yep :). On a standalone one could implement some cleanup scheme which checks everything to see if an asset is still referenced, and deletes that asset if it is not. In grid mode this is a much more difficult problem since references are scattered across many different regions servers. The situation is even worse if you are running a grid where not all of them are guaranteed to be connected. But isn't that ... horrible? (in lack of a better/worse word.) As I said yesterday, IMHO there is no real need to think about optimizations when you have a serious blocker like this. I would even go so far that this is a major roadblock for grid based technologies per se. (grid as in Rosedale's 'Happily now, Second Life has been proven to exist. If we disappeared tomorrow, the grid would be rebuilt by you.') I take it the bad news is that any proposed solution to this breaks SL compatibility? Maybe now would be a good time to take a step away from 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] oddities with asset storage
I suggest we talk more about complementary and parallell scenarios and strategies, and less about either/or - this is a platform, and various implemetations will prioritize differently. Best regards, Stefan Andersson Tribal Media AB Date: Wed, 18 Feb 2009 20:02:38 +0100 From: dirk.kra...@pixelpark.com To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] oddities with asset storage There could be business modell attached to it. Lets say you sell only the 'right to use it for a given time' to the user, then you would have only one set of assets with multiple inventory pointers from your 2000 customers. Once you delete/disable it, no one can use it anymore. Once you update it, all 2000 have a newer version of it. The other model would be the 'I buy it so I get a real copy of it'. The asset will be copied (in my scenario to my local inventory domain, so I 'really' own it). If you delete yours, mine is still there. If you update it, I need to obtain a newer copy. There could even be a concept that something is there only once (maybe art); you create it, give it a away (for a good price) and you don't have it anymore. The asset vanishes from your inventory domain. Regarding the SL compatibility - maybe it doesn't need to be broken. IIRC isn't there this CAPS mechanism that already proxies assets? Couldn't there be some kind of intelligence behind it that collects and distributes assets from the different domains? -Ursprüngliche Nachricht- Von: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Melanie Gesendet: Mittwoch, 18. Februar 2009 19:57 An: opensim-dev@lists.berlios.de Betreff: Re: [Opensim-dev] oddities with asset storage Making a copy is the greater evil. With implicitly shared assets, only content creators create assets. With asset copying, each sale/give creates assets. Take SL: I make a clothing item. I have to make 18 uploads (creating 18 assets) to finally use 2 of the uploaded textures. I have also created 36 wearable assets through this. Then i put that item for sale. 2000 users buy it. With implicitly shared assets, assets consumed: 18 texture, 36 wearable. With asset copying, assets consumed: 4001 texture, 4003 wearable See, the point of diminishing returns for copying is very close. Melanie John Ward wrote: Justin Clark-Casey wrote: The problem is that you may have given that item to somebody else. Giving an item does not make an asset copy, it just makes an inventory item copy (both inventory items still point towards the same asset). So you may delete your item, but we don't know if the asset referenced by that item lives on in someone else's inventory (or in an object inventory). So we can't delete the underlying asset. Why not make an asset copy when one makes an inventory copy? Then delete the asset when deleted from inventory. Is each user having their own copy of many things a bigger problem? I guess this doesn't address one having out of ban knowledge of an assets UUID and expecting it to be there. Also, I accept that I may be missing some fundamental knowledge of how things work. Please be gentle :-) John. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
[Opensim-dev] Heads Up: Updating Prebuild to Upstream
Dear colleagues, Kunnis and JHurliman has been working to incorporate our Prebuild customizations into the upstream source, and we're now at the point where we can do an upstream update and subsequentially move the Prebuild source out of the trunk and into opensim-libs. (Or should it go on the forge?) Since the code hasn't changed that much, I believe we should simply go ahead and do the switch, and if any cross-environment breakage would happen, work together to solve it. So please help us troubleshoot Prebuild on your environment. Best regards, Stefan Andersson Tribal Media AB ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Setting default locale for opensim processes
Yes. It will probably also have to be set on each new spawned thread. Best regards, Stefan Andersson Tribal Media AB Date: Mon, 9 Feb 2009 23:42:28 +0200 From: tommi.s.e.laukka...@gmail.com To: opensim-dev@lists.berlios.de Subject: [Opensim-dev] Setting default locale for opensim processes 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] Proposal for a cleanup/correction of the region-module system
Actaully, how would y'all feel about a simple abstraction of our own; Making an OpenSim.Framework IConfig interface of our own, that just exposes a few, simple config methods, like; TValue IConfig.SetConfigValueTValue(string key, TValue value); TValue IConfig.GetConfigValueTValue(string key, TValue default); Then for each module instantiation the core would just create a 'facade' to the right config source/section (nini or not) - that would be responsible for negotiating config sections and config source (file)name resolution. A simple and elegant solution to getting the nini ref out of the region modules. While we're at it, why don't we introduce a sibling IConfigBridge that the MODULE is optionally supposed to implement, that could provide simple config negotiation info like; string IConfigBridge.GetConfigSectionName(); string IConfigBridge.GetConfigSourceName(); Best regards, Stefan Andersson Tribal Media AB From: a...@deepthink.com.au To: homer.horw...@gmail.com; opensim-dev@lists.berlios.de Date: Sun, 25 Jan 2009 02:37:01 -0500 Subject: Re: [Opensim-dev] Proposal for a cleanup/correction of the region-module system One other suggested change. Let's remove IConfigSource from the RegionModule Initialise method - and instead make some kind of globally accessible (via Scene?) .Config. The reason for this is twofold: 1. We pass config in multiple times, one per scene. 2. It introduces a dependency on Nini that every region module must fill - this is annoying when a module isn't configurable. Regards, Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Homer Horwitz Sent: Saturday, 24 January 2009 12:04 PM To: opensim-dev@lists.berlios.de Subject: [Opensim-dev] Proposal for a cleanup/correction of the region- module system Hi all, the current system for handling region-modules is slightly broken if you add/remove regions dynamically (or even for region-restarts). I've put up some thoughts at http://opensimulator.org/wiki/New_Region_Modules for discussion. Please answer on the associated 'discussion' page or here on the list. Cheers, Homer ___ 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] Hypergrid and Interoperability workshop
Diva, sorry I couldn't attend this meeting; however, I would be able to attend one this friday, 20th if you are going to host one? Best regards, Stefan Andersson Tribal Media AB Date: Mon, 2 Feb 2009 11:58:09 -0800 From: lo...@ics.uci.edu To: opensim-dev@lists.berlios.de Subject: [Opensim-dev] Hypergrid and Interoperability workshop Hi, We're planning a first meeting to talk about defining a roadmap for Hypergrid interoperability in OpenSim worlds. The meeting will be this Friday at 10am PST. We'll meet in the UCI Grid, Gateway 7000, until it crashes :-); then we'll move to an IRC channel. Note that this is not intended to be a support group meeting about the hypergrid, so don't come with support questions. The meeting has three main objectives: 1) Taking a picture of the maximum number of foreign avatars ever assembled in one place 2) Figure out how to define a roadmap for interoperability without falling into the trap of formal working groups 3) Start talking about trust in the decentralized HG-enabled Metaverse Crista ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Please do not revert fixes without careful comtemplation
1. We have a significant number of assets whose name is blank that are created with a default constructor. And I suspect are never accessible. In fact, this field has always seemed redundant to me since the user only ever manipulates assets by their inventory name, which is entirely separate from the asset name. The asset name is never visible to the user (and afaik is not used anywhere else in the code). At one point I thought about proposing to remove it. Possibly this issue should be revisited. I believe it's kept there just as a convenience - to be able to get some kind of semantics, not necessarily exact, when browsing the table. 2. We have a significant number of assets of each and every edit of terrain, where only the very last one is accessible. Yes, this does seem wasteful to me since old terrain assets are not used by anything, afaik. I have proposed a number of times that we could have a virtual asset_key as well as an asset_id - so that things that would rewrite assets could use the asset_key as an aux method to actually try to overwrite the asset. In the terrain case, the asset would be overwritten by key, not by id. This would allow us to implement a number of parallell schemas where some assets would be overwritten (asset_key = asset_id) and some where we would keep a history (only asset_key) and some where doing either or would be configurable. 3. We have a significant number of assets of each and every text edit for each and every textual assets. Where only the last one should be accessible. Unfortunately, this is not the case. For instance, imagine that you create a script in your inventory. You drag this script into a region object. At this point, both the entry in your inventory and the entry in the region point to the same textual asset. But then you edit the script in your inventory. After the edit it points to a new asset containing the edited text. However, the region object is still pointing to the old script asset. So we need to keep both the old and new textual assets. Not to mention the fact that the viewer caches stuff. However, you're right in that textual assets which are never used elsewhere (i.e. are intermediate edits that never get dragged into an object, given to someone else, or otherwise transmitted) might possibly be eliminated with some sufficiently careful scheme. Binary de-duplication and added semantics in the form of 'key' or 'class' would probably go a long way. Its a bit like collecting every scrap of paper ever written with either text or binary glyphs and putting them in a big filing cabinet. After a while, finding the ones that are interesting in a timely manner starts to get a little challenging. Let's keep the shining torch of this discussion burning. /Stefan ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Blockers for unit testing physics modules
I just committed a fix to actually honour the 'path' in Nant and vs2005/8 targets, something that was actually not done. (Bloody hell, we need to get back to upstream prebuild.) I believe you should be able to do this now. Best regards, Stefan Andersson Tribal Media AB Date: Tue, 17 Feb 2009 18:05:04 +0200 From: tommi.s.e.laukka...@gmail.com To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Blockers for unit testing physics modules The thing with the ode tests is that instead of having them in separate test dll as with all the rest of the tests the ode tests are placed in the same dll as ode plugin. Because of this it does not need to reference the ode plugin dll which would not work. I think we should really push for improvements to prebuild as getting everything to same output directory is not very clean solution considering for example deployment of different exe files to different machines. There is also problem of not being able to clean the bin directory as it permanently contains dll dependencies and even runtime data. In practice I think it is a good pattern that the bin directory is completely emptied on build clean. It would be also nice to be able to build different exe files to their own distribution folders. These last two as a long term goals to consider. regards, Tommi On Tue, Feb 17, 2009 at 4:29 PM, Teravus Ovares tera...@gmail.com wrote: Stefan, No, this doesn't work. We've tried all sorts of ways to do that. But, there is a solution that we're already using for this very problem with bamboo. Simply copy the physics assembly to bin when running the tests. As I said, bamboo already does this. The test harness is currently in the odeplugin assembly and gets run successfully. Best Regards Teravus On Tue, Feb 17, 2009 at 6:24 AM, Stefan Andersson ste...@tribalmedia.se wrote: You should be able to specify a 'path' attribute on the prebuild reference element. Reference name=Test localCopy=false path=../../Whatever/Dir/Test.dll / If that doesn't work, let me know and I'll have a look at a solution. (Sorry for the late reply) Best regards, Stefan Andersson Tribal Media AB Date: Mon, 9 Feb 2009 20:54:33 +0200 From: tommi.s.e.laukka...@gmail.com To: opensim-dev@lists.berlios.de Subject: [Opensim-dev] Blockers for unit testing physics modules 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 ___ 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] 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] Avatar movement packet optimization
I do agree with you. I think that the important thing here is that the patch creator and applier both think carefully about the situation when private members are being made protected. Of course. One advantage of private members is that they tend to make debugging and reasoning about code considerably easier. For instance, if I know no other code can call a particular method because it is private, then that means I don't need to hunt down references or reason about possible interactions between different callers. However, these arguments are stronger, I think, when fields are public rather than protected (I have spent too much time trying to unpick interactions with Scene where callers were directly manipulating public fields where this was not desirable or necessary). You make a very good point; I actually was going to write that for example functions that are extracted to add semantic information normally should be kept private (and does not really need to be separately tested) since they are conceptually still a part of another context; then again, if any derived code would see fit to use those methods, I would have a hard time accepting a 'no'. And regarding 'public', one of my pet decoupling strategies is just to turn stuff that is public to protected and see what breaks, then have a really hard think about why the 'breakee' needs public access. Another one is to encapsulate a public field in a getter-only property and see what breaks. Those two excercises can be very enlightening. If I have recieved no strong objections, I will add this to the code conventions by friday 20/2 2009. Well, you know, I was just idly agreeing with you :) But it would be good to have such things in the code conventions. Yeah, I'm just jumping at the occasion. ;-D Btw, I suggested a 'commit recipe' a while ago, I think I'll add that as well. /Stefan ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] [Opensim-users] User Server issues with 8236
Guys, we (Tribal) have seen this behaviour since a couple of months back; our hypthesis is that there's something wrong with the mono-addins lib, possibly in conjunction with old dlls. The symptom is that the database modules just don't load, and with no error, and since the db logic is a foreach(plugin) over an empty plugin set, nothing happens. Usually, a clean checkout, rebuild and copying over only of data files will remedy the whole thing. Make sure not to copy over into an old directory - a total wipe and rebuild is necessary. Best regards, Stefan Andersson Tribal Media AB From: lordofpleas...@pleasureplanet.net To: opensim-us...@lists.berlios.de Date: Fri, 13 Feb 2009 09:18:59 -0800 Subject: [Opensim-users] User Server issues with 8236 I tried a full build letting the OS regenerate the XML and I did a copy paste with the xml files. No good either way. It seems to just not be executing the connection to the Mysql database. Here's what I get when I run the 8236 user server 10:07:04 - Launching UserServer... 10:07:04 - [STARTUP]: Beginning startup processing 10:07:04 - [STARTUP]: Version: OpenSimulator Server 0.6.2.8236 10:07:04 - [STARTUP]: Establishing data connection 10:07:04 - [PLUGINS]: Initializing addin manager 10:07:06 - [PLUGINS]: Loading extension point /OpenSim/UserData 10:07:06 - [GridInfoService]: Grid info service initialized with 11 keys 10:07:06 - [LIBRARY INVENTORY]: Loading library control file .\inventory\Librari es.xml 10:07:06 - [STARTUP]: Starting HTTP process 10:07:06 - [GRID]: Login Level set to 0 10:07:06 - [HTTPD]: Starting up HTTP Server 10:07:06 - [HTTPD]: Spawned main thread OK 10:07:06 - [STARTUP]: Startup took 0m 1s Enter help for a list of commands User# : Here's what I get when I run the 8131 User Server 10:08:54 - Launching UserServer... 10:08:54 - [STARTUP]: Beginning startup processing 10:08:54 - [STARTUP]: Version: OpenSimulator Server 0.6.2.8131 10:08:54 - [STARTUP]: Establishing data connection 10:08:54 - [PLUGINS]: Initializing addin manager 10:08:57 - [PLUGINS]: Loading extension point /OpenSim/UserData 10:08:57 - [PLUGINS]: Trying plugin /OpenSim/UserData/NHibernateUserData 10:08:57 - [PLUGINS]: Trying plugin /OpenSim/UserData/SQLiteUserData 10:08:57 - [PLUGINS]: Trying plugin /OpenSim/UserData/MySQLUserData 10:08:57 - [PLUGINS]: Plugin Loaded: OpenSim.Data.MySQL 10:08:57 - [PLUGINS]: Trying plugin /OpenSim/UserData/MSSQLUserData 10:08:58 - [MYSQL]: Connection established 10:08:58 - [REGION DB]: Connection wait timeout 28860 seconds 10:08:58 - Creating 10 DB connections... 10:08:58 - Connecting to DB... [0]: 10:08:58 - [MYSQL]: Connection established 10:08:58 - [REGION DB]: Connection wait timeout 28860 seconds 10:08:58 - Connecting to DB... [1]: 10:08:58 - [MYSQL]: Connection established 10:08:58 - [REGION DB]: Connection wait timeout 28860 seconds 10:08:58 - Connecting to DB... [2]: 10:08:58 - [MYSQL]: Connection established 10:08:58 - [REGION DB]: Connection wait timeout 28860 seconds 10:08:58 - Connecting to DB... [3]: 10:08:58 - [MYSQL]: Connection established 10:08:58 - [REGION DB]: Connection wait timeout 28860 seconds 10:08:58 - Connecting to DB... [4]: 10:08:58 - [MYSQL]: Connection established 10:08:58 - [REGION DB]: Connection wait timeout 28860 seconds 10:08:58 - Connecting to DB... [5]: 10:08:58 - [MYSQL]: Connection established 10:08:58 - [REGION DB]: Connection wait timeout 28860 seconds 10:08:58 - Connecting to DB... [6]: 10:08:58 - [MYSQL]: Connection established 10:08:58 - [REGION DB]: Connection wait timeout 28860 seconds 10:08:58 - Connecting to DB... [7]: 10:08:58 - [MYSQL]: Connection established 10:08:58 - [REGION DB]: Connection wait timeout 28860 seconds 10:08:58 - Connecting to DB... [8]: 10:08:58 - [MYSQL]: Connection established 10:08:58 - [REGION DB]: Connection wait timeout 28860 seconds 10:08:58 - Connecting to DB... [9]: 10:08:58 - [MYSQL]: Connection established 10:08:58 - [REGION DB]: Connection wait timeout 28860 seconds 10:08:58 - [MIGRATIONS]: UserStore up to date, no migrations to apply 10:08:58 - [GridInfoService]: Grid info service initialized with 11 keys 10:08:58 - [LIBRARY INVENTORY]: Loading library control file .\inventory\Librari es.xml 10:08:58 - [STARTUP]: Starting HTTP process 10:08:58 - [GRID]: Login Level set to 0 10:08:58 - [HTTPD]: Starting up HTTP Server 10:08:58 - [HTTPD]: Spawned main thread OK 10:08:58 - [STARTUP]: Startup took 0m 4s Enter help for a list of commands For some reason it seems the MySql connection just isn't being called. Here's the .xml for the user server. Root Config default_startup_message=Welcome to Pleasure Planet default_grid_server=http://64.150.177.108:8001/; grid_send_key=1234 grid_recv_key=1234 default_inventory_server=http://64.150.177.108:8004/; library_location=.\inventory\Libraries.xml database_provider=OpenSim.Data.MySQL.dll
[Opensim-dev] Refactoring the backend codepaths
Esteemed colleagues, friends, lovers; I have taken upon me to embark on an long and arduous journey; to try to refactor the mess that is called 'LoginService' - and in the process probably touch on quite a lot of the backend codepath messiness. The general idea is to eliminate duplication by abstracting the architecture into 'service proxies', 'service implementations', 'model managers' and 'service interfaces'. This will be done in babysteps, over a long time - my goal is to never do any big restructuring, but merely work with my trusty refactoring tools, and as fast as time permits. This said, the current tangliness may cause me to break something in some code path; if so, I beg your forgiveness and support in rectifying the situation. Now, at this very moment, I have but one question upon my mind; pray answer it if you are among the wise - why is RegionProfileData marked as Serializable - what is serializing it? Thank you for your time, effort, support and understanding. Best regards, Stefan Andersson Tribal Media AB ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Organization and naming patterns of commands on the console
Well, I don't mean anything that advanced; It just struck me that commands could just as well contain spaces. Best regards,Stefan AnderssonTribal Media AB Date: Thu, 5 Feb 2009 10:53:26 -0800From: dahliatrim...@gmail.comto: opensim-...@lists.berlios.desubject: Re: [Opensim-dev] Organization and naming patterns of commands on the consoleI always liked a feature often seen on some older unix terminal based programs, like some curses based IRC clients, where just typing enough characters of a command to resolve any ambiguity would give you the complete command, and where the help section is nicely organized. It sounds to be like that may be what you are describing? Another issue I find, not sure if it's related or not, is the inability to use the backspace key in the OpenSim console while running on various linux distributions. I don't know where this is coming from, but I wonder if it's something OpenSim could control? On Thu, Feb 5, 2009 at 10:28 AM, Stefan Andersson ste...@tribalmedia.se wrote: Just chipping in my 2c: How about the modules are supposed to register the 'command' whatever that is, but that the 'command' can include spaces? So, create user should be a valid command, sending the remainder to that region (via the registered delegate). which means another module can register create region but not create user, as that would have already been registered. Of course, it cannot register a non-character terminated subset either, like simply create. the command parser would simply run thru the list, doing a 'starts with characters' match, probably with a non-character terminator in the regexp. (If you're really anal on performance, the whole list of matches can be concatenated into a regexp and compiled once) Of course, you would have to register help create user as well, but it seems to me that there could be an abstract base class providing some protected generative helper functions. (To either create and register verb+ +noun and/or noun+ +verb, and the corresponding help text in one go)This seems like the most flexible approach to me, as it poses no limitations on what commands makes the most sense for each context.Best regards,Stefan AnderssonTribal Media AB Date: Thu, 5 Feb 2009 18:30:25 +0100 From: drscofi...@xyzzyxyzzy.net To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Organization and naming patterns of commands on the console Justin Clark-Casey wrote: Ai Austin wrote: Any chance we can have the verb first, as this is much more intuitive? E.g. create user create region i prefer addressing the entity that is supposed to do something first (to get it's attention, so to speak), then tell it what to do: region create user create user reset password that approach also has the advantage that it's up to the module what vocabulary to support. -- 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 listopensim-...@lists.berlios.dehttps://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] AssetBase and metadata
Hm, thinking a bit more about it, I guess you have a very good point there; of course, you could let there be an 'virtual' inventory item (with the assetId as the inventoryId) that translates to the asset itself - and that would have some special way of determining permissions. That said, I'd much rather do something like separating out the 'permissions' bit in inventory and have that mean 'asset permissions for the trust domain' - you can still operate on the permissions in the same manner, and the net result will be the same, I guess. In other words; instead of having restricted inventory and full access assets, I'd rather say you had full access inventory and restricted assets, if that is any the least clearer? If you strip out permissions and type from inventory, the only thing left is name, owner and some data - and the inventory has most oftenly a pretty straightforward perms set (only let owner see and change on trusted regions) while assets parms can vary wildly with application. Best regards,Stefan AnderssonTribal Media AB Date: Mon, 2 Feb 2009 08:24:52 -0500 From: tera...@gmail.com To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] AssetBase and metadata To the 'all assets have inventory items associated with them', no, they don't, however, there's no harm in requesting the inventory item where possible. It would limit the UUIDs that systems would have access to as a reference, as well. I'm sure that there will be some methods that must use Asset ID. Mostly, images. I suppose object inventory might use Asset ID also, but probably does not have to until they're requested by the client for editing. To the 'So I guess I don't understand what specific case you're referring to?', See last Tuesday's Zero meeting for several references to the pitfalls of Hypergrid (and it's not just Zero saying things to criticize it. It's our users as well. That was a widely positive meeting towards Hypergrid to the detriment of LLOGP. Mingled within that, the way we handle property was the main criticism. Reference: http://wiki.secondlife.com/wiki/User:Zero_Linden/Office_Hours/2009_Jan_27 I was saying that currently, we're doing nothing at all to limit trust. If we maintain this approach, it will be a big factor in other, non-currently-codified, standards being adopted and It'll likely be impossible to fully implement other 'permissioned' standards without some way to check the permissions first (such as OGP). Currently, directly requesting Assets precludes this option. Not all virtual worlds will have 'Property', but the ones that do will suffer. Comparing to a web server, think .htaccess. Best Regards Teravus On 2/2/09, Stefan Andersson ste...@tribalmedia.se wrote: Are we sure all assets have inventory items associated with them? I can think of scripted objects that set textureIds programatically. (Melanie pointed that out to me) You can also have the case where you upload a texture (yes, it's in inventory) apply it to a shirt, then delete the original inventory item (the asset is still referenced from within the shirt asset, but is in no inventory) So I guess I don't understand what specific case you're referring to? Best regards, Stefan Andersson Tribal Media AB Date: Sun, 1 Feb 2009 23:58:55 -0500 From: tera...@gmail.com To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] AssetBase and metadata Is there any reason that we don't request items from the asset server internally by the inventory UUID instead of the asset UUID? Requesting assets by inventory UUID would make it a LOT simpler to apply permissions at the trusted service level instead of at the simulator level. Best Regards Teravus On 2/1/09, Mike Mazur mma...@gmail.com wrote:Hi, On Fri, 30 Jan 2009 07:37:27 -0500Sean Dague sda...@gmail.com wrote: It's fine for the object to be called AssetMetaData, just don't make the property that. On Fri, 30 Jan 2009 14:51:12 + (GMT)MW michaelwr...@yahoo.co.uk wrote:I agree, I'd say call the class AssetMetaData, but just call the property (in AssetBase) MetaData. Makes perfect sense. Thanks for the feedback. Mike ___Opensim-dev mailing listOpensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev___ Opensim
Re: [Opensim-dev] asset_database = local or grid?
I believe the general concensus was to support all three (four?) asset server configs (internal, local, grid, hg(?)) but refactor the code paths. While I do understand the confusion, I have already shown how we could re-arrange the services so that we get a uniform set of interfaces - ideally, the config option should turn from specifying a mode to specifying a module and its config. Best regards,Stefan AnderssonTribal Media AB Date: Sun, 1 Feb 2009 22:29:18 + From: mela...@t-data.com To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] asset_database = local or grid? Hi, funny you would suggest that. That is one of the code paths I suggested removing a long time ago, and was booed and rejected. Melanie Justin Clark-Casey wrote: Chris Hart wrote: Setting asset_database to local will store your assets in a .db sqlite database on your file system, and not in MySQL at all. If you run in grid mode, you should always set this to grid to avoid confusion unless you are connecting to someone else's grid and want your assets to be stored locally and not on their asset server. I have to say I made that same mistake when first starting out with opensim and had to migrate all my assets over to my database server. Several others have made the same mistake and I've had to help them to migrate their assets too - is the local storage model really that widely used? Should it actually be the default? For standalone I'm guessing it is ignored(?), but in grid mode I've found it just causes pain and confusion.Chris is right - I find the asset_database switch annoying because it catches me out on occasion.The problem with using local assets on a grid is one of grid asset blakanization - people coming to your region can't see your assets (because their requests go to the grid asset service rather than your local asset store) and when you go to other people's regions you can't rez objects you created on your local region.But it strikes me that now, if you wanted to retain your regions assets locally, you could set up your region as a hypergrid enabled region, as Hypergrid regions use the local asset store (there is conceptually no global).In view of this, I'd like to completely remove the asset_database option. This would mean that in standalone and hypergrid modes, the db used would always be local and in grid mode the grid asset service would always be used.Are there any objections to this? Chris / Strawberry Fride-Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Ai Austin Sent: 01 February 2009 17:12 To: opensim-dev@lists.berlios.de Subject: [Opensim-dev] asset_database = local or grid?I have MySQL running on the same system that the UGAIM servers are running on at the moment, though we want to separate some of them out...I am wondering if I set asset_database = grid rather than asset_database = local is there any performance penalty... or will it run identically if the assets are in fact local anyway?___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-devNo virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.0.233 / Virus Database: 270.10.16/1926 - Release Date: 01/30/09 17:31:00 ___ 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] proposal: cleanup and break up region modules
I think that some confusion stems from the fact that it's a difference between referencing the assembly, and dynamically instancing classes out of it. If you reference classes directly, as in mything = new Thing(); where thing could be a module, albeit _referenced_, not _loaded_ is a huge difference to mything = loadedAssembly.Instantiate( Thing ); in the former, the jit compiler can do all kinds of neat optimizations when referencing classes in the Assembly, since it has both the referenced component and the referrer at hand. It can also inline and optimize away type validity checks and trusted domain checks. In the latter, it really can't, and need to wrap everything in prudent encapsulation, protection and indirection. Optimization points aside, I would hate for us to expand the core modules into separate projects just because we can; I think we would have to add 20 more projects to the solution and that would just suck - especially now that we have cleaned out so many. Some of the these new projects will have just a handful of classes, which is just an absurd waste of resources for something that should be used in 95% of the setups. I actually don't know how mono addins work, but in the .net framework individual classes are referenced by assembly and class if loaded at runtime, so for examble authModule= MyAuthLib.dll, MyAuthenticator would reference the class MyAuthenticator in the dll MyAuthLib.dll - which means that you can lump as many of those together in an dll that you want to. so we should make sure we can do something liket that, and instead try to lump modules that share a common domain together. The only two reasons to ever split an assembly into two is from * references being too different (if you want to re-use them separately) * encapsulation and security issues (actuallly USING internal as it was intended) So, what I'm saying is that we should strive towards a situation where the core modules are bundled into a minimal set of assemblies, and the rest put on forge. Best regards,Stefan AnderssonTribal Media AB Date: Thu, 29 Jan 2009 11:28:19 +0100 From: drscofi...@xyzzyxyzzy.net To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] proposal: cleanup and break up region modules Tleiades Lauridsen wrote: Date: Thu, 29 Jan 2009 08:31:48 +0100 From: drscofi...@xyzzyxyzzy.net To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] proposal: cleanup and break up region modules Tleiades wrote: I'd be much more of a fan of having each module a seperate dll. Files are cheap too. :) And that makes it very clear to people what they are loading, and what they aren't loading. (On the fear of talking about performance prematurely) Won't that cause problems for the JIT'er? Normally access to member variables gets optimized away into a direct memory access rather than invocation of a JSR. If I recall correctly this optimization does not work for dynamically loaded assemblies. well, if that's the case, then it's not working currently either :-) currently we lump all region modules into one large super DLL and load that dynamically.I guess what I'm saying is that dll files are not as cheap as it is being implied. Having an application dynamicallly load a large number of dll's at runtime, is less efficient that loading a few large dll's during load time. The JIT'ed code will be less efficient and loadtime of the application will increase. While load time may not be a big issue, I believe it is best to give the JIT engine the best working condition. we are always loading at runtime --- or let me ask the other way round: what do you define as loadtime? As I understand it the JIT engine and assembly loader have been designed based on a use pattern which states: Most assemblies will be loaded during application load time, and only few assemblies will be loaded at a latter stage, well, we are loading at runtime then. -- 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
[Opensim-dev] Proposal: Removal of the Data Framework
As I understand it, we have no longer anything actually using the Data Mapper Framework introduced as a proposed alterantive to NHibernate a year ago. I propose we now retire that piece of code. These are the projects that will be removed: * OpenSim.Data.MySQLMapper * OpenSim.Data.MSSQLMapper * OpenSim.Data.Base In OpenSim.Data, the following classes would be removed: * OpenSimDatabaseConnector.cs * OpenSimDataReader.cs * OpenSimObjectFieldMapper.cs* PrimitiveBaseShapeTableMapper.cs Also, the AvatarFactoryModule erroneously still references these namespaces, but that's a minor fix. If nobody has a strong objection, I will start removing these files Feb 2 2009. Best regards,Stefan AnderssonTribal Media AB___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Proposal: Killing off AvatarFactory
Argh. s/Jan/Feb/ Best regards,Stefan AnderssonTribal Media AB Date: Mon, 26 Jan 2009 09:54:12 +From: michaelwr...@yahoo.co.ukto: opensim-...@lists.berlios.desubject: Re: [Opensim-dev] Proposal: Killing off AvatarFactoryMy preference is that we modulariSe the whole avatar creation, its much more flexible. Also on that subject I suggest we move the server side avatar data from the user server to one of the other servers (most likely the inventory server). I don't think it should be in the user server for a number of reasons. But one reason we have came across is wanting to share a single user server with multiple grids. I think the user server really should just be account infomation.But anyway back onto the AvatarFactoryModule, yes if we aren't going to modularise it then we should just move it all to IAvatarService. No point in having the current half way solution.Also I think the process should even a more general, start modularising the whole of the CommsManager.But not sure anyone is going to be able to give a +1 or -1 on any idea before Jan 2 2009 ;)Stefan Andersson ste...@tribalmedia.se wrote: It's kind of crazy that we have a RegionModule (AvatarFactoryModule) that really just look up the CommsManager AvatarService and forwards a request to that.I propose we either modularize the whole thing (the prefferrable thing) or merge the AvatarFactory module code into the IAvatarService. If nobody has objected strongly until Jan 2 2009, I will mantis this.Best regards,Stefan AnderssonTribal Media AB___Opensim-dev mailing listopensim-...@lists.berlios.dehttps://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] Proposal for a cleanup/correction of the region-module system
Ok, so I suggest we establish an 0.7 roadmap page. With that one as a 'definite', not a 'discussion'.Best regards,Stefan AnderssonTribal Media AB Date: Sun, 25 Jan 2009 15:27:29 -0500 From: sda...@gmail.com To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Proposal for a cleanup/correction of the region-module system MW wrote: actually should we wait a while and get more reaction. As this is going to effect anyone who has a module that isn't in trunk. Seems a lot of hasle for such a small thing. Would seem better to wait and make the change when/if we change to homer's new module interface. Yes, agreed. I'll both wait for reactions, and wait for Homer's work, to minimize the number of times we break things. I think normalizing that would make sense prior to 0.7, just to give us some more consistency. I know every time I walk someone new through parts of the code there is a lot of head scratching over the inconsistency. For those of us that have been here a long time, we are used to it. From the outside it looks like we are all just a bunch of crazies... which may or may not be true, but I'd rather not get the reputation from method naming. :) -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] Hooking in Scene.EventManager
One might add that if you want to hook into grabs of a small set of specific objects, you should probably look into patching the sceneobjects up with event hooks, and then use those. There _are_ OnGrab functions, but afaik there's no events firing in them, which there should be, really.Best regards,Stefan AnderssonTribal Media AB Date: Wed, 21 Jan 2009 21:13:12 +From: garrett.hus...@gmail.comto: opensim-...@lists.berlios.desubject: Re: [Opensim-dev] Hooking in Scene.EventManager Great stuff - thanks for your help Diva Cheers Garrett 2009/1/21 Diva Canto d...@metaverseink.com Yep, that's it.Those events are there for being used.When writing region modules just keep in mind that your region module code runs natively with the core code; if you mess up, the core behavior may get messed up too. So, for example, if your module adds significant delays in processing an event, it may interfere with the normal OpenSim operation. So be smart with your region modules :-) Garrett Hussey wrote: Hi, sorry - I should have elaborated a bit more. At the moment the EventManager exposes a number of events. I want to do the following in my region module ... // TEST TEST SET m_scene.EventManager.OnObjectGrab += new EventManager.ObjectGrabDelegate(MYObjectGrabDelegate); So my module with get notified of every object grab event in the scene. So my question is - is this a good/reasonable way to trap every objectgrab event in the scene or is there another mechanism I should be using? Thanks again Garrett 2009/1/21 Diva Canto d...@metaverseink.com Which ones do you need that aren't there?Garrett Hussey wrote: Hi, I'm playing around with my own region module and was wondering ifs its reasonable/sane, good/bad practise to add extra event handlers to the Scene.EventManager and handle the events in my region module ? Thanks Garrett ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___Opensim-dev mailing listopensim-...@lists.berlios.dehttps://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 listopensim-...@lists.berlios.dehttps://lists.berlios.de/mailman/listinfo/opensim-dev___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
