Re: [Opensim-dev] Opensim beginner

[Stefan Andersson]

I would presume you also need to schedule the prim for a terse or a full
update.

 

/Stefan

 

From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Nilushi perera
Sent: den 12 februari 2010 07:16
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Opensim beginner

 

Hi
I could successfully build the opensim workspace and run the helloworld
region module. Now I am looking for more programming stuff. I tried to
change the color of hello prim. But it didnt change. Here is the code:

  SceneObjectPart sop = new SceneObjectPart();
  sop.UUID = new UUID();
  sop.CreatorID = UUID.Zero;
  sop.Shape = PrimitiveBaseShape.CreateBox();
  sop.Material = (byte)Material.Metal;
  Color color1 = Color.FromArgb(255, 255, 0, 0);
  sop.Color = color1;
  sop.Scale = new Vector3(0.3f, 0.3f, 2f);
  Vector3 pos = new Vector3(120, 128, 30);
  SceneObjectGroup sog = new SceneObjectGroup(UUID.Zero, pos,
PrimitiveBaseShape.CreateBox());
  sog.SetRootPart(sop);
  prims1.Add(sog);

Please can you help me & give some suggestions. 



On Fri, Feb 12, 2010 at 1:12 AM, Robert Martin  wrote:

On Thu, Feb 11, 2010 at 12:15 PM, Nilushi perera 
wrote:
> Hi
>

> Thank you very much for your immediate response Michael and Robert. I'll
go
> through those links and instructions. I'll let you know my status after
> following your instructions Robert.
>
> Thank You
>

as far as how to make the stuff if you have a SecondLife account send
me a message
(robertltux mccallen) and i can give you a few pointers and you can
also google for
|| mermaid diaries secondlife || for a few tutorials



--
Robert L Martin

 

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

Re: [Opensim-dev] How Was OpenSim "Born"?

[Stefan Andersson]

I just had a quick look, and I think 01-03 is in the git repo; for some
reason the version naming scheme that was introduced around 0.4 has gotten
corrupted on the earlier versions; at least the 'origin' branches

 

0.1-prestable

Sugilite

Tourmaline

Ruby

Zircon


And quite possibly "Standalone"

 

Reflect early versions - one need to dig deeper to remember which is what
though.

 

(That work should be fun to do for the so inclined, and should probably go
on the history page as well)

 

/Stefan

 

 

 

From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Len Brown
Sent: den 11 februari 2010 11:40
To: opensim-dev@lists.berlios.de
Subject: [Opensim-dev] How Was OpenSim "Born"?

 

Hello everyone!

 I know that the various versions of the viewer are derived from Linden
Lab releasing the viewer source code as open source, but what about the
server side of things?

 Is what we now call OpenSim the result of taking what we know about the
viewer and working backwards to how we presume the server pushes the
information to it?  This would be my guess.

 I don't ever recall there being any releases of the early server source
code ever made available.  This thought hit me when I started wondering how
Open Simulator originated if the Linden Lab server source was never made
publicly available.

 The Open Simulator site dist directory goes back to OpenSim 0.4 so I'm
a bit mystified.  I started messing with OpenSim at version 0.6 and on.

 Thanks for any info offered on this topic.  I've been active in Second
Life since December 2003 and am just wanting to flesh out a bit of the
historical side of things, when it comes to OpenSim beginnings.

-- 
- Len W. Brown 
  lenwbr...@gmail.com 

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

Re: [Opensim-dev] peticion de ayuda

[Stefan Andersson]

So, I guess we will need a to devise a format, protocol or app named PADL.
What will the acronym stand for?

 

/Stefan

 

From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of James Stallings
II
Sent: den 5 februari 2010 14:51
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] peticion de ayuda

 

Yeah,

 

It's bad, but often bridges an otherwise unbridgeable language gap, so I
tend to employ it even though :)

 

 

Cheers!

 

 

James

SimHost.com

2010/2/5 Impalah Shenzhou 

I thought my english was bad, but I've discovered that Google's
spanish is even worse.

:-P

It translated literally OAR
(http://www.wordreference.com/es/translation.asp?tranword=oar).

Thanks for the morning laughs, James



El 04/02/10, James Stallings II  escribió:

> Hola Juan Felipe,
> Mi compañero de trabajo Nebadon Izumi alberga algunos archivos OAR muy
útil
> en http://nebadon2025.com/oars
>
> Ellos pueden o no pueden satisfacer sus necesidades específicas, pero
usted
> puede encontrar algunas cosas útiles allí.
>
> Buena suerte amigo!
>
> ¡Salud!
> James Stallings
> SimHost.com
>
> 2010/2/4 James Stallings II 
>
>> Hola y como estas, John Felipe,
>>
>> Hay un remo de algunos archivos de un lado - Voy a ver si puedo encontrar
>> la ubicación de algunos de los mejores para usted cuando el creador de
los
>> artículos es de alrededor. Yo recomendaría a visitar la red os en la
>> región 'Wright Plaza' y 'Samsara' productos gratis, que luego puede
>> utilizar
>> para crear un archivo de IAR para el transporte a su mundo virtual.
Espero
>> que esto ayude:)
>>
>> On Thu, Feb 4, 2010 at 7:17 AM, J Ross Nicoll
> > wrote:
>>
>>> I don't even recognise the language!
>>>
>>
>> The language is spanish.
>>
>>
>>>
>>> elanie wrote:
>>> > Hi,
>>> >
>>> > the mailing list language is English. I doubt many can understand
>>> > your question.
>>> >
>>> > Melanie
>>> >
>>> > john felipe urrego mejia wrote:
>>> >> Hola creadores, ustedes me pueden ayudar con algunos archivo oar, iar
>>> >> o
>>> xml
>>> >> para llenar mi mundo virtual, gracias un saludo
>>> >>
>>> >>
>>> >>
>>> >>
>>> 
>>> >>
>>> >> ___
>>> >> 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
>>>
>>
>>
>>
>> --
>> ===
>> http://osgrid.org
>> http://del.icio.us/SPQR
>> http://twitter.com/jstallings2
>> http://www.linkedin.com/pub/5/770/a49
>>
>
>
>
> --
> ===
> http://osgrid.org
> http://del.icio.us/SPQR
> http://twitter.com/jstallings2
> http://www.linkedin.com/pub/5/770/a49
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev




-- 
===
http://osgrid.org
http://del.icio.us/SPQR
http://twitter.com/jstallings2
http://www.linkedin.com/pub/5/770/a49

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

[Opensim-dev] Friends in trouble

[Stefan Andersson]

Esteemed fellow metanauts,

 

Today I read this disturbing post;

 

http://blogs.sun.com/wonderland/entry/good_news_and_bad_news

 

Basically, the SUN Wonderland seems to be losing SUN (now Oracle) support.
They now need to transition into a community-driven effort.

 

This prompted me to add the following comment to the blog post: 

 

"Sad Tidings in deed. I don't know if any of you have been following the
OpenSim project, or been in touch with it, but maybe this is an golden
opportunity to seek inter-project collaboration. The OpenSim community has
worked without a central organization backing it up since the beginning, so
I guess we have some experience working the way I guess you need to do.
Since we have no central organization, nobody can speak for it, but most of
us are nice people, always eager to help a fellow metanaut. (on an unrelated
note, I for one would love++ to see a wonderland stack for OpenSim.)"

 

While nobody can tell nobody what to do I personally think the OpenSim
community should do our outmost to help and support this sibling project.
Contrary to the beliefs of many, the field of virtual worlds are nowhere
near the maturity where we can stand the consolidation-by-biting-dust that
we have seen recently. There will be no thousand worlds blooming.

 

Incidentally, I have for some time been thinking that it might be timely to
start thinking about how OpenSim would be able to support the architectures
of client-oriented environments (like Wonderland and Unity) better.

 

Best regards,

/Stefan

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

Re: [Opensim-dev] Mumble & Voice

[Stefan Andersson]

> If you hooked that up with the current freeswitch solution - you could
> have standard clients getting crappy PCM8000, people with better clients
> would get whatever you could negotiate (Speex?)

Or indeed per region; if the region could answer 'where is my speech url and
what kind of backend am I using?' then, on the region change trigger, the
voice process could ask that and change voice lib entirely.

Though my voice comms kung fu is weaker than Darrens, I'd say it's probably
a bit messy, but not undoable.

/Stefan

> 
> > -Original Message-
> > From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> > boun...@lists.berlios.de] On Behalf Of Stefan Andersson
> > Sent: Monday, 7 December 2009 8:26 AM
> > To: opensim-dev@lists.berlios.de
> > Subject: Re: [Opensim-dev] Mumble & Voice
> >
> > Since the SL viewer accepts command line options to tell it what port
> > the
> > SLVoice service is available on, and also whether to attempt to start
> > SLVoice.exe, if you don't want to replace the exe, you could just as
> > well
> > have the custom voice exe start first, establish a service port, then
> > let it
> > (the voice exe) locate and launch the sl viewer with the correct args,
> > instead of letting the sl viewer start the hardcoded SLVoice.exe.
> >
> > We did this in PIM; works like a charm.
> >
> > /Stefan
> >
> > > -Original Message-
> > > From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> > > boun...@lists.berlios.de] On Behalf Of Robert A. Knop Jr.
> > > Sent: den 7 december 2009 16:09
> > > To: opensim-dev@lists.berlios.de
> > > Subject: Re: [Opensim-dev] Mumble & Voice
> > >
> > > 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.
> > >
> > > --
> > > --Rob Knop
> > >   E-mail:rk...@pobox.com
> > >   Home Page: http://www.pobox.com/~rknop/
> > >   Blog:  http://www.sonic.net/~rknop/blog/
> >
> > ___
> > Opensim-dev mailing list
> > Opensim-dev@lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev

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

Re: [Opensim-dev] Mumble & Voice

[Stefan Andersson]

Yeah, I think it's a pretty good solution; yet another of those things that
could go into a generic client-side launcher thingy.

If you would attempt this though, be aware that the voice port settings are
'sticky' ie, gets saved to the viewer config, so you would probably also
want to specify a new config file location as not to mess up the original
sl-specific config. There's an arg for that too.

/Stefan

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Frisby, Adam
> Sent: den 8 december 2009 02:44
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] Mumble & Voice
> 
> *that* is very clever; since it'd allow you to have backwards/forwards
> compatible.
> 
> If you hooked that up with the current freeswitch solution - you could
> have standard clients getting crappy PCM8000, people with better clients
> would get whatever you could negotiate (Speex?)
> 
> Adam
> 
> > -Original Message-
> > From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> > boun...@lists.berlios.de] On Behalf Of Stefan Andersson
> > Sent: Monday, 7 December 2009 8:26 AM
> > To: opensim-dev@lists.berlios.de
> > Subject: Re: [Opensim-dev] Mumble & Voice
> >
> > Since the SL viewer accepts command line options to tell it what port
> > the
> > SLVoice service is available on, and also whether to attempt to start
> > SLVoice.exe, if you don't want to replace the exe, you could just as
> > well
> > have the custom voice exe start first, establish a service port, then
> > let it
> > (the voice exe) locate and launch the sl viewer with the correct args,
> > instead of letting the sl viewer start the hardcoded SLVoice.exe.
> >
> > We did this in PIM; works like a charm.
> >
> > /Stefan
> >
> > > -Original Message-
> > > From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> > > boun...@lists.berlios.de] On Behalf Of Robert A. Knop Jr.
> > > Sent: den 7 december 2009 16:09
> > > To: opensim-dev@lists.berlios.de
> > > Subject: Re: [Opensim-dev] Mumble & Voice
> > >
> > > 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.
> > >
> > > --
> > > --Rob Knop
> > >   E-mail:rk...@pobox.com
> > >   Home Page: http://www.pobox.com/~rknop/
> > >   Blog:  http://www.sonic.net/~rknop/blog/
> >
> > ___
> > Opensim-dev mailing list
> > Opensim-dev@lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev

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

Re: [Opensim-dev] Opensim Wave?

[Stefan Andersson]

On a side note, from what I understand, The Blink 3D arch (that is 
client-based, with very little going on on the server) uses xmpp to communicate 
object property updates between the clients. So, without diving too deep into 
the protocol, I’d venture you could do quite a lot with it, not only text 
messaging.

 

/Stefan

 

From: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Rich White
Sent: den 6 december 2009 23:18
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Opensim Wave?

 

I second AI Austins comment.  :)

On Dec 6, 2009 3:57 PM, "Ai Austin"  wrote:

A great place to start would be to get XMPP/jabber chat linked up
with Opensim as an alternative to  the IRC linkup.

The  look at how to allow more useful communication via the XML
payloads which XMPP/Jabber can carry.

I believe several folks have experimented with Jabber/XMPP chat
client link up, but am not aware of a stable module for Opensim.  Can
someone update us ion this if something is available now?

___ Opensim-dev mailing list 
opensim-...@lists.berlios

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

Re: [Opensim-dev] Mumble & Voice

[Stefan Andersson]

Since the SL viewer accepts command line options to tell it what port the
SLVoice service is available on, and also whether to attempt to start
SLVoice.exe, if you don't want to replace the exe, you could just as well
have the custom voice exe start first, establish a service port, then let it
(the voice exe) locate and launch the sl viewer with the correct args,
instead of letting the sl viewer start the hardcoded SLVoice.exe.

We did this in PIM; works like a charm.

/Stefan

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Robert A. Knop Jr.
> Sent: den 7 december 2009 16:09
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] Mumble & Voice
> 
> 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.
> 
> --
> --Rob Knop
>   E-mail:rk...@pobox.com
>   Home Page: http://www.pobox.com/~rknop/
>   Blog:  http://www.sonic.net/~rknop/blog/

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

[Opensim-dev] OpenSim turns Three

[Stefan Andersson]

Hey people,

 

Just figured I'd remind you out that in less than two months, on 29th of Jan
2010, OpenSim turns three. Celebrations and announcements are in order.

 

As a starter, this is my blog post from the last birthday:

http://lbsa71.net/2009/01/21/opensim-turns-two/

 

Love,

/Stefan

 

 

 

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

Re: [Opensim-dev] Min and Max X,Y location

[Stefan Andersson]

You also need to make sure your default and default is set correctly;
otherwise the grid service is sending you to a non-existing location, even
if its in standalone.

 

/Stefan

 

From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Huan Dau
Sent: den 8 oktober 2009 18:17
To: opensim-us...@lists.berlios.de; opensim-dev@lists.berlios.de
Subject: [Opensim-dev] Min and Max X,Y location

 

Hi all

I created some regions whit Location =0,0 and Location = 1,1 Location =
100,100 Location = 900,900 and run on Standalone mode. but can not login. 
I can login Location = 1000,1000


Pls tell me on Opensim Minimum and Maximum Location X,Y can use?

Thank so much.
  





-- 
Dau Huan

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

[Opensim-dev] Stepping down from OpenSim core

[Stefan Andersson]

Folks,

 

just letting you know I'm stepping down from OpenSim core.

 

Since Tribal Media keeled over, my life situation simply does not allow me
neither to participate in the dev community regularly nor contribute code. I
have committed exactly three characters since we moved to git.

 

What I have come to respect the most in OpenSim is the disrespectful
attitude against 'talk'.

 

OpenSim has always been about participating thru effort; testing, promoting,
writing, coding, building. So while discussion has always been welcome, any
kind of demands have always been met with "do it yourself, or pay someone to
do it". A harsh sentiment, but ultimately the only viable attitude in a
project like this.

 

Sean Dague disliked the term 'founding four', feeling that just because you
were among the first didn't automatically give you authority. Back then, I
didn't agree; for some time now, I have.

 

So rather than lingering, I'm leaving.

 

I wish to thank all core devs, past and present; thank you all gridnauts,
testers, hosts, customers and partners - It's been an immensely satisfying
ride. Hope to see you all on the 3D Web.

 

Best regards,

Stefan Andersson aka lbsa71

http://lbsa71.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?

[Stefan Andersson]

Well, 

as Melanie said,

given the modularity of OpenSim, anybody is free to do an IGenericStorage
module interface that implements that. All it needs is a couple of
XXXGenericStorageImpl for the various data providers, and you're good to go.

The underlying question is if those modules should be part of core or not;
and if so, whether it should in any way 'hook into' any of the existing
storages.

/Stefan

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of d...@metaverseink.com
> Sent: den 22 september 2009 20:28
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] Thoughts on adding a generic key-value
> storage system to OpenSim?
> 
> 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.
> 
> 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

___
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?

[Stefan Andersson]

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

Re: [Opensim-dev] Thoughts on adding a generic key-value storage system to OpenSim?

[Stefan Andersson]

John,

I'm not a big fan of tall/skinny untyped string/string storage, as I believe
that approach always come back to bite you in the ass in the end. Adam F did
propose the same thing a year ago, and I was against it then as well.

Since then, my stance has softened somewhat, as there hasn't really emerged
any other option than nhibernate (but still, wouldn't that be an option?)

If you can just turn string GetValue(string context, string key) into 

bool TryGetValue(string context, string key, out string value)

embracing the Try pattern, I'm 0 on it.

I'm presuming that you're going to implement a behind-the-scene
module-unique identifier also, so modules don't clash on context? I would
suggest having an IGenericDataStore factory that produces handlers that are
private to the modules.

/Stefan

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Hurliman, John
> Sent: den 21 september 2009 22:05
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] Thoughts on adding a generic key-value
> storage system to OpenSim?
> 
> Formatting got messed up, that should have looked like this:
> 
> // returns true if the key was found and data was updated, otherwise
> false if a new key row was added
> bool AddOrUpdateKeyValue(string context, string key, string value);
> 
> // returns true if the key was found and deleted
> bool DeleteKeyValue(string context, string key);
> 
> // returns the string value if the key was found, otherwise null
> string GetValue(string context, string key);
> 
> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Hurliman, John
> Sent: Monday, September 21, 2009 12:54 PM
> To: opensim-dev@lists.berlios.de
> Subject: [Opensim-dev] Thoughts on adding a generic key-value storage
> system to OpenSim?
> 
> A lot of the work going into OpenSim recently has been modularizing the
> codebase and making it easy for third party developers to write
> plugins. One feature that I think would really complete the picture
> would be a (simple) generic data storage interface that leveraged the
> existing OpenSim storage framework. Most plugins I've seen (and wrote)
> currently tack on their own database tables, use a simple text file
> with a custom format, or use some other means of data storage that does
> not match up with the rest of OpenSim. Adding a new database table that
> had three columns: [context, key, value] would allow plugins to store
> key/value mappings (string to string) without worrying about data
> collisions between plugins or having to implement a custom data store
> every time.
> 
> // returns true if the key was found and data was updated, otherwise
> false if a new key row was added
> bool AddOrUpdateKeyValue(string context, string key, string value);
> // returns true if the key was found and deleted
> bool DeleteKeyValue(string context, string key);
> // returns the string value if the key was found, otherwise null
> string GetValue(string context, string key);
> 
> Although I've been writing extensions for the OpenSim codebase for
> quite a while, I'm still fairly new to the guts of the system. Does
> this seem like the correct solution? If so, where would this interface
> go? I'm happy to write the code to implement this, I just want feedback
> from the dev community first to see if I'm on track.
> 
> John
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev

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

Re: [Opensim-dev] scene import/export to another app: oar? dotscene? collada?

[Stefan Andersson]

Shack,

Have you read 
http://opensimulator.org/wiki/OpenSim:Xml_Serialization
page?

Also, Adam F authored (?) an orphaned page
http://opensimulator.org/wiki/Xml_Objects_Format
that I'm wondering what it's about?

/Stefan

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Shack Dougall
> Sent: den 17 september 2009 17:28
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] scene import/export to another app: oar?
> dotscene? collada?
> 
> I'm excited to see this discussion and would just like to mention the
> HPA format (Hierarchical Prim Archive) which is what Prim Composer for
> 3ds Max uses to store its scenes.
> 
> https://liferain.com/projects/hpa/
> 
> When I started Prim Composer, I looked at the existing formats such as
> OAR and rejected them because they were too closely tied to the server
> implementation.  For example, one of the many problems with the
> server-centric encoding is that it is much harder than it needs to be
> to
> determine the type of a prim.  There isn't a single field that says,
> "This is a box".  Also, some prim fields such as taper have different
> definitions depending on what type of prim it is being applied to.
> 
> HPA is the alternative XML format that I came up with.  It stores the
> data using the client-side values that are presented to the user and
> allows a hierarchical scene graph.
> 
> It's not complete (e.g., it doesn't describe task inventory yet) and
> I'm
> not claiming that it is perfect, but it *is* very well documented.  It
> might be useful as a starting point and I'm more than willing to make
> changes to it and update the documention accordingly.
> 
> It uses the file extensions .hpa for the XML data files and .hpz for
> the
> zipped archive.  I haven't implemented the zipped archive in Prim
> Composer yet, but it is the logical extension of the current
> specification and would give you something similar to an OAR file that
> could be passed around easily.
> 
> Toni Alatalo wrote:
> > Justin Clark-Casey kirjoitti:
> >
> >>> I've now been leaning against writing OAR support elsewhere exactly
> >>> 'cause it is the internal structure and perhaps awkward for what
> need
> >>>
> >>>
> >> That's theoretically true, but I should think that the old format
> will still be
> >> loadable in some way since changes here would break everybody's
> existing content
> >>
> >>
> >
> > Yah was thinking about the same - I guess there are ways to deal with
> > that .. perhaps kind of loosing the initial comfort of automatic
> > serialization though, needing manual processing for backwards compat.
> >
> >
> >> Separate files for objects and assetes were used in order to
> potentially allow
> >> regions to be more easily composed out of world from separate
> components.
> >> Whether this is a good thing or whether there are more advantages to
> a single
> >> monolithic file is, I'm sure, something that could be debated.
> >>
> >>
> >
> > Agreed - I think assets in separate files easily make sense, and for
> > SL/Opensim like prims too 'cause there is no distinction of the
> specific
> > geom and it's instance(s) in the scene. That said the single file
> > Collada .dae files that am working with now seem sensible too.
> >
> >
> >>> Collada and X3D would be engine independent standards that would
> >>>
> >>>
> >
> > I built something called 'ColladaDotNet', using the Collada Document
> > class from the Collada for XNA project, and have succesfully tested
> > using that to read reference Collada scene files, and my own exports
> > from Blender.
> >
> > Am planning to test importing scene info to Opensim / ModRex using
> that
> > .. first just object positions. May test in the Naali viewer (first)
> too
> > .. reading collada files there for local preview (may use with the
> > pycollada lib there, have the same test as for ColladaDotNet working
> now
> > with that too).
> >
> > ~Toni
> >
> >
>  Toni Alatalo wrote:
> 
> 
> 
> > Hi,
> >
> > I started looking into implementing scene exchange between
> Opensim and
> > Blender yesterday, and am planning to continue later today. Was
> reading
> > OARs and the code in
> OpenSim.Region.Framework.Scenes.Serialization ..
> > where SceneObjectPart #region XML Schema seems to be the fields
> that are
> > autoserialized by some .net writer, right?
> >
> > It seems well possible to read and write OAR elsewhere, but I'm
> not sure
> > if it makes sense, or whether it's more the internal
> representation in
> > Opensim. Are there any alternatives? With Ogre we've sometimes
> used the
> > simple DotScene (.scene) made for it, and basically that would
> cover the
> > info I'm interested in now (positions of meshes in a scene, not
> prim
> > geom 'cause am not having prims in Blender at least right now
> anyway).
> > There is an existing DotScene exporter for Blender, woul

