Re: [Opensim-dev] Rev 8957 PIDFile
Sacha Magne wrote: > Thanks for that one Melanie :) > > One good usecase could be "monit" managment system > > http://mmonit.com/monit/ ... i'd augment that however with doing a REST call periodically to test whether OpenSim is really still alive and not stuck... cheers DrS > > Anywa, Thanks :) > > Sacha > > On Thu, Apr 2, 2009 at 2:16 AM, Melanie <mailto:mela...@t-data.com>> wrote: > > Yes, that is what it is. A text file containing the unix PID > > Melanie > > Ralf Haifisch wrote: > > Hi Melanie, > > > > > > > > this is a pidfile in the unix sense ? > > > > > > > > so one can use unixtools on pidfiles ? > > > > > > > > cheers, > > > > Ralf > > > > > > > > > > > > > > > > > > > > > > > ___ > > Opensim-dev mailing list > > Opensim-dev@lists.berlios.de <mailto:Opensim-dev@lists.berlios.de> > > https://lists.berlios.de/mailman/listinfo/opensim-dev > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de <mailto:Opensim-dev@lists.berlios.de> > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > > -- > > http://K-grid.com > Just be cause it's Kool > > > -------- > > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] [Opensim-commits] r9036 - in trunk/OpenSim
Mikko Pallari wrote:
> Hi,
>
> Was there some particular reason why the OpenSim.32BitLaunch.csproj was
> removed from trunk? It has been previously found very useful:
> http://teddmaa.blogspot.com/2008/12/opensim-in-visual-studio-on-win64.html
>
as alan said, no, there wasn't aside from me doing a lousy job checking the
commit --- i assumed that *.csproj files were generated as part of prebuild (and
that the commit from alan was merely cleaning up stuff), should have checked
instead of just assumed, i apologize for causing inconvenience/pain.
DrS/dirk
> Cheers,
> Mikko
>
> -Original Message-
> From: opensim-commits-boun...@lists.berlios.de
> [mailto:opensim-commits-boun...@lists.berlios.de] On Behalf Of
> drscofi...@opensimulator.org
> Sent: 7. huhtikuuta 2009 19:54
> To: opensim-comm...@lists.berlios.de
> Subject: [Opensim-commits] r9036 - in trunk/OpenSim:
> Region/OptionalModules/Avatar/Chat Tools/OpenSim.32BitLaunch
> Tools/OpenSim.GridLaunch
>
> Author: drscofield
> Date: 2009-04-07 09:53:41 -0700 (Tue, 07 Apr 2009)
> New Revision: 9036
>
> Removed:
>trunk/OpenSim/Tools/OpenSim.32BitLaunch/OpenSim.32BitLaunch.csproj
>trunk/OpenSim/Tools/OpenSim.GridLaunch/OpenSim.GridLaunch.csproj
> Modified:
>trunk/OpenSim/Region/OptionalModules/Avatar/Chat/IRCBridgeModule.cs
> Log:
> From: Alan Webb
>
> Fix null reference exception during close down of IRC module if the
> region was not actually initialized.
>
> Modified: trunk/OpenSim/Region/OptionalModules/Avatar/Chat/IRCBridgeModule.cs
> ===
> --- trunk/OpenSim/Region/OptionalModules/Avatar/Chat/IRCBridgeModule.cs
> 2009-04-07 16:41:07 UTC (rev 9035)
> +++ trunk/OpenSim/Region/OptionalModules/Avatar/Chat/IRCBridgeModule.cs
> 2009-04-07 16:53:41 UTC (rev 9036)
> @@ -148,8 +148,16 @@
> if (!enabled)
> return;
>
> +if (region == null)
> +return;
> +
> region.Close();
> -lock (m_regions) m_regions.Remove(region);
> +
> +if(m_regions.Contains(region))
> +{
> +lock (m_regions) m_regions.Remove(region);
> +}
> +
> }
>
> #endregion
>
> ___
> Opensim-commits mailing list
> opensim-comm...@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-commits
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
--
dr dirk husemann virtual worlds research ibm zurich research lab
SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/
RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] remote admin
Ralf Haifisch wrote: > Heho, > > > > > > Is there any way to save an oar using the remote admin plugin ? yes. admin_save_oar (see RemoteAdminPlugin for usage). cheers, DrS/dirk > > > > I only know of loading a oar… > > > > > > If not, any plans for an extension like that ? > > > > > > What about the module that was around some time to do those operations > from the browser ? (wich would be very nice..) > > > > > > > > Cheers, > > Ralf > > > > > > > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Ruth vs Gas Clouds: Bug or feature?
Arthur Valadares wrote: > Hi everyone.. > > I've been looking into a "bug" where if you get a brand new avatar and > create pants, shirt, shape and skin and wear all of them, you turn into > a gas cloud. After lot's of research, it seems this is "kind of" > expected behavior. Let me try to explain what I think is happening. > > After SL Viewer 1.20, Ruth no longer existed. If you took off all > wearables, you would now become a cloud of gas. Apparently, the viewer > thinks that if you use all those 4 wearables without changing anything, > you have become Ruth, and so you should now be a cloud of gas. If you > make the 4 wearables, but change ANY parameter, you no longer become a > cloud of gas . The thing is on OpenSim you start as Ruth, and not as a > cloud of gas! Which is kind of confusing that the viewer thinks you > become Ruth when you're actually trying not to. excellent work finding this out, arthur! DrS/dirk -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] voice meetings
Mike Dickson wrote: The only obvious problem to voice for some of these conversations is that if you're not there at the time it happens you lose out. No way to archive them (easily) for historical purposes or simply for those who can't contribute at the time the conversation happens. Since in many cases these are design discussions I think there's benefit to that record. freeswitch can record/stream MP3... Of course there's a way around that. If you do a voice meeting just publish notes from the discussion. That will help to foster communication and increase the level of participation rather than be exclusionary. In that scenarios its a win-win for everyone. Mike On Sat, 2009-05-16 at 18:23 +, Charles Krinke wrote: Indeed, discussing these subjects with those on the opensim-dev mailing list in voice or text is to all of our mutual advantage. Many folks have complained to me of the way the money issue was handled and communication with the rest of the community is important to moving forward and helping credibility. Charles ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- dr dirk husemann math & computer science ibm zurich research lab RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ SL: drscofi...@xyzzyxyzzy.net - http://xyzzyxyzzy.net/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] breaking OpenSim.ini changes
Melanie wrote: > Charles, > > I develop out in the open, commit early and often. Most of these > past 100 commits were not meant to be used by anyone but myself and > Diva. It's a work in progress in a work area and documentation would > have been premature. IMHO that is way too many commits that are not meant to be used by anyone but yourself and diva --- coupled with "stay clear of that, we are going to change it big time" you effectively closing out others who might be working in the same area. IMHO a better way of dealing with this is to document upfront (at least roughly) where you intend to take the code to or else work in branch and do less frequent code drops from there. -- dr dirk husemann virtual worlds research ---- ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] breaking OpenSim.ini changes
Melanie wrote: > So you say I should spend hours on documentation which I already > KNOW it will be obsolete within days? > > That _is_ just what big corps do. 20% dev time, 80% doc time. nonsense. opensource projects have to have reasonably good communication. an email, a wiki entry just outlining where you want to take the code to, should really not take that much time. -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] breaking OpenSim.ini changes
Melanie wrote: > MW pretty much reached the conclusion never to use a branch again. > It was stated that trunk is a developers' WORK area. well, could it be because of a lack of communication going on, effectively steam rolling MW? > > It is not meant to be usable all the time. The only requirement is > that it compiles. > > People who want stable should use stable. I think demands that trunk > remain usable sets a bad precedent. i don't really believe you want to turn trunk into sandbox, do you? dirk -- dr dirk husemann virtual worlds research ---- ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Region Startup & Sculpt Meshing Asset Retreival
Dahlia Trimble wrote: > I asked Nebadon to post this to the list to generate discussion. It's > not clear to me when the appropriate time would be to allow logins to a > region. Meshing and script loading are not confined to startup, they can > happen at any time when a region is running and prims and scripts are > rezzed or edited. It would seem that something in the scene would know > the appropriate time, but many of the processes related to scene loading > are asynchronous such as sculpt meshing, which is (currently) dependent > on asset deliveries. > > Could we list some of the observations surrounding this issue? What > happens when people log in before the region is fully loaded? Can these > problems be mitigated, or should logins and region entry be denied until > some pre-programmed decision can be made? Are there current safeguards > in place now that may have been rendered ineffective by past code revisions? we have been using the RegionReady region module to be notified of all scripts being ready and running (it sends out a message on the configurable region ready channel). not sure whether that could be extended to the sculpted prim stuff. one idea i had (being faced by a similar issue as nebadon) was to use that RegionReady signal (or the event it itself is using) to enable logins. dirk > > -dahlia > > > On Thu, May 28, 2009 at 10:41 PM, Nebadon Izumi <mailto:nebadon2...@gmail.com>> wrote: > > At the request of dahlia, I am starting this thread to discuss > Region startup, I would 1st like to bring attention to the feature > request that i filed on this topic > > http://opensimulator.org/features/issue.php?id=45 > > What is happening is for many minutes after the [Startup Complete] > message is displayed, startup is still going and not actually > finished, if an avatar logs in during this time it results in a hung > viewer that never loads. This can be pretty frustrating if your > debuging and testing all day because the only way to really know > when the sculpt retreival and decoding of sculpties prior to the > meshing of these assets can take a really long time, and just as a > note and for dahlias sake this is not a meshing issue, its unrelated > to the mesher itself other than its the process that occurs prior to > the meshing so meshing can be completed. anyway this is not really > the issue, the issue is that the region is not actually started and > we are making a claim on the console that is has, I would be great > if we could work something out that the startup complete message and > logins are disabled until not only the full pre-meshing sculpty > retreival / scripting and the meshing itself are complete, because > in reality until these all finish, the sim is not actually started > and ready, and if enough people log in during this window it can > result in scripting errors and simulator crashing in addition to > hung viewers. Please lets discuss methods on how we can perhaps > correct this and make the opensimulator experience better. Thanks > -- > Michael Emory Cerquoni - Nebadon Izumi @ http://osgrid.org > > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de <mailto:Opensim-dev@lists.berlios.de> > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > > > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Is the message "Please wait 5 minutes" still needed?
Frisby, Adam wrote: Make it standard. +1 +1, since the potential other session is kicked anyhow already... Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Arthur Valadares Sent: Friday, 29 May 2009 2:59 PM To: OpenSim-Dev Subject: [Opensim-dev] Is the message "Please wait 5 minutes" still needed? Hi everyone, I wanted to consult you all about this matter, even though I have already committed some related code. I will gladly change it if we decide to do things differently. Once upon a time, there seemed to be a necessity that you had to wait 5 minutes if you crashed and tried to log back in. Those were the days before my time, tales that the elder tells us by the fireside. After these days, when I started messing around with OpenSim, there was a bug that would kick you after a few minutes if you tried to log back on without waiting. This was also fixed (thanks Crista!), which leads me to my question. Why are we still getting this message? Well, the only purpose I can think of is it warns you that you either crashed last time or that someone is using your account. Either way, something went wrong and the user might want to know that. So the code I committed puts an option in standalone that allows you to skip this message and just let OpenSim kick the old user and connect the new one, kind of like what happens in messengers if you logon from a different location. This is very useful when you have softwares that encapsulate the login process and doesn't want to leave the user looking at the viewer's login page with a failed message. So, should this become standard and just skip and kick, or should we leave it up to configuration? Opinions please.. -- Arthur Valadares ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- dr dirk husemann math & computer science ibm zurich research lab RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ SL: drscofi...@xyzzyxyzzy.net - http://xyzzyxyzzy.net/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Web login
Olli Aro wrote: > Hi all, > > > > I am trying to implement web login for OpenSim. > > > > I have added appropriate web login key in the database for the user and > then tried both of the following redirect both inside and outside the > viewer: > > > > secondlife:///app/login?first_name= > *firstname*&last_name=*lastname*&location= > &grid=&web_login_key=*LLUUID * > > * * > > about:blank?redirect-http-hack=secondlife:///app/login?first_name= > *firstname*&last_name=*lastname*&location= > &grid=&web_login_key=*LLUUID * > > > > but viewer comes back all cases saying authentication failed. hmm...are you sure that the recent viewers do support weblogin? as far as i know (but that might be outdated already) weblogin was disabled a short while after it got introduced (apparently lindens had problems getting it to work reliably). DrS > > > > Could someone confirm if the web login should work and also give me > indication on correct way to implement? > > > > Regards, > > > > Olli > > > > > > > > > > > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Web login
Olli Aro wrote: > > -Original Message- > From: opensim-dev-boun...@lists.berlios.de > [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Dr Scofield > Sent: 11 June 2009 15:47 > To: opensim-dev@lists.berlios.de > Subject: Re: [Opensim-dev] Web login > > > Olli Aro wrote: >> Hi all, >> >> >> >> I am trying to implement web login for OpenSim. >> >> >> >> I have added appropriate web login key in the database for the user and >> then tried both of the following redirect both inside and outside the >> viewer: >> >> >> >> secondlife:///app/login?first_name= >> > *firstname*&last_name=*lastname*&locatio > n= >> &grid=&web_login_key=*LLUUID * >> >> * * >> >> about:blank?redirect-http-hack=secondlife:///app/login?first_name= >> > *firstname*&last_name=*lastname*&locatio > n= >> &grid=&web_login_key=*LLUUID * >> >> >> >> but viewer comes back all cases saying authentication failed. > > hmm...are you sure that the recent viewers do support weblogin? as far as i > know > (but that might be outdated already) weblogin was disabled a short while > after > it got introduced (apparently lindens had problems getting it to work > reliably). > > > DrS > > [[Olli Aro Wrote]] > > Not sure at all. If it does not support web login, do I need to hack OpenSim > authentication mechanism in order to get it working or is there some other > options? I am trying to integrate OpenSim with a SSO framework, so need an > authentication that let's person in without password, since the > authentication has already happened previously. the SL client would need to be fixed. BUT --- before looking at the SL client code, consider that you then cannot contribute code back to OpenSim for the next 6 months (IIRC). -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Help needed for stand alone grid for 800 users... HELP! [bayes]
Dirk Krause wrote: > Hi, > > > > I don’t want to spoil the show for OpenSim here, but if you really want > 800 users in a virtual world there is no way around ActiveWorlds > (http://activeworlds.com/ ) – at least that’s how IBM does it according > to David van Gent. When it comes to user number of 50 or higher at one > place, they switch to ActiveWorlds. It is an old but very proven > technology that is very affordable. > > > > Again, I am not promoting AW being a big OpenSim fan myself ( > http://web3dblog.wordpress.com ) but if you want to get the job done, > you might consider AW. I didn’t try it myself but filed it under ‘you > need that for large numbers’ > those large user numbers do come at a cost though: very limited user interface, very limited user experience... there's a reason we are using OpenSim as the basis of our "Sametime 3D" project... DrS/dirk -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Help needed for stand alone grid for 800 users...HELP! [bayes]
Dirk Krause wrote: > That’s exactly what AW does. You can host it completely in-house. > > > > Again, I didn’t try it myself but I know several members of this list did. > > > > Since the AW issue is going off-topic for this list, and we will talk > anyhow, I close here. > if you/your school is concerned about ownership of content, read the licenses and ToS clauses carefully... DrS/dirk -- dr dirk husemann virtual worlds research ---- ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Help needed for stand alone grid for 800 users... HELP!
Charles Krinke wrote: > Well, let me jump in here a little bit. > > If I were going to set this up, I would start with four OpenSim regions, > each running on a different Linux server. > > I would put them in a square and make the landing point at the > four-corner junction. > > I would then make each of the four regions a seperate classroom and plan > on reliably handling 20-30 simultaneous in each of the four regions. > > When I had sufficient experience, i.e. one quarter (or semester), then I > would consider expanding (or coalescing two regions into one server) > based on the quarter's (or semester's) reliability or stability. > > I think MCortez said something very similar to this a few posts ago and > he would tend to know also. > > Charles > > p.s. At this point, one can expect to handle 20 avatars simultaneously > in one region comfortably. > > p.p.s 40 Avatars simultaneous in one region is 'iffy'. +1 on that given the current state of affairs. DrS/dirk -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Shaping the user services
Melanie wrote: Currently, profile information is handled in part by the user server and in part by the profiles module. This data really has no business in the user server, because it is Linden client specific, furthermore, it should not be split between two services. The profile information in the user server is a legacy of a quick fix to get a profile picture and text working before we had a real profile service. It would be quite foolish to pollute a new, clean architectural approach with such legacy data and Lindenisms, actually i'd take the opposite approach and make it part of the user service and make it more general. just because lindens had the idea of providing profile information is not bad per se. profile information is a useful tool, certainly in the corporate environment. i agree that the current way it's structured is not good. DrS/dirk Melanie Justin Clark-Casey wrote: Melanie wrote: Profile information has no place in this architecture and will be handled exclusively by the profiles module. Please could you elaborate on this. Why will this be handled differently from the other things being handled by servers? What are the implications of doing it this way? ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- dr dirk husemann math & computer science ibm zurich research lab RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ SL: drscofi...@xyzzyxyzzy.net - http://xyzzyxyzzy.net/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] trying to improve OpenSim performance under heavy load
Paul Fishwick wrote: > Dirk > Let's suppose for the moment that all prims, textures, and assets in > general were preloaded as they are for most multi-player games. > If you wanted to go to my island, you would need my island's OAR, or the > equivalent. Would the same performance issues exist in terms of having, > say 60 avatars in a region? > -paul can't really say at this point in time. what we have been seeing is that even after avatars/bots have gotten hold of the textures the load on the machine stays pretty high (4 core machine, 32bit). a faster machine will certainly help. also, we've only touched on a small part of OpenSim so far --- and haven't even done a test with 40 "real" avatars yet. DrS/dirk -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Suggestion for project organization.
Charles Krinke wrote: > As I think about this a little bit, it seems that drawing a little > analogy between the linux kernel and modules used with the kernel might > be an interesting way to think of our OpenSim evolution. > > There is a core set of logic, somewhat analogous to a kernel. Then there > are various modules of which some are in the kernel SVN and others are > in forge.opensimulator.org and now other places. > i like the linux kernel approach: * make config -> configures build tree * make -> compiles the system -- dr dirk husemann virtual worlds research ---- ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Deprecate OpenSim.Grid.InventoryServer and OpenSim.Grid.AssetServer?
Melanie wrote: > Charles, I said documentation is on it's way. I would like to get > people's opinions on moving forward with deprecating the old > servers, not people's opinions on the obvious need for documentation. > > Further, if the old servers are kept, they will have to be > maintained indefinitely and so will the protocols, blocking any real > progress. So, could you please explain your -1? have to agree with charles, so -1 from me as long as the documentation is absent. -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Deprecate OpenSim.Grid.InventoryServer and OpenSim.Grid.AssetServer?
Melanie wrote: > Information on the B.U.S.T. server and how to set up a grid with it > is at http://opensimulator.org/wiki/Configuration. The previous > documentation has been moved to > http://opensimulator.org/wiki/LegacyServers and linked from the > Configuration page ok, changing to +1. -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Deprecate OpenSim.Grid.InventoryServer and OpenSim.Grid.AssetServer?
Sean Hennessee wrote: > MW wrote: >> I also would rather a different name than BUST, and also before any >> protocol changes are done, see full documentation about the plans. > > How about BOSS? Basic Open Simulator Servers? +1 -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] author names in git vs. svn
Sean Dague wrote: > When we make the transition from svn to git, there will be a one time > mapping of svn usernames to something more friendly. That means that > for every username in our svn repo (34 of them) we need to figure out > what the author would like their entry to be. > > Git user entries are of the form: Name . For instance, mine is > going to be: > > Sean Dague > > Below is the current author mappings that I have to make the transition. > If you are one of the people on this list, please email back with what > you want your entry to look like. For entries I don't get a response > from I'll try to divine something sane out of the old -dev lists. > Thanks in advance. > > sdague = Sean Dague > cw = cw > mw = mw > jmalthus = jmalthus > gareth = gareth > jhurliman = jhurliman > lbsa71 = lbsa71 > afrisby = afrisby > andy = andy > morphw = morphw > mingchen = mingchen > babblefrog = babblefrog > tedd = tedd > danx0r = danx0r > dalien = dalien > tleiades = tleiades > ckrinke = ckrinke > chi11ken = chi11ken > darok = darok > teravus = teravus > adjohn = adjohn > justincc = justincc > joha1 = joha1 > alondria = alondria > mikkopa = mikkopa > drscofield = drscofield drscofield = Dr Scofield -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Minimum OpenSim mono version now 2.4? (was Re: [Opensim-commits] r10113 - trunk)
Impalah wrote: > Please allow me to be cynic but... For using/developing for/testing > trunk Opensim versions I am forced to tweak my stable and well patched > Linux and to include an unstable mono version which I have no guarantee > about everything will work (maybe with 2.4, maybe with 2.5, maybe with > future 2.9)... hmm...not sure where the "tweak my stable and well patched linux" comes into the game. installing mono 2.4.2 can be done in parallel to an existing mono tree even. you just have to be careful to use the right one for opensim (we have systems with 3 different mono version installed). but then again, i might be misunderstanding you. if that is the case, forget what i said. -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Main Repository now in Git
Ursula MATOVA wrote: > Hi all, > > Just my comment on the use of "git" instead of "svn" ... > ... Was so simple for us ( "non - core-devs" ) when it was on subversion > ... > > I've read the git documentation, and sure many many feature are > interresting for active core-devs, but ... > > - The details posted on OpenSim Commits list are so uggly, and > unreadable ... Was really better before, the diffs were included in the > mail ... was helpful, because we were able to see what has changed in a > commit, the post "Subject" isn't clear at all ( maybe it's because the > transition between svn & git is not finished yet ), > - About, "revisions" ... now, it's impossible to know what release > number is "current" ... > (( As somebody mentioned here, all my scripts performing an automatic > upgrade are now broken :( )) > > Anyway, that doesn't change the quality of the work done :D > ... that will only make our task harder to maintain our opensim servers ... > > The only thing is that "svn" if more "user-friendly" than "git", as somehow who has suffered from the many many quirks of svn --- and was a firm disbeliever in git when sean "evangelized" it in the IBM opensim community way back when --- i've since come to LOVE git. sure it's different (but then cars are different to horse-drawn coaches :-) and, yes, i can sympathize with the "release naming issue" --- but i've to say, it's much more user friendly because i as a user of it have considerable less problems with it and have in fact more freedom to work MY workflow instead of having to bow to SVN. just my CHF 0.02 ;-) cheers, drs/dirk -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Main Repository now in Git
Ursula MATOVA wrote: > Sure you're right ... let's go to "git" then :) > > But, is it possible to change the "OpenSim Commits" posts ? > Really, it's un-useful and unreadable ... i agree 100% with you on that. and, yes, it's possible to change them (i've done that for our local git repos), i guess sean hasn't had time to tackle that yet (and i don't have enough cred [aka sudo rights] on opensimulator.org to have a look at it :-( drs/dirk > > Regards, > Ursula. >> Ursula MATOVA wrote: >> >>> Hi all, >>> >>> Just my comment on the use of "git" instead of "svn" ... >>> ... Was so simple for us ( "non - core-devs" ) when it was on subversion >>> ... >>> >>> I've read the git documentation, and sure many many feature are >>> interresting for active core-devs, but ... >>> >>> - The details posted on OpenSim Commits list are so uggly, and >>> unreadable ... Was really better before, the diffs were included in the >>> mail ... was helpful, because we were able to see what has changed in a >>> commit, the post "Subject" isn't clear at all ( maybe it's because the >>> transition between svn & git is not finished yet ), >>> - About, "revisions" ... now, it's impossible to know what release >>> number is "current" ... >>> (( As somebody mentioned here, all my scripts performing an automatic >>> upgrade are now broken :( )) >>> >>> Anyway, that doesn't change the quality of the work done :D >>> ... that will only make our task harder to maintain our opensim servers ... >>> >>> The only thing is that "svn" if more "user-friendly" than "git", >>> >> as somehow who has suffered from the many many quirks of svn --- and was a >> firm >> disbeliever in git when sean "evangelized" it in the IBM opensim community >> way >> back when --- i've since come to LOVE git. sure it's different (but then cars >> are different to horse-drawn coaches :-) and, yes, i can sympathize with the >> "release naming issue" --- but i've to say, it's much more user friendly >> because >> i as a user of it have considerable less problems with it and have in fact >> more >> freedom to work MY workflow instead of having to bow to SVN. >> >> just my CHF 0.02 ;-) >> >> cheers, >> drs/dirk >> >> > > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Main Repository now in Git
Tommi Laukkanen wrote: > Out of curiosity: does commit I make register under my name in > repository now that git is used? In other words can non core member > claim their commits in ohloh.net now? yes, provided the patch was supplied in the right format. if you look in the git log for last monday, you'll see the following commit: commit 068f54725ba5cc658257b5e0f4b9d7c51638c376 Author: Alan Webb Date: Mon Aug 3 23:07:12 2009 -0400 Slight change to state management for attach scheduling. Signed-off-by: dr scofield (aka dirk husemann) that's a commit that alan committed, which i pulled, signed off on and pushed into trunk. drs/dirk -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Main Repository now in Git
Michael Cortez wrote: > James Stallings II wrote: >> So far Adam it's just the hash, but I've not got even that working yet >> so I will see if I can find a way to get a date in there too :) > Maybe pull the time stamp of the creation date off the file itself? > > Although, I'd suggest MMDD followed by the hash instead of MMDD. +100, please, please, please. -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Main Repository now in Git
Ursula MATOVA wrote: > Hey Sean ... I know it's hard work ... > My post was just "comments/feeling" about the migration from svn to > git ... > ` > On my side ( I'm not a core-dev, just trying to be an active > reporter ) I need to be able to migrate my OpenSim server to the > latest current release to test some new feature/improvments and to be > able to quick reverse to the previous release in case of problems > ( it's normal when working with dev branch ) ... And all is based on > the "release number" ... ... > We were in SVN. #10115 ... Then what about now ? > It's not clear at all, don't know the current release number ... ... > do you know it ? > What changes ? > .../... > When checking the git repository, I'm not sure to checkout the latest > dev release ... is it ? or is it the stable branch ? > Sorry, maybe my english is not good enough to follow the git/wiki > instructions ... while i'm not sean, here's what we are doing for sametime 3d: * we've got the "sametime3d" branch for what we consider stable * we've got the "opensim" branch that tracks opensim's master branch to test the latest & greatest & breaking ;-) i do: % git checkout opensim % [...testing...] to go back to "stable" i do: % git checkout sametime3d to update the opensim branch: % git checkout opensim % git pull whenever we are satisfied that a certain opensim level is stable, we merge the opensim to the sametime3d branch: % git checkout sametime3d % git merge opensim for this all to work, i had to create the sametime3d branch: % git checkout -b sametime3d opensim also, i'm using the following .git/config sections: [remote "ibm"] url = ssh://d...@opensim.zurich.ibm.com/git/opensim fetch = +refs/heads/*:refs/remotes/origin/* [branch "sametime3d"] remote = origin merge = refs/heads/sametime3d [remote "origin"] url = ssh://drscofi...@opensimulator.org/var/git/opensim fetch = +refs/heads/*:refs/remotes/opensimulator.org/* [branch "opensim"] remote = origin merge = refs/heads/master those sections define: two remotes, "ibm" and "origin", which are the hosts for the two repositories i pull from; two branches, "sametime3d" and "opensim", along with the remotes i'm pulling from/pushing to. hope, this helps a bit. cheers, dirk -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Main Repository now in Git
Dr Scofield wrote: > Ursula MATOVA wrote: >> Hey Sean ... I know it's hard work ... >> My post was just "comments/feeling" about the migration from svn to >> git ... >> ` >> On my side ( I'm not a core-dev, just trying to be an active >> reporter ) I need to be able to migrate my OpenSim server to the >> latest current release to test some new feature/improvments and to be >> able to quick reverse to the previous release in case of problems >> ( it's normal when working with dev branch ) ... And all is based on >> the "release number" ... ... >> We were in SVN. #10115 ... Then what about now ? >> It's not clear at all, don't know the current release number ... ... >> do you know it ? >> What changes ? >> .../... >> When checking the git repository, I'm not sure to checkout the latest >> dev release ... is it ? or is it the stable branch ? >> Sorry, maybe my english is not good enough to follow the git/wiki >> instructions ... > > while i'm not sean, here's what we are doing for sametime 3d: > > * we've got the "sametime3d" branch for what we consider stable > * we've got the "opensim" branch that tracks opensim's master branch > > to test the latest & greatest & breaking ;-) i do: > > % git checkout opensim > % [...testing...] > > to go back to "stable" i do: > > % git checkout sametime3d > > to update the opensim branch: > > % git checkout opensim > % git pull > > whenever we are satisfied that a certain opensim level is stable, we merge the > opensim to the sametime3d branch: > > % git checkout sametime3d > % git merge opensim > > for this all to work, i had to create the sametime3d branch: > > % git checkout -b sametime3d opensim > > also, i'm using the following .git/config sections: > > [remote "ibm"] > url = ssh://d...@opensim.zurich.ibm.com/git/opensim > fetch = +refs/heads/*:refs/remotes/origin/* > [branch "sametime3d"] > remote = origin err, make that: [branch "sametime3d"] remote = ibm sorry, was adapting the config sections to minimize confusion... > merge = refs/heads/sametime3d > [remote "origin"] > url = ssh://drscofi...@opensimulator.org/var/git/opensim > fetch = +refs/heads/*:refs/remotes/opensimulator.org/* > [branch "opensim"] > remote = origin > merge = refs/heads/master > > > those sections define: two remotes, "ibm" and "origin", which are the hosts > for > the two repositories i pull from; two branches, "sametime3d" and "opensim", > along with the remotes i'm pulling from/pushing to. > > hope, this helps a bit. > > cheers, > dirk > > -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Main Repository now in Git
krtaylor wrote: > Well, since I wrote the original code way back when, I felt some > ownership for this. I have been considering several ways for us to make > this nice again. > > Since the version, specifically the build, now really only makes sense > in a local context, it really can no longer be linear. However, for the > version (build) to be useful again, it at least needs to be an > increasing number to enables product upgrades, etc. As it turns out, > this is a common problem and there are lots of email and blogs on the > subject. > > So, the solution I like best so far is something similar to: > > http://michaelandlaura.org.uk/~michael/blog/index.php?id=379 > > Comments? like it. +1 -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Performance optimization of complex ScienceSim regions
Lake, Dan wrote: > A few months back, we analyzed and proposed optimizations to scripting and > timers on homogeneous regions which were dynamically created with up to > 40,000 simple cubes and physics disabled. Considerable reductions in scene > creation time and cpu utilization were achieved. > > The regions running on ScienceSim at this time have few scripts (less than 1% > of objects), have large linked sets, are loaded at startup from a database, > and most have ODE physics enabled although very few objects are physical. > This represents a completely different workload for OpenSim from our previous > analysis. Some of these ScienceSim regions are extremely complex with between > 60,000 and 140,000 prims. We have noticed that startup on these regions can > take 45 minutes or more and consume 50% of a CPU once they reach a steady > state with no users connected. We did not expect that high utilization since > script counts were below 200 and no users were connected. > > We have identified 3 areas of optimization. > > 1. On startup, the region must be loaded from the database and all region > modules must be started to prepare the region to run. On the largest > ScienceSim regions, this step takes 20 minutes before the command prompt > appears. We refer to this phase as the startup time. > > 2. The appearance of the OpenSim command prompt indicates that the Heartbeat > thread has started up. Commands can be issued such as "create user" or "show > stats", but the Heartbeat thread itself will remain in its first "beat" for > up to 40 more minutes. During this time, users cannot connect and the stats > are all listed as 0 and do not update. We refer to this phase as "first > heartbeat time". > > 3. Once the region has completely started up, but before any users have > connected, we notice that the CPU utilization seems unusually high for the > amount of "action" in the scene. Less than 200 scripted or physical objects > should not represent a high load, but the 140,000 static prims somehow > consumed 50% of a CPU. > > Analysis > [lots of very good stuff] wow! -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] versioning question
krtaylor wrote:
> I have been playing around with a solution for the sequential version
> reporting, but it is not as simple as it may seem. The best description
> of the problem and solution I have found is at:
>
> http://michaelandlaura.org.uk/~michael/blog/index.php?id=379
>
>
> The catch is that we appear to be using tag objects that are orphaned.
> To see an example of that, just run git show-ref on a clone tree for
> 0.6.6-release. The hash is shown, but then git log does not contain that
> hash, even when tracking the master.
hmm, i don't even get that tag:
% git show-ref | grep 0.6.6
cb7704e6498d2899fe4cd17c8f28d02522f80d77 \
refs/remotes/opensimulator.org/0.6.6-post-fixes
is all i get, but that hash is known to git:
% git show cb7704e6498d2899fe4cd17c8f28d02522f80d77
commit cb7704e6498d2899fe4cd17c8f28d02522f80d77
Author: Melanie
Date: Sat Aug 8 01:42:50 2009 +0100
Change the default for internal IP address back to 0.0.0.0
diff --git a/OpenSim/Framework/RegionInfo.cs b/OpenSim/Framework/RegionInfo.cs
index 7ac1e62..4640406 100644
--- a/OpenSim/Framework/RegionInfo.cs
+++ b/OpenSim/Framework/RegionInfo.cs
@@ -493,7 +493,7 @@ namespace OpenSim.Framework
}
else
{
-address =
IPAddress.Parse(MainConsole.Instance.CmdPrompt("Internal IP address",
"127.0.0.1"));
+address =
IPAddress.Parse(MainConsole.Instance.CmdPrompt("Internal IP address",
"0.0.0.0"));
config.Set("InternalAddress", address.ToString());
}
i guess i'm missing something here...
--
dr dirk husemann virtual worlds research ibm zurich research lab
SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/
RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] ConsoleClient -pass option
Dickson, Mike (ISS Software) wrote: > I'd agree with Dave on this one. Just a simple long ps listing gets you the > password if its on cleartext on the command line. At least the file can be > locked down via permissions. A password on the command line is pretty much > insecure. Might as well not have one. ...unless you rewrite argv (which is standard practise for stuff like that). DrS/dirk > > Mike > > -Original Message- > From: opensim-dev-boun...@lists.berlios.de > [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Melanie > Sent: Thursday, September 03, 2009 10:02 PM > To: opensim-dev@lists.berlios.de > Subject: Re: [Opensim-dev] ConsoleClient -pass option > > It's choosing the lesser evil. > > Melanie > > > Dave Coyle wrote: >> On Thursday 03 September 2009 03:00:46 pm wrote: >>> commit 6b70b5709913e9734f5864560e997b34dfd58b85 >>> Author: Justin Clark-Casey (justincc) >>> Date: Thu Sep 3 20:00:18 2009 +0100 >>> >>> * Add extra warning about using -pass in >>> OpenSim.ConsoleClient.ini.example >>> >>> <...> >>> >>> +; Please be aware that this is not secure since the password is in the >>> clear +; we recommend the use of -pass wherever possible >>> ;pass = secret >> >> Is the password not also in the clear, visible to any local user who does a >> 'ps', if you use the -pass switch? Access to OpenSim.ConsoleClient.ini can >> at >> least be restricted to specific user(s). I don't see how -pass is the >> lesser >> of the two evils. >> >> -coyled >> >> >> >> >> ___ >> 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 -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Serializing parcel data in OARS (was Re: [Opensim-commits] [OpenSim Git Master Repository] master branch updated. r/10596)
Justin Clark-Casey wrote: > dr scofield, could we serialize/deserialize this manually, as done in > OpenSim.Framework.Serialization.External.RegionSettingsSerializer.cs? > hmm. i'll have a look. SceneObjectPart is doing it the XmlSerialiser way, so we end up with kind of a mixture here. > Otherwise I fear that there will be a lot of awkardness if the external > format > changes in certain ways (e.g. renaming of xml attributes). > cheers, DrS/dirk -- dr dirk husemann math & computer science ibm zurich research lab RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ SL: drscofi...@xyzzyxyzzy.net - http://xyzzyxyzzy.net/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Load OAR and on_rez
Alan M Webb wrote: > > Currently when an OAR is loaded, on_rez is inappropriately driven for > every script. From a script's perspective, a region restored from an OAR > file is not fundamentally different to a region restored from the region > database following a region restart. The only event we should be seeing > (for scripts with saved state, and by definition all scripts in an OAR > file have saved state) is a CHANGED event indicating > CHANGED_REGION_RESTART. If everyone is cool with this, I'll make the > change (it's a simple one-line change in ArchiveReadRequest) and submit it. +1 from me. -- dr dirk husemann virtual worlds research ---- ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] ConsoleClient -pass option
Dickson, Mike (ISS Software) wrote:
> Ok, after a tour through the REST console code as best as I can tell it
> *looks* like all your REST console does is wrap cli commands in XML and ship
> messages back and forth. I guess that sort of band-aids the need for a
> console remotely but there are whole sets of things that don't work. For
> instance if I want to do a "load oar" command how does the oar file get to
> the server and where does it need to live to get found? If I need to do some
> sort of out of band mechanism to achieve that how does that translate to a
> fully functional console?
>
> In a case like this where I *personally* want a truly remote management
> interface for a server I'd strongly prefer a set of well documented remotely
> callable functions. They should fully capture the semantics for the
> operations involved (i.e. the load oar "function" specifies how the oar file
> is transported over the wire) so the interface is truly remotable. If you
> had that you could still implement a text based local console over the
> implementation interface but at least what remotely managing the server means
> is well defined. And programming against it means using a straightforward
> RPC call vs. XML mangling.
i've to agree on that. i'd started something like that, but haven't really made
any headway due to lack of time. being a pythonista i tend to look at things
through python glasses: invoking an XmlRpc method is easy, doing the same thing
with REST is a pain.
cheers,
DrS/dirk
--
dr dirk husemann virtual worlds research ibm zurich research lab
SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/
RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] The return of short version numbers (as tags)
Teravus Ovares wrote: > http://teravus.wmcv.com/googletester/GitLog.jpg > > Regards > > Teravus > > On Tue, Sep 8, 2009 at 10:10 AM, Frisby, Adam wrote: >> Where do we see this number? And is there any way to easily translate >> between the two? >> also: git log --decorate --- commit 62358014ed59136cfd1d452f08171a0bc32612cf (r/10656, opensimulator.org/master, x-opensim, notecard-unicode) Author: dr scofield (aka dirk husemann) Date: Wed Sep 9 08:28:13 2009 +0200 reformatting. ... DrS/dirk -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] The return of short version numbers (as tags)
Dr Scofield wrote: > Teravus Ovares wrote: >> http://teravus.wmcv.com/googletester/GitLog.jpg >> >> Regards >> >> Teravus >> >> On Tue, Sep 8, 2009 at 10:10 AM, Frisby, Adam wrote: >>> Where do we see this number? And is there any way to easily translate >>> between the two? >>> > > also: git log --decorate --- > > commit 62358014ed59136cfd1d452f08171a0bc32612cf (r/10656, > opensimulator.org/master, x-opensim, notecard-unicode) > Author: dr scofield (aka dirk husemann) > Date: Wed Sep 9 08:28:13 2009 +0200 > > reformatting. > > ... > > DrS/dirk > ...and doing: % git config alias.dlog "log --decorate" gives a customized dlog git command: % git dlog commit 62358014ed59136cfd1d452f08171a0bc32612cf (r/10656, opensimulator.org/master, x-opensim, notecard-unicode) Author: dr scofield (aka dirk husemann) Date: Wed Sep 9 08:28:13 2009 +0200 reformatting. ... -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Make ODE and Meshmerizer the default options?
Justin Clark-Casey wrote: > In the OpenSim developer's meeting yesterday on OSGrid we had a discussion > about > making ODE the default physics engine and Meshmerizer the default mesher. [...] +1 on ODE default +1 on Meshmerizer default DrS/dirk -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] [Opensim-users] OpenSim defaults now ODE and Meshmerizer
Justin Clark-Casey wrote: > As of revision 077d01c2255009a1e47e8bed42375ce81b770ef9, the default physics > engine in OpenSim is ODE and the default meshmerizer is Meshmerizer. > > I have added a note to > > http://opensimulator.org/wiki/Configuration#Running_OpenSim_in_64_bit_Windows_on_the_future_0.6.7_release > > about the need to use OpenSim.32BitLaunch.exe on 64 bit Windows. That > document > sure is a mess though. > > Thanks to all for their feedback on this topic. > and 077d01c2255009a1e47e8bed42375ce81b770ef9 translates into r/10722 :-) -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] lslc project
d...@metaverseink.com wrote: > Alan Webb's commit of today introduced a new project called lslc that > smells like it was by accident. Just checking. > If it's intentional, I think that code needs cleaning up on names -- > should probably be called OpenSim.Tools.Lslc. > What's the inside scoop on this? > it's intentional. re naming, fine with me. cheers, dirk > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Opensim Prims
André Filipe wrote: I have a problem in OpenSim where editing objects parameters like path-cut, hole, etc only change the object visual representation, the physical remains the same. For example, make a large hollow cylinder, like a pipe. The avatar wont pass through the hole, doesnt matter the size of the cylinder. It means the physical representation of the hollow cylinder is still a solid cylinder without any holes in it. I see that in Science Sim this doesnt happen. If I create a large pipe the avatar can pass through it. What is the trick?? use ODE physics and the meshmerizer. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- dr dirk husemann math & computer science ibm zurich research lab RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ SL: drscofi...@xyzzyxyzzy.net - http://xyzzyxyzzy.net/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Thoughts on adding a generic key-value storage system to OpenSim?
d...@metaverseink.com wrote: > I think the issue at hand is how to allow plugins (regions modules and > others) to store additional data in the existing databases. Many times > the extra data is just a few more fields. Having to setup entire > databases for those plugins, separate from the existing ones, and > requiring coordination with the existing ones, seems like an unnecessary > complexity. > > So definitely +1 on jhurliman's proposal. +1 as well. > > Stefan Andersson wrote: >> For what it's worth, I'd rather have us encourage exploring notions of >> cloud-like and distributed services than to create a serve-all string >> storage. >> >> Pitched against monolithic database providers, I feel it's more in line with >> the OpenSim distributed, modular and decoupled mantras. >> >> /Stefan >> >>> -Original Message- >>> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- >>> boun...@lists.berlios.de] On Behalf Of Dickson, Mike (ISS Software) >>> Sent: den 22 september 2009 17:55 >>> To: opensim-dev@lists.berlios.de >>> Subject: Re: [Opensim-dev] Thoughts on adding a generic key-value >>> storage system to OpenSim? >>> >>> And OpenSim is? >>> >>> I actually really like the notion of a REST like interface for semi- >>> structured attribute/value storage for modules. Similar to the cloud >>> centric storage services. Maybe you configure a URL for the REST >>> storage svc to use and a module that needs it can look it up and use >>> it. One implementation could certainly be in the local database but an >>> external svc (either a separate shared "internal" svc or a real >>> external cloud storage svc depending on needs). >>> >>> Anyway, I'd hate to see restricting options for this based on perceived >>> stability of a solution. OpenSim itself is "alpha" as has been pointed >>> out. Melanie, you seem to have a preconceived design in mind, maybe >>> you could share some details. >>> >>> Mike >>> >>> -Original Message- >>> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- >>> boun...@lists.berlios.de] On Behalf Of Melanie >>> Sent: Tuesday, September 22, 2009 10:42 AM >>> To: opensim-dev@lists.berlios.de >>> Subject: Re: [Opensim-dev] Thoughts on adding a generic key-value >>> storage system to OpenSim? >>> >>> CouchDB is generally not considered stable at this time. >>> >>> Melanie >>> >>> Daniel Smith wrote: >>>> You mentioned JSON -- Anyone looking at CouchDB? >>>> http://couchdb.apache.org/ >>>> >>>> >>>> On Tue, Sep 22, 2009 at 12:16 AM, Frisby, Adam >>> wrote: >>>>> I think something that has emerged a lot in the last year is the >>>>> scalability properties of key-value stores. You can get them up to >>> gigantic >>>>> sized databases fairly efficiently; definitely more so than a >>> conventional >>>>> DB. It would however be nice if we could get some kind of struct >>> format for >>>>> serialising/deserialising data and knowing how to decode it >>> implicitly. >>>>> (XML, JSON?) >>>>> >>>>> 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 >> ___ >> Opensim-dev mailing list >> Opensim-dev@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] [Opensim-commits] [OpenSim Git Master Repository] master branch updated. r/10793
Justin Clark-Casey wrote: Tests! I love you Diva and I want to have your babies :) we read that... ;-) opensim-commits-boun...@lists.berlios.de wrote: The branch, master has been updated via 1260c81 More tests. Seems to be working. via fd8fb77 First test passes -- regions being registered and retrieved correctly in Data.Null. via 3c19bd5 Unit tests for the grid service. Yey! via 6727658 Changed IGridService to use the new GridRegion data structure instead of old SimpleRegionInfo. via b8f0398 Merge branch 'master' of ssh://d...@opensimulator.org/var/git/opensim via 35deff7 Modules active. Tested HGGridConnector in standalone only for now. Modules commands work. via 486a9a5 Merge branch 'master' of ssh://d...@opensimulator.org/var/git/opensim via 882d2c9 Added hg console commands to the module. via ffd30b8 Moved RegionName from RegionInfo to SimpleRegionInfo. via 0fc2b73 Merge branch 'master' of ssh://d...@opensimulator.org/var/git/opensim via 34f4738 Added HGGridConnector and related code. via a9ced0f Added Remote grid connector module. via ae07b22 Changed position methods so that they assume the input params are in meters. from c592a60 Fix endlines on UrlModule.cs Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - -- dr dirk husemann math & computer science ibm zurich research lab RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ SL: drscofi...@xyzzyxyzzy.net - http://xyzzyxyzzy.net/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Mono minimum version bump
Melanie wrote: > 2.4.x with x < 2 will certainly do it. Other versions might, but not > as frequently as earlier ones. x >= 2 ... if < 2 you WILL run into mono problems with 2.4.x, we tried that. -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Mono minimum version bump
Snowdrop Short wrote: > Personally I find this constant relying on the latest and greatest > version quite annoying. > > Using a version of Mono, which isn't in the published repo's is not only > complicated, but has a tendency to cause problems in other parts of the > OS, at least in Ubuntu it does. you can install mono to a non-standard path and use that for opensim without causing pain on the distro's mono setup. > > Not only does it cause instabilities, e.g. in Beagle, but it also causes > problems when logging support requests to Canonical. > > Isn't it possible to attack the specific crash some other way, e.g. use > a different method or a different sequence of statements? if it's an easy, low-penalty work-around, yes and we've done that in the past. however, there's the danger that we end up spending more time working around mono bugs than we really want to. for Sametime 3D we've done quite a bit of testing with the various mono versions. we found that anything < 2.4.2 is just not stable (with the exception of 2.0.1, but that suffers from performance/memory problems). your mileage might vary, of course, in our experience we've crashed in the wall once we started putting load on mono < 2.4.2. DrS/dirk -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] git branches
git branches actually don't cost that much (it's just a pointer to a commit basically). so why bother? DrS/dirk Frisby, Adam wrote: > Nix anything from 07/08 - the code isn't used anymore. > > Adam > >> -Original Message- >> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- >> boun...@lists.berlios.de] On Behalf Of Jeff Ames >> Sent: Wednesday, 30 September 2009 5:32 PM >> To: opensim-dev@lists.berlios.de >> Subject: [Opensim-dev] git branches >> >> Hello, >> >> Looking at the git branches on the server, many of them are rather >> old. Do we really want to keep all of them? >> >> The dates listed are the date of the last commit to the branch. >> >> Releases / post-fixes, presumably want to keep: >> origin/0.6.0-stable Dec 18 2008 >> origin/0.6.1-post-fixes Jan 14 2009 >> origin/0.6.2-post-fixes Mar 17 2009 >> origin/0.6.3-post-fixes Feb 21 2009 >> origin/0.6.4-post-fixes Apr 3 2009 >> origin/0.6.4-rc1Mar 11 2009 >> origin/0.6.5-post-fixes Jun 24 2009 >> origin/0.6.5-rc1May 24 2009 >> origin/0.6.6-post-fixes Aug 8 2009 >> origin/0.6.7-post-fixes Sep 29 2009 >> origin/0.6b-realxtend Feb 26 2008 >> >> Updated recently, presumably want to keep: >> origin/inventory-connector Aug 16 2009 >> origin/arthursv Aug 21 2009 >> origin/diva-texturesSep 30 2009 >> origin/diva-textures-osgrid Sep 30 2009 >> origin/grid-service-redux Sep 28 2009 >> origin/vehicles Sep 30 2009 >> >> Last updated in 2007: >> origin/standalone Feb 19 2007 >> origin/ogs...@86Feb 26 2007 >> origin/gareth Mar 1 2007 >> origin/brokenpluginsMar 2 2007 >> origin/ogs...@151 Mar 2 2007 >> origin/physicsExample Mar 5 2007 >> origin/railsMar 7 2007 >> origin/ConvertToPlugins Mar 7 2007 >> origin/ogs...@155 Mar 7 2007 >> origin/ogs...@160 Mar 7 2007 >> origin/ogs-cs Mar 14 2007 >> origin/adam-ogscs Mar 20 2007 >> origin/adam Mar 20 2007 >> origin/physics-inventorytesting Mar 20 2007 >> origin/LLdemo Mar 27 2007 >> origin/tourmaline Mar 28 2007 >> origin/scripting-jvmApr 10 2007 >> origin/0.1-prestableMay 7 2007 >> origin/remotingTest May 27 2007 >> origin/mergeJun 8 2007 >> origin/zircon Jun 12 2007 >> origin/NameSpaceChanges Jun 29 2007 >> origin/ruby Jul 8 2007 >> origin/OGSMerge Jul 10 2007 >> origin/Sugilite Jul 11 2007 >> origin/physics Aug 19 2007 >> origin/update-to-latest-libsl Oct 1 2007 >> >> Last updated in 2008: >> origin/ThreadPoolClientBranch Feb 24 2008 >> origin/afrisby Feb 22 2008 >> origin/afrisby-3Feb 25 2008 >> origin/afrisby-rexmerge Feb 22 2008 >> origin/rexserver_r830 Feb 29 2008 >> >> Last updated in early 2009: >> origin/GenericGridServerConcept May 15 2009 >> >> Probably a relic of the svn-git changeover: >> origin/trunkAug 2 2009 >> >> There are also a few tags that look like they might not be needed: >> archive Feb 27 2007 >> archive2Mar 7 2007 >> >> Any thoughts? >> >> Jeff >> ___ >> Opensim-dev mailing list >> Opensim-dev@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] osXXXX function parameter types
width, integer height) > string osDrawFilledRectangle(string drawList, integer width, integer > height) > string osDrawFilledPolygon(string drawList, list x, list y) > string osDrawPolygon(string drawList, list x, list y) > string osSetFontSize(string drawList, integer fontSize) > string osSetFontName(string drawList, string fontName) > string osSetPenSize(string drawList, integer penSize) > string osSetPenColour(string drawList, string colour) > string osSetPenCap(string drawList, string direction, string type) > string osDrawImage(string drawList, integer width, integer height, > string imageUrl) > vector osGetDrawStringSize(string contentType, string text, string > fontName, integer fontSize) > osSetStateEvents(integer events) > osSetRegionWaterHeight(float height) > osSetRegionSunSettings(integer useEstateSun, integer sunFixed, float > sunHour) > osSetEstateSunSettings(integer sunFixed, float sunHour) > float osGetCurrentSunHour() > float osSunGetParam(string param) > osSunSetParam(string param, float value) > string osWindActiveModelPluginName() > osWindParamSet(string plugin, string param, float value) > osWindParamGet(string plugin, string param) > float osList2Double(list src, int index) -- should exist, comment in > the code suggests it should be removed > osSetParcelMediaURL(string url) > osSetParcelSIPAddress(string SIPAddress) > string osGetScriptEngineName() > string osGetSimulatorVersion() > osMessageObject(key objectUUID, string message) > osMakeNotecard(string notecardName, list contents) > string osGetNotecardLine(string name, integer line) > string osGetNotecard(string name) > integer osGetNumberOfNotecardLines(string name) > key osAvatarName2Key(string firstname, string lastname) > string osKey2Name(key id) > string osGetGridNick() > string osGetGridName() > string osGetGridLoginURI() > string osFormatString(string str, list strings) > list osMatchString(string src, string pattern, integer start) > string osLoadedCreationDate() > string osLoadedCreationTime() > key osLoadedCreationID() > list osGetLinkPrimitiveParams(integer linknumber, list rules) > key osNpcCreate(string firstname, string lastname, vector position, > vector cloneFrom) > osNpcMoveTo(key npc, vector position) > osNpcSay(key npc, string message) > osNpcRemove(key npc) > > > So what do you think? > Snowcrash > > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] open sim UUID and Passwordhash
assword) + ":" + > String.Empty); > > The salt should be where String.Empty is. > > I think it doesn't change in the most recent versions, so the "create > user" method of the console (both standalone and ugaim) are unsecure by > default. > > > Anyway, I agree with Melanie and Adam that the salt is needed for > improving security, if not a random salt every time you create an user, > at least a long and secret unique salt. > > Greetings > > 2009/10/16 Frisby, Adam <_a...@deepthink.com.au_ > <mailto:a...@deepthink.com.au>> > +1 to Melanie, that code is *not* secure. It is salted with a ":" but > that's a fixed known salt. > > This is what I suggest: > > $passwordSalt = md5(time() . utime() . mt_rand(0,mt_getrandmax())); // > or any other good random source > $passwordHash = md5(md5($password) . ':' . $passwordSalt); > > $passwordSalt should be unique among your database (very likely with the > above code); if there are duplicates, then it allows dictionary attacks > to be done, the more duplicates, the more effective it is. > > Adam > >> -Original Message- >> From: _opensim-dev-boun...@lists.berlios.de_ > <mailto:opensim-dev-boun...@lists.berlios.de> [mailto:_opensim-dev-_ > <mailto:opensim-dev-> >> _boun...@lists.berlios.de_ <mailto:boun...@lists.berlios.de>] On > Behalf Of Melanie >> Sent: Thursday, 15 October 2009 4:14 PM >> To: _opensim-...@lists.berlios.de_ <mailto:opensim-dev@lists.berlios.de> >> Subject: Re: [Opensim-dev] open sim UUID and Passwordhash >> >> Please don't use that code. It creates unsalted hashes, which are >> not secure. >> The "" should be a ranndom salt, stored in the passwordSalt field in >> the DB. If that is blank, you're running a very insecure system >> >> >> Melanie >> >> >> Rich White wrote: >> > here is the PHP code - $password_hash = md5(md5($password) . ":" >> .""); >> > >> > an md5 hash of an md5 hash >> > >> > = >> > >> > 2009/10/15 Márcio Cardoso <_marciomai...@gmail.com_ > <mailto:marciomai...@gmail.com>>: >> >> Good night, >> >> >> >> will be possible that someone could help me with 2 problems I have? >> I'm >> >> trying to create a stored procedure in mysql to add users, but do >> not know >> >> how UUID is generated. anyone have any idea how this happens? >> Another >> >> problem is how is the encoding of the password. >> >> >> >> The ideal was to have access to the code that opensim uses to add >> avatars. >> >> but I got tired of looking and nothing. I thank you for your help. >> >> >> >> Greetings, >> >> >> >> Márcio Cardoso >> >> >> >> ___ >> >> Opensim-dev mailing list >> >> _opensim-...@lists.berlios.de_ <mailto:Opensim-dev@lists.berlios.de> >> >> _https://lists.berlios.de/mailman/listinfo/opensim-dev_ >> >> >> >> >> > ___ >> > Opensim-dev mailing list >> > _opensim-...@lists.berlios.de_ <mailto:Opensim-dev@lists.berlios.de> >> > _https://lists.berlios.de/mailman/listinfo/opensim-dev_ >> >> ___ >> Opensim-dev mailing list >> _opensim-...@lists.berlios.de_ <mailto:Opensim-dev@lists.berlios.de> >> _https://lists.berlios.de/mailman/listinfo/opensim-dev_ > ___ > Opensim-dev mailing list_ > __opensim-...@lists.berlios.de_ <mailto:Opensim-dev@lists.berlios.de>_ > __https://lists.berlios.de/mailman/listinfo/opensim-dev_ > > > ___ > Opensim-dev mailing list_ > __opensim-...@lists.berlios.de_ <mailto: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 -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] [opensim-core] snowcrash's contributions
Ryan McDougall wrote: On Mon, Oct 19, 2009 at 8:30 PM, Cristina Videira Lopes wrote: dr scofield wrote: to me this is another piece from the legal FUD department (reminiscent of the "money" discussions). It's very easy to brush difficult issues under the rug of "I don't care, this is ethics, not technical, hence it's FUD". You're entitled to that stand. Give your -1 on whatever is being proposed and stay out of the rest of the conversation, instead of trying to "FUD the FUD." Some of us care about these difficult issues. Having a co-copyright holder who releases an addon to opensim under a discriminatory license (in this case based on country, but could be based on race, gender, sexual orientation,...) is not something some of us can ignore. Unclear if/what we should do about it, but clear that this is bugging a lot of people, not just core devs, and hence it should be discussed not ignored. Crista Nationality, or more to the point of the clause, political disposition, can be changed; unlike race or gender -- which is the kind of the point, to make a political stand in the face of potential human catastrophe. :D Have I mentioned that I'm not a fan of the secret mailing list? ... Here I am feeling like a member of a community, but largely without voice on the crucial matter of eccentric licenses(?)! :P i'd like to add that this has nothing to do with OpenSim per se. the "eccentric license" referred to relates to a third party component. cheers, DrS/dirk -- dr dirk husemann math & computer science ibm zurich research lab RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ SL: drscofi...@xyzzyxyzzy.net - http://xyzzyxyzzy.net/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] The notion of "core"
Ryan McDougall wrote: > On Tue, Oct 20, 2009 at 8:27 AM, Frisby, Adam wrote: >> I disagree. >> >> * Commit Rights - those discussions cannot occur in public (although the >> discussion archives are open to committers after being invited), the reason >> for this is no-one can be frank & honest without hurting people's feelings. > > Firstly, I did waive discussion for commit access. I also waive money > and legal matters. > > Secondly, I disagree with the logic of the link, as it's premised > entirely on being honest might hurt someone's feelings. Honesty is not > a function of secrecy. i think honesty can be a facilitated by a discussion remaining confidential. > And the case of "there was a long drawn out > discussion about me in which I was not able to represent my myself" > causing hurt feelings is not considered. i can see that point, but i can also see the points made by adam respectively the points made in the F/OSS guidebook --- in balance (my personal one) i'd rather have core committers discuss whether i should have voting rights in private. > > Thirdly, I don't think snowcrash thing is about giving him commit > access. I don't think things are as neatly compartmentalized as is > told (though I could be wrong, it's hard to guess from a secret > mailing list). no, you are right on that one. it's a discussion about our understanding of licensing issues and whether there is indeed an issue here or not. re compartmentalized: they are, at least we try very hard to. DrS -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] The notion of "core"
Impalah Shenzhou wrote: > And who is the Linus Torvalds of Opensim? it's the opensim core group --- because, let's face it, there's only one Linus Torvalds, the rest of the projects have to spread the load. ;-) -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] The notion of "core"
Edward Middleton wrote: > Teravus Ovares wrote: >> ... Your argument was that the advent of the distributed source control >> system made the 'commit right vote' obsolite, ... > > My point was that, with a DVCS, "commit rights" are really just the > right to release manage the official repository. right. opensim-core is just a bunch of dudes and dudettes that manage the official repository. DrS -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] No change author recorded in git! (was Re: [Opensim-commits] [OpenSim Git Master Repository] master branch updated. r/11319)
Justin Clark-Casey wrote:
> This looks like a great change but could we make sure that the Author field
> is
> filled in on git am patches? Otherwise it's going to be a bit hard to tell
> who
> to talk to about which changes...
perhaps it would be good to have the core committer sign-off on the patch? that
way we'd know who dragged it in...
DrS
>
> Best,
>
> Justin
>
> opensim-commits-boun...@lists.berlios.de wrote:
>> The branch, master has been updated
>>via 71c9291 Inconsistent locking of SenseRepeaters in Script Engine.
>> from b0923e0 Fix a glitch in a ROBUST message
>>
>> Those revisions listed above that are new to this repository have
>> not appeared on any other notification email; so we list those
>> revisions in full, below.
>>
>> - Log -
>>
>> commit 71c929137f48a0a7d97dbc866cbe2b12319aa40b
>> Author: unknown
>> Date: Fri Oct 23 03:52:49 2009 -0700
>>
>> Inconsistent locking of SenseRepeaters in Script Engine.
>>
>> When I attempt to 'save oar' on a region with thousands of scripts with
>> timers, I get a NullReferenceException every time. The problem comes from
>> inconsistent locking in SensorRepeat.cs of the SenseRepeaters List. It is
>> iterated and modified in many places and these places are all wrapped in a
>> lock except in the GetSerializationData(). This is the function throwing the
>> exception because an item in the list becomes null during iteration.
>>
>> The attached patch locks SenseRepeatListLock in GetSerializationData()
>>
>> 71c929137f48a0a7d97dbc866cbe2b12319aa40b
>> diff --git
>> a/OpenSim/Region/ScriptEngine/Shared/Api/Implementation/Plugins/SensorRepeat.cs
>>
>> b/OpenSim/Region/ScriptEngine/Shared/Api/Implementation/Plugins/SensorRepeat.cs
>> index ee01c3c..b75a2e4 100644
>> ---
>> a/OpenSim/Region/ScriptEngine/Shared/Api/Implementation/Plugins/SensorRepeat.cs
>> +++
>> b/OpenSim/Region/ScriptEngine/Shared/Api/Implementation/Plugins/SensorRepeat.cs
>> @@ -516,16 +516,19 @@ namespace
>> OpenSim.Region.ScriptEngine.Shared.Api.Plugins
>> {
>> List data = new List();
>>
>> -foreach (SenseRepeatClass ts in SenseRepeaters)
>> +lock (SenseRepeatListLock)
>> {
>> -if (ts.itemID == itemID)
>> +foreach (SenseRepeatClass ts in SenseRepeaters)
>> {
>> -data.Add(ts.interval);
>> -data.Add(ts.name);
>> -data.Add(ts.keyID);
>> -data.Add(ts.type);
>> -data.Add(ts.range);
>> -data.Add(ts.arc);
>> +if (ts.itemID == itemID)
>> +{
>> +data.Add(ts.interval);
>> +data.Add(ts.name);
>> +data.Add(ts.keyID);
>> +data.Add(ts.type);
>> +data.Add(ts.range);
>> +data.Add(ts.arc);
>> +}
>> }
>> }
>> return data.ToArray();
>>
>> -------
>>
>> Summary of changes:
>> .../Api/Implementation/Plugins/SensorRepeat.cs | 19
>> +++
>> 1 files changed, 11 insertions(+), 8 deletions(-)
>> ___
>> Opensim-commits mailing list
>> opensim-comm...@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-commits
>>
>
>
--
dr dirk husemann virtual worlds research ibm zurich research lab
SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/
RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] No change author recorded in git! (was Re: [Opensim-commits] [OpenSim Git Master Repository] master branch updated. r/11319)
Justin Clark-Casey wrote:
Dr Scofield wrote:
Justin Clark-Casey wrote:
This looks like a great change but could we make sure that the Author field is
filled in on git am patches? Otherwise it's going to be a bit hard to tell who
to talk to about which changes...
perhaps it would be good to have the core committer sign-off on the patch? that
way we'd know who dragged it in...
Yes, I saw this on some of your commits (looks like the same format as Linux
kernel signoffs). I take it there's some standard git mechanism for doing this?
yes: "git --signoff --amend" once you've merge the patch on your local
system and BEFORE you do the push to master.
cheers,
dirk
If no-one objects then I'd very much like to see that turned on.
DrS
Best,
Justin
opensim-commits-boun...@lists.berlios.de wrote:
The branch, master has been updated
via 71c9291 Inconsistent locking of SenseRepeaters in Script Engine.
from b0923e0 Fix a glitch in a ROBUST message
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit 71c929137f48a0a7d97dbc866cbe2b12319aa40b
Author: unknown
Date: Fri Oct 23 03:52:49 2009 -0700
Inconsistent locking of SenseRepeaters in Script Engine.
When I attempt to 'save oar' on a region with thousands of scripts with timers, I get a NullReferenceException every time. The problem comes from inconsistent locking in SensorRepeat.cs of the SenseRepeaters List. It is iterated and modified in many places and these places are all wrapped in a lock except in the GetSerializationData(). This is the function throwing the exception because an item in the list becomes null during iteration.
The attached patch locks SenseRepeatListLock in GetSerializationData()
71c929137f48a0a7d97dbc866cbe2b12319aa40b
diff --git a/OpenSim/Region/ScriptEngine/Shared/Api/Implementation/Plugins/SensorRepeat.cs b/OpenSim/Region/ScriptEngine/Shared/Api/Implementation/Plugins/SensorRepeat.cs
index ee01c3c..b75a2e4 100644
--- a/OpenSim/Region/ScriptEngine/Shared/Api/Implementation/Plugins/SensorRepeat.cs
+++ b/OpenSim/Region/ScriptEngine/Shared/Api/Implementation/Plugins/SensorRepeat.cs
@@ -516,16 +516,19 @@ namespace OpenSim.Region.ScriptEngine.Shared.Api.Plugins
{
List data = "" List();
-foreach (SenseRepeatClass ts in SenseRepeaters)
+lock (SenseRepeatListLock)
{
-if (ts.itemID == itemID)
+foreach (SenseRepeatClass ts in SenseRepeaters)
{
-data.Add(ts.interval);
-data.Add(ts.name);
-data.Add(ts.keyID);
-data.Add(ts.type);
-data.Add(ts.range);
-data.Add(ts.arc);
+if (ts.itemID == itemID)
+{
+data.Add(ts.interval);
+data.Add(ts.name);
+data.Add(ts.keyID);
+data.Add(ts.type);
+data.Add(ts.range);
+data.Add(ts.arc);
+}
}
}
return data.ToArray();
---
Summary of changes:
.../Api/Implementation/Plugins/SensorRepeat.cs | 19 +++
1 files changed, 11 insertions(+), 8 deletions(-)
___
Opensim-commits mailing list
opensim-comm...@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-commits
--
dr dirk husemann math & computer science ibm zurich research lab
RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/
SL: drscofi...@xyzzyxyzzy.net - http://xyzzyxyzzy.net/
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] No change author recorded in git! (was Re: [Opensim-commits] [OpenSim Git Master Repository] master branch updated. r/11319)
dr scofield wrote: Justin Clark-Casey wrote: Dr Scofield wrote: Justin Clark-Casey wrote: This looks like a great change but could we make sure that the Author field is filled in on git am patches? Otherwise it's going to be a bit hard to tell who to talk to about which changes... perhaps it would be good to have the core committer sign-off on the patch? that way we'd know who dragged it in... Yes, I saw this on some of your commits (looks like the same format as Linux kernel signoffs). I take it there's some standard git mechanism for doing this? yes: "git --signoff --amend" once you've merge the patch on your local system and BEFORE you do the push to master. well, actually i meant: git commit --signoff --amend once you've merge the patch on your local system and BEFORE you do the push to master. was a bit too quick on sending that reply... cheers, DrS -- dr dirk husemann math & computer science ibm zurich research lab RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ SL: drscofi...@xyzzyxyzzy.net - http://xyzzyxyzzy.net/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Snowcrash's contributions - whether his eclectic license on SCEngine affects contributions to opensim master and specifically whether to accept patches relating to it. (Licensing.)
Snowcrash Short wrote: > I can see that I - or at least my license - has been the topic of > discussion on the -core mailing list. > > I would like to point out, that I have submitted all my patches, advise > and comments, both in mantis, the mailing list, the wiki and on the IRC > channel, in the spirit of the contribution guidelines. > > Consequently my patches in mantis is released to the public under BSD > Any comments on the wiki are under creative-commons Attribution-Share > Alike 2.5, and any advise given on IRC is considered by me to be in the > public domain. > > Whether or not, core will accept patches from me, would be of interest > to me, since preparing the patches takes time, which I could spend more > productively otherwise. there WAS some concern/confusion about licensing issues on -core and we've settled that. your patches (submitted under the OpenSim BSD license as are all other patches) will continue to be accepted on their technical merit --- again, like we treat all other submitted patches. your case is not the first one and certainly will not be the last one. we try to steer a straight course IP/licensing wise and sometimes we need to discuss issues and implications before reaching consensus (and, in true -core fashing, we sometimes do this in a rather engaged manner, jumping at the chance of having a really good debate). cheers, DrS > > Best regards > ps. I don't want to start any drama, just provide cool facts > pps. there is no sarcasm intended in this email. > > On Tue, 2009-10-20 at 12:27 -0400, Frisby, Adam wrote: >> OK, since I have a nagging feeling no-one read Teravus's original post in >> this long thread (and with a hope of putting this to rest). >> >> There are guidelines for the -core list, which are the following: >> If the topic can be discussed on dev, it should be. Core's scope is limited >> to issues related to commit access, licensing, money, server administrator >> and other 'meta' issues relating to running the project. No-one on dev is >> missing out on any development or code related discussion. Membership is >> limited to active committers (min. one commit in last 6 mo to maintain >> commit access & ML access). 'Votes' are done on consensus with any committer >> having full veto power. >> >> That said, DSVC is not a panacea to programming. Git is better than SVN at >> merging files; but it's still not excellent - Melanie puts in a ton of work >> each week in managing our various branches and bringing them together, >> conflicts and all. >> >> Until someone realises that DSVC needs to include language specific patterns >> (such as refactorings), there is still going to need to be a core project at >> the middle making sure the base works, and still a bunch more people who can >> update branches & forks accordingly. Otherwise maintaining distributions >> becomes an effort in trying to hit moving targets. >> >> Since it'll probably satisfy some of the people who are curious about what >> is discussed on core, here's the last 10 threads. (this represents probably >> 3-5 months of traffic, as I said before, it's low volume.) - as you can see, >> they all do fall into the guidelines listed above. >> >> Last 10 threads on opensim-core: >> 1. Snowcrash's contributions - whether his eclectic license on SCEngine >> affects contributions to opensim master and specifically whether to accept >> patches relating to it. (Licensing.) >> 2. Mantis stopped sending emails, can someone look? >> 3. Where is the CS2JK license? >> 4. Forwarded a request for a spokesperson to speak to someone studying OSS >> communities. >> 5. Stefan announcing his resignation (cc:'d to dev) >> 6. JHurliman commit access [redux]? >> 7. Sean changing projects at IBM, resignation. >> 8. JHurliman commit access? >> 9. Request for moderator access on the wiki. >> 10. Vote on go/no-go on git after trial. >> >> Regards, >> >> Adam >> >>> -Original Message- >>> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- >>> boun...@lists.berlios.de] On Behalf Of Dr Scofield >>> Sent: Tuesday, 20 October 2009 6:50 AM >>> To: opensim-dev@lists.berlios.de >>> Subject: Re: [Opensim-dev] The notion of "core" >>> >>> >>> Edward Middleton wrote: >>>> Teravus Ovares wrote: >>>>> ... Your argument was that the advent of the distributed source >>> control >>>>
Re: [Opensim-dev] Leaving Project
On 11/23/2009 03:13 PM, Len Brown wrote: > If the goal of OpenSim is to be incompatible with everyone elses vision > then I too have little further interest in the project. errm: the statement "OpenSim is not SecondLife" IS NOT EQUIVALENT to "the goal of OpenSim is to be incompatible with everyone elses vision". OpenSim aims to be a general purpose 3D platform. one "profile/application" of it allows us to run it in a (mostly) SecondLife compatible mode. > > I'd hoped after IBM dropped OpenSim like a hot potato that the devs Would love to see a quote from IBM on that! as far as i know and am aware of IBM is still using OpenSim big time and even including it as part of their IBM Sametime 3D service offering. DrS -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Leaving Project
On 11/23/2009 05:43 PM, Fly Man wrote: > Adam, > > You hit the nail right on his head with this passage: > > *The big problem here is there’s a very real lack of viewer developers > in this community – there is some overlap between server & network engineers > (like the OS community) and 3D Viewer Developers here, but not much. If > we do have 3D devs in the community who haven’t done anything and feel like > contributing – you really should be talking to some of the ‘next gen > viewer’ projects and seeing if we can get something awesome done faster. > * > And maybe someone should explain WHY people won't burn their hands on > the viewer > > Main reason: There's a clausule on the Website and internally about > "*Look at viewer code, and there's 6 months no working on OpenSim"* > > So any person that would like to keep working on OpenSim doesn't look at > viewer code, and vice versa. > > That's about the main reason that some viewer developers won't > co-operate with OpenSim and the other way, developers from OpenSim can't > help viewer developers that clause applies to the LL viewer and any viewer derived from it. there are independent viewer projects, however. -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Opensim Wave?
On 12/05/2009 02:21 AM, Rich White wrote: > XMPP/Jabber are also supported by OpenCobalt so further support of > XMPP by Opensim could prove to be a starting point to virtual world > convergence with regard to platforms. A bit more here - > http://roots.greenbush.us/?p=867 it would help to have a C# XMPP library that's license compatible with OpenSim's BSD-style license... cheers, dirk > > Cheers, > Rich > == > > On Fri, Dec 4, 2009 at 5:33 PM, Aldon Hynes > wrote: >> Okay, I must admit I've mostly been sitting on the sidelines recently. I >> still have OpenSim 0.5 installed on a computer or two... >> >> Anyway, there have been some interesting discussions recently about Second >> Life - Google Wave integration. Much of it is focused on the fact that >> Google Wave runs as a XMPP component (XEP-114). I seem to recall there had >> been some work with OpenSim/XMPP. Looking at it, it looks like OpenSim/XMPP >> is focused on OpenSim as an XMPP client instead of an XMPP component. >> >> Are there people around interested in OpenSim/Wave connectivity? Thoughts >> about what that might look like? Drop me a note if your interested. >> >> I do have a FedOne Wave server running and have been testing different >> clients and would love to share ideas. >> >> Aldon >> ___ >> Opensim-dev mailing list >> Opensim-dev@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> > > > -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Mumble & Voice
On 12/07/2009 04:09 PM, Robert A. Knop Jr. wrote: > On Mon, Dec 07, 2009 at 07:05:06AM -0800, Snoopy Pfeffer wrote: > >> My friend told me, that he will simply replace SLVoice.exe. That >> module provides an interface for the viewer and as long as that >> interface stays the same, no viewer changes are need. > > Excellent. > > As I mentioned, I think that that interface *did* change somewhere in > the viewer 1.22 or 1.23 cycle; I'm not sure how much it changed, and I > may be wrong and it may be that it didn't change at all. > i think snoopy's friend (who both happen to be friends of mine as well ;-) has captured the recent cycle IIRC... cheers, DrS -- dr dirk husemann ---- virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Leaving Project
On 01/04/2010 03:56 PM, Len Brown wrote: > Dr. Scofield, > > This is a two month old debate and issue, but since you quoted me from > back on November 23rd, I'd like to offer a bit of an update for you. > > After I'd been assured by others that my arguments were unsubstantiated > I was also assured by members of the development team that I would be > personally contacted to assist in some areas of development. > > I received no such communication from a single individual, even after > making cash donations to certain persons (as well as OSGrid) as a means > of saying thank you to them for the hard work they have done. > > As a result, I've spent the last month and a half doing my own custom > work on the project and have stopped waiting for good intentions from > those claiming to want my assistance. k. still puzzled how you arrived at the statement that "IBM dropped OpenSim like a hot potato"... cheers, DrS/dirk -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
On 01/07/2010 11:15 PM, Toni Alatalo wrote:
> Impalah Shenzhou kirjoitti:
>> http://www.dotnetnuke.com/
>> Is a CMS (like Alfresco, Drupal, Joomla...) but runs over .NET. It
>> shouldn't be too difficult to connect the native Opensim components to
>> get/set data instead of accessing directly to database.
>
> It is also possible to use some of the Python written CMSes and web
> frameworks (Django and such) and the Opensim .net code together.
> I'd do it with pythondotnet, which is a .net to Python bridge for the
> normal cpython that allows use of .net libs in py apps. I've used that
> to use LibOMV in Blender before - it runs the normal .net vm under the
> hood and just translates the types passed/returned in the method calls,
> performance has seemed ok and would certainly be fine for the management
> stuff I can imagine.
interesting, need to take a look at that one.
>
> Another option would be IronPython, some folks have tried running Django
> on it: http://jdhardy.blogspot.com/2008/12/django-ironpython.html but
> afaik that is still incomplete - probably some simpler web frameworks
> work fully on it already.
>
> To me using the opensim code instead of direct access to DB seems
> attractive, given that the schemas may change, and that it's easy to
> make a mess if have bugs in own code that work with the db differently
> than Opensim itself?
IMHO, accessing the DB directly is the worst thing that we can do. it begs for
trouble, so agree, we really ought to go via the OpenSim interfaces (a lot of
the RemoteAdmin XmlRpc calls were motivated by that).
DrS/dirk
--
dr dirk husemann virtual worlds research ibm zurich research lab
SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/
RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] TSB Feasibility Study: Online Virtual Worlds for Urban Regeneration Consultation
Ben Francis wrote: > Dear OpenSim community, > > I am working on a UK Government Technology Strategy Board funded > feasibility study into "using commercial gaming technology to improve > the user experience in the urban re-generation consultation process". > > My part of the study involves investigating using Online Virtual Worlds > to create an online resource that would help involve communities in the > re-development of urban areas. The idea is to create virtual worlds > which mirror real life cities and enable users to explore an accurate 3D > map of the area under consideration. The user would also be able to > create their own spatial designs from a library of 3D buildings and > other geographical primitives such as trees, plants, walls, fences etc. > > I am interested in including OpenSimulator in my study as a candidate > solution. I notice that early experiments into the importing of > geospatial data have taken place at slgis.org <http://slgis.org>. Is the > importing of geospatial data something that the OpenSimulator project is > actively pursuing or supporting and does anyone on this list have > experience of doing so? > > If geospatial applications or interest in integration with such > technology exists within the project, I would like to ask further > questions about OpenSimulator. Would it be OK to pose these questions to > this list? > > Thanks for your time > as we are looking at similar OpenSim applications, i'd be interested in learning more about this study. any links that we could follow up? cheers DrS/dirk -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] TSB Feasibility Study: Online Virtual Worlds for Urban Regeneration Consultation
Nebadon Izumi wrote: > *I woul like to add this URL to the conversation as well:* > > http://www.virtualwhite.com/?p=100 > > Hope this helps. it does. thx! DrS/dirk -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Status of voice
we are now looking at voice again more closely --- lots of other stuff kind of took precedence (i.e., necessary to get funding arranged :-) --- current port of call is research into a vivox voice module. -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Timezones, UTC, GMT & PST
Dahlia Trimble wrote: > With the err... um... inevitable future event when the LL grid opens the > doors to full interoperability, and given that their large customer base > is accustomed to using "SLT" (California time) and all the scripts that > may assume SLT, shouldn't we weigh that option over UTC or GMT or CUT or > whatever it's called these days? no. not at all. i'd like to have my regions running in CET (GMT +1) --- so, actually, i'd like to see everything run on UTC internally and have the region display whatever timezone its owner wants to use. for me this has a lot to do with respecting different cultures. while i kind of like california (well, parts of it anyhow), i'm also quite at home in good old europe ;-) > > On a side note, regions running in virtual machines may have less > control over the system clocks than regions running in a regular > machine. I'd like to suggest that region times could be configured in > OpenSim.ini and/or set by a central server using ntp or a similar protocol. do we really want to drag NTP into OpenSim? i can see the point, yes --- i can also see the point for delegating that to the underlying OS. also, if the internal time format were UTC we'd be able to tell the drift... cheers, DrS/dirk -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Timezones, UTC, GMT & PST
Melanie wrote: > And, as I said, I care about being _able_ to put time data on disk > in local time (NOT UTC + offset) with all local time quirks. > That doesn't have to be default, or trivial, but must remain possible. well, if you know the time data is always UTC, what difference does it make? -1 on the "must remain possible", it just unnecessarily complicates things. DrS/dirk -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Status of voice
Dirk Krause wrote: > Regarding voice: I very much liked the approach of having the Asterisk > connection, like you described in your blog entry. In general, I think SIP > etc. is the way to go - I mean how cool is it to pick up a phone and call > into an OpenSim voice meeting? And also being able to integrate with a > softphone? So I hope guys don't lose this vision ... > personally, i agree a 100% :-) -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] anon logins
Paul Fishwick wrote: > People do a lot of web-browsing and perhaps anon accounts will help better > integrate opensim with the web. Consider the following: > > 1. Someone is browsing the web for a topic such as "red wine" > 2. They get to various wine distributor and vineyard web pages > 3. They find out that one of the vineyards has a "hot link" to a 3D space > 4. They click on it and find themselves in the opensim world for the > vineyard > > We need to find ways of making it easier, and more transparent, to go > between > #2 and #4. It may be that a stepping-stone is required such as Xenki, > which is > browser embedded (before launching a full-blown viewer). > > Anon accounts may help because it is similar to unrestricted web browsing. > And, these accounts may ease the transition between #2 and #4, and thus > grow the metaverse. > interesting thoughts. we could give anonymous guests black and white avatars :-) i like the idea of a randomly chosen first (or last) name. we could even integrate that with gridinfo and the rezzme URI scheme and protocol handlers: a rezzme URI such as rezzme://anonymous%20anonym...@vineyard.com:9000/merlot/ could obtain as part of the mandatory gridinfo retrieval from vineyard.com:9000 also obtain an anonymous user name generated by the grid and the client would then use that as the avatar name; for example, vineyard.com's gridinfo might return Joe Anonymous the restriction on the anonymous user class would be as specified (and they'd get a black & white avatar :-) cheers, DrS/dirk -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] anon logins
Charles Krinke wrote: > Overweight tourist with a camera like There.com ?? > > But, yes, that is another good question, how should we represent the > avatar and what features should a sim allow to a guest avatar. All good > things to consider as we evolve the Metaverse off into the future. > > Personally, I would think a guest should have the ability to read > notecards, experience scripts, probably be able to "touch". Things that > would fit into the paradigm of a naive user entering the Metaverse for > the first time. > i like the idea of this being configurable per grid. > I like the browser Xenkii idea. I rather suspect most of these folks > will enter our Metaverse through some sort of browser interface as a > result of a hyperlink on a 'Flat Web Site'. or a rezzme: URI -- dr dirk husemann ---- virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Proposal for a cleanup/correction of the region-module system
MW wrote: > I have to say I'm not a big fan of what I've seen of mono.addins so far. > Maybe ExtensionLoader is better, so I do think we should look at that. > As I think it is better to only have one system of loading plugins/modules. > > As for initialise vs Initialize, hehe. Well personally I think it should > stay as it is. I really see no reason to change it. I do know of other > opensource projects that use initialise, Ogre being one. And it would be > as hard for me to remember to look/search for Initialize as it would be > for you to look for initialise. > > So my vote is a strong keep to UK english or even the mix we have > (because some bits are in US english). But I really don't think people > should have to switch code that is there to US english. Sorry thats a > point I do feel quite strongly on. > > But saying that if everyone else voted in favour of that switch I > wouldn't stand in the way. Just would think it was wrong. Any code I > write is just likely to have uk spelling. The same way any code you > write is likely to have US spelling. And opensim has had the UK spelling > from the start. so, +1 on keeping the UK spelling :-) DrS/dirk -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Proposal for a cleanup/correction of the region-module system
Charles Krinke wrote: > ROFL. Oh, it was the 'z' versus the 's' you were discussing. > > I thought it was the "i" versus the "I". ROFL. yeah, i can imagine there are folks out there that object to the capital "I" as being too capitalistic... -- dr dirk husemann ---- virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Proposal for a cleanup/correction of the region-module system
Ryan McDougall wrote: > My apologies for thread-jacking... > > I just want to be clear I didn't propose it because I came later and > decided I didn't like UK spelling. I am Canadian and historically > Canadians have used UK spelling. > > I proposed it for the same reason (US) English is the standard > language of all things international; business, science, open source, > etc: we have to pick one anyway, there will be more people unhappy > with the choice than happy, so might as well just pick the most common > one and suck it up. so, to balance things a bit, if we actually do want to standardize one spelling system, i'd say, let's standardize on the UK variant then, given that that is the one OpenSim was born with. -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Source tree cleanup
Sean Dague wrote: > Jeff Ames wrote: >> Hello, >> >> There are a few dusty corners in trunk from before >> forge.opensimulator.org was up, but I was wondering about moving them >> over, or merging them with core. [...] >> * share/python i've cleaned out that one. was just example code. -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Proposal for a cleanup/correction of the region-module system
MW wrote: > But do we standardize on one variant or standardise on that? > > Sorry couldn't stop myself :) that was a test :-) or was that a tezt? :-D DrS/dirk -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Source tree cleanup
while we are on the topic of cleaning up: could we move OpenSim/Region/Modules/* to (appropriate) subdirectories under OpenSim/Region/Environment/Modules? at least to me it's not clear what the difference between those two directories is (made worse by the fact that we have SvnSerializer in OpenSim/Region/Modules but the OAR archiver in OpenSim/Region/Environment/Modules. if there are no objections, i'd even do the move ;-) cheers, DrS/dirk -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Proposal for a cleanup/correction of the region-module system
Ideia Boa wrote: > I think it was a te5t not a te2t > :) oop5, m3 b4d. Dr5/d1rk > > > Dr Scofield wrote: >> MW wrote: >> >>> But do we standardize on one variant or standardise on that? >>> >>> Sorry couldn't stop myself :) >>> >> >> that was a test :-) or was that a tezt? :-D >> >> DrS/dirk >> >> >> > > > > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
[Opensim-dev] proposal: cleanup and break up region modules
i've been looking at where region modules live in our source tree --- OpenSim/Region/Modules and OpenSim/Region/Environment/Modules --- and how they get bundled: modules in OpenSim/Region/Modules get their own private DLL OpenSim/Region/Environment/Modules get lumped into ONE gigantic DLL off the 3 modules living in OpenSim/Region/Modules 2 might be good candidate for forge project: python and SvnSerializer. the third really belongs to the Terrain region module and seems to contain the default terrain effects. i think it would make sense to have all region modules living in the same neighborhood (i'd prefer OpenSim/Region/Modules), the current layout is a bit confusing break up the region module super-DLL so that each region module gets a DLL of its own this would make the whole region module business much more, err, modular (and, who knows, perhaps we'd even have one day a build system like the "make menuconfig" one found in the linux kernel tree) what is the general opinion on this? i'd be willing to undertake the refactoring (including tackling the prebuild.xml dragon). DrS/dirk -- dr dirk husemann virtual worlds research ---- ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] proposal: cleanup and break up region modules
Justin Clark-Casey wrote: > Dr Scofield wrote: >> i've been looking at where region modules live in our source tree --- >> OpenSim/Region/Modules and OpenSim/Region/Environment/Modules --- and >> how they get bundled: >> >> * modules in OpenSim/Region/Modules get their own private DLL >> * OpenSim/Region/Environment/Modules get lumped into ONE gigantic DLL >> >> off the 3 modules living in OpenSim/Region/Modules 2 might be good >> candidate for forge project: python and SvnSerializer. the third really >> belongs to the Terrain region module and seems to contain the default >> terrain effects. >> >> i think it would make sense to >> >> * have all region modules living in the same neighborhood (i'd >> prefer OpenSim/Region/Modules), the current layout is a bit confusing > > Don't we need to make a distinction between 'service' modules (such as the > REST module) and scene/environment modules > though? The former are not attached to a scene (and may well never be > concerned with scene code) while the latter are > very much scene related. that would be another step. first i'd like to get the modules settled in the same neighborhood. > >> * break up the region module super-DLL so that each region module >> gets a DLL of its own > > At least on mono, I'm guessing that this would vastly expand build times. > Certainly at the moment, each invocation of > mono to build a new assembly appears to take far longer than building many > files in a single dll. vastly? > > I also tend to think of the current modules in > OpenSim/Region/Environment/Modules as fairly core modules that one would > expect to be packaged together, and which it would be inconvenient to split > up. hmm...that kind of goes against the idea of them being modules, i'd think :-) -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] 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. -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] 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
Re: [Opensim-dev] proposal: cleanup and break up region modules
Sean Dague wrote: [...] > > That being said, this isn't an all or nothing approach. I'd say step > one, lets get the modules into a seperate dll (like diva suggested). > Then we can experiment with some level break up and see if it does cause > the end of the world. :) If so, we can quickly go back. that sounds like a good approach: move everything into OpenSim.Region.CoreModules (as MW suggested) and then take it (or not) from there with regards to separate DLLs. -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] TP protocol handle
Cristina Videira Lopes wrote: > Dirk, > > How do I make the SL viewer underline these things? > I still don't know what packet is involved, but I can see that urls like > these > http://slurl.com/secondlife/Foo/ > secondlife://Foo/ > result in something being sent to the server querying for region Foo. > That's all I need to make it happen. do you? what if Foo is on another grid? is that taken care by HG? > But this: > rezzme://Foo/ > doesn't. > > I mean, I can always do what I want via an OS scripting function, but if > there's a way of doing it via a simple click, that would be ideal. no. the SL client is not aware of the rezzme URI handler it then seems. i guess it all depends on how it picks up URI handlers... -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] TP protocol handle
Dr Scofield wrote: > Cristina Videira Lopes wrote: >> Dirk, >> >> How do I make the SL viewer underline these things? >> I still don't know what packet is involved, but I can see that urls like >> these >> http://slurl.com/secondlife/Foo/ >> secondlife://Foo/ >> result in something being sent to the server querying for region Foo. >> That's all I need to make it happen. > > do you? what if Foo is on another grid? is that taken care by HG? > >> But this: >> rezzme://Foo/ >> doesn't. >> >> I mean, I can always do what I want via an OS scripting function, but if >> there's a way of doing it via a simple click, that would be ideal. > > no. the SL client is not aware of the rezzme URI handler it then seems. i > guess > it all depends on how it picks up URI handlers... actually, i think the SL client needs to be modified so that it picks up RezzMe URIs. see my comment re hippo viewer. -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Organization and naming patterns of commands on the console
Justin Clark-Casey wrote: > Hello, > > I want to add more commands to the archiving module but I want to do this > within the module itself rather than adding > any specific logic to core. > > The terrain module already has a 'module commander' to help do this, but this > prefixes all commands with the word > terrain (e.g. terrain fill, terrain load, etc.) > > For consistency purposes, eventually I think that all console commands should > largely follow the same pattern. If we > the terrain module scheme, then we get the following kinds of changes (if we > assume that commands from different modules > can actually share the same initial 'keyword') > > backup=> region backup > create user => user create > create-region => region create > help users=> user help (for user commands) > show assets => assets show > show users=> user show > load-xml => region xml load (?) > load-oar => region oar load (?) > kickuser => user kick > > I think that the pros of this approach are that it makes it easy to avoid > name collisions and easy to distribute > commands to the right module. The console seem to include the fact that it's > not very intuitive (e.g. show users seems > easier to remember than user show) and it involves more typing in some cases > (e.g. region xml load rather than load-xml > or load xml). > > Any thoughts on this? Just kind of thinking about it at this stage - part of > me prefers typing things like "show users" > or "help terrain" while another part of my mind likes the 'tidiness' of > prefixing every module command with the same > word (e.g. terrain fill or region oar load). > +1 from me. -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Organization and naming patterns of commands on the console
Justin Clark-Casey wrote:
> Gary Chernega wrote:
>> A common parsing routine that used keywords as commands and triggered
>> off of those would work best.
>>
>> show users:>> users module receives: show
>> The parser would be looking for the module level first (users
>> etc), and since it is the 2nd word, it would strip it, and pass the
>> remaining text to the users module.
>>
>> users show:>> users module receives: show
>> The parser stripped module (users) from beginning, and passed
>> remainder of text line
>>
>> region load oar \filespec -x 123 -y 234:>> region module would
>> receive: load oar \filespec -x 123 -y 234
>>
>> Parser only parses off the module, and the command module decides what
>> to do with what it gets.
>>
>> So -> help region is functionally the same as region help
>> Or ->region load oar zzyy == load oar region zzyy == load oar zzyy
>> region (since region is stripped out no matter where it is, and
>> remainder is passed to region command handler)
>>
>> Am I clear enough in plain text?
>
> I see where you're going, although I'm not a great fan of "there's more than
> one way to execute that command", since it
> complicates the code and potentially the documentation.
me neither... reminds me a bit of an uncle of my wife (philosophy prof) who once
claimed that logically the sentences
"the lion roars"
and
"the roar lions"
would be the same... nobody quite believed him for some strange reason...
--
dr dirk husemann virtual worlds research ibm zurich research lab
SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/
RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] 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] refactored OpenSim.Region.Environment
hi all,
as you might have noticed, r8259 refactored
OpenSim.Region.Environment. This changeset is the step 1 of 2 in
refactoring OpenSim.Region.Environment into a "framework" part
and a modules only part. This first changeset refactors
OpenSim.Region.Environment.Scenes,OpenSim.Region.Environment.Interfaces,
and OpenSim.Region.Interfaces into
OpenSim.Region.Framework.{Interfaces,Scenes} leaving only region
modules in OpenSim.Region.Environment.
The next step will be to move region modules up from
OpenSim.Region.Environment.Modules to OpenSim.Region.CoreModules
and then sort out which modules are really core modules and which
should move out to forge.
I've been very careful to NOT BREAK anything. i hope i've
succeeded. as this is the work of a whole week i hope i managed
to keep track with the applied patches of the last week --- could
any of you that did check in stuff have a look at whether it
survived?
DrS/dirk
--
dr dirk husemann virtual worlds research ibm zurich research lab
SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/
RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] [Opensim-users] Circular dependency in 8262
Paul Fishwick wrote: > If prebuild creates the appropriate assembly references, it must have broken > in this version. There are numerous instances in VC# 2008 of bad references, > including: > > OpenSim.Data.Base > OpenSim.Data.MapperFactory > OpenSim.Data.MySQLMapper > > Could be others I am cc'ing the dev list. > in all likelihood r8259 is the one that breaks it, that introduced a refactoring of OpenSim.Region.Environment. prebuild.xml was changed as well, and i've probably introduced the VC#2008 problem then... as i'm not a windows dude, any hints will be appreciated. -- dr dirk husemann math & computer science ibm zurich research lab RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ SL: drscofi...@xyzzyxyzzy.net - http://xyzzyxyzzy.net/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] [Opensim-users] Circular dependency in 8262
Frank W Sweet wrote: > Guys, the latest svn will not compile. It complains that: "A circular > dependency involving project 'OpenSim.Framework.Communications' has > been detected." a concerted effort on the opensim-dev #IRC channel has sorted this one (and the bad refs) out! thx go to dahlia for providing VS 2008 compile service and lbsa71 for quickly tracking down that rogue OpenSim.Region.Framework ref in the OpenSim.Framework.Communications prebuild block. update to r8267 and VS 2008 should be sailing in calm waters again. good night, DrS/dirk -- 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] what are the core region modules? which are not?
i'm now working on step 2 of the OpenSim.Region.Environment refactor. here is a list of CoreModules and OptionalModules. clearly the later ones are candidates for moving to forge. any comments on the contents of these two lists? any modules that should not be in CoreModules (and any modules that should be in CoreModules)? Core region modules: CoreModules/Communications/REST CoreModules/Communications/Local CoreModules/Hypergrid CoreModules/World/TreePopulator CoreModules/World/Sound CoreModules/World/Land CoreModules/World/Terrain CoreModules/World/Terrain/FloodBrushes CoreModules/World/Terrain/FileLoaders CoreModules/World/Terrain/PaintBrushes CoreModules/World/Terrain/Effects CoreModules/World/Terrain/Tests CoreModules/World/Estate CoreModules/World/Wind CoreModules/World/Vegetation CoreModules/World/Sun CoreModules/World/Permissions CoreModules/World/WorldMap CoreModules/World/Archiver CoreModules/World/Archiver/Tests CoreModules/World/Serialiser CoreModules/Agent/TextureDownload CoreModules/Agent/Capabilities CoreModules/Agent/TextureSender CoreModules/Agent/TextureSender/Tests CoreModules/Agent/AssetTransaction CoreModules/Agent/Xfer CoreModules/Framework/EventQueue CoreModules/Framework/InterfaceCommander CoreModules/Scripting/XMLRPC CoreModules/Scripting/LoadImageURL CoreModules/Scripting/DynamicTexture CoreModules/Scripting/EMailModules CoreModules/Scripting/VectorRender CoreModules/Scripting/WorldComm CoreModules/Scripting/HttpRequest CoreModules/Grid/Interregion CoreModules/Avatar/Groups CoreModules/Avatar/Lure CoreModules/Avatar/InstantMessage CoreModules/Avatar/AvatarFactory CoreModules/Avatar/Inventory/Transfer CoreModules/Avatar/Inventory/Archiver CoreModules/Avatar/Profiles CoreModules/Avatar/Gestures CoreModules/Avatar/Friends CoreModules/Avatar/ObjectCaps CoreModules/Avatar/Chat CoreModules/Avatar/Currency/SampleMoney CoreModules/Avatar/Dialog Optional region modules: OptionalModules/World/NPC OptionalModules/Avatar/Voice OptionalModules/Avatar/Voice/AsterixVoice OptionalModules/Avatar/Voice/SIPVoice OptionalModules/Avatar/Concierge OptionalModules/Avatar/Combat OptionalModules/Avatar/Chat OptionalModules/ContentManagementSystem OptionalModules/InterGrid -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] what are the core region modules? which are not?
Dr Scofield wrote: > i'm now working on step 2 of the OpenSim.Region.Environment refactor. > here is a list of CoreModules and OptionalModules. clearly the later > ones are candidates for moving to forge. any comments on the contents of > these two lists? any modules that should not be in CoreModules (and any > modules that should be in CoreModules)? oh...and forgot OpenSim.Region.Modules! -> OptionalModules? > > Core region modules: > > CoreModules/Communications/REST > CoreModules/Communications/Local > CoreModules/Hypergrid > CoreModules/World/TreePopulator > CoreModules/World/Sound > CoreModules/World/Land > CoreModules/World/Terrain > CoreModules/World/Terrain/FloodBrushes > CoreModules/World/Terrain/FileLoaders > CoreModules/World/Terrain/PaintBrushes > CoreModules/World/Terrain/Effects > CoreModules/World/Terrain/Tests > CoreModules/World/Estate > CoreModules/World/Wind > CoreModules/World/Vegetation > CoreModules/World/Sun > CoreModules/World/Permissions > CoreModules/World/WorldMap > CoreModules/World/Archiver > CoreModules/World/Archiver/Tests > CoreModules/World/Serialiser > CoreModules/Agent/TextureDownload > CoreModules/Agent/Capabilities > CoreModules/Agent/TextureSender > CoreModules/Agent/TextureSender/Tests > CoreModules/Agent/AssetTransaction > CoreModules/Agent/Xfer > CoreModules/Framework/EventQueue > CoreModules/Framework/InterfaceCommander > CoreModules/Scripting/XMLRPC > CoreModules/Scripting/LoadImageURL > CoreModules/Scripting/DynamicTexture > CoreModules/Scripting/EMailModules > CoreModules/Scripting/VectorRender > CoreModules/Scripting/WorldComm > CoreModules/Scripting/HttpRequest > CoreModules/Grid/Interregion > CoreModules/Avatar/Groups > CoreModules/Avatar/Lure > CoreModules/Avatar/InstantMessage > CoreModules/Avatar/AvatarFactory > CoreModules/Avatar/Inventory/Transfer > CoreModules/Avatar/Inventory/Archiver > CoreModules/Avatar/Profiles > CoreModules/Avatar/Gestures > CoreModules/Avatar/Friends > CoreModules/Avatar/ObjectCaps > CoreModules/Avatar/Chat > CoreModules/Avatar/Currency/SampleMoney > CoreModules/Avatar/Dialog > > Optional region modules: > > OptionalModules/World/NPC > OptionalModules/Avatar/Voice > OptionalModules/Avatar/Voice/AsterixVoice > OptionalModules/Avatar/Voice/SIPVoice > OptionalModules/Avatar/Concierge > OptionalModules/Avatar/Combat > OptionalModules/Avatar/Chat > OptionalModules/ContentManagementSystem > OptionalModules/InterGrid > -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] what are the core region modules? which are not?
Justin Clark-Casey wrote: > Dr Scofield wrote: >> i'm now working on step 2 of the OpenSim.Region.Environment refactor. >> here is a list of CoreModules and OptionalModules. clearly the later >> ones are candidates for moving to forge. any comments on the contents of >> these two lists? any modules that should not be in CoreModules (and any >> modules that should be in CoreModules)? > > Could you tell us what criteria you're using for this? the following: Core should be anything that is (a) referenced directly or indirectly from outside CoreModules/OptionalModules (b) is necessary to provide the base 3D/VW user experience and, admittedly, this is a rough view and i'm the first to admit that i misclassified, hence my request for comments! :-) > >> Core region modules: >> >> CoreModules/Communications/REST >> CoreModules/Communications/Local referenced directly. >> CoreModules/Hypergrid dito. >> CoreModules/World/TreePopulator >> CoreModules/World/Sound >> CoreModules/World/Land >> CoreModules/World/Terrain >> CoreModules/World/Terrain/FloodBrushes >> CoreModules/World/Terrain/FileLoaders >> CoreModules/World/Terrain/PaintBrushes >> CoreModules/World/Terrain/Effects >> CoreModules/World/Terrain/Tests >> CoreModules/World/Estate >> CoreModules/World/Wind >> CoreModules/World/Vegetation >> CoreModules/World/Sun >> CoreModules/World/Permissions >> CoreModules/World/WorldMap >> CoreModules/World/Archiver >> CoreModules/World/Archiver/Tests >> CoreModules/World/Serialiser not sure whether ALL of these are core. so in dubio pro reo. >> CoreModules/Agent/TextureDownload >> CoreModules/Agent/Capabilities >> CoreModules/Agent/TextureSender >> CoreModules/Agent/TextureSender/Tests >> CoreModules/Agent/AssetTransaction >> CoreModules/Agent/Xfer those seem to contribute essential services. >> CoreModules/Framework/EventQueue >> CoreModules/Framework/InterfaceCommander dito. >> CoreModules/Scripting/XMLRPC >> CoreModules/Scripting/LoadImageURL >> CoreModules/Scripting/DynamicTexture >> CoreModules/Scripting/EMailModules >> CoreModules/Scripting/VectorRender >> CoreModules/Scripting/WorldComm >> CoreModules/Scripting/HttpRequest required for script engines, i guess. in dubio pro reo. >> CoreModules/Grid/Interregion required for Grid mode, i guess. >> CoreModules/Avatar/Groups rudimentary group support. >> CoreModules/Avatar/Lure teleport lures. >> CoreModules/Avatar/InstantMessage i consider this core functionality. >> CoreModules/Avatar/AvatarFactory referenced directly. >> CoreModules/Avatar/Inventory/Transfer >> CoreModules/Avatar/Inventory/Archiver i consider this core functionality. >> CoreModules/Avatar/Profiles >> CoreModules/Avatar/Gestures >> CoreModules/Avatar/Friends >> CoreModules/Avatar/ObjectCaps >> CoreModules/Avatar/Chat/ChatModule dito. >> CoreModules/Avatar/Currency/SampleMoney i don't consider this core functionality, but it's referenced. >> CoreModules/Avatar/Dialog core functionality. >> >> Optional region modules: >> >> OptionalModules/World/NPC >> OptionalModules/Avatar/Voice >> OptionalModules/Avatar/Voice/AsterixVoice >> OptionalModules/Avatar/Voice/SIPVoice none of the voice modules has working client counter part so far. so, definitely optional. >> OptionalModules/Avatar/Concierge definitely optional. >> OptionalModules/Avatar/Combat where does this come from and how is it being used? >> OptionalModules/Avatar/Chat/IRC-stuff i'd consider this optional. >> OptionalModules/ContentManagementSystem same here. >> OptionalModules/InterGrid ok, this could be a CoreModule on the same level as HyperGrid...it's just that HyperGrid seems to be much more advanced and we made the decision to move it from forge to core. as i said, i'd LOVE to hear on this and get this sorted. -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] what are the core region modules? which are not?
Melanie wrote: > Two chat modules? The chat module should certainly be core. sorry. typo. one ChatModule in Core and IRC stuff (which lived in Chat module subdir) which i'd like to move to Optional. DrS/dirk > > Melanie > > > Dr Scofield wrote: >> Dr Scofield wrote: >>> i'm now working on step 2 of the OpenSim.Region.Environment refactor. >>> here is a list of CoreModules and OptionalModules. clearly the later >>> ones are candidates for moving to forge. any comments on the contents of >>> these two lists? any modules that should not be in CoreModules (and any >>> modules that should be in CoreModules)? >> oh...and forgot OpenSim.Region.Modules! -> OptionalModules? >>> Core region modules: >>> >>> CoreModules/Communications/REST >>> CoreModules/Communications/Local >>> CoreModules/Hypergrid >>> CoreModules/World/TreePopulator >>> CoreModules/World/Sound >>> CoreModules/World/Land >>> CoreModules/World/Terrain >>> CoreModules/World/Terrain/FloodBrushes >>> CoreModules/World/Terrain/FileLoaders >>> CoreModules/World/Terrain/PaintBrushes >>> CoreModules/World/Terrain/Effects >>> CoreModules/World/Terrain/Tests >>> CoreModules/World/Estate >>> CoreModules/World/Wind >>> CoreModules/World/Vegetation >>> CoreModules/World/Sun >>> CoreModules/World/Permissions >>> CoreModules/World/WorldMap >>> CoreModules/World/Archiver >>> CoreModules/World/Archiver/Tests >>> CoreModules/World/Serialiser >>> CoreModules/Agent/TextureDownload >>> CoreModules/Agent/Capabilities >>> CoreModules/Agent/TextureSender >>> CoreModules/Agent/TextureSender/Tests >>> CoreModules/Agent/AssetTransaction >>> CoreModules/Agent/Xfer >>> CoreModules/Framework/EventQueue >>> CoreModules/Framework/InterfaceCommander >>> CoreModules/Scripting/XMLRPC >>> CoreModules/Scripting/LoadImageURL >>> CoreModules/Scripting/DynamicTexture >>> CoreModules/Scripting/EMailModules >>> CoreModules/Scripting/VectorRender >>> CoreModules/Scripting/WorldComm >>> CoreModules/Scripting/HttpRequest >>> CoreModules/Grid/Interregion >>> CoreModules/Avatar/Groups >>> CoreModules/Avatar/Lure >>> CoreModules/Avatar/InstantMessage >>> CoreModules/Avatar/AvatarFactory >>> CoreModules/Avatar/Inventory/Transfer >>> CoreModules/Avatar/Inventory/Archiver >>> CoreModules/Avatar/Profiles >>> CoreModules/Avatar/Gestures >>> CoreModules/Avatar/Friends >>> CoreModules/Avatar/ObjectCaps >>> CoreModules/Avatar/Chat >>> CoreModules/Avatar/Currency/SampleMoney >>> CoreModules/Avatar/Dialog >>> >>> Optional region modules: >>> >>> OptionalModules/World/NPC >>> OptionalModules/Avatar/Voice >>> OptionalModules/Avatar/Voice/AsterixVoice >>> OptionalModules/Avatar/Voice/SIPVoice >>> OptionalModules/Avatar/Concierge >>> OptionalModules/Avatar/Combat >>> OptionalModules/Avatar/Chat >>> OptionalModules/ContentManagementSystem >>> OptionalModules/InterGrid >>> >> > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] what are the core region modules? which are not?
Melanie wrote: > Hi, > > I believe TreePopulator should be an optional module. k. > Conversely, > Combat is required to be present for the llSetDamage() and related > functions as well as the damage setting in the viewer to work > properly and should therefore be core. ah. ok, makes sense. updated list to follow. > > Melanie > > > Dr Scofield wrote: >> i'm now working on step 2 of the OpenSim.Region.Environment refactor. >> here is a list of CoreModules and OptionalModules. clearly the later >> ones are candidates for moving to forge. any comments on the contents of >> these two lists? any modules that should not be in CoreModules (and any >> modules that should be in CoreModules)? >> >> Core region modules: >> >> CoreModules/Communications/REST >> CoreModules/Communications/Local >> CoreModules/Hypergrid >> CoreModules/World/TreePopulator >> CoreModules/World/Sound >> CoreModules/World/Land >> CoreModules/World/Terrain >> CoreModules/World/Terrain/FloodBrushes >> CoreModules/World/Terrain/FileLoaders >> CoreModules/World/Terrain/PaintBrushes >> CoreModules/World/Terrain/Effects >> CoreModules/World/Terrain/Tests >> CoreModules/World/Estate >> CoreModules/World/Wind >> CoreModules/World/Vegetation >> CoreModules/World/Sun >> CoreModules/World/Permissions >> CoreModules/World/WorldMap >> CoreModules/World/Archiver >> CoreModules/World/Archiver/Tests >> CoreModules/World/Serialiser >> CoreModules/Agent/TextureDownload >> CoreModules/Agent/Capabilities >> CoreModules/Agent/TextureSender >> CoreModules/Agent/TextureSender/Tests >> CoreModules/Agent/AssetTransaction >> CoreModules/Agent/Xfer >> CoreModules/Framework/EventQueue >> CoreModules/Framework/InterfaceCommander >> CoreModules/Scripting/XMLRPC >> CoreModules/Scripting/LoadImageURL >> CoreModules/Scripting/DynamicTexture >> CoreModules/Scripting/EMailModules >> CoreModules/Scripting/VectorRender >> CoreModules/Scripting/WorldComm >> CoreModules/Scripting/HttpRequest >> CoreModules/Grid/Interregion >> CoreModules/Avatar/Groups >> CoreModules/Avatar/Lure >> CoreModules/Avatar/InstantMessage >> CoreModules/Avatar/AvatarFactory >> CoreModules/Avatar/Inventory/Transfer >> CoreModules/Avatar/Inventory/Archiver >> CoreModules/Avatar/Profiles >> CoreModules/Avatar/Gestures >> CoreModules/Avatar/Friends >> CoreModules/Avatar/ObjectCaps >> CoreModules/Avatar/Chat >> CoreModules/Avatar/Currency/SampleMoney >> CoreModules/Avatar/Dialog >> >> Optional region modules: >> >> OptionalModules/World/NPC >> OptionalModules/Avatar/Voice >> OptionalModules/Avatar/Voice/AsterixVoice >> OptionalModules/Avatar/Voice/SIPVoice >> OptionalModules/Avatar/Concierge >> OptionalModules/Avatar/Combat >> OptionalModules/Avatar/Chat >> OptionalModules/ContentManagementSystem >> OptionalModules/InterGrid >> > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
[Opensim-dev] UPDATE: Re: what are the core region modules? which are not?
[update following input from melanie] i'm now working on step 2 of the OpenSim.Region.Environment refactor. here is a list of CoreModules and OptionalModules. clearly the later ones are candidates for moving to forge. any comments on the contents of these two lists? any modules that should not be in CoreModules (and any modules that should be in CoreModules)? == proposed list of CORE region modules: == CoreModules/Agent/AssetTransaction CoreModules/Agent/Capabilities CoreModules/Agent/TextureDownload CoreModules/Agent/TextureSender CoreModules/Agent/TextureSender/Tests CoreModules/Agent/Xfer CoreModules/Avatar/AvatarFactory CoreModules/Avatar/Chat/ChatModule CoreModules/Avatar/Combat CoreModules/Avatar/Currency/SampleMoney CoreModules/Avatar/Dialog CoreModules/Avatar/Friends CoreModules/Avatar/Gestures CoreModules/Avatar/Groups CoreModules/Avatar/InstantMessage CoreModules/Avatar/Inventory/Archiver CoreModules/Avatar/Inventory/Transfer CoreModules/Avatar/Lure CoreModules/Avatar/ObjectCaps CoreModules/Avatar/Profiles CoreModules/Communications/Local CoreModules/Communications/REST CoreModules/Framework/EventQueue CoreModules/Framework/InterfaceCommander CoreModules/Grid/Interregion CoreModules/Hypergrid CoreModules/Scripting/DynamicTexture CoreModules/Scripting/EMailModules CoreModules/Scripting/HttpRequest CoreModules/Scripting/LoadImageURL CoreModules/Scripting/VectorRender CoreModules/Scripting/WorldComm CoreModules/Scripting/XMLRPC CoreModules/World/Archiver CoreModules/World/Archiver/Tests CoreModules/World/Estate CoreModules/World/Land CoreModules/World/Permissions CoreModules/World/Serialiser CoreModules/World/Sound CoreModules/World/Sun CoreModules/World/Terrain CoreModules/World/Terrain/Effects CoreModules/World/Terrain/FileLoaders CoreModules/World/Terrain/FloodBrushes CoreModules/World/Terrain/PaintBrushes CoreModules/World/Terrain/Tests CoreModules/World/Vegetation CoreModules/World/Wind CoreModules/World/WorldMap == proposed list of OPTIONAL region modules (forge candidates): == OptionalModules/Avatar/Chat/IRC-stuff OptionalModules/Avatar/Concierge OptionalModules/Avatar/Voice OptionalModules/Avatar/Voice/AsterixVoice OptionalModules/Avatar/Voice/SIPVoice OptionalModules/ContentManagementSystem OptionalModules/InterGrid OptionalModules/World/NPC OptionalModules/World/TreePopulator -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
[Opensim-dev] UPDATE[2]: Re: what are the core region modules? which are not?
[update following input from melanie, justincc] i'm now working on step 2 of the OpenSim.Region.Environment refactor. here is a list of CoreModules and OptionalModules. clearly the later ones are candidates for moving to forge. any comments on the contents of these two lists? any modules that should not be in CoreModules (and any modules that should be in CoreModules)? anyone know about Modules/Python and/or Environment/Modules/Grid/Interregion??? == proposed list of CORE region modules: == CoreModules/Agent/AssetTransaction CoreModules/Agent/Capabilities CoreModules/Agent/TextureDownload CoreModules/Agent/TextureSender CoreModules/Agent/TextureSender/Tests CoreModules/Agent/Xfer CoreModules/Avatar/AvatarFactory CoreModules/Avatar/Chat/ChatModule CoreModules/Avatar/Combat CoreModules/Avatar/Currency/SampleMoney CoreModules/Avatar/Dialog CoreModules/Avatar/Friends CoreModules/Avatar/Gestures CoreModules/Avatar/Groups CoreModules/Avatar/InstantMessage CoreModules/Avatar/Inventory/Archiver CoreModules/Avatar/Inventory/Transfer CoreModules/Avatar/Lure CoreModules/Avatar/ObjectCaps CoreModules/Avatar/Profiles CoreModules/Communications/Local CoreModules/Communications/REST CoreModules/Framework/EventQueue CoreModules/Framework/InterfaceCommander CoreModules/Hypergrid CoreModules/Scripting/DynamicTexture CoreModules/Scripting/EMailModules CoreModules/Scripting/HttpRequest CoreModules/Scripting/LoadImageURL CoreModules/Scripting/VectorRender CoreModules/Scripting/WorldComm CoreModules/Scripting/XMLRPC CoreModules/World/Archiver CoreModules/World/Archiver/Tests CoreModules/World/Estate CoreModules/World/Land CoreModules/World/Permissions CoreModules/World/Serialiser CoreModules/World/Sound CoreModules/World/Sun CoreModules/World/Terrain CoreModules/World/Terrain/Effects CoreModules/World/Terrain/FileLoaders CoreModules/World/Terrain/FloodBrushes CoreModules/World/Terrain/PaintBrushes CoreModules/World/Terrain/Tests CoreModules/World/Vegetation CoreModules/World/Wind CoreModules/World/WorldMap == proposed list of OPTIONAL region modules (forge candidates): == OptionalModules/Avatar/Chat/IRC-stuff OptionalModules/Avatar/Concierge OptionalModules/Avatar/Voice OptionalModules/Avatar/Voice/AsterixVoice OptionalModules/Avatar/Voice/SIPVoice OptionalModules/ContentManagementSystem OptionalModules/InterGrid OptionalModules/World/NPC OptionalModules/World/TreePopulator == proposed list of DEAD region modules: == Modules/Python Environment/Modules/Grid/Interregion -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] UPDATE[2]: Re: what are the core region modules? which are not?
Alan M Webb wrote: > > Based upon Melanie's remarks, it would seem useful to annotate each of > these with the core functionality that they support - as in Melanie's > example. With that annotation, the reasoning for the grouping would be > evident. sigh. guess a wiki page would be better? > > Best regards > Alan > --- > T.J. Watson Research Center, Hawthorne, NY > 1-914-784-7286 > alan_w...@us.ibm.com > > > From: Dr Scofield > To: opensim-dev@lists.berlios.de > Date: 02/09/2009 11:14 AM > Subject: [Opensim-dev] UPDATE[2]: Re: what are the core region modules? > which are not? > > > > > > > [update following input from melanie, justincc] > > i'm now working on step 2 of the OpenSim.Region.Environment refactor. > here is a list of CoreModules and OptionalModules. clearly the later > ones are candidates for moving to forge. any comments on the contents of > these two lists? any modules that should not be in CoreModules (and any > modules that should be in CoreModules)? > > anyone know about Modules/Python and/or > Environment/Modules/Grid/Interregion??? > > == proposed list of CORE region modules: == > > CoreModules/Agent/AssetTransaction > CoreModules/Agent/Capabilities > CoreModules/Agent/TextureDownload > CoreModules/Agent/TextureSender > CoreModules/Agent/TextureSender/Tests > CoreModules/Agent/Xfer > > CoreModules/Avatar/AvatarFactory > CoreModules/Avatar/Chat/ChatModule > CoreModules/Avatar/Combat > CoreModules/Avatar/Currency/SampleMoney > CoreModules/Avatar/Dialog > CoreModules/Avatar/Friends > CoreModules/Avatar/Gestures > CoreModules/Avatar/Groups > CoreModules/Avatar/InstantMessage > CoreModules/Avatar/Inventory/Archiver > CoreModules/Avatar/Inventory/Transfer > CoreModules/Avatar/Lure > CoreModules/Avatar/ObjectCaps > CoreModules/Avatar/Profiles > > CoreModules/Communications/Local > CoreModules/Communications/REST > > CoreModules/Framework/EventQueue > CoreModules/Framework/InterfaceCommander > > CoreModules/Hypergrid > > CoreModules/Scripting/DynamicTexture > CoreModules/Scripting/EMailModules > CoreModules/Scripting/HttpRequest > CoreModules/Scripting/LoadImageURL > CoreModules/Scripting/VectorRender > CoreModules/Scripting/WorldComm > CoreModules/Scripting/XMLRPC > > CoreModules/World/Archiver > CoreModules/World/Archiver/Tests > CoreModules/World/Estate > CoreModules/World/Land > CoreModules/World/Permissions > CoreModules/World/Serialiser > CoreModules/World/Sound > CoreModules/World/Sun > CoreModules/World/Terrain > CoreModules/World/Terrain/Effects > CoreModules/World/Terrain/FileLoaders > CoreModules/World/Terrain/FloodBrushes > CoreModules/World/Terrain/PaintBrushes > CoreModules/World/Terrain/Tests > CoreModules/World/Vegetation > CoreModules/World/Wind > CoreModules/World/WorldMap > > > == proposed list of OPTIONAL region modules (forge candidates): == > > OptionalModules/Avatar/Chat/IRC-stuff > OptionalModules/Avatar/Concierge > OptionalModules/Avatar/Voice > OptionalModules/Avatar/Voice/AsterixVoice > OptionalModules/Avatar/Voice/SIPVoice > > OptionalModules/ContentManagementSystem > > OptionalModules/InterGrid > > OptionalModules/World/NPC > OptionalModules/World/TreePopulator > > > == proposed list of DEAD region modules: == > > Modules/Python > Environment/Modules/Grid/Interregion > > > > -- > dr dirk husemann virtual worlds research ibm zurich research lab > SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ > RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ > > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > > > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] what are the core region modules? which are not?
Sean Dague wrote: > Dahlia Trimble wrote: >> When a module moves out of core and to forge, what process would be in place >> to make sure these modules remain compatible when possibly breaking changes >> are made to core? I use the IRC module in some of my regions and I wouldn't >> want to see it broken, and I like to stay close to head in all of my regions >> so I can be more aware of how development progresses. As such I would >> potentially vote -1 on taking IRC out of core until there is some way to >> maintain functionality as core evolves. > > I'm personally all for moving thinks to an Optional space, but we have > to be honest with ourselves, moving a module to the forge means that > there is a better than 50% chance it's unusable in 2 weeks time. I > think for things we've considered "dead" that's fine, but I'd be > reluctant to push bits out that people do regularly use (like the irc > bridge). At least until we have: > > 1. an easy way to build an out of core module build tree > 2. network repository support for modules (ala what's in mono addins) > 3. some type of versioning on module interfaces, so we can know if a > plugin thinks it can work with the current build > > Otherwise we are more or less jetisoning a lot of features and reducing > the number of users that we can serve out of the box. The same logic > that would leave these modules in the tree is the same logic that keeps > all the extra stuff in bin/, to make it easy for the new user to get > started. > > This shouldn't stop this current level of reorganization, which I think > is very useful. But is just a warning on next steps of removing things > from the tree. i agree on all of that. my plan was to currently ONLY SORT the modules into CoreModules and OptionalModules --- NOT REMOVE them. dahlia has a point on the stability of our APIs and we'd need to find good maintainers first for modules before moving them off to forge. DrS/dirk -- 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