Re: [Opensim-dev] pruning reference servers in core

[Stefan Andersson]

+1 and some cheers to go.

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of d...@metaverseink.com
> Sent: den 16 september 2009 16:23
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] pruning reference servers in core
> 
> I'll wait another couple of days, and if there are no objections by the
> end of the week, Grid.AssetServer and Grid.InventoryServer will be
> deleted from the main distribution.
> 
> I'll take a look at the documentation, to delete outdated instructions.
> But that wiki is a jungle, so I'm pretty sure I won't find all the
> pages
> that need updates.
> 
> David W Levine wrote:
> >
> >
> > opensim-dev-boun...@lists.berlios.de wrote on 09/15/2009 03:23:36 PM:
> >
> >  > Justin Clark-Casey 
> >  > Sent by: opensim-dev-boun...@lists.berlios.de
> >  >
> >  > 09/15/2009 03:23 PM
> >  >
> >  > Please respond to
> >  > opensim-dev@lists.berlios.de
> >  >
> >  > To
> >  >
> >  > opensim-dev@lists.berlios.de
> >  >
> >  > cc
> >  >
> >  > Subject
> >  >
> >  > Re: [Opensim-dev] pruning reference servers in core
> >  >
> >  > +1, that sounds good to me, multiple servers are confusing.
> >  >
> >  > What would be really really helpful is if we could make sure that
> the
> > wiki
> >  > documentation reflects this when it happens.  Nothing major, just
> > clearly
> >  > deprecate all the old stuff and provide
> >  > just sufficient instructions for people to elaborate on later if
> > required.  I
> >  > know there is some documentation but even technically proficient
> >  > people seem to
> >  > have problems in this area.
> >
> > +1 on this the current tangle of old/new and stubbed stuff basically
> > requires people to re-ask the same questions on IRC and e-mail
> > weekly.
> >
> >  >
> >  > Or perhaps that confusion would clear up one the old servers are
> >  > eliminated and
> >  > the old doc becomes clearly out of date.
> >  >
> >  >
> >  > d...@metaverseink.com wrote:
> >  > > Hi everyone,
> >  > >
> >  > > Now that summer vacation is over and everyone seems to be back,
> it's
> >  > > time to revisit this thread. It's been one month, and no one has
> > stepped
> >  > > up to bringing the old Grid.InventoryServer up to date with the
> new
> >  > > requirements. The simulators can still talk to old server, but
> really
> >  > > poorly, after failures; and they don't take advantage of the new
> >  > > streamlined interactions that avoid downloading the entire
> inventory
> >  > > into the simulators.
> >  > >
> >  > > In this past month, OSGrid has switched the inventory service to
> > ROBUST,
> >  > > and lots of other grids have followed. The newly released IAR
> tool has
> >  > > been developed nicely for the new interface too.
> >  > >
> >  > > So -- I propose we drop the old Asset and Inventory servers now,
> so
> > that
> >  > > we stop supporting old code. Any objections?
> >  > >
> >  > > Again, the door is always open for someone to step up and
> maintain
> > those
> >  > > servers as alternatives -- even write/maintain connectors for
> them,
> > and
> >  > > write/maintain corresponding pre-packaged configurations that
> use
> > them.
> >  > > But without that kind of commitment, we're bound to make things
> very
> >  > > confusing by having multiple reference implementations of the
> same
> >  > > things, some of which are not evolving, and only one pre-
> packaged
> >  > > configuration that assumes the new interfaces.
> >  > >
> >  > > Crista
> >  > >
> >  > > d...@metaverseink.com wrote:
> >  > >> Ping me when you tune in to the IRC, if you still have
> questions
> > after
> >  > >> reading this. The additions are really easy. Look in
> >  > >>
> OpenSim/Server/Handlers/Inventory/InventoryServerInConnector.cs,
> > in my
> >  > >> local repo (the one currently in head is outdated)
> >  > >> http://github.com/diva/Diva-s-OpenSim-Tests/blob/
> >  > 21b5ebdc1f59ee449f56e40d8cbb9f3f5b3de644/OpenSim/Server/Handlers/
> >  > Inventory/InventoryServerInConnector.cs
> >  > >>
> >  > >> The 2 service handlers that you need to add and implement are
> these:
> >  > >>
> >  > >> m_httpServer.AddStreamHandler(
> >  > >>  new RestDeserialiseSecureHandler > List>(
> >  > >> "POST", "/SystemFolders/", GetSystemFolders,
> CheckAuthSession));
> >  > >>
> >  > >> m_httpServer.AddStreamHandler(
> >  > >>  new RestDeserialiseSecureHandler InventoryCollection>(
> >  > >> "POST", "/GetFolderContent/", GetFolderContent,
> > CheckAuthSession));
> >  > >>
> >  > >> You can copy and paste the implementations I have there.
> >  > >> Let me know when you're done, so that I can push my local mods.
> >  > >>
> >  > >>
> >  > >>
> >  > >> MW wrote:
> >  > >>> If you can provide the details of those two handlers that need
> > adding to
> >  > >>> the old servers, I can have a go at implementing them;
> dependent
> > on how
> >  > >>> much work it involves.
> >  > >>>
> >  > >>> --- On *Thu, 13/8/09, 

[Opensim-dev] Proposal: OpenSim StyleCop compliance

[Stefan Andersson]

Hey guys,

 

I've been working with Microsoft StyleCop compliance for legacy projects
lately, and wrote a blog about it:

http://lbsa71.net/2009/09/10/introducing-stylecop-on-legacy-projects-using-s
tylecop-for-resharper/

 

basically, StyleCop is a tool for enforcing Micrososft Source Analysis
recommended C# source code style.

http://code.msdn.microsoft.com/sourceanalysis

 

the rule set defines a coherent coding standard for C#.  One compilation of
these rules are here:

http://www.thewayithink.co.uk/stylecop/stylecop4_3rules.htm

 

Now, while I personally don't necessarily agree on all rules, they are all
described - some of them even have (good) motivations attached to them - and
I'd rather follow that set of rules than have no enforcement at all.

 

So, I propose we introduce the StyleCop ruleset as OpenSim code standard.

 

As I've outlined in the blog, doing this would fall into three categories:

. Documentation

. File Headers

. Code

 

The two first ones are the bulk of the manual job, and can be considered
optional. I do believe that being StyleCop documentation compliant would
seriously raise the bar on OpenSim documentation. Optionally, we can exclude
documentation rules and work on them separately.

 

Regarding code, the "StyleCop for ReSharper" plugin can take care of the
bulk of the issues. What's left is basically renaming functions, fields and
doing some formatting that the automatic clean up fails to take care of.

 

One of the biggest impacts on code is the transition from "m_" to explicit
"this." and that commenting, regions and line break formatting is strictly
governed.

 

As you all know, I've been a proponent of "m_" but that's something I'm
ready to lay aside to achieve consistent code style. I also know that there
is reflecting code depending on the "m_" naming, but those projects can be
excluded until we can get a fix for that.

 

As StyleCop is implemented as a Visual Studio plug-in I guess code cleanup
will have to be a voluntary effort by the Visual Studio developers. This
proposal is more about embracing the StyleCop code style in itself. 

 

Best regards,

/Stefan

 

___
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?

[Stefan Andersson]

Good call; if nobody objects within a reasonable timeframe, I'm all +1 for
it as well.

 

/Stefan

 

From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Nebadon Izumi
Sent: den 9 september 2009 22:44
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Make ODE and Meshmerizer the default options?

 

you no longer need to rebuild ODE for 64 bit.. and about both ODE and
Meshmerizier +1 on both.  I would also like to extend this thread to ask
anyone who is using Basic Physics and Zeromesher, please let us know why you
are using it, thanks.

Neb

On Wed, Sep 9, 2009 at 12:25 PM, dz  wrote:

Justin,

The wiki still has sections indicating that some linux platforms may require
a rebuild of the ODE software.  This may be me mis-reading the wiki, or it
may be old info.
Because we run on 64 bit linux (Ubuntu 9.04 server), we do Mono and ODE
builds from source anyway.  It would seem, however, that if some of the
linux platforms will not run ODE "out of the box", it may be a reason to
stick to the current default.  Im sorry I dont have any way to test and see
if the wiki information is outdated.

If ODE is made the default, please add some information to the wiki
documentation describing the configuration flags used to build it.  This may
provide the basis for discussions on the impact the build parameters have on
performance.  You may also want to note that using the ODE engine uses a LOT
more memory than the current defaults.

I really dont have a preference one way or the other, except to say that
having a 'default' configuration that works in the majority of installations
seems a better idea than one likely to trigger posts to forums complaining
about a "more complicated" setup.   Maybe the transition to ODE later
provides a "built in" delay for beginning administrators to get thier feet
wet, find out what they want to tweak, and might insure they look at the
wiki for directions :)

Doug Osborn

 

On Wed, Sep 9, 2009 at 11:17 AM, 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.

Currently, basicphysics is the default physics engine but the general
response
was that everybody quickly switches to ODE since objects can only be phantom
under basicphysics.

The disadvantage with switching to ODE is that 64 bit Windows users would
have
to run bin/OpenSim.32BitLaunch.exe since there is currently no compilable 64
bit
Windows ODE (though there is a Linux one).

Everybody at the meeting felt that the advantages of going with ODE
outweighed
this disadvantage.  Does anybody on the list have a good reason for not
switching defaults?

As for meshing, ZeroMesher is currently the default.  However, this
implements
extremely basic meshing (non rotatable cubes).  In comparison, Meshmerizer
is
much more sophisticated.  There was strong feedback in the meeting that many
people quickly switch to Meshmerizer and that it would be good to make this
the
default.  Anybody have good counter-arguments to this?  I think there is
potentially some performance impact but users sophsticated enough to
encounter
that can always switch back to ZeroMesher.

--
justincc
Justin Clark-Casey
http://justincc.org
___
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




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

___
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?

[Stefan Andersson]

Yes,

 

One of the main reason for introducing, and keeping, .Net-only modules for
physics was to ensure minimal friction on first install.

 

One option would be to work on the installation procedure; to add an
"engine" configuration step to initial setup, having ODE as default; this
would let us document caveats in the configuration instructions.

 

I see no problem with switching to Meshmerizer as default though; +1 on
that.

 

/Stefan

 

From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of dz
Sent: den 9 september 2009 21:25
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Make ODE and Meshmerizer the default options?

 

Justin,

The wiki still has sections indicating that some linux platforms may require
a rebuild of the ODE software.  This may be me mis-reading the wiki, or it
may be old info.
Because we run on 64 bit linux (Ubuntu 9.04 server), we do Mono and ODE
builds from source anyway.  It would seem, however, that if some of the
linux platforms will not run ODE "out of the box", it may be a reason to
stick to the current default.  Im sorry I dont have any way to test and see
if the wiki information is outdated.

If ODE is made the default, please add some information to the wiki
documentation describing the configuration flags used to build it.  This may
provide the basis for discussions on the impact the build parameters have on
performance.  You may also want to note that using the ODE engine uses a LOT
more memory than the current defaults.

I really dont have a preference one way or the other, except to say that
having a 'default' configuration that works in the majority of installations
seems a better idea than one likely to trigger posts to forums complaining
about a "more complicated" setup.   Maybe the transition to ODE later
provides a "built in" delay for beginning administrators to get thier feet
wet, find out what they want to tweak, and might insure they look at the
wiki for directions :)

Doug Osborn

On Wed, Sep 9, 2009 at 11:17 AM, 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.

Currently, basicphysics is the default physics engine but the general
response
was that everybody quickly switches to ODE since objects can only be phantom
under basicphysics.

The disadvantage with switching to ODE is that 64 bit Windows users would
have
to run bin/OpenSim.32BitLaunch.exe since there is currently no compilable 64
bit
Windows ODE (though there is a Linux one).

Everybody at the meeting felt that the advantages of going with ODE
outweighed
this disadvantage.  Does anybody on the list have a good reason for not
switching defaults?

As for meshing, ZeroMesher is currently the default.  However, this
implements
extremely basic meshing (non rotatable cubes).  In comparison, Meshmerizer
is
much more sophisticated.  There was strong feedback in the meeting that many
people quickly switch to Meshmerizer and that it would be good to make this
the
default.  Anybody have good counter-arguments to this?  I think there is
potentially some performance impact but users sophsticated enough to
encounter
that can always switch back to ZeroMesher.

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

 

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

Re: [Opensim-dev] versioning question

[Stefan Andersson]

I haven't been working with git all that much since the switch, but it seems
to me, that what the community wants is some sense of progression to compare
two "official" git revisions to each others.

While sequence make no or little sense in a 'true' git world, I believe that
we might want to think of the opensimulator.org master as a "distribution"
and keep that concept separate from the technical innards of the versioning
system.

We are already doing this by tagging releases with a version number, so
either we
a) start doing (tagging) more frequent official releases so most users very
seldom feel the need to bother with individual git revisions.
or
b) Tag some kind of sequential number to each opensim commit, possibly by
adding some git commit hooks to update a text file somewhere.

That would mean, basically that we would have a show version output saying
something like

OpenSim 0.6.6.10201 (Git:6cf610) (Dev) (interface version 5)

/Stefan

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Toni Alatalo
> Sent: den 3 september 2009 20:07
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] versioning question
> 
> On Sep 3, 2009, at 7:30 PM, Justin Clark-Casey wrote:
> 
> >> The next revision to 6cf610 will be 6cf610 + 1 = 6cf611, then at
> >> least there is some logic to it.
> > This is exactly what isn't the case - the identifiers are generated
> > randomly without any connection between them.  This
> > seems to be one of the (few) downsides of git.
> 
> In a way it is what GIT, and distributed versioning control, is. I
> think at least, am still just learning the practice of it..
> 
> On the base system level, there is no sequence 'cause you can arrive to
> the same situation in many ways.
> 
> Commits are commits, and each commit/revision/patch has an identity. I
> think this 'theory of patches' applies to GIT as well, the part about
> 'Patch relationships' seems relevant
> http://darcs.net/manual/node9.html#SECTION0094 ..
> besides sequential patches there are parallel patches: "There is one
> other very useful relationship that two patches can have, which is to
> be parallel patches, which means that the two patches have an identical
> context (i.e. their representation applies to identical trees). Of
> course, two patches may also have no simple relationship to one
> another. In that case, if you want to do something with them, you'll
> have to manipulate them with respect to other patches until they are
> either in sequence or in parallel."
> 
> So to have what grows as a sequence in the current opensim main thing,
> something else besides the individual patch IDs are needed. The thing
> in the blog post that has been referred to seemed promising, but don't
> know much about that.
> 
> ~Toni
> 
> > There was some talk on this list about somehow producing sequential
> > numbers some time ago but I don't know the details.
> >
> >>
> >> If my hex intuitions serve me, 6cf610 < a82950 so does anyone know
> >> how these version #s are to be interpreted or are they random
> >> identifiers?
> >> And if they are random, how do we track where we are? maybe, I
> should
> >> go back to the "10185 revision(s)" and use that #.
> >>
> >> -p
> >>
>  not sure how to interpret this hexadecimal indexing. Should I
>  consider
>  "10185" to be the number? The actual commit # is a long
> hexadecimal
>  string. The beginning of it matches what you said:
> 
>  6cf610 is the revision #? Do we need to bring out the old HP
>  calculators? :)
>  -paul
> 
> 
> 
>  Justin Clark-Casey wrote:
> 
> > Paul Fishwick wrote:
> >
> >
> >> Justin:
> >>
> >> Justin Clark-Casey wrote:
> >>
> >>
> >>> The 'interface v5' part refers to the interface protocol
> between
> >>> the region simulator and the grid (and defacto, between
> >>> region simulators).  It doesn't have anything at all to do with
> >>> the OpenSim version (0.6.6).
> >>>
> >>>
> >>>
> >>>
> >> OK
> >>
> >>
> >>> In principle, if you are running from a source repository
> update
> >>> then the git version should be tacked on the end of
> >>> OpenSim 0.6.6 (e.g. 0.6.6 239a1).  This should also be true if
> >>> you are updating from the SVN mirror (e.g. 0.6.6.10108).
> >>>   If this isn't the case then this is arguably a bug.
> >>>
> >>>
> >>>
> >> Where does one find this build # (i.e., "239a1" or "10108") ? It
> >> is not
> >> produced through "show version". If that is a bug, I can file
> it.
> >> -paul
> >>
> >>
> > If you execute 'git log' on the command line, the long string
> > after the word "commit" is the build identifier, e.g. in
> >
> > 
> > commit 4841858600cf35903966d48451015b2be5e97d5c
> > Author: Chris Hart 
> > Date:   Wed Sep 2 13:28:57 

Re: [Opensim-dev] Currency

[Stefan Andersson]

Aldon,

 

The source codes are hosted mostly on the GForge; some resources I could dig
up was these:

 

. The DTL Module -
http://forge.opensimulator.org/gf/project/currency/

. OpenCurrency, was the SampleMoneyModule -
http://forge.opensimulator.org/gf/project/opencurrency/

. I believe the OpenSimWi contains a basic monetary system backend -
http://forge.opensimulator.org/gf/project/opensimwi/

. The Money page on the wiki - http://opensimulator.org/wiki/Money
(This page should have a fat disclaimer saying "Does not represent current
opensim stance - content should move to "discussion", but it contains some
good points)

 

Aloas, when it comes to documentation, it's sorely lacking.

 

Hope you can get your effort started.

 

Best regards,

/Stefan

 

 

From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Aldon Hynes
Sent: den 8 juli 2009 17:03
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Currency

 

Stefan, et al.,

 

  I'm glad you think this is a good idea.  I'm heading on vacation for a
couple weeks leaving this weekend, so I'll be hard to reach.  However, if we
can get the project up and going before I go, that would be great.
Questions I have:  Who wrote and/or has copies of the 

SampleMoney and OpenCurrency code?  Who has any design documents are would
be willing to create some design documents?  

 

  If you want to help, please contact me directly.  I can set up a Wiki on
one of my hosting accounts and try to get the ball rolling, but I'll need
help.

 

Aldon

-Original Message-
> So, for any of you that are really interested in OpenSimCurrency, what do
> you say to starting a parallel project that provides a third party
currency
> framework that can run in OpenSim?

Go for it. Host it on the forge, create a wiki for it. Can't wait to see the
first release.
 
Also, I believe there is still an Freenode IRC channel called
#opensim-money.
 
/Stefan
 

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

Re: [Opensim-dev] Changes to IAssetDataPlugin

[Stefan Andersson]

> I propose that we change to just having one "Store" method that
> replaces both the insert and update method, which will insert or
> update.  This is what we have in practice with MySQL, so this will
> just change the interface to match it.  My biggest concern would be
> breaking external data providers.

Since I was the one who painstakingly separated this into two methods, I'm
opposed to merging it, but won't fight it, so a 0 from me.

But:

It's a very common separation of context in most data workflows to clearly
separate Create from Update, and from a data integrity standpoint, you do
want to be able to trap re-inserts and updates of non-existent resources, as
these are indications something has gone wrong.

Although the above might come off as somewhat abstract, fact is that a
majority of data storage architectures enforce and rely on the separation,
forcing you to do an extra lookup before each operation if you throw the
semantics away. I did the separation just because the extra lookup was
causing pain. (Though this was like 1,5 years ago - much has happened since)

> When I mentioned this idea to Adam, he also mentioned changing the
> naming of the Fetch methods to Get, so that everything will be
> consistent.   I have an example of what this change would look like on
> this mantis entry:  http://opensimulator.org/mantis/view.php?id=4015
> Any feedback or thoughts on this idea is greatly appreciated.

Even better would be introducing the TryGet pattern.

/Stefan


___
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

[Stefan Andersson]

> lbsa71 = lbsa71 


> --
> __
> 
> Sean Dague   Mid-Hudson Valley
> sda...@gmail.com Linux Users Group
> http://dague.net http://mhvlug.org
> 
> There is no silver bullet.  Plus, werewolves make better neighbors than
> zombies, and they tend to keep the vampire population down.
> __
> 


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

Re: [Opensim-dev] Currency

[Stefan Andersson]

Mark,

 

Just a couple of corrections:

 

I have heard no 'rage' from any core dev over the concept of an
"OpenCurrency" project. On the contrary, that is what we want to see happen,
preferably several currency projects targeting different usage models and
catering for differing audiences.

 

Whether or not currency management hosted by the core repository is pivotal
for the success of OpenSim or not is a matter of opinion. In my opinion, if
that would be the case, that would be a sad prospect for OpenSim indeed.

 

Managing an economic points system is no more central to OpenSim than it is
for the Apache web server. It might be pivotal for certain implementations
based on OpenSim, like it would be for certain e-commerce sites running on
Apache, but not for OpenSim itself.

 

The OpenSim core devs has repeatedly stated that we are willing to add
whatever reasonable hooks any currency module would reasonably need into the
core. Please open mantis issues and attach your patches, and we'll review
them like any other patch.

 

I fail to see the need to 'fork' the entire code base over this kind of
issue.

 

The Rex team forked before the OpenSim core were even aware of them. The
issue was whether to re-incorporate their codebase into core, something that
was decided against in the end. From what I can see, both projects have
continued to run in parallel just fine, each free to pursue their specific
development goals.

 

There has been mailings before pointing to existing currency module code
bases.

 

A friendly suggestion though; it's probably not the best way to start your
fledgling currency project passing remarks discrediting core devs and their
motifs.

 

Best regards,

/Stefan

 

 

From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Mark Malewski
Sent: den 21 juli 2009 12:18
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Currency

 

Jason/Colin/Rock/Aldon,

 

I completely agree with your stance on having a virtual currency
system/Karma system (whether it is or is not based on actual real-world
currency).

 

Companies like Zynga that do online gaming, have "virtual currencies" and
things such as "virtual money" and "Godfather points" in their Mafia Wars
games, and all of their other various games.

 

Yes, I agree that there needs to be some form of "virtual currency" or
points system.  There is no argument concerning "virtual currency" as being
unsecure, or inappropriate or any form of liability.

 

I'm not saying that OpenSim core needs to add a gateway to secure e-commerce
(such as PayPal) but there are lots of way to implement secure commerce.

 

First off, the "points" in the game, are nothing more than that.  They are
just points.  I've lost items (through "gifting") before on other online
games, and it's really no big deal.  Tech support normally "makes things
right".  But this is not a liability issue as much as this seems to be a
"money making" issue.

 

There seem to be some developers (in the core dev team) that may or may not
want to offer their OWN e-commerce system (as a service/money making
opportunity).  So I can understand their rage in the concept of someone
creating an "OpenCurrency" project, because they may feel that it's a loss
of opportunity for them to sell a product (if someone gives it away for
free, as in air). Ultimately I feel that a points/virtual currency system is
vital to OpenSim's success. 

 

I believe e-commerce is an important part of Virtual World development, just
as e-commerce is an important part of the web. Trying to have a virtual
world without any form of e-commerce is similar to having an internet
without any form of e-commerce.

 

I've seen payment gateways for virtual worlds dating all the way back to
1996 (Active Worlds) and designing the core (securely) from the ground up,
so that it could handle a virtual "points" system would seem to make sense.
You don't need to build a mamoth of secure servers, as PayPal already does
much of that for you.  It would seem that just a simple module that would
work hand in hand with PayPal's API would suffice.

 

Linden dollars are nothing more than a points system.  Whether you choose to
call it Karma points, or currency, or virtual dollars, whatever the case...
it's still points.  It's NOT real money, it's NOT real cash, it's just
points. 

 

It would seem to make sense to create a separate OpenCurrency project as
Aldon suggested, as this seems to be an EXTREMELY important piece of the
OpenSim project.  

 

Designing a virtual world system (like OpenSim) without any form of points
systems (Karma, Currency, or whatever you wish to call it) would be similar
to designing a computer without a monitor, keyboard or mouse.

 

I understand the concept of having a 3D Virtual Chatroom (for educational
purposes and online learning) but 3D portals (such as Linden's) where people
come together, talk, chat, play online games, and engage in trading, e

Re: [Opensim-dev] Request for documentation - InventoryItems.InvType

[Stefan Andersson]

Maybe we should be using that enum at least at some point in the process, to
get into the OpenSim codebase.

Or just add a comment somewhere.

/Stefan

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of jradford
> Sent: den 16 juli 2009 07:59
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] Request for documentation -
> InventoryItems.InvType
> 
> Its in OpenMetaverseTypes.dll which I believe you guys are using.
> 
> On Thu, 16 Jul 2009 07:47:54 +0200, "Stefan Andersson"
> 
> wrote:
> > Maybe that should go into an enum somewhere, for documentations sake.
> >
> > /Stefan
> >
> >> -Original Message-
> >> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> >> boun...@lists.berlios.de] On Behalf Of Frisby, Adam
> >> Sent: den 16 juli 2009 06:46
> >> To: opensim-dev@lists.berlios.de
> >> Subject: Re: [Opensim-dev] Request for documentation -
> >> InventoryItems.InvType
> >>
> >> Thanks
> >>
> >> > -Original Message-
> >> > From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> >> > boun...@lists.berlios.de] On Behalf Of jradford
> >> > Sent: Wednesday, 15 July 2009 8:31 PM
> >> > To: opensim-dev@lists.berlios.de
> >> > Subject: Re: [Opensim-dev] Request for documentation -
> >> > InventoryItems.InvType
> >> >
> >> > From Libomv:
> >> >
> >> > /// 
> >> > /// Inventory Item Types, eg Script, Notecard, Folder, etc
> >> > /// 
> >> > public enum InventoryType : sbyte
> >> > {
> >> > /// Unknown
> >> > Unknown = -1,
> >> > /// Texture
> >> > Texture = 0,
> >> > /// Sound
> >> > Sound = 1,
> >> > /// Calling Card
> >> > CallingCard = 2,
> >> > /// Landmark
> >> > Landmark = 3,
> >> > /*
> >> > /// Script
> >> > //[Obsolete("See LSL")] Script = 4,
> >> > /// Clothing
> >> > //[Obsolete("See Wearable")] Clothing = 5,
> >> > /// Object, both single and coalesced
> >> > */
> >> > Object = 6,
> >> > /// Notecard
> >> > Notecard = 7,
> >> > /// 
> >> > Category = 8,
> >> > /// Folder
> >> > Folder = 8,
> >> > /// 
> >> > RootCategory = 9,
> >> > /// an LSL Script
> >> > LSL = 10,
> >> > /*
> >> > /// 
> >> > //[Obsolete("See LSL")] LSLBytecode = 11,
> >> > /// 
> >> > //[Obsolete("See Texture")] TextureTGA = 12,
> >> > /// 
> >> > //[Obsolete] Bodypart = 13,
> >> > /// 
> >> > //[Obsolete] Trash = 14,
> >> > */
> >> > /// 
> >> > Snapshot = 15,
> >> > /*
> >> > /// 
> >> > //[Obsolete] LostAndFound = 16,
> >> > */
> >> > /// 
> >> > Attachment = 17,
> >> > /// 
> >> > Wearable = 18,
> >> > /// 
> >> > Animation = 19,
> >> > /// 
> >> > Gesture = 20
> >> > }
> >> >
> >> >
> >> > On Wed, 15 Jul 2009 22:56:07 -0400, "Frisby, Adam"
> >> > 
> >> > wrote:
> >> > > Does anyone know what the values of InventoryItems.InvType
> >> represent?
> >> > It's
> >> > > an integer and represents the type of inventory; but I cant seem
> to
> >> > find
> >> > > any documentation (either in code, or externally) about what the
> >> > integers
> >> > > correlate to.
> >> > >
> >> > > Adam
> >> > >
> 
> 
> -- Jim
> 
> !DSPAM:370,4a5ec18619052153975079!
> 
> 
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev

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

Re: [Opensim-dev] Request for documentation - InventoryItems.InvType

[Stefan Andersson]

Maybe that should go into an enum somewhere, for documentations sake.

/Stefan

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Frisby, Adam
> Sent: den 16 juli 2009 06:46
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] Request for documentation -
> InventoryItems.InvType
> 
> Thanks
> 
> > -Original Message-
> > From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> > boun...@lists.berlios.de] On Behalf Of jradford
> > Sent: Wednesday, 15 July 2009 8:31 PM
> > To: opensim-dev@lists.berlios.de
> > Subject: Re: [Opensim-dev] Request for documentation -
> > InventoryItems.InvType
> >
> > From Libomv:
> >
> > /// 
> > /// Inventory Item Types, eg Script, Notecard, Folder, etc
> > /// 
> > public enum InventoryType : sbyte
> > {
> > /// Unknown
> > Unknown = -1,
> > /// Texture
> > Texture = 0,
> > /// Sound
> > Sound = 1,
> > /// Calling Card
> > CallingCard = 2,
> > /// Landmark
> > Landmark = 3,
> > /*
> > /// Script
> > //[Obsolete("See LSL")] Script = 4,
> > /// Clothing
> > //[Obsolete("See Wearable")] Clothing = 5,
> > /// Object, both single and coalesced
> > */
> > Object = 6,
> > /// Notecard
> > Notecard = 7,
> > /// 
> > Category = 8,
> > /// Folder
> > Folder = 8,
> > /// 
> > RootCategory = 9,
> > /// an LSL Script
> > LSL = 10,
> > /*
> > /// 
> > //[Obsolete("See LSL")] LSLBytecode = 11,
> > /// 
> > //[Obsolete("See Texture")] TextureTGA = 12,
> > /// 
> > //[Obsolete] Bodypart = 13,
> > /// 
> > //[Obsolete] Trash = 14,
> > */
> > /// 
> > Snapshot = 15,
> > /*
> > /// 
> > //[Obsolete] LostAndFound = 16,
> > */
> > /// 
> > Attachment = 17,
> > /// 
> > Wearable = 18,
> > /// 
> > Animation = 19,
> > /// 
> > Gesture = 20
> > }
> >
> >
> > On Wed, 15 Jul 2009 22:56:07 -0400, "Frisby, Adam"
> > 
> > wrote:
> > > Does anyone know what the values of InventoryItems.InvType
> represent?
> > It's
> > > an integer and represents the type of inventory; but I cant seem to
> > find
> > > any documentation (either in code, or externally) about what the
> > integers
> > > correlate to.
> > >
> > > Adam
> > >
> >
> > -- Jim
> >
> > !DSPAM:370,4a5e9ed719051028312470!
> >
> >
> > ___
> > Opensim-dev mailing list
> > Opensim-dev@lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev

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

Re: [Opensim-dev] STUN for OpenSim?

[Stefan Andersson]

Ah, I was under the (wrong) impression that STUN incorporated UDP hole
punching[1] support.

Then, let me rephrase my suggestion; would UDP hole-punching be a viable way
of approaching this, and has anybody worked with that?

/Stefan

[1] http://en.wikipedia.org/wiki/UDP_hole_punching

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Infinity Linden
> Sent: den 15 juli 2009 00:49
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] STUN for OpenSim?
> 
> STUN is used by a client to establish it's routable IP address. in
> other words, the address a peer would have to connect to in order to
> have a chance at crossing the NATting firewall.
> 
> DynDNS can help with this too, but is used to do name resolution.
> 
> they're effectively used for different scenarios. DynDNS and STUN can
> both be used by systems which are given dynamic IP addresses from
> their ISPs. depending on the type of fabric you want to use, either
> might be useful. if you're talking about software that starts up,
> registers it's IP address with a service, that's STUN. if you want to
> publish a DNS name and have it route to your NATting firewall even if
> you're on the wrong end of a dynamic IP address, thats DynDNS.
> 
> for what it's worth, STUN considered to address a subset of the
> problem of maintaining stateful application layer sessions across a
> NATted firewall. RFC5389 describes the problem in a little more
> detail, along with more generic solutions. (
> http://tools.ietf.org/html/rfc5389 )
> 
> RFC5389 describes a series of techniques for UDP messages to
> successfully traverse a firewall that are not found in DynDNS.
> Ultimately, a good read of 5389 and practical experience with your
> firewall will do you a load of good.
> 
> -cheers
> -meadhbh
> 
> On Tue, Jul 14, 2009 at 3:15 PM, Mojito Sorbet
> wrote:
> > If you are running OpenSim behind a NAT router, you are going to have
> to
> > configure the routing in some way, regardless of whether STUN, or
> even
> > TCP, is used.  That is because the connection is originating outside
> of
> > the firewall, and the whole purpose of firewalls is to not let that
> > happen, except in carefully prescribed circumstances.  Same thing
> > applies to VOIP.
> >
> > The problem of people not being able to find your IP address has
> already
> > been solved by services such as DynDNS.
> >
> > On Tue, 2009-07-14 at 07:57 +0200, Stefan Andersson wrote:
> >> One of the main shortcomings of the linden-legacy model is that
> >> OpenSim does not work well (as in simple and consistent)  from
> behind
> >> NATs and several home routers.
> >>
> >>
> >>
> >> I was thinking, if something like STUN could help us overcome this?
> >
> >>
> >
> > ___
> > Opensim-dev mailing list
> > Opensim-dev@lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> >
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev

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

Re: [Opensim-dev] Where to put synthetic objects?

[Stefan Andersson]

Do you mean they will be included in core, and what functionality does these 
'Synth' objects bring?

/Stefan

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Sean Dague
> Sent: den 10 juli 2009 20:21
> To: opensim-dev@lists.berlios.de
> Subject: [Opensim-dev] Where to put synthetic objects?
> 
> I'd like to start putting some synthetic object code in the main tree,
> and trying to figure out where that should be.
> 
> OpenSim/Region/Framework/Synth seems like a reasonable place, but I
> value other opinions here.  This will include a set of classes that
> inherit or wrap SOP/SOG, and a SyntheticManager, as sometimes you'll
> want to manage these objects outside of the normal Scene.
> 
> Comments welcome.  I'll hopefully get to start digging in on code next
> week.
> 
>   -Sean
> 
> --
> __
> 
> Sean Dague   Mid-Hudson Valley
> sda...@gmail.com Linux Users Group
> http://dague.net http://mhvlug.org
> 
> There is no silver bullet.  Plus, werewolves make better neighbors than
> zombies, and they tend to keep the vampire population down.
> __
> 


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

[Opensim-dev] STUN for OpenSim?

[Stefan Andersson]

One of the main shortcomings of the linden-legacy model is that OpenSim does
not work well (as in simple and consistent)  from behind NATs and several
home routers.

 

I was thinking, if something like STUN could help us overcome this?

 

There is a c# implementation here;

http://www.codeplex.com/Wiki/View.aspx?ProjectName=SharpStunt

 

I was thinking something like there could be well-known public STUN servers
operating (maybe on grids) that could help clients and regions connect to
regions that are behind NATs (ideally  even without them having to configure
port forwarding). I'm a bit fuzzy on the details, but I could imagine the
Grider proxy could play a role in proof-of-concepting it until we can get a
viewer port that would support if natively.

 

STUN could also help regions connect when communicating region-to-region.

 

Is this even feasible? Anybody had actual experience with STUN?

 

/Stefan

 

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

Re: [Opensim-dev] Proposal: change opensim command line options for console

[Stefan Andersson]

Maybe "text" or "textonly"?

 

/Stefan

 

From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Impalah
Sent: den 10 juli 2009 14:03
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Proposal: change opensim command line options for
console

 

Minimal?

+1 too

2009/7/10 Melanie 

Well, basic _is_ a basic console
no editing, no colors. Otherwise functional. So what should it be
called?

Melanie


Stefan Andersson wrote:
> Same here, +1 but better name for 'basic'.
>
> /Stefan
>
>> -Original Message-
>> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
>> boun...@lists.berlios.de] On Behalf Of Melanie
>> Sent: den 10 juli 2009 13:35
>> To: opensim-dev@lists.berlios.de
>> Subject: [Opensim-dev] Proposal: change opensim command line options
>> for console
>>
>> I propose to change the command line options as follows:
>>
>> Remove -background and -gui
>>
>> Add -console, which can be either "local", meaning a full featured,
>> colored console with help and editing, "basic", corresponding to
>> -gui=true, "rest", which will be a REST console handler for a remote
>> GUI app, and "none", which will act like -background.
>>
>> Add -logfile to specify a per-instance log file
>>
>> Make both these new options available in the [Startup] section as well.
>>
>> Melanie
>> ___
>> Opensim-dev mailing list
>> Opensim-dev@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

 

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

Re: [Opensim-dev] Proposal: change opensim command line options for console

[Stefan Andersson]

Same here, +1 but better name for 'basic'.

/Stefan

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Melanie
> Sent: den 10 juli 2009 13:35
> To: opensim-dev@lists.berlios.de
> Subject: [Opensim-dev] Proposal: change opensim command line options
> for console
> 
> I propose to change the command line options as follows:
> 
> Remove -background and -gui
> 
> Add -console, which can be either "local", meaning a full featured,
> colored console with help and editing, "basic", corresponding to
> -gui=true, "rest", which will be a REST console handler for a remote
> GUI app, and "none", which will act like -background.
> 
> Add -logfile to specify a per-instance log file
> 
> Make both these new options available in the [Startup] section as well.
> 
> Melanie
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev

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

Re: [Opensim-dev] Visual Studio 2005 support

[Stefan Andersson]

+1

 

From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Charles Krinke
Sent: den 9 juli 2009 22:18
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Visual Studio 2005 support

 

+1, seems reasonable to me.

Charles

 

  _  

From: Teravus Ovares 
To: opensim-dev@lists.berlios.de
Sent: Thursday, July 9, 2009 1:01:35 PM
Subject: Re: [Opensim-dev] Visual Studio 2005 support

It's been long enough, I think :)

Regards

Teravus

On Thu, Jul 9, 2009 at 3:51 PM, Justin
Clark-Casey wrote:
> Jeff Ames wrote:
>> Hello,
>>
>> Back in April there was a proposal to drop support for VS 2005 after
>> 0.6.5.  Since we're now at 0.6.6, can we go ahead and do the
>> runprebuild.bat switch, and remove the proposal from the wiki?
>
> I think so.  I'm sure this was mentioned before in this list and nobody
objected to the change.
>
> --
> justincc
> Justin Clark-Casey
> http://justincc.wordpress.com
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

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

Re: [Opensim-dev] Deprecate OpenSim.Grid.InventoryServer and OpenSim.Grid.AssetServer?

[Stefan Andersson]

How about “Redesigned OpenSim Basic Universal Server Technology” –
R.O.B.U.S.T? ;)

 

Btw, You will hear no end of references to LoA from me:
http://www.youtube.com/watch?v=u1jzVJjk32E

 

/Stefan

 

From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Laurent B.
Sent: den 9 juli 2009 14:01
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Deprecate OpenSim.Grid.InventoryServer and
OpenSim.Grid.AssetServer?

 

+1 for B.U.S.T : in B.U.S.T we trust !

 

Laurent

> Date: Thu, 9 Jul 2009 09:03:58 +0200
> From: drscofi...@xyzzyxyzzy.net
> To: opensim-dev@lists.berlios.de
> Subject: 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

 

  _  

Discutez sur Messenger où que vous soyez ! Mettez Messenger
  sur votre mobile !

___
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?

[Stefan Andersson]

This discussion went west pretty fast it seems.

 

To try to get things on track; this is what I've heard said, and proposed,
in roughly this proposed order:

 

1)  The BUST architecture might or might not change name. *This is a
separate item for discussion*.

2)  The BUST architecture should be documented. This documentation is
allegedly on the way, but should be seen as a work in progress, like always.

3)  After discussing it thru, reviewing documentation, proofing and
accepting BUST, there will be a round of voting on a proposal to retire the
old exes from the core distro. Everything will ideally work the same, just
that the new exes are configured differently, and allows for way better
modularization.

4)  The Cable Beach offspring AssetInventoryServer might or might not
move out of core. *This is a separate item for discussion*.

5)  After retiring the old exes, we can start documenting and peer
reviewing ideas for how a new set of protocols (OGS2) could work. *This is a
separate item for discussion*. 

6)  Whether this new protocol should be developed in or outside of trunk
is part of that separate discussion.

7)  BUST will allow OGS1 and OGS2 to exist side by side.

8)  OGS1 might or might not be retired. *This is a separate item for
discussion*

 

I think the vote to retire the exes came somewhat prematurely, jilting
people. Let's keep these tracks well separated and move along in an orderly
fashion.

 

Just to put things in perspective, I would estimate bullets 5-8 probably to
be during 2010. Point 8 probably more around early 2011.

 

/Stefan

 

From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of MW
Sent: den 9 juli 2009 02:43
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Deprecate OpenSim.Grid.InventoryServer and
OpenSim.Grid.AssetServer?

 


Where are all these remarks of great acclaim? This is the first I've heard
about a new protocol being designed without any plan at all. 

I'm all for a new protocol but there needs to be a design and peer review.
Please stop adding any more work on a new protocol to the trunk until that
process can take place. As my vote is -1 (and consider it a veto vote) on
just writing it from a plan in your head when no one else knows what that
plan is. 

--- On Wed, 8/7/09, Melanie  wrote:


From: Melanie 
Subject: Re: [Opensim-dev] Deprecate OpenSim.Grid.InventoryServer and
OpenSim.Grid.AssetServer?
To: opensim-dev@lists.berlios.de
Date: Wednesday, 8 July, 2009, 11:42 PM

It doesn't need to be segregated. This can be done in trunk 
perfectly well. We have had bad experiences with branches and I 
believe there is a general aversion to them now.

There is no need to push this outside of the core scope, especially 
since it's already well underway. This whole discussion has been 
totally sidetracked, questioning the project as a whole, a project 
that has won great acclaim from my fellow core members and was, 
among others, called "long overdue" and "badly needed".

This entire thread came from me trying to ascertain the fundamental 
willingness to remove the monolithic servers _at some point_.

Melanie


Gryc Ueusp wrote:
> This is what branches are for.
> 
> Melanie wrote:
>> This can not be reasonably done on the forge..
>>
>> Melanie
>>
>> Charles Krinke wrote:
>>   
>>> Sounds like a good argument to put this new work on the forge.
>>>
>>> That way, we can get it wrung out, completed, functional, tested. 
>>>
>>> This seems to me a reasonable and proper way to change the underlying
grid servers without having a revolution in mid-air.
>>>
>>> Charles
>>>
>>>
>>>
>>>
>>> 
>>> From: Melanie 
>>> To: opensim-dev@lists.berlios.de
>>> Sent: Wednesday, July 8, 2009 2:51:39 PM
>>> Subject: Re: [Opensim-dev] Deprecate OpenSim.Grid.InventoryServer and
OpenSim.Grid.AssetServer?
>>>
>>> Which is precisely what is intended. But the old dinosaur servers 
>>> are in the way.
>>>
>>> You can rest assured no grids will be harmed in the making of these 
>>> servers - to paraphrase the movie industry
>>>
>>> Melanie
>>>
>>> Charles Krinke wrote:
>>> 
 I believe it is pretty important to ensure that we go forwards in a
compatible manner and not backwards.

 Certainly new implementations of servers, executables, protocols and
the like are encouraged, but we also need to make sure that everything
continues to work.

 Perhaps this new work should be on the forge. Perhaps it should be done
in such a way that the users can ultimately determine which server is
appropriate in a similar manner to differing physics implementations.

 But, regardless, I believe that moving forward in a compatible manner
and making sure we dont shoot ourselves in the foot is very important. I
would counsel caution *and* I would counsel some independent testing to make
sure we are moving forward in a predictable manner.

 Charles

Re: [Opensim-dev] Currency

[Stefan Andersson]

Aldon,

 

> Clearly, there are issues about people not understanding what it means to
> use alpha code, as we learned last April, but that is also not a reasonable
> excuse for not producing code. All code is alpha at some stage.


I can assure you that neither of us are looking for excuses not to produce code.

 
> As Jeroen noted, there are other aspects of how currency could be used such
> as a karma system, that are well worth exploring.


Definitively. I would suggest it would be based on some already-existing, 
web-based karma management cloud service implementation, so we don't need to 
download, compile and manage as much stuff.

 
> Perhaps the best would be for people committed to OpenSimCurrency to start a
> seperate project where they can collaborate on building a strong and robust
> currency system.
>

> So, for any of you that are really interested in OpenSimCurrency, what do
> you say to starting a parallel project that provides a third party currency
> framework that can run in OpenSim?


Go for it. Host it on the forge, create a wiki for it. Can't wait to see the 
first release.

 

Also, I believe there is still an Freenode IRC channel called #opensim-money.

 
/Stefan

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

Re: [Opensim-dev] Currency

[Stefan Andersson]

Rock,

 

If I understand your question correctly, the answer is that if you as a grid 
service provider have enabled being able to invest economically in assets thru 
the use of an external currency module, it is you as a responsible grid service 
provider that has to make sure the currency module and the asset server is 
secure enough for your business model.

 

This still holds: OpenSim is alpha software, provided without guarantee. It can 
be used in commercial settings provided you have the means to mitigate the 
risks involved. Most commercial grid operations have their own opensim 
development and quality assurance resources.

 

That said, there is nothing stopping noone from creating and distributing 
currency, points or other economic implementations. We have provided hooks and 
examples.


Best regards,
Stefan Andersson



 


From: colin.with...@eumetsat.int
To: opensim-dev@lists.berlios.de
Date: Wed, 8 Jul 2009 10:06:47 +0200
Subject: Re: [Opensim-dev] Currency





I fully understand that argument Stefan (although I do not agree with it). What 
I do not understand is how a currency module can be considered risky, but the 
entire asset server (holding everything that people have bought with an 
external currency module) is not considered even more of a risk.
 
Rock


From: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Stefan Andersson
Sent: Wednesday, July 08, 2009 7:54 AM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Currency
 
Rock,
 
An implementation of a functional monetary system has been declared as out of 
scope for OpenSim. It is something that has to go into the custom 
implementation/third party provider layer.
 
There is a live and ongoing discussion as of where to draw the line for what 
goes into the core, and what should be left to external module creators and 
custom implementation.
 
It is within scope of OpenSim to provide hooks so that such a module, tailored 
for the specific use case, be created.
 
As a project we need to draw a scope line somewhere, and often it’s a case of 
weighting several variables against each other.
 
In this case, it’s been a long standing stance that implementation of a 
monetary system is outside of the scope of the OpenSim core distribution.
 
We did provide the SampleMoneyModule, but the problem was that people was using 
this unsafe and immature example code directly in live and production 
environments. Though we could swear ourselves free from that with a  “suit 
yourself, it was wholly at your own risk”, it’s not only a legal case, but also 
a case of us not wanting to expose our users to unsafe and immature code that 
could cause them direct economic damage. We generally don’t want to take 
decisions for our users, but this one would be considered a real-world risk 
policy decision.
 
I believe that the very absence of a money implementation outside of core would 
be an indication that it’s right not having one inside; if there is no external 
module being maintained and used, it either means nobody see value enough to 
work on it, or that any implementation is too use case specific for there to be 
any value for the general public.
 
At any rate, it is my opinion that the whole economy domain needs a lot more 
work and reach a much higher level of maturity before anything could be 
considered for inclusion into the core distribution.
 
/Stefan
 



From: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Colin B. Withers
Sent: den 7 juli 2009 15:27
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Currency
 
If ReactionGrid uses no currency, and has no plans to ever have it, and does 
not wish to get involded in virtual commerce, using either core solutions or 
external solutions, then indeed it is a 3D chatroom. 3D chatrooms are well 
suited to Educational purposes, and indeed my own Opensim grid has been used by 
a US college for educational purposes. 
 
However, for a virtual space to take on the mantle of a virtual world, then 
commerce is an essential element, and currency is essential to that.
 
I think the argument that there is a risk in providing a currency module in 
core, from those who might complain "your code ate my money" is a specious 
argument. This charge could be levelled whenever opensim is used as a platform 
for a virtual world providing virtual real estate, for real world money 
(whether a  currency module is implemented in core or external) as if the grid 
goes down due to software bugs the grid owner stands to lose rental income, or 
be liable for the claims of others.
 
This can all be mitigated against (in territotories that allow it) by use of a 
carefully worded TOS.
 
Should the development of opensim be halted because someone might claim "your 
software crashed my hard-drive, and I have lost US$$$" or "the bugs in your 
software have contributed to me losing 

Re: [Opensim-dev] Currency

[Stefan Andersson]

Rock,

 

An implementation of a functional monetary system has been declared as out
of scope for OpenSim. It is something that has to go into the custom
implementation/third party provider layer.

 

There is a live and ongoing discussion as of where to draw the line for what
goes into the core, and what should be left to external module creators and
custom implementation.

 

It is within scope of OpenSim to provide hooks so that such a module,
tailored for the specific use case, be created.

 

As a project we need to draw a scope line somewhere, and often it's a case
of weighting several variables against each other.

 

In this case, it's been a long standing stance that implementation of a
monetary system is outside of the scope of the OpenSim core distribution.

 

We did provide the SampleMoneyModule, but the problem was that people was
using this unsafe and immature example code directly in live and production
environments. Though we could swear ourselves free from that with a  "suit
yourself, it was wholly at your own risk", it's not only a legal case, but
also a case of us not wanting to expose our users to unsafe and immature
code that could cause them direct economic damage. We generally don't want
to take decisions for our users, but this one would be considered a
real-world risk policy decision.

 

I believe that the very absence of a money implementation outside of core
would be an indication that it's right not having one inside; if there is no
external module being maintained and used, it either means nobody see value
enough to work on it, or that any implementation is too use case specific
for there to be any value for the general public.

 

At any rate, it is my opinion that the whole economy domain needs a lot more
work and reach a much higher level of maturity before anything could be
considered for inclusion into the core distribution.

 

/Stefan

 

From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Colin B. Withers
Sent: den 7 juli 2009 15:27
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Currency

 

If ReactionGrid uses no currency, and has no plans to ever have it, and does
not wish to get involded in virtual commerce, using either core solutions or
external solutions, then indeed it is a 3D chatroom. 3D chatrooms are well
suited to Educational purposes, and indeed my own Opensim grid has been used
by a US college for educational purposes. 

 

However, for a virtual space to take on the mantle of a virtual world, then
commerce is an essential element, and currency is essential to that.

 

I think the argument that there is a risk in providing a currency module in
core, from those who might complain "your code ate my money" is a specious
argument. This charge could be levelled whenever opensim is used as a
platform for a virtual world providing virtual real estate, for real world
money (whether a  currency module is implemented in core or external) as if
the grid goes down due to software bugs the grid owner stands to lose rental
income, or be liable for the claims of others.

 

This can all be mitigated against (in territotories that allow it) by use of
a carefully worded TOS.

 

Should the development of opensim be halted because someone might claim
"your software crashed my hard-drive, and I have lost US$$$" or "the bugs in
your software have contributed to me losing several tenants this week,
losing US$$$ in the process"?

 

The software is used 'as is', with no claims as fitness for any particular
purpose, and this would apply to any core currency module.

 

Rock

PS Another grid, that the owner ploughed 1000s of dollars into, has
collapsed recently, due to lack of a viable currency solution.

 

From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Chris Hart
Sent: Monday, July 06, 2009 3:50 PM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Currency

 

Couldn't disagree more - ReactionGrid has no inworld currency and no plans
to ever have it. Encouraging creativity, sharing, and collaborative learning
has proved more than worthwhile to us. And quite frankly, the legal and tax
issues around running a currency system should require dedicated qualified
experts to manage correctly. You can do a huge amount without play money
inworld - and if you want to pay someone money for a product, there are many
solutions out there that are properly regulated by financial services
authorities.

 

Money should be something you can add in yourselves if you want (hence I
believe it's on Forge these days), but I completely understand core
developer reluctance to have code in trunk that could potentially come back
to haunt with "your code ate my money" complaints.

 

Chris

 

From: Colin   B. Withers 

Sent: Monday, July 06, 2009 1:30 PM

To: opensim-dev@lists.berlios.de 

Subject: Re: [Opensim-dev] Currency

 

Has this alw

Re: [Opensim-dev] Deprecate OpenSim.Grid.InventoryServer and OpenSim.Grid.AssetServer?

[Stefan Andersson]

+1 by all means.

At the same time, I invite discussion on the cable beach descendant - do you
see that this one could be merged into the... bust?

Again, big thanks to you and Diva for pulling this off. It's a major step
forward indeed!

/Stefan

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Melanie
> Sent: den 7 juli 2009 22:32
> To: opensim-dev@lists.berlios.de
> Subject: [Opensim-dev] Deprecate OpenSim.Grid.InventoryServer and
> OpenSim.Grid.AssetServer?
> 
> Hi all,
> 
> we now have B.U.S.T., which runs the code that was originally in the
> asset and inventory servers. The asset server is new, from scratch,
> while the inventory server runs a port of the old code, courtesy of
> Diva, who translated it to in and out connectors.
> 
> This means that the old standalone inventory and asset servers are
> now no longer needed. I propose to move the legacy servers out,
> either by removing them completely, or by converting them to a forge
> project.
> 
> There is no need to have them, since B.U.S.T. can be configured to
> do just what they did, meaning, it can also run each service in a
> separate process, if desired.
> 
> Melanie
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev

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

Re: [Opensim-dev] Question: Collaborative tools in Opensim

[Stefan Andersson]

I know Darren implemented a pretty nifty real-time standard-issue SL viewer 
OpenSim whiteboard for drawing and placing images on, point and click - and the 
Rex people have been supporting VNC-on-a-prim for quite some time.

Best regards,
Stefan Andersson



 


Date: Fri, 3 Jul 2009 12:53:37 +0200
From: impa...@gmail.com
To: opensim-dev@lists.berlios.de
Subject: [Opensim-dev] Question: Collaborative tools in Opensim

Hi:

Yesterday, talking with a client who wanted something similar to a blackboard 
into Second Life, I was trying to remember if there is something similar for 
Opensim.

Not the clasical "prim-on-rez" blackboard (sometimes called "sim overloader 
blackboard) or the web-over-prim refresher and all that "almost but not" stuff.

Something like the Project Wonderland X11 integration or VNC full integration, 
or event the OpenCroquet 3D painter. Some thing that "really" allows to save 
the collaborative work and access to external applications.

So, that's my question: does this stuff exists for Opensim or there are plans 
to develop something similar?

Thanks

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

[Opensim-dev] Proposal: Changing Runprebuild.bat

[Stefan Andersson]

Guys,

 

As we officially no longer support Microsoft Visual Studio 2005 (neither Pro
nor Express) I propose we get rid of either of the runprebuild bats.

 

My vote is for the runprebuil2008.bat to go, and upgrade runprebuild to
build the vs2008 target.

 

Thoughts?

 

/Stefan

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

Re: [Opensim-dev] Adding virtual to many methods on Region/Framework/* for experimentation

[Stefan Andersson]

I would argue that opening up for (reasonable) subclassing is a very core ideal 
of opensim-as-an-API.

And on the subject; somewhere in 0.7 land, I would argue that we have to 
rethink the whole scene/SOG/SOP bit - right now, state and behavior is 
intermingled to the degree that we cannot do anything that requires reasonable 
decoupling of state and behavior. Not to mention if one were to start working 
with using these objects in a non-core context.

Just look at the scene constructor that I tried to write some unit tests for; 
it does way too much.

At some point, we need to have a little bit more subtle scene startup process 
than just throwing parameters on the constructor and have it start everything. 
I'd much rather see the constructor being empty and that various aspects were 
connected to the scene in passes.

Oh, well - just throwing cents around.

/Stefan

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Sean Dague
> Sent: den 1 juli 2009 21:36
> To: opensim-dev
> Subject: [Opensim-dev] Adding virtual to many methods on
> Region/Framework/* for experimentation
> 
> I'd like to make a number of the methods in SceneObject* (group/part)
> virtual to experiment with subclassing SOG/SOP for interesting effects,
> especially when it comes to generating object definitions in region
> modules.
> 
> I'm not really sure where any of this is going yet, but just wanted to
> make sure there weren't objections to adding virtual to methods there,
> or if there are unseen consequences of doing so.  I'm not really sure
> up front all the methods that might be interesting to do this with,
> though ProcessBackup is one that I want to make virtual early on.  It
> would just be good to get a feel that this is generally in the spirit
> of the project before I touch innards like this.
> 
> Please raise concerns if you have them.  I'd be looking to do some of
> this early next week if there aren't major objections, hopefully
> providing plenty of time for feedback.
> 
>   -Sean
> 
> --
> __
> 
> Sean Dague   Mid-Hudson Valley
> sda...@gmail.com Linux Users Group
> http://dague.net http://mhvlug.org
> 
> There is no silver bullet.  Plus, werewolves make better neighbors than
> zombies, and they tend to keep the vampire population down.
> __
> 


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

Re: [Opensim-dev] Help needed for stand alone grid for 800 users... HELP!

[Stefan Andersson]

I'm so happy saltwater melds in my eyes.

 

<3

Best regards,
Stefan Andersson



 
> Date: Mon, 22 Jun 2009 20:35:48 +0200
> From: mela...@t-data.com
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] Help needed for stand alone grid for 800 users... 
> HELP!
> 
> There I go, that was not supposed to go on-list. Sorry for the spam.
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Shaping the user services

[Stefan Andersson]

Separating login from user service has been one of my concerns for quite some 
time; doing so allow closed grids to expose only the login service while 
keeping all other interfaces behind the firewall.


I would argue that there should be exactly one grid services http port that has 
to be opened in the firewall; the one that answers the login xmlrpc (and llsd) 
request.

 

Everything else should be on other (protected) ports.

 

Pushing profiles out is also a big +1 for me, as I'm mainly concerned with 
being able to take that information form other backends.

 

While we're at it, could we please make the authentication token pluggable, or 
at least something a little bit less SL-centric than first, last, pass? 
pluggable credentials class would be best, but even string + pass would be 
better than the current.


Best regards,
Stefan Andersson



 
> Date: Mon, 22 Jun 2009 06:33:51 -0700
> From: lo...@ics.uci.edu
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] Shaping the user services
> 
> +1 on this, especially separating the login functionality from 
> everything else.
> 
> (I'll be back working on opensim shortly; I've been traveling and had 
> some technical difficulties at the destination)
> 
> Melanie wrote:
> > After breaking my head over this for a few weeks, I believe I have 
> > figured out how to do this in a sane way.
> > 
> > The fallacy was to assume that the login server and the user server 
> > would be one entity. That makes things overcomplicated and breaks 
> > the architecture all over the place.
> > 
> > Now, here is what I have come up with:
> > 
> > User Server:
> > - Resolve name to key queries
> > - Resolve key to name queries
> > - Provide avatar picker lists
> > - Manage home region data
> > 
> > Authentication server
> > - Create and manage authentication handles (string) and session keys 
> > (UUID)
> > - Check passwords or other forms of authentication
> > 
> > Login server
> > - Provide the interface for the Linden viewer to log into a grid. 
> > Uses the services above, but doesn't contain them.
> > 
> > Presence server
> > - Manages last position data
> > - Keeps list of logged in avatars and their locations
> > 
> > Alongside with this, a new database is needed. This will not be an 
> > upgrade path, but a parallel development with a migration tool.
> > 
> > Profile information has no place in this architecture and will be 
> > handled exclusively by the profiles module.
> > 
> > The user table will specifically be designed to accommodate 
> > additional fields and allow getting/setting of such fields.
> > 
> > With all user data, a scope identifier will be passed. This will be 
> > UUID.Zero in the most common case (Standalone or single grid) but 
> > will allow sharing of server processes between multiple logical grids.
> > 
> > Comments are welcome.
> > 
> > Melanie
> > ___
> > 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] Using Grider to teleport SL <-> OpenSim

[Stefan Andersson]

Diva,

 

I was reading the New World Notes on the grider teleports, and one thing 
occured to me;

 

Given I have understood the grider concept, couldn't grider be one way to 
accomplish "seamless" sl<->opensim teleports?


(seamless in a very wide sense, of course)

 

If I would set up an sl lightweight sim as a 'storefront' on SL, couldn't 
grider then intercept tp requests to that storefront and redirect it to my 
opensim region and vice versa?


Best regards,
Stefan Andersson



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

Re: [Opensim-dev] 0.7 Release Discussion

[Stefan Andersson]

I think I need to re-formulate myself; what I intended was for each of us to 
take the decision -for-ourselves- whether we wanted to work towards this goal 
or not.

 

I would never dream of trying to try to impose any suggestion of imposing 
anything on anyone. I just thought that if I'd call out, people could rally 
over an initiative and say 'hell yeah', 'I'm in', 'I'm going to take on 
mantis', 'what can I do to help!' et c.

 

For myself, I have now taken the oath -to-myself- to concentrate solely on 
mantis and nunit testing until we tag 0.7, whenever that is.


As a side effect of that thinking, I think I have begun thinking about a 
'OpenSim lightweight issue squashing cycle'. The goal there would be to 
maximize collaborative effect while minimizing personal effort. As always. 
Maybe that's something that can grow out of this 0.7 discussion.

 

One of the ideas I have is to have a mantis user class 'tester' that can

* close resolved cases (the idea is to ideally have the original reporter close 
it, but if we have resolved issues older than say two weeks, any tester can 
claim the issue, test it, and close)

* set issues as duplicate of another, or related to (this is probably one of 
the most low hanging fruit we have)

* set issues to "confirmed" (the idea being that issues that are older than say 
two months will automatically be demoted to "unconfirmed", and would have to be 
re-confirmed)

 

and quite possibly some other things as well. I believe this class is quite 
similar to the 'updater' class we already have, but that we don't use. Maybe 
with some tweaking, it could become that?

 

Anybody out there would want to be such a 'tester'? If so, now's the time to 
step forward.


Best regards,
Stefan Andersson



 


Date: Sun, 31 May 2009 13:40:17 -0700
From: c...@pacbell.net
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] 0.7 Release Discussion





Just to pick on the "Longest Open" for a little bit, here they are. The last 
column is the number of days the Mantis has been open.

It seems to me that a Mantis open over a year is a good candidate for a feature 
request, perhaps a 'wont fix' or even a 'we did fix and forgot to close'.

So, to avoid me unilaterally starting to close some of these, I would like to 
call on others to look into them and I will support *any* reasonable decision 
in getting our "Longest Open" to be less then 451 days old.

Charles








721 - opensim does not support https in *STANDALONE*
451

765 - Continual request of 'non existent asset' 
c228d1cf-4b5d-4ba8-84f4-899a0796aa97
444

960 - Neighbors that start up don't display
411

0001054 - On teleport, child agents are not hidden, but remain visible in 
region of origin
400

0001131 - Physical prims pushed off edge of region roll to infinity
392

0001147 - Doing shift-drag-copy linked non-phantom prims produces phantom copies
390

0001149 - Doing shift-drag-copy linked prims produces a new center point
390

0001176 - "Already logged in" message on first connect attempt
388

0001184 - Day Cycle Editor settings not remembered for sim
388

0001209 - There are currently no constraints on link set size or prim count.
387

0001211 - Individually set Phantom flag for prims in a linkset
387

0001217 - Edited child prims in linksets revert and don't save as changed
387

0001229 - Avatar sometimes remains with selection after right-clicking an object
385

0001244 - Prim permissions lost while in-world
384

0001317 - r4746 - client does not get or display "inventory timeout" message 
from region
377

0001332 - Taking groups of objects not implemented
376

0001342 - sitting pose is not correct when sitting on a box
375

0001343 - sitting pose is not correct when sitting on the rotated cylinder
375

0001344 - simulator can't provide service and system cpu 100%
375

0001347 - Client gets flooded upon logon and lag increased in sims
375

0001366 - sitting facing to the hill when sitting on tali ground
373

0001373 - Logouts/Dropoffs not properly registered at both User Server and 
Region server
373

0001379 - terrain load wildcard effect without using change regions first
371

0001397 - Prims out of FOV should not be rendered client-side
369

0001415 - llTargetOmega stops working from time to time







From: Charles Krinke 
To: opensim-dev@lists.berlios.de
Sent: Sunday, May 31, 2009 1:29:10 PM
Subject: Re: [Opensim-dev] 0.7 Release Discussion



No problem, man.

As I look at two other parts of the Mantis Summary page, both the "Longest 
Open" and the "Most Active" jump out at me.

So, ... I would suggest that if we were to concentrate on resolving/closing 
some of the "Longest Open" and "Most Active" that we have a way to move forward 
in a m

Re: [Opensim-dev] HUGE ASSET CACHE

[Stefan Andersson]

On a side note, one thing to profile would be to work towards having large 
binaries transferred as streams instead of bringing them into memory and 
transforming them into various temporary forms.

Best regards,
Stefan Andersson



 
> Date: Sun, 31 May 2009 08:12:30 -0700
> From: mcor...@gmail.com
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] HUGE ASSET CACHE
> 
> Dan wrote:
> > Is it possible to configure a huge disk asset-cache for region servers?
> A disk cache is currently being tested.
> 
> No guarantees, warranties, express or implied but the test patch is 
> available at
> 
> http://code.google.com/p/flotsam/downloads/list
> 
> This is just something I threw together in a couple minutes of coding as 
> a proof of concept for a file cache. There is no limiting or expiration 
> mechanism, and as such is not appropriate for production use. If 
> testing proves that it's useful, then I'll submit to mantis for 
> inclusion in OpenSim SVN.
> 
> --
> Michael Cortez
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] 0.7 Release Discussion

[Stefan Andersson]

Again, this would be entirely by agreement - anybody not wishing to do bug 
fixing can do whatever they like, but I do think even core devs get a kick out 
of bugfixing now and then, and adding stuff like those pesky last lsl commands.

 

Regarding the mantis, there are several things that can be done; and what I was 
_really_ thinking was that "clearing" would mean "getting organized"

 

If we can rally users and testers to help with the mantis, there are a number 
of things that can be done;

1) De-duplicate

2) Place mantis is "feature" vs "bug" - I did say "feature freeze" and this is 
roughly what I meant - the feature mantises would linger, but would not be part 
of this endeavour

3) Off major feature bugs onto the feature voting site

4) Re-reproduce and close of non-reproducible

5) Place major issues (that would require major restructuring) in a "post 
0.7.0" category


This way, we could "clear" mantis, as in getting to a point where all issues 
with the current feature set is fixed or closed.


Again, only striving to set a tone.


Best regards,
Stefan Andersson



 


Date: Sun, 31 May 2009 06:34:36 -0700
From: nebadon2...@gmail.com
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] 0.7 Release Discussion

I can agree with that, if everyone else agrees i have no problem with it, I 
would just hate for anyone to think that we are locking things up and they wont 
have our support.  And mostly i was more concerned with trying to clear mantis, 
that seams a bit unrealistic, as a good portion of fixing the mantis probably 
rely on us instituting many feature requests.  It kind of goes against the 
whole premise of freezing up feature requests.


On Sun, May 31, 2009 at 6:29 AM, Stefan Andersson  wrote:


Wise from experience, I would never propose anything as preposterous as to tell 
any core dev to do anything.
 
But if a substantial part of core devs and the patching community think it's a 
good idea and can be swayed to rally for it, I think we can see some really 
extraordinary measures that would make us all look pretty god damn good.

And hell, I stated it would be ambitious. Aim for the stars, hit the treetops, 
you know.
 
Best regards,
Stefan Andersson



 


Date: Sun, 31 May 2009 06:24:51 -0700
From: nebadon2...@gmail.com
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] 0.7 Release Discussion




Have you even looked at mantis??? there are 728 open tickets, chances are if we 
clear mantis, we will have OpenSimulator 1.0.. I personally don't see this as 
feasible, this is to me looks like us trying to control what all the developers 
are doing, and I have to -1 this idea as it would probably make most devs just 
stop working.

Neb


On Sun, May 31, 2009 at 6:20 AM, Stefan Andersson  wrote:



I do believe we're all feeling the advent of 0.7 - a milestone in any open 
source project.
 
Here's a crazy idea for you; how about we agree to freeze feature set and major 
architecture as of now, and concentrate on only:
 
* Finalizing the backend restructuring
* Clear mantis (hell, let's CLEAR mantis! how's that for ambitious?)
* Write unit tests
 
until the cows come home, and tag the cow homecoming rev as 0.7? Or, say, 1st 
of aug happens, and we'll tag 0.6.7 then instead. ;)

I believe this kind of solidified 0.7 would give us all a breather, help us 
recoup, and then we can all go back to fiddling with our various dev projects 
again.
 
What you say?

Best regards,
Stefan Andersson




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



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

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



-- 
Michael Emory Cerquoni - Nebadon Izumi @ http://osgrid.org
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] 0.7 Release Discussion

[Stefan Andersson]

Wise from experience, I would never propose anything as preposterous as to tell 
any core dev to do anything.

 

But if a substantial part of core devs and the patching community think it's a 
good idea and can be swayed to rally for it, I think we can see some really 
extraordinary measures that would make us all look pretty god damn good.


And hell, I stated it would be ambitious. Aim for the stars, hit the treetops, 
you know.
 
Best regards,
Stefan Andersson



 


Date: Sun, 31 May 2009 06:24:51 -0700
From: nebadon2...@gmail.com
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] 0.7 Release Discussion

Have you even looked at mantis??? there are 728 open tickets, chances are if we 
clear mantis, we will have OpenSimulator 1.0.. I personally don't see this as 
feasible, this is to me looks like us trying to control what all the developers 
are doing, and I have to -1 this idea as it would probably make most devs just 
stop working.

Neb


On Sun, May 31, 2009 at 6:20 AM, Stefan Andersson  wrote:



I do believe we're all feeling the advent of 0.7 - a milestone in any open 
source project.
 
Here's a crazy idea for you; how about we agree to freeze feature set and major 
architecture as of now, and concentrate on only:
 
* Finalizing the backend restructuring
* Clear mantis (hell, let's CLEAR mantis! how's that for ambitious?)
* Write unit tests
 
until the cows come home, and tag the cow homecoming rev as 0.7? Or, say, 1st 
of aug happens, and we'll tag 0.6.7 then instead. ;)

I believe this kind of solidified 0.7 would give us all a breather, help us 
recoup, and then we can all go back to fiddling with our various dev projects 
again.
 
What you say?

Best regards,
Stefan Andersson




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



-- 
Michael Emory Cerquoni - Nebadon Izumi @ http://osgrid.org
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

[Opensim-dev] 0.7 Release Discussion

[Stefan Andersson]

I do believe we're all feeling the advent of 0.7 - a milestone in any open 
source project.

 

Here's a crazy idea for you; how about we agree to freeze feature set and major 
architecture as of now, and concentrate on only:

 

* Finalizing the backend restructuring

* Clear mantis (hell, let's CLEAR mantis! how's that for ambitious?)

* Write unit tests

 

until the cows come home, and tag the cow homecoming rev as 0.7? Or, say, 1st 
of aug happens, and we'll tag 0.6.7 then instead. ;)


I believe this kind of solidified 0.7 would give us all a breather, help us 
recoup, and then we can all go back to fiddling with our various dev projects 
again.

 

What you say?


Best regards,
Stefan Andersson



___
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?

[Stefan Andersson]

How about configurable, with 0 being immediately?

Best regards,
Stefan Andersson



 


Date: Sat, 30 May 2009 20:52:19 +0200
From: drscofi...@xyzzyxyzzy.net
To: opensim-dev@lists.berlios.de
Subject: 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] Anonymous Avatar

[Stefan Andersson]

Set authenticate=false in the opensim.ini and create a local launcher 
application that launches the viewer with the arg –login {randomfirstname} 
{randomlastname} {dummy password} 
 
If you want to clear the avatar name, that would be really simple for a coder 
to clear the avatar names in the login process – just send spaces for first and 
last back in the loginresult. Also make sure the user server always returns 
empty values for all other users as well.
 
(both these have been done on many occasions when substituting the user/login 
service with something integrated to, for example, a third party user database)
 
If somebody would code a reasonably encapsulated and configurable patch for 
something like this, I think many would be thankful.
 
/Stefan


 
Best regards,
Stefan Andersson



 


Date: Thu, 28 May 2009 12:00:29 +0200
From: thomas.schind...@t-systems-mms.com
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Anonymous Avatar

Let's assume we set up a server and use it - let's call it - a showroom. This 
server would be accessable through the internet, so anybody could connect to 
it. Now it would be annoying to create new accounts anytime we want to show the 
content of our showroom to somebody, so we say: with login "guest" and password 
"guest" anybody can connect anytime to the server, can walk through the region 
but can do nothing else. So far, so good - no trouble until here. But it may be 
possible 2 or more person use this login at the same time. So the idea is to 
create temporary accounts on demand (guest1, guest2, ...) and delete them 
afterwards. Is this possible or are there restrictions in the login process, 
which can not be bypassed.

greetings
Thomas


Destiny Niles schrieb: 
are you talking about your own opensim region on a local system or one
of the systems that are hosted?
I guess in theory you could have pre-setup anonymous avatars in the
user database and a sql trigger to reset them on log out.

On Wed, May 27, 2009 at 8:05 AM, Daniel Herzog  wrote:
  
Hi all,



for some special purposes I want to have an anonymous avatar to log in into
OpenSim (no rights, no inventar, will be deleted after log out). Is this
possible in general and are there any ambitions or somebody who has already
done that?



Best regards,

Daniel

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


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

Re: [Opensim-dev] Tag 0.6.6

[Stefan Andersson]

I don't think there should be any limits as to when a release is tagged; go 
forth with the release cycle recipe - just make sure to apply the newly (post 
0.6.5) introduced 'Flavour' if you decide to do so.

 

http://opensimulator.org/wiki/Release_Cycle

Best regards,
Stefan Andersson



 


From: a...@deepthink.com.au
To: opensim-dev@lists.berlios.de
Date: Thu, 28 May 2009 09:51:30 -0400
Subject: [Opensim-dev] Tag 0.6.6





Is it appropriate to tag 0.6.6 given that there was a network break in trunk 
and now post-fixes users are incompatible? (I don’t think there is too much 
between the versions, so it would be a fairly minor upgrade)
 
Adam___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Memory cache

[Stefan Andersson]

Imaze,

 

if you are doing work from scratch, you always have the option to keep a 
proprietary version for yourself, whilst releasing one version as BSD. As long 
as you're not using code that any other OpenSim developer has committed, all 
rights still belong solely to you.

 

> Before jumping to coding with CnmHashGenerationCache - anyone have idea 
> what is IAsssetCache interface and why there isn't any implementation 
> for it? 

 

That I believe I can answer - I wrote the test class TestAssetCache to unit 
test the asset handlers - I would presume that by now, the asset handlers are 
using some new and improved interface (we are currently doing work in this 
area) and the test class was probably just 'left behind'. I will have a look at 
this and remove the tests and interfaces if they are no longer used.

 

> (Might also be result from bad trunk import) And why current 
> CoreCaches implementation class "Cache" is used directly in 
> FriendsModule and LandMaangementModule? I guess I could figure out these 
> by staring code long enough, but this just might be faster way and 
> collect some extra requirements/knowledge... :)


Of that I'm not 100% sure, but it is _probably_ for historical reasons, as 
Cache has been with us for some time.

 

/Stefan


> Thanks!
> 
> - Imaze Rhiano
> 
> Melanie kirjoitti:
> > In fact, it must be a BSD compatible license for all parts to be 
> > eligible for core. If any part is not licensed under a BSD 
> > compatible license, then it would have to live on Forge, which hosts 
> > other licenses.
> >
> > Melanie
> >
> > d...@metaverseink.com wrote:
> > 
> >> Imaze, this is awesome! Thank you so much for such extensive testing and 
> >> for doing the extra cache module implementation. This is really valuable.
> >>
> >> If there are no objections from fellow committers, I will be more than 
> >> happy to take an improved version of your code and add it to OpenSim as 
> >> a 3rd alternative cache module that people can test out there in the wild.
> >>
> >> Technically, your code needs thread-safety, that's all. Procedurally, it 
> >> also needs a license on top. If you want to give your code to the 
> >> OpenSim project, it needs the OpenSim license text. Otherwise, the cache 
> >> itself (CnmHashGenerationCache) needs to be added as a 3rd party dll, 
> >> and only the module would be 100% OpenSim. In any case, if you want to 
> >> do this, whichever way you want to do it, please do it via a patch 
> >> submitted in mantis, so we can have a record. 
> >> http://opensimulator.org/mantis
> >>
> >> As for the more substantial contribution of the Cenome DB, I'll leave 
> >> that to the people here who know more about DBs than I do.
> >>
> >>
> >> Imaze Rhiano wrote:
> >> 
> >>> Hi!
> >>>
> >>> I have done some research about asset server. I used lates trunk from 
> >>> this morning.
> >>>
> >>> Here are my findings:
> >>> 1. CoreAssetCache's CacheBuckets configuration is not working properly. 
> >>> Cache's size is limited to 1024 buckets, because of bug or by design. So 
> >>> "default" configuration value 32768 - didn't never happen.
> >>> See: private void SetSize(int newSize) in Cache.cs
> >>> lock (m_Index)
> >>> {
> >>> if (Count <= Size)
> >>> return;
> >>> .
> >>> }
> >>> During initialization phase, Count is 0 - so initial size value 1024 
> >>> is used. (And Count never can't grow up bigger than Size)
> >>>
> >>> 2. GlynnTucker cache is basically Hashtable that contains all assets 
> >>> they are never removed from cache unless assets is exlusively removed by 
> >>> calling Expire method. It definately can provide huge performance impact 
> >>> for short time - but eventually your server is going to run out of memory.
> >>>
> >>> 3. To evaluate different cache's performance I first tried to do some 
> >>> testing in stand alone SIM. Unfortunately single client, just didn't 
> >>> provide enough caching to really to measure performance, so I adopted 
> >>> different strategy. I did write simple Window$ console application with 
> >>> 4 different test cases.
> >>>
> >>> Test Case 1 "EnumerateAllTest": Just add assets to cache by predefined 
> >>> order and then try to get them from cache in same order. (Basically 
> >>> caches were pretty much guranteed to forgot first few thousands assets.)
> >>> Test Case 2 "GetRandom": Try to get random asset from cache, and if 
> >>> asset is not found, add it to there.
> >>> Test Case 3 "GetRandomMoreFrequentTest": Try to get random asset from 
> >>> cache, and if asset is not found, add it to there. However, this time 
> >>> there 1000 assets that are more likely asked than other assets (80% 
> >>> chance).
> >>> Test Case 4 "GetRandomMoreFrequentWithExpireTest": Same as Test Case 3 - 
> >>> except that there is 25% chance to remove (expire) random assets from 
> >>> cache for each item retrieve iteration. Remove assets didn't actually 
> >>> need to be in cache.
> >>>
> >>> From these test cases, case 4 is maybe most

[Opensim-dev] OpenSim lightweight Release Cycle

[Stefan Andersson]

I've added 

 

http://opensimulator.org/wiki/Release_Cycle

 

and

 

http://opensimulator.org/wiki/On_revisions%2C_tags_and_branches

 

to the wiki.

 

I would appreciate greatly if somebody could link to these pages from good 
places on the wiki.
 
Best regards,
Stefan Andersson



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

Re: [Opensim-dev] What is the difference between various releases

[Stefan Andersson]

No, there is only one revision connected to that _tag_, because tags should be 
considered static (by convention). 

 

When we say 'it's based on 9561' we mean, 'that was the trunk rev we chose to 
base the 0.6.5-rc on, and subsequent tags and branches'.


/trunk is a branch, off which we choose a candidate revision.

when we branch that off to /branches/0.6.5-rc1, that gets a new revision number.

subsequent work in 0.6.5-rc1 gets new, unique numbers, as does subsequent work 
in /trunk

the act of tagging the /tags/0.6.5-release creates a new and unique number for 
the 'tag' revision. (it's not a reference, it's a copy)

the act of renaming 0.6.5-rc1 to 0.6.5-post-fixes advances its revision number.

 

et c.

 

simply: the revision number is not a 'version number'.


Best regards,
Stefan Andersson



 


Date: Tue, 26 May 2009 10:02:07 +0200
From: avdle...@gmail.com
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] What is the difference between various releases

I understand what you're saying, but in that light, should the SVN 
releasenumbers stay 'static' for a given tag?
(Yes, I've read the mail about SVN version numbers).

I understand the 0.6.5-release is a tag, but I've already seen a lot of 
different SVN releasenumbers associated with that specific tag. Could it be 
there was a mistake in making the tag?

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

[Opensim-dev] FW: On Revisions, tags and branches

[Stefan Andersson]

In light of recent confusion, reposting this; should go onto wiki, I suppose.
 
Best regards,
Stefan Andersson



 


From: ste...@tribalmedia.se
To: opensim-dev@lists.berlios.de
Date: Sat, 4 Apr 2009 20:27:06 +0200
Subject: [Opensim-dev] On Revisions, tags and branches



Esteemed colleagues,
 
a couple of good-to-know points about SVN versioning;
 
In an SVN repo, the 'revision' is a discrete version of the software. But; the 
revision _number_ is _not_ an indication of sequential functional increment.
 
Revisions are based on the revision before it, but that does not have to be the 
one with the revision _number_ before it.
 
The revision number counter is global to the repo, hence it is upped whenever 
somebody does something within the repo, regardless of what branch the thing 
happens to.
 
An example:
 
I commit something to trunk, the rev number is upped to, say, 1337, and my new 
version is given that number.
 
I now branch trunk into /branches/mybranch. I do this by doing a remote copy of 
trunk. This copy of trunk, although identical to 1337, is a new version and is 
thus given the revision number 1338, the first revision on the new _branch_.
 
Now I commit a number of changes to trunk, spinning past 1339, 1340, 1341 and 
1342 - each being separate _versions_ but on the _branch_ called /trunk (think 
of it as paths)
 
Now, if I commit some minor change to /branches/mybranch, what revision number 
will it get? You guessed it - 1343.
 
If I now commit something to trunk again, it will get 1344. I then commit 
something to the really old branch based on, say, revision 666. It will get 
1345.
 
So, my point is: we really should stop talking only about revision numbers when 
we're trying to convey an idea of some kind of advancement of state.
 
Ie, in my example, 1344 is probably the one reflecting the most development, 
1343 is essentially based in 1337 and 1345, currently the highest rev number, 
could basically be six months old, with just a minor modification.
 
Now on to tags - trunk, branches and tags are really all one thing: paths. The 
only real difference is by convention: there is a certain path called /trunk 
that serves a certain purpose, nemaly to be the focal point for developers. 
There is a certain name used for paths other than trunk, and that is 
"branches". Some branches by convention aren't meant to be modified, but serve 
as snapshots of a point in time - they are called "tags".
 
But to the server, they are all revisions along differerent link paths. There 
is really nothing stopping you from committing to a tag - it's just the svn 
client will be reluctant to do so, as it's aware of the convention.
 
Keep this in mind, when referring to a 'revision' - it might be on a totally 
different path, so be sure to mention what path you're really talking about. 
specifying "trunk, between revision 1343 and 1780" or "0.6.2 post-fixes, 
between revision 1764 and 2006" again lets you compare revision numbers to 
indicate advancement of state.

So, don't tell people to check a certain revision out, unless you mean 
_exactly_ that version - tell them the logical path to it instead.
 
Just thought this might clear some confusion up.

Best regards,
Stefan Andersson
Tribal Media AB



___
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] Announce: 0.6.5-release now tagged

[Stefan Andersson]

All,

 

as of fifteen minutes ago, I just back-tagged 0.6.5-release, and subsequently 
turned 0.6.5-rc1 into 0.6.5-post-fixes.

 

This release is essentially based on trunk rev 9561, which has gotten some good 
review - plus version number bumping and some aplied minor fixes.

 

This is the last release to support Visual Studio 2005.


I will now upgrade trunk to reflect our current version as 0.6.5. (we don't up 
trunk until we know we have a proper release)

 

Tomorrow, I will also put into place a little mechanism to be able to specify 
"trunk", "rc1" or "release" in the version info.

 

Happy 0.6.5 everybody!


Best regards,
Stefan Andersson



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

Re: [Opensim-dev] Memory cache

[Stefan Andersson]

If the cache is releasing objects, I think we might well be seeing LOH 
fragmentation.

http://msdn.microsoft.com/en-us/magazine/cc534993.aspx

 

The solution would then be to break the binaries apart into byte cucks smaller 
than the LOH trshold.


Best regards,
Stefan Andersson



 
> From: a...@deepthink.com.au
> To: opensim-dev@lists.berlios.de
> Date: Wed, 20 May 2009 17:21:51 -0400
> Subject: Re: [Opensim-dev] Memory cache
> 
> We are using an external caching library I believe, it could be sitting in 
> there.
> 
> Adam
> 
> > -Original Message-
> > From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> > boun...@lists.berlios.de] On Behalf Of Melanie
> > Sent: Wednesday, 20 May 2009 1:56 PM
> > To: opensim-dev@lists.berlios.de
> > Subject: Re: [Opensim-dev] Memory cache
> > 
> > The surprise really is that the cache would be a performance loss
> > instead of a performance gain. What is there that makes it so slow?
> > 
> > Melanie
> > 
> > Frisby, Adam wrote:
> > > As chief engineer aboard the USS OSgrid, I might want to recommend
> > against this.
> > >
> > > Not having the sims cache assets will mean that every asset request
> > will hit the core asset server which in turn will result in higher
> > bandwidth requirements for it in the long run. It doesn't appear to
> > have made a huge impact on our bandwidth charts for this week yet -
> > however I wouldn't be surprised if it did if everyone did this.
> > >
> > > Adam
> > >
> > > From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> > boun...@lists.berlios.de] On Behalf Of Nebadon Izumi
> > > Sent: Wednesday, 20 May 2009 10:19 AM
> > > To: d...@metaverseink.com; opensim-dev@lists.berlios.de
> > > Subject: Re: [Opensim-dev] Memory cache
> > >
> > > Yay for mistakes that end in gains!!! of course if anyone asks i
> > planned this ;P anyway i thought people would like to see my ini
> > changes.. this is what lead to the discovery:
> > >
> > > [OpenSim.ini]
> > > ; The following is the configuration section for the new style
> > grid servers
> > > ; If you don't know what this is, don't enable it. It will eat
> > your data,
> > > ; format your hard drive and make all meat in your fridge spoil.
> > > ; You have been warned.
> > > ; Some of this is starting to work!
> > > [Modules]
> > > ; Choose one
> > > ;AssetServices = "LocalAssetServicesConnector"
> > > AssetServices = "RemoteAssetServicesConnector"
> > > ;AssetServices = "HGAssetBroker"
> > >
> > > ; If you don't want asset caching in the regions, comment this
> > > AssetCaching = "CoreAssetCache" ;<<<---*** SEE ERROR HERE ***---
> > ->>>
> > >
> > > ; Choose one
> > > ;UserServices = "LocalUserServicesConnector"
> > > UserServices = "RemoteUserServicesConnector"
> > >
> > >
> > > [AssetService]
> > > ; Parameters for local assets, formerly known as "standalone"
> > > LocalServiceModule =
> > "OpenSim.Services.AssetService.dll:AssetService"
> > > StorageProvider = "OpenSim.Data.SQLite.dll"
> > > ;StorageProvider = "OpenSim.Data.MySQL.dll"
> > > ;ConnectionString = "Data Source=localhost;Database=opensim;User
> > ID=opensim;Password=opensim;"
> > > DefaultAssetLoader =
> > "OpenSim.Framework.AssetLoader.Filesystem.dll"
> > > AssetLoaderArgs = "assets/AssetSets.xml"
> > >
> > > ; Parameters for remote assets, formerly known as "grid"
> > > AssetServerURI = "http://assets.osgrid.org:8003/";
> > >
> > > ; Paremeters for the Hypergrid connector
> > >
> > > ;; Parameters for the HG Broker
> > > ; Use this one if you have a standalone grid
> > > ;LocalGridAssetService =
> > "OpenSim.Services.AssetService.dll:AssetService"
> > > ; Use this one if this sim is connected to a grid-wide asset
> > server
> > > ;LocalGridAssetService =
> > "OpenSim.Services.Connectors.dll:AssetServiceConnector"
> > > ;HypergridAssetService =
> > "OpenSim.Services.AssetService.dll:HGAssetService"
> > >
> > > [AssetCache]
> > > ; Number of buckets for assets
> > > CacheBuckets = 32768
> > >
> > > [UserService]
> > > ;LocalServiceModule =
> > "OpenSim.Services.UserService.dll:UserService"
> > >
> > > [/OpenSim.ini]
> > >
> > > Please test this out and see if you see gains too and let us know.
> > >
> > > Neb
> > >
> > >
> > >
> > > -
> > ---
> > >
> > > ___
> > > Opensim-dev mailing list
> > > Opensim-dev@lists.berlios.de
> > > https://lists.berlios.de/mailman/listinfo/opensim-dev
> > ___
> > Opensim-dev mailing list
> > Opensim-dev@lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] breaking OpenSim.ini changes

[Stefan Andersson]

Zonja,

 

thank you for your feedback.

 

Has anybody else seen this behaviour, and is it something that has been fixed 
in subsequent revisions?

Best regards,
Stefan Andersson



 


Date: Wed, 20 May 2009 11:15:29 +0200
From: zonja.capal...@gmail.com
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] breaking OpenSim.ini changes

Hi,


I've been running 9561 since last sunday in my own grid and it works quite 
well. Particularly,
a problem with scripts in attachments not running with XEngine has been fixed.


Two things I've seen that are nasty:


* When I log in, all my attachments are gone, and I have to re-attach them.


* If I HG-tp somewhere and I come back home, the terrain in my home region
is not painted, and I move funny. I can tp to adjacent regions, tho, where
av behaviour is normal (but the home region remains undrawn and with
strange properties).


Regards,


/Zonja

On Wed, May 20, 2009 at 8:43 AM, Stefan Andersson  wrote:


Okay, so I branched off /branches/0.6.5-rc1 based on 9561, and upped the 
revision numbers.
 
Please all testers (from now on fondly known as "trunkheads") give that a spin, 
and give your feedback so we can nail it and update the wiki et c.

Best regards,
Stefan Andersson



 


Date: Tue, 19 May 2009 22:00:51 -0700
From: nebadon2...@gmail.com

To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] breaking OpenSim.ini changes


9561 is the last good rev before breakage I vote +1 for it being the release.

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

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


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

Re: [Opensim-dev] breaking OpenSim.ini changes

[Stefan Andersson]

Yes, I've done nothing in trunk.

 

Check out /branches/0.6.5-rc1

Best regards,
Stefan Andersson



 


Date: Wed, 20 May 2009 01:31:00 -0700
From: nebadon2...@gmail.com
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] breaking OpenSim.ini changes

I just updated trunk and its still reading 0.6.4.9611 when the region starts 
and also when you type "show version".
-- 
Michael Emory Cerquoni - Nebadon Izumi @ http://osgrid.org
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] breaking OpenSim.ini changes

[Stefan Andersson]

Okay, so I branched off /branches/0.6.5-rc1 based on 9561, and upped the 
revision numbers.

 

Please all testers (from now on fondly known as "trunkheads") give that a spin, 
and give your feedback so we can nail it and update the wiki et c.

Best regards,
Stefan Andersson



 


Date: Tue, 19 May 2009 22:00:51 -0700
From: nebadon2...@gmail.com
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] breaking OpenSim.ini changes

9561 is the last good rev before breakage I vote +1 for it being the release.

-- 
Michael Emory Cerquoni - Nebadon Izumi @ http://osgrid.org
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] breaking OpenSim.ini changes

[Stefan Andersson]

Can we _please_ post-tag a 0.6.5-rc1, from before the current breaking 
changeset? Anybody got a good candidate rev?

Best regards,
Stefan Andersson



 


Date: Tue, 19 May 2009 05:43:06 -0500
From: mark.malew...@gmail.com
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] breaking OpenSim.ini changes

I completely agree with Charles...


It might be good idea to at least try to schedule or group all the ini 
"breaking" changes together, and also try to implement them as close to a new 
point release as possible, so that we can at least try to preserve 
"compatibility" between build versions and "minor update" releases and give 
users proper notice. 


By scheduling the "breaking changes" together in groups, it would also give us 
additional time to update the WIKI pages, and properly document all the new INI 
changes in an updated "ReadMe" file as well.  


 Mark


On Mon, May 18, 2009 at 8:20 PM, Charles Krinke  wrote:




We seem to have breaking changes in OpenSim.ini today and I would like to 
recommend that we slow that down. 

In the past, we have been very careful about breaking changes in OpenSim.ini to 
preserve compatibility and go out of our way to send notice. It seems that 
changing syntax in our .ini file is something that should be done with 
deliberation and more concern and notice to our users.

Charles

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


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

Re: [Opensim-dev] WARNING: r9562 may break things

[Stefan Andersson]

Diva, Melanie;

 

kudos on you both - what I see of the new arch pleases my eye immensely. ;-)

 

That said, would you feel comfortable merging all the 
OpenSim.Servers.X.Handlers projects into one OpenSim.Servers.Handlers project? 
As it stands now, with a Server, a Service and a Handler Project per backend 
function, there will be lots of small projects in the solution.


On a side note, shouldn't the Region server move into the Servers as well? Just 
a thought.


Best regards,
Stefan Andersson



 
> Date: Fri, 15 May 2009 10:37:27 +0200
> From: mela...@t-data.com
> To: d...@metaverseink.com; opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] WARNING: r9562 may break things
> 
> Diva,
> 
> good work, thank you.
> 
> "Modules" is meant to be more generic, It is supposed to be a 
> section holding all module selections eventually. I would appreciate 
> being asked about this, and I'd like it changed back.
> 
> Melanie
> 
> 
> d...@metaverseink.com wrote:
> > Everyone --
> > Just a warning to please stay away from head, starting in r9562, for the 
> > next couple of days unless you really really really want to help test 
> > things. We started replacing the services to the new service model that 
> > was discussed here a few weeks ago, staring with the asset service. For 
> > starters, there are new configuration variables in OpenSim.ini that you 
> > need to get acquainted with -- see the OpenSim.ini.example at the 
> > bottom. But unless you really need to be in head, don't; please wait at 
> > least 24 hours.
> > 
> > Melanie --
> > The transplant is mostly done. See commit message for the things that 
> > are borked. Also note, I changed the config var you had called "Modules" 
> > to "ServiceConnectors", you probably need to change your local .ini.
> > Talk to you tomorrow.
> > ___
> > Opensim-dev mailing list
> > Opensim-dev@lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> > 
> > 
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] MRM Loader

[Stefan Andersson]

Mike,

 

massive bigups for the mrml, and phat kudos on the blog post! :D


By the way, what is the current state of affairs for the dotnetengine vs 
xengine? I'm perfectly aware of the differences and whys of having two engines, 
but is the dotnetengine even used or maintained anymore?

 

Is there a degree of abstraction that can be attained so as to fuse them into 
one configurable LSL Script Engine?


Best regards,
Stefan Andersson



 


Date: Tue, 12 May 2009 21:38:11 -0700
From: m...@maimedleech.com
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] MRM Loader


In response to some questions I've received, I created a blog post that 
explains how MRM Loader fits into the OpenSim programmability picture, along 
with DotNetEngine, XEngine, MRM Scripts, and Region Modules.
 
  == Mike ==


On Mon, May 11, 2009 at 11:55 PM, Mike Deem  wrote:


Hello, I would like to call your attention to a new forge project: MRM Loader. 
 

MRM Loader is an experimental package based application model for virtual world 
content. Packages will contain assemblies, textures, prims, and all the other 
assets necessary to fully describe and implement a house, vehicle, attachment, 
etc. They will be downloaded from web sites and run by Open‍Sim.

MRM Loader also allows MRM code to be edited, compiled, and debugged using 
Visual C# Express, all without restarting Open‍Sim.


MRM Loader provides a region model that looks for scripts that contain 
"//MRM:Loader {package-path}" and loads the indicated MRM package into an 
application domain created just for it. The region module unloads these 
application domains when the script is removed. Only package paths that 
identify a directory on the local machine are currently supported. All of an 
MRM's assemblies are loaded from this directory.

MRM Loader extends Adam's MRM infrastructure. The MRM region module must 
enabled in order to use MRM Loader functionality. It is also currently 
necessary to apply a patch to MRM module before it can be used with MRM Loader 
(mantis).

See this thread for instructions.
Thanks,
 
  == Mike ==
 
 
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Exposed web interfaces in OpenSim

[Stefan Andersson]

Excellent job! Now, if we could just get example interaction contents for each 
of those, we'd open a world of possibilitites for web developers! :D
 
Best regards,
Stefan Andersson



 
> Date: Fri, 8 May 2009 16:23:34 +0300
> From: sempu...@gmail.com
> To: opensim-dev@lists.berlios.de
> Subject: [Opensim-dev] Exposed web interfaces in OpenSim
> 
> I wanted to enumerate all web interfaces in OpenSim (XMLRPC, REST,
> CAPS, LLSD -- anything no in SLUDP) by simply greping for where anyone
> adds handlers.
> 
> The following is that list:
> http://opensimulator.org/wiki/Known_Web_Interfaces_within_OpenSim
> 
> Would that list be complete, accurate, useful?
> 
> Which ones are SL and which are OS-only? Hypergrid interfaces are
> usually clearly denoted. :)
> 
> Cheers,
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

[Opensim-dev] OpenSim hits r10k.

[Stefan Andersson]

So, I just comitted revision r9449 - which means we will hit r10k pretty soon.

 

Think about it. 10 000 commits. That's like putting two millimetre thick coins 
on top of each others, and getting a stack that is.. well.. 20 000 
millimetres... which is roughly 20 metres. Which, while not being as long as to 
the moon and back, still is longer than any of us. Maybe the lenght of all the 
active core devs when laid down in a row, head-to-foot?


So, what should we do to celebrate? Another link-and-blog-fest and having 
another go att trying to tidy the example content up?

Best regards,
Stefan Andersson



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

Re: [Opensim-dev] Upgrading NUnit

[Stefan Andersson]

The Test assemblies are built with a reference to that dll, but when you run it 
in another environment, you can but hope that the signatures of the compiled 
dll and the hosting processes dll match.


Most oftenly, it will work, but sometimes, it will break. I must admit I don't 
know exactly why it breaks, as the typeloader just gives me an NullException.

 

Anyway, if this is a breaker for the linux peeps, I suggest we postpone until a 
fix has arrived.

 

I can download an older nunit-gui. ;-)
 
Best regards,
Stefan Andersson



 
> Date: Wed, 6 May 2009 20:33:07 +0800
> From: mma...@gmail.com
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] Upgrading NUnit
> 
> Hi,
> 
> On Wed, May 6, 2009 at 6:28 PM, Stefan Andersson  
> wrote:
> > I started working on some weird failiures in tests yesterday, and realized
> > that our current nunit-framework is somewhat lagging behind, to the point of
> > the newest nunit-gui not accepting OpenSim tests. (On Windows)
> 
> Is the nunit dll in the bin/ directory used when tests are run?
> Perhaps it is on Windows...
> 
> To my understanding, the nunit dll in the bin/ directory is there to
> satisfy build dependencies, but when the tests are run, the nunit
> executables and dlls installed on the system (and being run) are used
> instead.
> 
> Can anyone clarify?
> 
> Thanks,
> Mike
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

[Opensim-dev] Upgrading NUnit

[Stefan Andersson]

Hey guys,

 

I started working on some weird failiures in tests yesterday, and realized that 
our current nunit-framework is somewhat lagging behind, to the point of the 
newest nunit-gui not accepting OpenSim tests. (On Windows)

 

I propose we update to the latest version of nunit-framework to remedy this.


 

I have created a mantis with a patch

http://opensimulator.org/mantis/view.php?id=3591

 

which I believe does this, and fixers some build errors stemming from minor 
introduced nunit framework changes.

 

Whoever applies it (yo, sdague!) should make sure that our builder system 
'Panda' doesn't get acute indigestion on this.


Best regards,
Stefan Andersson



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

Re: [Opensim-dev] Alternatively Identifying Assets using URL's

[Stefan Andersson]

It is my impression that adressing by uri/url has been a goal for the last 1.5 
years or so.

 

I'd be interested in hearing if there's actually anybody _not_ wanting us to 
work towards that.

 

The only issue that I can see would be in regards to SL compatibility. I have 
started to poc an approach where guid-based adressing of resources is 
considered a thing purely between the viewer and the content endpoint (aka the 
region) - that the region acts as a 'proxy' translating guids to uris and back 
as needed. So far the code is merely stubs, so I haven't got to the point of 
proofing it, but I believe you all understand what I'm saying. Have a look at 
what uses the fairly new ContainsReferences method on AssetBase to see where I 
was going.

Best regards,
Stefan Andersson



 
> Date: Fri, 1 May 2009 08:56:57 +0300
> From: tommi.s.e.laukka...@gmail.com
> To: opensim-dev@lists.berlios.de
> Subject: [Opensim-dev] Alternatively Identifying Assets using URL's
> 
> If we do not consider SL restrictions for a second and look to the
> future it would be nice to discuss the following which popped out from
> dahlias idea of supporting loading textures from websites directly and
> Stefans suggestion of using strings as ids in the standard format
> thread:
> 
> It is good to consider supporting identification of assets by
> traditional urls. Some public asset servers could be www servers or
> svn http servers. As all 3d modeling programs are refering to
> aggregate assets using file paths, it would be easy to upload the
> model to SVN http server and then using viewer pull out the model and
> aggregate assets for viewing. This could be alternative asset
> distribution model. it could work through region asset cache or
> directly from viewer to the http server. This could be much more
> scalable than the current model. I realize this is a threat to the
> data consistency as models and aggregate assets are not saved to
> relational database which could safeguard relations. It is also viable
> only for completely public content but I assume considerable portion
> of the vw content is likely to be freely distributable.
> 
> This would be in practice support for "importing" content from web on the fly.
> 
> -tommi
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] moving away from grid vs. standalone

[Stefan Andersson]

+1 on breaking things more often in trunk.

That said, unless we have 'release' tags reasonably up-to-date, people will use 
trunk and resent opensim for it not working, whatever we tell them.

Best regards,
Stefan Andersson




> Date: Thu, 30 Apr 2009 00:01:43 +0200
> From: mela...@t-data.com
> To: d...@metaverseink.com; opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] moving away from grid vs. standalone
> 
> Maybe these things need to be broken. We are almost locked into a 
> rigid schema, now we still have a chance to go to true modularity 
> and we should take it. After all, trunk is meant to be broken :)
> 
> Melanie
> 
> d...@metaverseink.com wrote:
> > I'm also noticing that the region registration with the grid happens 
> > before the post-initialization of the region modules, at least as of 
> > now. In other words, the design has been that Comms would be in place 
> > very early on, so if we change that, it may break all sorts of random 
> > things.
> > 
> > Melanie wrote:
> >> I have done a lot of stuff related to that. Master avatar should not 
> >> even exist in the way it still does today, that is legacy. The very same 
> >> thing can be done in another way (code-wise).
> >> So the existing master avatar stuff can be removed,if that is the only 
> >> blocker, i'll think up some new semantics for that and implement it.
> >> 
> >> Melanie
> >> 
> >> d...@metaverseink.com wrote:
> >>> I think that there is a technical obstacle to doing that: the master 
> >>> avatar stuff, that happens early on in the application (OpenSimBase, 
> >>> line 688), needs to have the communication code in place. I think -- 
> >>> although I may be wrong -- that that happens before region modules are 
> >>> in place.
> >>>
> >>> Melanie wrote:
> >>>> I still think all that stuff can be put in region modules
> >>>>
> >>>> Melanie
> >>>>
> >>>> d...@metaverseink.com wrote:
> >>>>> Maybe the right name for it is
> >>>>> OpenSim.Region.ResourceServicesConnectors.dll
> >>>>>
> >>>>> d...@metaverseink.com wrote:
> >>>>>> Stefan Andersson wrote:
> >>>>>>> How about
> >>>>>>>  
> >>>>>>> ---
> >>>>>>> [RegionResourceServices]
> >>>>>>> ;GridService = OpenSim.Region.Communications.Hypergrid.dll, 
> >>>>>>> HGGridServices
> >>>>>>> ;GridService = OpenSim.Region.Communications.Local.dll, 
> >>>>>>> LocalBackEndServices
> >>>>>>>  
> >>>>>>> GridService = OpenSim.Region.Communications.OGS1.dll, 
> >>>>>>> OGS1GridServices
> >>>>>>>  
> >>>>>>> [GridService]
> >>>>>>> grid_server_url = "http://192.168.1.101:9000";
> >>>>>>> grid_send_key = "null"
> >>>>>>> grid_recv_key = "null"
> >>>>>>
> >>>>>> The problem with specifying dlls *in this particular case* is that 
> >>>>>> these things aren't entirely orthogonal/different. The Hypergrid 
> >>>>>> dlls are a mashup of the other two. Therefore from a source code 
> >>>>>> perspective it makes things a heck of a lot more complicated than 
> >>>>>> they need to be if we simply merge things and use conditionals on 
> >>>>>> configuration variables. For example, hyperlinks (part of grid 
> >>>>>> services) is a really simple extension to LocalGrid services.
> >>>>>>
> >>>>>> The issue of local vs remote services isn't entirely orthogonal 
> >>>>>> either. Some parts of OGS1 use Local services -- the well know 
> >>>>>> pattern of trying things locally first and if that doesn't work, 
> >>>>>> proceed for a remote service call (e.g. OGS1 grid services does that).
> >>>>>>
> >>>>>> I see why you want this, in abstract. If another service comes 
> >>>>>> along, it can simply be added as a component. Or if someone writes, 
> >>>>>> say, a completely different inventory service, its interface can be 
> >>>>>> added as dll.
> >>>>>>
> 

Re: [Opensim-dev] Standardizing OpenSim data formats

[Stefan Andersson]

John,

great initiative, great work.

Could we move away from 'uuid' as identifier for resources (users, assets, 
inventory) and instead use 'string' on a protocol level? As we're trying to 
move towards that in the code and database, I think having it already in the 
protocols would be one less obstacle.

Best regards,
Stefan Andersson




> From: john.hurli...@intel.com
> To: opensim-dev@lists.berlios.de
> Date: Tue, 28 Apr 2009 17:32:12 -0600
> Subject: [Opensim-dev] Standardizing OpenSim data formats
> 
> Currently, OpenSim server<->server communication is primarily made up of .NET 
> XML serialization. As a side effect of this, I've seen the wire format 
> between simulator and grid services or grid service to grid service change 
> many times since I started working on backend services. The OAR file format 
> has also changed at least once while retaining the same version number 
> because the underlying prim XML format changed. I am working on a libomv OAR 
> reader/writer at the moment, and trying to deal with hacks for supporting pre 
> and post change OAR files.
> 
> To increase compatibility between versions of OpenSim and with third party 
> services I'd like to propose a standardization of (eventually) all 
> over-the-wire communication in OpenSim. I started with an attempt at an LLIDL 
> definition for primitives:
> 
> http://opensimulator.org/wiki/PrimitiveFormatProposal
> 
> Is anything missing? Does this look like a reasonable start?
> 
> John 
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] moving away from grid vs. standalone

[Stefan Andersson]

> > 2.  On your previous suggested ini stuff, in my opinion something like
> > 
> > UserService = { local | remote }
> > 
> > would be clearer than
> > 
> > LocalUserService = {True|False}
> > 
> >  From what I remember, specifying remote is understandable even if the 
> > services are actually on the same machine (but 
> > one has chosen to run them as separate processes).  Local would naturally 
> > denote the use of services in the same process 
> >   as the simulator.
> 
> Actually, there's a subtle but very important difference in the case of 
> hypergrid. A standalone grid wanting to allow Guests would have to use 
> the Remote dll, even though the service for local users is local.

I don't see a problem with 'chaining' services; something like

[RegionResourceServices]

GridService = OpenSim.Region.Communications.Hypergrid.dll, HGGridServices

[Hypergrid]
RemoteGridService = OpenSim.Region.Communications.OGS1.dll, OGS1GridServices 

> This is, in fact, the kernel of the complexity here. Local has been 
> designed to be Sandbox connectors, and OSG1 has been designed to connect 
> with exactly *one* of each type of service. All remote calls in it 
> hardcode serversInfo.xxxURL.

Yes. As part of the login/distributed assets refactoring, I was thinking of 
introducing an UserServicesManager that would keep proxies to all registered 
user services. Of course, I never got that far.

> The Hypergrid needs the regions to interact with *several* of each type 
> of service, potentially, including the local one. So, most of the 
> hypergrid changes have to do with determining local vs remote and, if 
> remote, determining the service URL, making it a variable instead of a 
> constant.

Again, some kind of repository for proxy classes would probably be the easy 
way, I think. the proxy classes could just as well be non-proxy persistent 
(local db), non-proxy volatile (in-mem), proxy to 'home' user service or proxy 
to foreign service. It would be the proxies that contained the 
protocol-specific functions to resolve calls (or just local in-mem calls in 
case of local)

+1 on the

> AllowGuests = {True|False}
vs
> gridmode = {True|False}


> So if we want to keep 3 architectures around, as separate architectures 
> (and not one, more general), we have a meta option here:
> 
> ServiceConnectors = {Sandbox|LLGrid|Hypergrid}

again, I guess service connector plugins could report a 'short name' that could 
be used in resolving configurations like this.
 
> With this, I can make the hypergrid architecture have configuration 
> variables to be able to generate all of the behaviors of Sandbox and 
> LLGrid, and more -- basically place the ideas on my original email under 
> the Hypergrid mode, and leave the other two as they are now.

For what it's worth, I think that all the various services should share a 
common abstract baseclass (per domain) so we can pull up and push down freely.

/Stefan

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

Re: [Opensim-dev] Opensim-dev Digest, Vol 20, Issue 75

[Stefan Andersson]

Just a heads up; I will probably not have time to champion the release cycle I 
have outlined in earlier posts - I hereby declare and underline it being a 
community effort.

Best regards,
Stefan Andersson

> From: r...@ralf-haifisch.biz
> To: opensim-dev@lists.berlios.de
> Date: Sat, 25 Apr 2009 20:15:47 +0200
> Subject: Re: [Opensim-dev] Opensim-dev Digest, Vol 20, Issue 75
> 
> Stefan,
> 
> i did play yesterday and today with different version over my whole set of
> regions.
> 
> While I have to admit not to be looking for something perfect and errorfree
> - SVN 9292 does look nice to me.
> 
> Anyone better suggestions ?
> 
> Somewhere in the later versions I have more trouble with region crossing /
> worldmap .. nothing dramatic, but 9292 is more stable (and has nice
> performance) from my tests.
> 
> If no other proposed version comes up, I would give it some days - maybe
> till Friday.
> 
> 
> Cheers,
> Ralf
> 
> Founder & Editor at
> www.maxping.org 
> ------
> 
> Message: 4
> Date: Sat, 25 Apr 2009 08:25:48 +0200
> From: Stefan Andersson 
> Subject: Re: [Opensim-dev] Request for feedback: 0.6.5 Release
>   Candidate Prospects
> To: "opensim-dev@lists.berlios.de" 
> Message-ID: 
> Content-Type: text/plain; charset="iso-8859-1"
> 
> 
> So, can anybody champion a suitable rc revision? Give us a number,
> goddammit! :D
> 
> Best regards,
> Stefan Andersson
> 
> 
> 
> 
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] moving away from grid vs. standalone

[Stefan Andersson]

Fair enough. Again, I'm all in favour for actual coding and experimentation 
over upfront architecture debates.

Best regards,
Stefan Andersson




> Date: Wed, 29 Apr 2009 09:48:12 -0700
> From: d...@metaverseink.com
> To: ste...@tribalmedia.se
> CC: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] moving away from grid vs. standalone
> 
> Stefan Andersson wrote:
> > How about
> >  
> > ---
> > [RegionResourceServices]
> > ;GridService = OpenSim.Region.Communications.Hypergrid.dll, HGGridServices
> > ;GridService = OpenSim.Region.Communications.Local.dll, LocalBackEndServices
> >  
> > GridService = OpenSim.Region.Communications.OGS1.dll, OGS1GridServices
> >  
> > [GridService]
> > grid_server_url = "http://192.168.1.101:9000";
> > grid_send_key = "null"
> > grid_recv_key = "null"
> 
> The problem with specifying dlls *in this particular case* is that these 
> things aren't entirely orthogonal/different. The Hypergrid dlls are a 
> mashup of the other two. Therefore from a source code perspective it 
> makes things a heck of a lot more complicated than they need to be if we 
> simply merge things and use conditionals on configuration variables. For 
> example, hyperlinks (part of grid services) is a really simple extension 
> to LocalGrid services.
> 
> The issue of local vs remote services isn't entirely orthogonal either. 
> Some parts of OGS1 use Local services -- the well know pattern of 
> trying things locally first and if that doesn't work, proceed for a 
> remote service call (e.g. OGS1 grid services does that).
> 
> I see why you want this, in abstract. If another service comes along, it 
> can simply be added as a component. Or if someone writes, say, a 
> completely different inventory service, its interface can be added as dll.
> 
> But in this particular case, for the code we already have, I think that 
> having Local.dll, OGS1.dll and Hypergrid.dll is not working well, even 
> if the configuration process is the one you suggest. The code is mess; 
> things are _way_ more complicated than they need to be.
> 
> So, maybe, what we can do is merging these two ideas. We'll have only 
> one dll (OpenSim.Region.ResourceServices.dll), but we'll specify things 
> in OpenSim.ini the way that you suggest, so that if anyone comes along 
> and wants to plug in a different inventory service, he can just specify 
> the  other dll and an entry class name for it.
> 
> What do you think?
> 
> 
> > [Security]
> >  
> > SessionAuthentication = {True|False}
> > KeyAuthentication = {True|False}
> > 
> > ---
> >  
> > The constructor is being fed a config source, so the service can pick 
> > out whatever it needs.
> >  
> > All the shipped grid services could move into one assembly, as we're 
> > explicitly specifying the implementing calss.
> >  
> > I believe this approach would get us improved flexibility.
> > 
> > /Stefan
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] moving away from grid vs. standalone

[Stefan Andersson]

We could then have an method similar to the way we define/select physics 
engines;

> 2.  On your previous suggested ini stuff, in my opinion something like
> 
> UserService = { local | remote }
> 
> would be clearer than
> 
> LocalUserService = {True|False}

So that each UserService module needs to expose a Name that in this case would 
be either "local" or "remote"?

And then maybe even "foo"?

/Stefan

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

Re: [Opensim-dev] moving away from grid vs. standalone

[Stefan Andersson]

In my world, the grid=true and all that were simply shorthands. It's always 
been our (my) intention that we would get to a point where you'd 'assemble' 
your installation, preferrably thru a gui.


> Below is a draft of 
> what OpenSim.ini could look like. Thoughts?
> 
> --
> 
> [RegionResourceServices]
> 
> grid_server_url = "http://192.168.1.101:9000";
> grid_send_key = "null"
> grid_recv_key = "null"
> ; are we to optimize for a standalone grid?
> LocalGridService = {True|False}


How about

 

---

[RegionResourceServices]

;GridService = OpenSim.Region.Communications.Hypergrid.dll, HGGridServices

;GridService = OpenSim.Region.Communications.Local.dll, LocalBackEndServices

 

GridService = OpenSim.Region.Communications.OGS1.dll, OGS1GridServices

 

[GridService]

grid_server_url = "http://192.168.1.101:9000";
grid_send_key = "null"
grid_recv_key = "null"


[Security]
 
SessionAuthentication = {True|False}
KeyAuthentication = {True|False}


---

 

The constructor is being fed a config source, so the service can pick out 
whatever it needs.

 

All the shipped grid services could move into one assembly, as we're explicitly 
specifying the implementing calss.

 

I believe this approach would get us improved flexibility.


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

Re: [Opensim-dev] GetAssetStreamHandler, grid mode and caching

[Stefan Andersson]

Diva, Tommil,

 

as being the one actually introducing the Get/SetAssetStreamHandlers, I can 
tell you that they are quite simply just that - handlers for incoming requests 
for assets.

 

Whether they should be cached or not is of course subject to the same questions 
as any 'should this be cached' discussion.

 

I see no reason why they shouldn't be. The reason they aren't is because they 
are jurassic - stemming from the 'true alpha' days when caching would just add 
another layer to debug.

Best regards,
Stefan Andersson



 
> Date: Sun, 26 Apr 2009 09:40:44 -0700
> From: d...@metaverseink.com
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] GetAssetStreamHandler, grid mode and caching
> 
> Tommil,
> 
> RegionAssetService is meant to be an http service to get assets from 
> regions when they run in standalone mode. Hence that original logic it 
> had for being enabled on the Hypergrid. In gridmode+HG, that module is 
> not enabled.
> 
> If you want to get assets from regions when you are in gridmode, you 
> should use the AssetCache, obviously. I suggest you don't touch 
> GetAssetStreamHandler, because (I think) that's meant to be what it is: 
> the raw request. It's your code's business to figure out what to do in 
> these different modes.
> 
> We can go into the old discussion about the complexity of managing 
> standalone vs grid mode, and all the headaches, but that's a much deeper 
> issue...
> 
> Crista
> 
> Tommi Laukkanen wrote:
> > Hello
> > 
> > Does someone know why GetAssetStreamHandler is not using cache but
> > fetching data directly from database with asset data plugin? This can
> > cause pretty heavy load on database when a lot of assets is loaded via
> > HTTP.
> > 
> > I noticed this when debugging why RegionAssetService does not work in
> > grid mode. It fails as GetAssetStreamHandler tries to load the assets
> > via data plugin which is not present in region instead of using
> > assetcache which is used by ll clients.
> > 
> > I would like to propose changing GetAssetStreamHandler to use
> > AssetCache to enable MXP enabled client to load assets via region in
> > grid mode (ll viewers load assets via region in grid mode but use
> > UDP).
> > 
> > -tommi
> > ___
> > Opensim-dev mailing list
> > Opensim-dev@lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> > 
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Request for feedback: 0.6.5 Release Candidate Prospects

[Stefan Andersson]

So, can anybody champion a suitable rc revision? Give us a number, goddammit! :D

Best regards,
Stefan Andersson




> From: a...@deepthink.com.au
> To: opensim-dev@lists.berlios.de
> Date: Fri, 24 Apr 2009 22:59:50 -0400
> Subject: Re: [Opensim-dev] Request for feedback: 0.6.5 Release Candidate 
> Prospects
> 
> I think those j2k cache files are somewhat necessary - perhaps we can get 
> those moved into a special subfolder so they don't clog up your bin 
> directory, alternatively we could move them into our caching subsystem where 
> assets go so they are part of a virtual file system.
> 
> That being said, if there are no other major outstanding issues, it is 
> probably a good time to tag 0.6.5; since there are a number of .NET 3.0 
> features I would like to begin utilizing (like lambda functions, etc). (This 
> is assuming that Mono 1.9 is now the defacto standard with Ubuntu/etc, or 
> that 1.2.X supports these.)
> 
> Adam
> 
> > -Original Message-
> > From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> > boun...@lists.berlios.de] On Behalf Of Ai Austin
> > Sent: Thursday, 23 April 2009 9:09 AM
> > To: opensim-dev@lists.berlios.de
> > Subject: Re: [Opensim-dev] Request for feedback: 0.6.5 Release
> > Candidate Prospects
> > 
> > 
> > >Would this be a good time to look for the 0.6.5 release?
> > 
> > 
> > Anyone know if the problem with massive numbers of small files benign
> > created in the jkDecoderCache directory is fixed (Mantis 3288).  It
> > does cause the bin folder for Opensim to grow VERY large when you
> > have been running a while.
> > 
> > 
> > ___
> > Opensim-dev mailing list
> > Opensim-dev@lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Request for feedback: 0.6.5Release Candidate 1Prospects

[Stefan Andersson]

Give me a rev, and I'll tag it, then let's take it for a drive, rev the rev, 
kick the wheels and see if we buy the car.

Best regards,
Stefan Andersson



 
> Date: Wed, 22 Apr 2009 11:16:32 -0700
> From: cmick...@gmail.com
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] Request for feedback: 0.6.5Release Candidate 
> 1Prospects
> 
> Would this be a good time to look for the 0.6.5 release? It will be a
> very good release with performance optimizations, MRM scripting, and
> VOICE (yeah!).
> 
> I think the bugs that were discussed earlier have been fixed now.
> 
> --mic
> 
> 
> On Sat, Apr 18, 2009 at 1:03 AM, Ralf Haifisch  wrote:
> > Does it ??
> >
> > Is there a mantis ?
> >
> > I did use the libsl testclients on 9160 for some measurement yesterday...
> >
> >
> > Cheers,
> > Ralf
> > --
> >
> > Message: 3
> > Date: Fri, 17 Apr 2009 19:36:59 -0400
> > From: "Frisby, Adam" 
> > Subject: Re: [Opensim-dev] Request  for feedback:   0.6.5Release
> >Candidate   1Prospects
> > To: "opensim-dev@lists.berlios.de" 
> > Message-ID:
> ><63fad4f30a4ea79de9e8be66473519180...@winxbeus19.exchange.xchg>
> > Content-Type: text/plain; charset="us-ascii"
> >
> > R9148 breaks support for libsl clients too - I'd rather not tag with that
> > broken.
> >
> > Adam
> >
> > From: opensim-dev-boun...@lists.berlios.de
> > [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Stefan Andersson
> > Sent: Friday, 17 April 2009 11:58 AM
> > To: opensim-dev@lists.berlios.de
> > Subject: Re: [Opensim-dev] Request for feedback: 0.6.5Release Candidate
> > 1Prospects
> >
> > Is this fixed?
> >
> > Best regards,
> > Stefan Andersson
> > Tribal Media AB
> >
> >
> >
> >
> >> Date: Wed, 15 Apr 2009 12:42:45 +0100
> >> From: ch...@codetorque.co.uk
> >> To: opensim-dev@lists.berlios.de
> >> Subject: Re: [Opensim-dev] Request for feedback: 0.6.5Release Candidate
> > 1Prospects
> >>
> >> Ah yes, this slipped through my tests yesterday - it's definitely there
> >> in 9137 too. Recommend we get that fixed before a tag.
> >>
> >>
> >> -Original Message-
> >> From: opensim-dev-boun...@lists.berlios.de
> >> [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Melanie
> >> Sent: 15 April 2009 11:12
> >> To: opensim-dev@lists.berlios.de
> >> Subject: Re: [Opensim-dev] Request for feedback: 0.6.5Release Candidate
> >> 1Prospects
> >>
> >> That circular regioncross bug, where a region server will crash if
> >> an agent returns to it, needs to be squashed before we can tag a
> >> relaease.
> >> I didn't see that having been resolved, so it is probably present in
> >> 9140.
> >>
> >> Melanie
> >>
> >> Ralf Haifisch wrote:
> >> > Agreed,
> >> >
> >> > maybe even 9140 after the cleanup...
> >> >
> >> >
> >> > cheers,
> >> > Ralf
> >> > --
> >> > Date: Wed, 15 Apr 2009 07:52:57 +0100
> >> > From: "Chris Hart" 
> >> > Subject: Re: [Opensim-dev] Request for feedback: 0.6.5 Release
> >> > Candidate 1Prospects
> >> > To: 
> >> > Message-ID: <6abfbbbfa9738e47a00f30bc3c74171c1da...@kitt.ct.local>
> >> > Content-Type: text/plain; charset="us-ascii"
> >> >
> >> > Very happy in tests yesterday with 9137 - 25 avatars on a sim for over
> >> > an hour, no crashes. OSGrid office hours had Wright Plaza on 9136 and
> >> > was also very stable, so I think around that point is a sweet spot...
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > From: opensim-dev-boun...@lists.berlios.de
> >> > [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Stefan
> >> > Andersson
> >> > Sent: 15 April 2009 02:29
> >> > To: opensim-dev@lists.berlios.de
> >> > Subject: [Opensim-dev] Request for feedback: 0.6.5 Release Candidate
> >> > 1Prospects
> >> >
> >> >
> >> >
> >> > Esteemed Testers and Developers,
> >> >
> >> > As you may know, the current lean release cycle handling defines
> >> > "te

Re: [Opensim-dev] Request for feedback: 0.6.5Release Candidate 1Prospects

[Stefan Andersson]

Is this fixed?

Best regards,
Stefan Andersson
Tribal Media AB



 
> Date: Wed, 15 Apr 2009 12:42:45 +0100
> From: ch...@codetorque.co.uk
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] Request for feedback: 0.6.5Release Candidate 
> 1Prospects
> 
> Ah yes, this slipped through my tests yesterday - it's definitely there
> in 9137 too. Recommend we get that fixed before a tag.
> 
> 
> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de
> [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Melanie
> Sent: 15 April 2009 11:12
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] Request for feedback: 0.6.5Release Candidate
> 1Prospects
> 
> That circular regioncross bug, where a region server will crash if 
> an agent returns to it, needs to be squashed before we can tag a 
> relaease.
> I didn't see that having been resolved, so it is probably present in 
> 9140.
> 
> Melanie
> 
> Ralf Haifisch wrote:
> > Agreed,
> > 
> > maybe even 9140 after the cleanup...
> > 
> > 
> > cheers,
> > Ralf
> > --
> > Date: Wed, 15 Apr 2009 07:52:57 +0100
> > From: "Chris Hart" 
> > Subject: Re: [Opensim-dev] Request for feedback: 0.6.5 Release
> > Candidate 1Prospects
> > To: 
> > Message-ID: <6abfbbbfa9738e47a00f30bc3c74171c1da...@kitt.ct.local>
> > Content-Type: text/plain; charset="us-ascii"
> > 
> > Very happy in tests yesterday with 9137 - 25 avatars on a sim for over
> > an hour, no crashes. OSGrid office hours had Wright Plaza on 9136 and
> > was also very stable, so I think around that point is a sweet spot...
> > 
> > 
> > 
> > 
> > 
> > From: opensim-dev-boun...@lists.berlios.de
> > [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Stefan
> > Andersson
> > Sent: 15 April 2009 02:29
> > To: opensim-dev@lists.berlios.de
> > Subject: [Opensim-dev] Request for feedback: 0.6.5 Release Candidate
> > 1Prospects
> > 
> > 
> > 
> > Esteemed Testers and Developers,
> > 
> > As you may know, the current lean release cycle handling defines
> > "testers and developers" as "anybody feeding off trunk" so if that's
> > you, I have a favour to ask;
> > 
> > it's time to gather round and try to nail down a good candidate
> revision
> > for 0.6.5. Ideally, it should
> > * Be (subjectively) as stable as the last version (0.6.4-post-fixes)
> > * Be reasonably close to head (not more than two weeks off, I'd say)
> > and
> > * Be reasonably well tested (in a pragmatic sense)
> > 
> > If you do have a revision that you feel particularly fond of, please
> > speak up.
> > 
> > With that, I leave the floor open.
> > 
> > Best regards,
> > Stefan Andersson
> > Tribal Media AB
> > 
> > 
> > 
> > 
> > No virus found in this incoming message.
> > Checked by AVG - www.avg.com
> > Version: 8.5.287 / Virus Database: 270.11.53/2054 - Release Date:
> > 04/14/09 06:17:00
> > 
> > -- next part --
> > An HTML attachment was scrubbed...
> > URL:
> >
> https://lists.berlios.de/pipermail/opensim-dev/attachments/20090415/6e61
> 2164
> > /attachment.html 
> > 
> > --
> > 
> > ___
> > Opensim-dev mailing list
> > Opensim-dev@lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> > 
> > 
> > End of Opensim-dev Digest, Vol 20, Issue 43
> > ***
> > 
> > ___
> > 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
> 
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 8.5.287 / Virus Database: 270.11.53/2054 - Release Date:
> 04/14/09 14:52:00
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] The essence of "grid"

[Stefan Andersson]

 

> > Am I correct in assuming that the hypergrid then boils down to the 
> > "untrusted" connections? What is left, basically.
> 
> Well, not quite. Given that a grid can contain several trust domains, 
> there may be untrusted connections even within a grid. For example, 
> Wright Plaza should not trust DNCH, even though they are part of the 
> same grid.

 

Yes. And, in my (somewhat fuzzy, as always) thinking, the trust invoked when, 
for example, teleporting from WP to DNCH would be something resolved by the 
Hypergrid.

 

ie, you have one 'Grid' Trust Domain that incorporates WP, and one that 
incorporates DNCH, both sharing the same "Resource Service Domain".

 

This screws up your definitions?

 

/Stefan

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

Re: [Opensim-dev] The essence of "grid"

[Stefan Andersson]

Wonderful job, Diva. I think we're onto something here.

 

> > - "Simulator trust domain": a set of simulators that trust each other, 
> > operated by one single authority


Sounds fine; akin or parallell to an 'estate' perhaps?

 

I propose the entity "Resource Services": A set of zero or more services 
serving resources for regions. Resources include:  assets, user accounts, and 
assorted services like lookup services,  forums, etc.

 

"Grid": a set of simulators that share "Resource services".  [And this is the 
thing] A Grid includes one *or more* 
 simulator trust domains.


> > - "Hypergrid": the interconnection of grids.


Am I correct in assuming that the hypergrid then boils down to the "untrusted" 
connections? What is left, basically.


> As a small point, the "Grid" definition would appear to mean that our current 
> 'Standalone' mode is confusingly also a 
> "Grid". Is there a suitable alternative term to "Grid" for this definition? 
> I've run into this problem myself when 
> writing about OpenSim. I keep having to using unclear formulations such as 
> OpenSim installations.


I have always said that we should talk about "Services" not "Servers". The 
trust is established between services, and the standalone is a "Grid" trust 
boundary in itself.


> Also as a small suggestion, it might be helpful to write this in a glossary 
> on the wiki somewhere so we can point back 
> to it. I think ages ago someone started a general one but I wouldn't be 
> surprised if it has been buried by now.


+1

 

/Stefan

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

Re: [Opensim-dev] Supplying IScene instead of Scene for the future region modules mechanism

[Stefan Andersson]

... unless it was exposed in that interface, or the functionality was available 
in some other way.

Best regards,
Stefan Andersson
Tribal Media AB



 
> Date: Wed, 15 Apr 2009 12:12:57 +0200
> From: mela...@t-data.com
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] Supplying IScene instead of Scene for the future 
> region modules mechanism
> 
> That member was actually introduced for the load balancer only, and 
> is not supposed to be accessed by anything else. But, it's a case in 
> point where a specialized application would not be possible if only 
> an interface were passed.
> 
> Melanie
> 
> 
> Stefan Andersson wrote:
> > 
> > 
> >> scene.m_restorePresences
> > 
> > 
> > O.o
> > 
> > 
> > 
> > /Stefan
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > ___
> > Opensim-dev mailing list
> > Opensim-dev@lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Supplying IScene instead of Scene for the future region modules mechanism

[Stefan Andersson]

 

> scene.m_restorePresences


O.o

 

/Stefan

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

[Opensim-dev] Request for feedback: 0.6.5 Release Candidate 1 Prospects

[Stefan Andersson]

Esteemed Testers and Developers,

 

As you may know, the current lean release cycle handling defines "testers and 
developers" as "anybody feeding off trunk" so if that's you, I have a favour to 
ask;

 

it's time to gather round and try to nail down a good candidate revision for 
0.6.5. Ideally, it should

* Be (subjectively) as stable as the last version (0.6.4-post-fixes)

* Be reasonably close to head (not more than two weeks off, I'd say)

and

* Be reasonably well tested (in a pragmatic sense)

 

If you do have a revision that you feel particularly fond of, please speak up.

 

With that, I leave the floor open.

Best regards,
Stefan Andersson
Tribal Media AB



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

Re: [Opensim-dev] Supplying IScene instead of Scene for the future region modules mechanism

[Stefan Andersson]

Hell, +1 on solving the issue at hand without going into long architectural 
discussion.


Just chipping in. :D


Best regards,
Stefan Andersson
Tribal Media AB



 
> Date: Wed, 15 Apr 2009 00:37:58 +0200
> From: mela...@t-data.com
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] Supplying IScene instead of Scene for the future 
> region modules mechanism
> 
> Hi,
> 
> as a mid to long range goal, +1, actually.
> 
> but in the short run, the ability to load and unload regions is 
> blocked by the existing module API, and to fix this basic piece of 
> functionality, they need to be migrated to the new API, asap.
> 
> If this is dragged into a long architectural discussion, we won't 
> get region restarts for many more months.
> 
> So, I'd rather see this iteration of the region module API pass 
> Scene, and remove the old API very soon, and then think about 
> architecting and refactoring when that is not a blocker to 
> adding/repairing basic functionality.
> 
> Melanie
> 
> 
> Stefan Andersson wrote:
> > Um,
> > 
> > 
> > 
> > I believe you're saying "supplying a smaller subset of the functionalities 
> > of Scene", as being able to supply something else than a concrete 
> > implementation should never really be a problem - in fact, in most cases 
> > supplying an interface is more desirable.
> > 
> > 
> > 
> > That said, what I was advocating, is that what is now Scene, probably could 
> > do well with an overhaul, and an explicit enumeration of what a "Scene" 
> > implementation really needs to provide, on one side as a contract with the 
> > core, and on the other side, as a contract with the module API.
> > 
> > 
> > 
> > I believe that those things should probably look (subtly or radically) 
> > different. Not to _hide_ core functionality from the module, but to provide 
> > _tailored_ functionality, enumerated for smooth decoupling and 
> > encapsulation.
> > 
> > Best regards,
> > Stefan Andersson
> > Tribal Media AB
> > 
> > 
> > 
> > 
> >> Date: Tue, 14 Apr 2009 20:32:48 +0200
> >> From: mela...@t-data.com
> >> To: opensim-dev@lists.berlios.de
> >> Subject: Re: [Opensim-dev] Supplying IScene instead of Scene for the 
> >> future region modules mechanism
> >> 
> >> I'm not happy with supplying IScene. It would basically curtail the 
> >> functionality of region modules to what core believes should be 
> >> possible, and will lead to ugly upcasting "(Scene)IScene" that the 
> >> code is already rife with.
> >> So, I'm not seeing that as a good idea at all, it limits things too 
> >> much.
> >> 
> >> Melanie
> >> 
> >> Justin Clark-Casey wrote:
> >> > Hey Homer (since this is primarily addressed to you :),
> >> > 
> >> > I see you're making some progress on the up-and-coming new region 
> >> > modules mechanism.
> >> > 
> >> > Instead of passing Scene itself to region modules, could we create an 
> >> > interface so that we better control the amount of 
> >> > innards that we expose to region modules? It's convenient-ish to give 
> >> > the original Scene class to modules now, but it 
> >> > will cause us problems down the road.
> >> > 
> >> > I'm quite happy to pitch in with this if you want. I suggest renaming 
> >> > the existing IScene to ISceneBase (since that's 
> >> > what it really is) and creating a new IScene that's implemented by Scene.
> >> > 
> >> > It strikes me that it's going to be more convenient to do this when we 
> >> > introduce the new system than as a separate change.
> >> > 
> >> > Thoughts?
> >> > 
> >> ___
> >> Opensim-dev mailing list
> >> Opensim-dev@lists.berlios.de
> >> https://lists.berlios.de/mailman/listinfo/opensim-dev
> > 
> > 
> > 
> > 
> > 
> > ___
> > Opensim-dev mailing list
> > Opensim-dev@lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Supplying IScene instead of Scene for the future region modules mechanism

[Stefan Andersson]

 
> - Should core really limit what _can_ be done by non-core module coders?

Yes. And in what sequence, and in what ways. That is what programming is. That 
is what designing is. And it's how you help people understand the intended use 
of an API.
 
We've already done that in Scene. Some things are private, some are protected. 
Some functions take values as parameters, others use the internal state.
 
> - Is it very likely that anyone would make a new Scene-type object 
> without inheriting from Scene?

Yes, definitively. Mocking is the most immediate example, but I can 
definitively think of scenarios where the inner workings of the SceneGraph 
would work radically different. For example, if the administration of inner 
state should be different, optimized, or simply react in other ways - say, 
because a third-party external protocol is radically different. I can 
definitively see why you'd want a 'passive' scene that just worked as a data 
model, not even running updates or backups for example, while still being able 
to function in a live region, and work with other SceneGraph objects.

> I believe that passing Scene directly is the right thing to do, as 
> the region modules' functionality is largely tied to Scene in an 
> indissoluble way anyway.
 
Which is in itself part of the problem. The way concrete classes are tied 
together right now makes it a mess to encapsulate, re-define or unit test in 
any sensible manner.
 
> Any interface would just have to carry 
> almost all methods of Scene anyway, and add yet another file to edit 
> when adding fundamental functionality.

Which is why I was proposing one re-evaluate the Scene methods, one by one. 
Incidentally, if what you say is true, we have WAY too many public methods and 
properties on Scene.

> Also, I believe it is very unlikely that someone would not inherit 
> Scene since it provides a huge amount of the bery basic 
> functionality everyone needs. If someone doesn't inherit Scene, they 
> are doing something fundamentally different and existing region 
> modules would be of no use to them anyway.

The problem is rather it provides too much, and in a way that makes it 
impossible to disentangle for cases where you want to be able to work with the 
classes in other ways than as part of a living live region.

> I know such an IScene would break all my private region modules, and 
> probably everyone else's, unless I add a slew of methods and 
> properties to IScene to make them work again.

I don't think anybody, so far, has proposed to define what the supplied IScene 
would and would not contain. That is why I think there should be a serparation 
between what the core wants out of a IScene and what the region modules want.

 

And maybe the region should have _more_ available than the core should. I can 
definitively think of cases where the core would want to be able to run a scene 
that does not implement the full ISceneForRegionModules simply because there 
will be no region modules loaded for that scene.
 
> I believe we can't possibly anticipate every method that needs to be 
> accessed, and we should not limit it to what we think is "correct" 
> or "hygienic". After all, someone may not even want to tell us what 
> their region modules are for, therefore would not aubmit their patch 
> but keep it as a private patch, adding maintenance effort and 
> complicating things.

I say 'correct' and 'hygienic' purely from a state-encapsulating, and 
best-practise point of view. If we believe neither of these apply to the method 
under discussion, or if we're too lazy to help the implementer get a coherent 
picture of how the public and protected methods are supposed to interact, then 
we'll just not bother, add the method and move on.

> I believe that would not be in the spirit of the BSD licensing if we 
> were to say "you can do what you want with it, but we'll make it as 
> hard as we can".

Nobody has, as far as I can see, forwarded that sentiment. I think we must be 
both misunderstanding each other?
 
/Stefan

> Stefan Andersson wrote:
> > Justin, Homer;
> > 
> > 
> > 
> > consider two things you might:
> > 
> > 
> > 
> > 1) take the opportunity to take a moment to re-ponder each "missing" IScene 
> > power - should the caller perhaps move instead? Or should the called method 
> > move to a place where the caller has access without going thru IScene? 
> > Maybe the Scene is too big, not IScene too small?
> > 
> > 
> > 
> > 2) maybe the notion of a IScene vs a ISceneBase is really an indication 
> > that you should have a 'ISceneForRegionModules' instead - an facade 
> > enumerating the powers the core wish to expose 

Re: [Opensim-dev] Supplying IScene instead of Scene for the future region modules mechanism

[Stefan Andersson]

Um,

 

I believe you're saying "supplying a smaller subset of the functionalities of 
Scene", as being able to supply something else than a concrete implementation 
should never really be a problem - in fact, in most cases supplying an 
interface is more desirable.

 

That said, what I was advocating, is that what is now Scene, probably could do 
well with an overhaul, and an explicit enumeration of what a "Scene" 
implementation really needs to provide, on one side as a contract with the 
core, and on the other side, as a contract with the module API.

 

I believe that those things should probably look (subtly or radically) 
different. Not to _hide_ core functionality from the module, but to provide 
_tailored_ functionality, enumerated for smooth decoupling and encapsulation.
 
Best regards,
Stefan Andersson
Tribal Media AB



 
> Date: Tue, 14 Apr 2009 20:32:48 +0200
> From: mela...@t-data.com
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] Supplying IScene instead of Scene for the future 
> region modules mechanism
> 
> I'm not happy with supplying IScene. It would basically curtail the 
> functionality of region modules to what core believes should be 
> possible, and will lead to ugly upcasting "(Scene)IScene" that the 
> code is already rife with.
> So, I'm not seeing that as a good idea at all, it limits things too 
> much.
> 
> Melanie
> 
> Justin Clark-Casey wrote:
> > Hey Homer (since this is primarily addressed to you :),
> > 
> > I see you're making some progress on the up-and-coming new region modules 
> > mechanism.
> > 
> > Instead of passing Scene itself to region modules, could we create an 
> > interface so that we better control the amount of 
> > innards that we expose to region modules? It's convenient-ish to give the 
> > original Scene class to modules now, but it 
> > will cause us problems down the road.
> > 
> > I'm quite happy to pitch in with this if you want. I suggest renaming the 
> > existing IScene to ISceneBase (since that's 
> > what it really is) and creating a new IScene that's implemented by Scene.
> > 
> > It strikes me that it's going to be more convenient to do this when we 
> > introduce the new system than as a separate change.
> > 
> > Thoughts?
> > 
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Supplying IScene instead of Scene for the future region modules mechanism

[Stefan Andersson]

Justin, Homer;

 

consider two things you might:

 

1) take the opportunity to take a moment to re-ponder each "missing" IScene 
power - should the caller perhaps move instead? Or should the called method 
move to a place where the caller has access without going thru IScene? Maybe 
the Scene is too big, not IScene too small?

 

2) maybe the notion of a IScene vs a ISceneBase is really an indication that 
you should have a 'ISceneForRegionModules' instead - an facade enumerating the 
powers the core wish to expose to the scene, to force the region module coder 
to code in a hygienic way. Laying the foundations for a ISceneAPI, if you will?

On my mind for a long time, both these things has been.


Best regards,
Stefan Andersson
Tribal Media AB



 
> Date: Tue, 14 Apr 2009 18:02:45 +0100
> From: jjusti...@googlemail.com
> To: opensim-dev@lists.berlios.de
> Subject: [Opensim-dev] Supplying IScene instead of Scene for the future 
> region modules mechanism
> 
> Hey Homer (since this is primarily addressed to you :),
> 
> I see you're making some progress on the up-and-coming new region modules 
> mechanism.
> 
> Instead of passing Scene itself to region modules, could we create an 
> interface so that we better control the amount of 
> innards that we expose to region modules? It's convenient-ish to give the 
> original Scene class to modules now, but it 
> will cause us problems down the road.
> 
> I'm quite happy to pitch in with this if you want. I suggest renaming the 
> existing IScene to ISceneBase (since that's 
> what it really is) and creating a new IScene that's implemented by Scene.
> 
> It strikes me that it's going to be more convenient to do this when we 
> introduce the new system than as a separate change.
> 
> Thoughts?
> 
> -- 
> justincc
> Justin Clark-Casey
> http://justincc.wordpress.com
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Proposal: Drop VS 2005 suppost [Was: C# 3.0 vs .Net 2]

[Stefan Andersson]

I have now updated the wiki with the proposal, linking to 

 

http://opensimulator.org/wiki/Visual_Studio_2005

 

from the main page. Please read article and add to it.

 

On the page I have stated that 0.6.5 be the last version building on VS 2005. 
Ideally, I'd like to tag that now, and then introduce a VS 2005 'breaker' to 
really get things going.

 

Do we have a 0.6.5-rc1 rev?

Best regards,
Stefan Andersson
Tribal Media AB



 


From: ste...@tribalmedia.se
To: opensim-dev@lists.berlios.de
Date: Thu, 26 Mar 2009 12:32:04 +0100
Subject: [Opensim-dev] Proposal: Drop VS 2005 suppost [Was: C# 3.0 vs .Net 2]



I propose that
 
"if nobody actually objects on this or the users list before 1st of May 2009, 
we'll drop VS 2005 support and move on".

If I get no strong objections on this, I'll re-post a proposal and update the 
wiki with the proposal and guidelines to objecting, on friday 3rd of April 2009.

Best regards,
Stefan Andersson
Tribal Media AB



 


Date: Thu, 26 Mar 2009 10:47:21 +
From: ch...@codetorque.co.uk
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] C# 3.0 vs .Net 2





You may find some issues with that since it’s a CTP (pre-beta) from 2006, so 
some supported syntax in there may have changed for final release, but can’t 
say for certain. 
 
Teravus is correct in that VS2008 is available for free 
(http://www.microsoft.com/express/vcsharp/). Installing C# 2008 Express you 
also get SQL Server 2008 Express installed, so you have some options for using 
that out of the box too. C# Express should be able to handle most basic 
development tasks – I guess it just depends on how nice you want to be to 2005 
Pro or higher owners going forward as to whether to stay in 2.0 land or move on.
 
 


From: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Stefan Andersson
Sent: 26 March 2009 07:45
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] C# 3.0 vs .Net 2
 
Could anybody actually using VS 2005 comment on whether installing the Orcas 
CTP would solve this?
 
http://www.microsoft.com/downloads/details.aspx?FamilyId=1E902C21-340C-4D13-9F04-70EB5E3DCEEA&displaylang=en
 
This is the community preview of the C# 3 extensions, made available as an 
extension to VS 2005.

Best regards,
Stefan Andersson
Tribal Media AB



 
> Date: Thu, 26 Mar 2009 01:27:42 -0400
> From: tera...@gmail.com
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] C# 3.0 vs .Net 2
> 
> Our issue here isn't mono support :) Mono has 3.0 support since
> 1.9.1. It's our support of Visual Studio 2005 as a build tool.
> 
> Visual Studio 2005 is the tool that doesn't understand code in C# 3.0 :).
> 
> Visual Studio 2008 will generate a 2.0 assembly from 3.0 code.
> Visual Studio 2005 will fail to build.
> 
> As far as I really know.. the only reason to support Visual Studio
> 2005 right now is for people who have Visual Studio 2005 Standard,
> Pro, or Team licenses. Visual Studio 2008 Express is freely
> downloadable and available and Mono is quite happy with 3.0 syntax
> 
> Sincerely
> 
> Teravus
> 
> On 3/26/09, Frisby, Adam  wrote:
> >
> >
> >
> > If we consider a shift to .NET 3, I’d like to also propose utilizing the new
> > Socket members that .NET 3 introduced – there is some in there for high
> > performance ASync socketing which perform significantly better than previous
> > ones in the kinds of situations we employ.
> >
> >
> >
> > (As long as Mono 2.0.2 has those implemented of course – but it shouldn’t be
> > hard for the, they could at least just make them a splint to the old
> > methods)
> >
> >
> >
> > Adam
> >
> >
> >
> >
> >
> > From: opensim-dev-boun...@lists.berlios.de
> > [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of
> > Ruud Lathrop
> > Sent: Wednesday, 25 March 2009 11:34 AM
> > To: opensim-dev@lists.berlios.de
> > Subject: Re: [Opensim-dev] C# 3.0 vs .Net 2
> >
> >
> >
> >
> > Visual Studio 2005 is using .NET 2.0/C# 2, only with some extending can you
> > use some .NET 3/C# 3 features (WCF is the best known).
> >
> > It seems that Visual Studio 2008 is doing some tricks for you when you have
> > a .NET 2.0 project, but use .NET 3/3.5 syntax. Like this:
> >
> > public string Test { get; set; }
> >
> > Just works in a .NET 2.0 project, same with lambda, while it is .NET 3/ C# 3
> > specs
> >
> > Ruud
> >
> >
> >
> > On Wed, Mar 25, 2009 at 3:57 PM, Teravus Ovares  wrote:
> >
> > The problem with Lamda Expressions isn't compiling to IL 2.0.. it's
> > compiling in Visual Studio 200

Re: [Opensim-dev] Security: multiple or the most generic?

[Stefan Andersson]

If we're going to do it 'right' from the start, then obviously, (c) as the 
general case and (b) as the special case should be the way to go.

 

(Easy for me to say)

 

And on a tangent, I'm closing in on having the AssetServer demanding a 
connection to a user server to resolve user urls. Thoughts?

 

(It baffles me we don't seem to have that already - I'm not working on the 
AssetInventory server as I feel its ultimate destiny is still somewhat hazy?)
 
Best regards,
Stefan Andersson
Tribal Media AB



 
> Date: Mon, 13 Apr 2009 11:25:06 -0700
> From: d...@metaverseink.com
> To: mela...@t-data.com
> CC: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] Security: multiple or the most generic?
> 
> Melanie wrote:
> > Well, if a key is an arbitrary string, then it may also be a constant 
> > UUID value, e.g. the standard session id we have now, so (c) really 
> > includes (b).
> They are very different. A key is specific for one client-server pair. 
> So for each region the client visits there is a unique key that the 
> other regions might not know about. When TPs are performed on the 
> server-side, this is equivalent to (b) because the regions are acting on 
> behalf of the agent. But for client-side Teleports, this makes all the 
> difference -- the regions don't know about the other regions' keys.
> 
> > [...]
> > So, for now, (c) is the way to go, just don't forget the (b) use case. 
> > Interregion trust should remain possible.
> Right. Even though my main focus is the Hypergrid, I'm a little 
> reluctant in letting go of (b), and even of (a). The problem I'm 
> debating is how to architect OpenSim so that these different schemes can 
> co-exist without the code and configuration being a mess.
> 
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Backports Testing Request

[Stefan Andersson]

How should we do this? What is a reasonable approach to a valid request like 
this?

 

Would a feasible route be to say "unless somebody says 'no', fixes go in by 
{date}" or something like that, I guess implying that "if you're serious about 
using opensim, you better help me test this".

Best regards,
Stefan Andersson
Tribal Media AB



 


From: a...@deepthink.com.au
To: opensim-dev@lists.berlios.de
Date: Wed, 8 Apr 2009 02:46:09 -0400
Subject: [Opensim-dev] Backports Testing Request





Could everyone running trunk please test r9048 extensively.
 
If it works appropriately, could someone please apply 9047 and 9048 to 
postfixes branches.
 
The patches fix an issue whereby sessionIDs aren’t properly checked in certain 
packets.
 
Adam___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

[Opensim-dev] Custom Nunit CategoryAttribute

[Stefan Andersson]

Esteemed colleagues,

 

I just added a custom DatabaseTestAttribute to help separating unit tests from 
component tests.

 

The general idea is to tag database tests (classes or individual methods) with 
[DatabaseTest]

 

The test runner will then be able to separate out database tests from 
non-database tests, aiding in swift nunit testing. This can be done visually in 
the runner, or on the runner command line with /exclude DatabaseTest.

 

We probably should have some other categories as well, but this is a start, and 
an example.

 

I also blogged shortly about it here:


http://lbsa71.net/2009/04/09/nunit-custom-categoryattribute-and-resharper-testrunner/
 
Best regards,
Stefan Andersson
Tribal Media AB



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

Re: [Opensim-dev] [Opensim-commits] r9036 - in trunk/OpenSim

[Stefan Andersson]

Done. I restored the gridlaunch as well, as I took the deletion of it to be 
another mistake?

Best regards,
Stefan Andersson
Tribal Media AB



 


To: opensim-dev@lists.berlios.de
CC: opensim-dev@lists.berlios.de; opensim-dev-boun...@lists.berlios.de
From: alan_w...@us.ibm.com
Date: Wed, 8 Apr 2009 12:03:55 -0400
Subject: Re: [Opensim-dev] [Opensim-commits] r9036 - in trunk/OpenSim


Dr Schofield is not going to be around for a few days, so I'll take the liberty 
of responding. It's my fault anyway. The files showed up flagged as a deleted  
in my repository, and I have inadvertently propagated that deletion with my 
change. My apologies. Perhaps someone with commit authority could restore these 
files? 

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






From: 
Mikko Pallari  

To: 
"opensim-dev@lists.berlios.de"  

Date: 
04/08/2009 02:22 AM 

Subject: 
Re: [Opensim-dev] [Opensim-commits] r9036 - in trunk/OpenSim





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

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


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

Re: [Opensim-dev] On Revisions, tags and branches

[Stefan Andersson]

 

> However, given that this means source releases magically appear
> shortly after tags, I'd recommend just tagging off 0.6.4.1-release,
> 0.6.4.2-release, etc when fixes go in that should release to the world.


Good call, Sean; I think that should be how we do it. At least, we could tag it 
once a week or every other week or so provided there's been any new fixes to 
it. Or if there's been critical fixes to it.

 

And again, I invite the whole community to participate in the release cycle 
handling - if done right, I believe it can be a powerful tool indeed.

 

/Stefan

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

[Opensim-dev] On Revisions, tags and branches

[Stefan Andersson]

Esteemed colleagues,

 

a couple of good-to-know points about SVN versioning;

 

In an SVN repo, the 'revision' is a discrete version of the software. But; the 
revision _number_ is _not_ an indication of sequential functional increment.

 

Revisions are based on the revision before it, but that does not have to be the 
one with the revision _number_ before it.

 

The revision number counter is global to the repo, hence it is upped whenever 
somebody does something within the repo, regardless of what branch the thing 
happens to.

 

An example:

 

I commit something to trunk, the rev number is upped to, say, 1337, and my new 
version is given that number.

 

I now branch trunk into /branches/mybranch. I do this by doing a remote copy of 
trunk. This copy of trunk, although identical to 1337, is a new version and is 
thus given the revision number 1338, the first revision on the new _branch_.

 

Now I commit a number of changes to trunk, spinning past 1339, 1340, 1341 and 
1342 - each being separate _versions_ but on the _branch_ called /trunk (think 
of it as paths)

 

Now, if I commit some minor change to /branches/mybranch, what revision number 
will it get? You guessed it - 1343.

 

If I now commit something to trunk again, it will get 1344. I then commit 
something to the really old branch based on, say, revision 666. It will get 
1345.

 

So, my point is: we really should stop talking only about revision numbers when 
we're trying to convey an idea of some kind of advancement of state.

 

Ie, in my example, 1344 is probably the one reflecting the most development, 
1343 is essentially based in 1337 and 1345, currently the highest rev number, 
could basically be six months old, with just a minor modification.

 

Now on to tags - trunk, branches and tags are really all one thing: paths. The 
only real difference is by convention: there is a certain path called /trunk 
that serves a certain purpose, nemaly to be the focal point for developers. 
There is a certain name used for paths other than trunk, and that is 
"branches". Some branches by convention aren't meant to be modified, but serve 
as snapshots of a point in time - they are called "tags".

 

But to the server, they are all revisions along differerent link paths. There 
is really nothing stopping you from committing to a tag - it's just the svn 
client will be reluctant to do so, as it's aware of the convention.

 

Keep this in mind, when referring to a 'revision' - it might be on a totally 
different path, so be sure to mention what path you're really talking about. 
specifying "trunk, between revision 1343 and 1780" or "0.6.2 post-fixes, 
between revision 1764 and 2006" again lets you compare revision numbers to 
indicate advancement of state.


So, don't tell people to check a certain revision out, unless you mean 
_exactly_ that version - tell them the logical path to it instead.

 

Just thought this might clear some confusion up.


Best regards,
Stefan Andersson
Tribal Media AB



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

Re: [Opensim-dev] Facebook app: inventory trade

[Stefan Andersson]

Yes. What we did as part of that prototype was a custom user server that 
authenticated directly against facebook and pulled user data from it. I believe 
stuff like wall-to-wall objects is fetched thru the fb api as well, so you 
could attach IAR, OAR os save-xml to it, or object urls.

Best regards,
Stefan Andersson
Tribal Media AB



 


Date: Fri, 3 Apr 2009 15:26:10 -0700
From: dzona...@dzonux.net
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Facebook app: inventory trade

What I had in mind maybe more simple than what TribalOne has done so far.

What you showed actually loads a mini-client to interface. I'm thinking of a 
simple interface like this facebook app has:
http://www.facebook.com/apps/application.php?id=3396043540

The main difference being when on trades 'flair', they actually give an 
inventory object to another avatar. The person can later enter the client and 
wear the button like normal inventory objects.

I'm going somewhere with this idea, but I think it become obvious with that 
basic interface and functionality. =)


Stefan Andersson wrote: 


Have a look at
 
http://lbsa71.net/2008/08/11/tribal-one-entering/
 
if that's interesting, have a look at the rest of the clips;
 
http://lbsa71.net/category/tribal-media/tribal-one/

Funnily enough, earlier today I was thinking re-creating the facebook connector 
for a modern version of OpenSim could be a good example of creating custom 
authorization and user data services for OpenSim.

Best regards,
Stefan Andersson
Tribal Media AB



 
> Date: Fri, 3 Apr 2009 13:31:45 -0700
> From: dzona...@dzonux.net
> To: opensim-dev@lists.berlios.de
> Subject: [Opensim-dev] Facebook app: inventory trade
> 
> Hello,
> 
> I googled the web to look for way how facebook and opensim (even sl) 
> have mixed together.
> 
> Has anybody started an app where one could trade an avatar's inventory 
> between facebook members?
> 
> 
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev

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

Re: [Opensim-dev] Facebook app: inventory trade

[Stefan Andersson]

Have a look at

 

http://lbsa71.net/2008/08/11/tribal-one-entering/

 

if that's interesting, have a look at the rest of the clips;

 

http://lbsa71.net/category/tribal-media/tribal-one/

Funnily enough, earlier today I was thinking re-creating the facebook connector 
for a modern version of OpenSim could be a good example of creating custom 
authorization and user data services for OpenSim.


Best regards,
Stefan Andersson
Tribal Media AB



 
> Date: Fri, 3 Apr 2009 13:31:45 -0700
> From: dzona...@dzonux.net
> To: opensim-dev@lists.berlios.de
> Subject: [Opensim-dev] Facebook app: inventory trade
> 
> Hello,
> 
> I googled the web to look for way how facebook and opensim (even sl) 
> have mixed together.
> 
> Has anybody started an app where one could trade an avatar's inventory 
> between facebook members?
> 
> 
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] New language for Downloads Page

[Stefan Andersson]

I added an 'older versions archive' paragraph too, just to push trunk even 
lower down the page.

Best regards,
Stefan Andersson
Tribal Media AB



 
> Date: Thu, 2 Apr 2009 18:46:44 -0400
> From: sda...@gmail.com
> To: opensim-us...@lists.berlios.de; opensim-dev@lists.berlios.de
> Subject: [Opensim-dev] New language for Downloads Page
> 
> A lot of what transpired was because it was apparently not clear enough
> about not using trunk. So that there isn't such confusion in the
> future, I've removed the direct SVN link off the front page, and moved
> the trunk links to this section of the Downloads page
> (http://opensimulator.org/wiki/Download) :
> 
> Experimental Upstream Code
> 
> There Be Dragons Beyond This Point
> 
> If you are truly feeling dangerous, adventurous, or want to help us test
> the next version of OpenSim you are welcome to grab the latest unstable
> code out of our subversion trunk. Any warnings previous expressed about
> the alpha nature of the code go double or triple if you are running
> directly off of trunk. Never, ever, ever, never run this in production
> environments, it is not suitable for that unless you are very familiar
> with the source code, and can hot fix any piece of it (that probably
> means you are an OpenSim core member). Feedback and testing on the
> unstable tree is appreciated, as that helps us make the next release
> better. If this scares you from using trunk, that was intended.
> 
> If it breaks, you get to keep both pieces.
> 
> * Latest Subversion revision version (bleeding edge)
> ...
> 
> 
> I replicate this here, because there are plenty of people that already
> have a trunk tree, hopefully they'll get this message here if not via
> the website.
> 
> I'd also ask a favor from our users, if you find links to SVN anywhere
> else in the wiki, please remove them, and just link in the Downloads
> page. If anyone in IRC asks you how to get source, please don't give
> them a direct svn command, please send them to that page. Everyone
> getting svn trunk needs to read that paragraph, and really internalize it.
> 
> Apologies to people for which this makes it a couple more steps to get
> code who understand trunk, and continue to be incredible testers for
> this incredible project.
> 
> Thanks folks,
> 
> -Sean
> 
> -- 
> Sean Dague / Neas Bade
> sda...@gmail.com
> http://dague.net
> 
> 
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] New language for Downloads Page

[Stefan Andersson]

Yay Sean! <3

Best regards,
Stefan Andersson
Tribal Media AB



 
> Date: Thu, 2 Apr 2009 18:46:44 -0400
> From: sda...@gmail.com
> To: opensim-us...@lists.berlios.de; opensim-dev@lists.berlios.de
> Subject: [Opensim-dev] New language for Downloads Page
> 
> A lot of what transpired was because it was apparently not clear enough
> about not using trunk. So that there isn't such confusion in the
> future, I've removed the direct SVN link off the front page, and moved
> the trunk links to this section of the Downloads page
> (http://opensimulator.org/wiki/Download) :
> 
> Experimental Upstream Code
> 
> There Be Dragons Beyond This Point
> 
> If you are truly feeling dangerous, adventurous, or want to help us test
> the next version of OpenSim you are welcome to grab the latest unstable
> code out of our subversion trunk. Any warnings previous expressed about
> the alpha nature of the code go double or triple if you are running
> directly off of trunk. Never, ever, ever, never run this in production
> environments, it is not suitable for that unless you are very familiar
> with the source code, and can hot fix any piece of it (that probably
> means you are an OpenSim core member). Feedback and testing on the
> unstable tree is appreciated, as that helps us make the next release
> better. If this scares you from using trunk, that was intended.
> 
> If it breaks, you get to keep both pieces.
> 
> * Latest Subversion revision version (bleeding edge)
> ...
> 
> 
> I replicate this here, because there are plenty of people that already
> have a trunk tree, hopefully they'll get this message here if not via
> the website.
> 
> I'd also ask a favor from our users, if you find links to SVN anywhere
> else in the wiki, please remove them, and just link in the Downloads
> page. If anyone in IRC asks you how to get source, please don't give
> them a direct svn command, please send them to that page. Everyone
> getting svn trunk needs to read that paragraph, and really internalize it.
> 
> Apologies to people for which this makes it a couple more steps to get
> code who understand trunk, and continue to be incredible testers for
> this incredible project.
> 
> Thanks folks,
> 
> -Sean
> 
> -- 
> Sean Dague / Neas Bade
> sda...@gmail.com
> http://dague.net
> 
> 
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev