Re: [Opensim-dev] Proposal: Introduce key:value pair dictionaries into SOP and PrimitiveBaseShape

[Frisby, Adam]

The OSDMap was at John Hurliman's suggestion - but yeah, you should probably 
start thinking about how to do this with components, as they are now in there 
(I'll be commiting a bunch of sample converted components this weekend which 
will make good references)

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Toni Alatalo
> Sent: Friday, 20 August 2010 3:02 PM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] Proposal: Introduce key:value pair
> dictionaries into SOP and PrimitiveBaseShape
> 
> Justin Clark-Casey kirjoitti:
> > Do you guys see any problems with storing and manipulating dynamic
> > data via the OSD classes in libopenmetaverse?
> 
> Seems fine so far, but we haven't done anything with it yet. May start
> with it soon as are starting to use custom scene entity data on the
> viewer side more, and have now the APIs in place there for addons /
> scripts to add and use custom data which needs to be synched via and
> stored on the server.
> 
> >> Would Adam's SOG/SOP refactor plan be essientally what you're
> thinking
> >> here, or do you see this somehow differently? I don't recall him
> needing
> >
> > I'm not sure.  If you could provide a reference I'd be obliged.
> 
> http://lists.berlios.de/pipermail/opensim-dev/2009-December/008098.html
> .. has a link to the pdf with diagrams etc. about the plan.
> 
> The first part is now in opensim git in the soprefactor branch,
> http://opensimulator.org/viewgit/?a=shortlog&p=opensim&h=refs/heads/sop
> refactor
> 
> I noticed Adam had also used a OSDMap to store the component info -
> perhaps this is very similar to your dynamicattributes branch?
> 
> ~Toni
> 
> >> We need this quite critically for RealXtend, not only because extend
> the
> >> scene for core functionality, but have worked for long now to allow
> >> arbitrary data in custom apps that anyone can write for the
> platform.
> >> I'm sure there are good ways to collaborate to get this done somehow
> --
> >> Adam has told that his work is taking a long time still, so perhaps
> >> others like our team&  you and other devs can speed things up.
> >
> > I still want to implement this, though it's prone now to slipping
> down
> > my priority list as other things bubble up.  My original code also
> > only concerned in memory storage.  Persistent storage could be
> > implemented simply by [de]serializing the OSDMap.
> >
> > What I will probably do is chuck the code up on a branch, implement
> > storage and see what you guys think.  I'd very much like input from
> > people who would make use of it, since my driving use case (moap) has
> > disappeared.
> >
> >>
> >>> Justin
> >>
> >> ~Toni
> >>
>  John
> 
> > -Original Message-
> > From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> > boun...@lists.berlios.de] On Behalf Of Justin Clark-Casey
> > Sent: Thursday, July 29, 2010 8:55 AM
> > To: opensim-dev@lists.berlios.de
> > Subject: Re: [Opensim-dev] Proposal: Introduce key:value pair
> > dictionaries
> > into SOP and PrimitiveBaseShape
> >
> > On 29/07/10 01:40, Dahlia Trimble wrote:
> >> Similar to the OSDMap in libomv?
> >
> > Not dissimilar, though the in-memory maps in OpenSim would need
> to
> > hold
> > arbitrary data types.  We couldn't use OSDMap directly unless we
> were
> > happy to serialize objects to and from OSD for every get and set
> > (or change
> > the values directly in the OSD representation, which might be an
> > idea).
> >
> >>
> >>
> >> On Wed, Jul 28, 2010 at 2:39 PM, Justin Clark-Casey
> >> mailto:jjusti...@googlemail.com>>
> wrote:
> >>
> >>   Hi there.  Whilst implementing media-on-a-prim, I've been
> >> keeping as
> >>   much code in the MOAP region module as possible.
> >>
> >>   I'm quite impressed with how feasible this is.  However,
> there
> >>   remain three major structures where the core of OpenSim
> has to
> >>   understand something about media on a prim.
> >>
> >>   1)  Database plugins - to get/put values to named database
> >> columns
> >>   (e.g. prims.MediaURL).
> >>   2)  Script functions (e.g. llGetPrimMediaParams()).
> >>   3)  Scene objects (PrimitiveBaseShape.Media and
> >>   SceneObjectPart.MediaURL).
> >>
> >>   It's difficult to do anything right now about (1) and (2),
> >> but I
> >>   believe there is an opportunity to address (3).
> >>
> >>   What I would like to do is introduce dictionaries into
> >>   PrimitiveBaseShape and SceneObjectPart that would
> supplement
> >>   existing fields by storing arbitrary key/value pairs.  So
> >> instead of
> >>   having to hardcode a new MediaURL property on
> >> SceneObjectPart I
> >>   could instead get/put 

Re: [Opensim-dev] Which revision is OpenMetaverse.StructuredData.dll now?

[Frisby, Adam]

It would have been trunk at the time of commit.

I asked John to add a feature in, and he did then updated it.

Regards,

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Justin Clark-Casey
> Sent: Wednesday, 18 August 2010 3:38 PM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] Which revision is
> OpenMetaverse.StructuredData.dll now?
> 
> On 18/08/10 23:28, Michael Cerquoni wrote:
> > heh dont you think after all this time and like sooo many times we
> have
> > never been able to figure out what version of libomv we are using
> that
> > we should add a file into the project that has libomv history? or
> > atleast the revision thats included?  maybe just a text file or
> > something.. anyway something to think about.. it just seems like this
> is
> > always a problem.
> 
> Nah, people just wouldn't update the file :).  I think the easiest
> thing is just to record the revision in the commit.
> Easy to forget, though.
> 
> >
> > On Wed, Aug 18, 2010 at 3:19 PM, Justin Clark-Casey
> > mailto:jjusti...@googlemail.com>> wrote:
> >
> > Hi John.  For the record, which version or revision of libomv was
> > used for this library update?  Thanks.
> >
> > On 17/08/10 20:26, opensim-commits-boun...@lists.berlios.de
> >  wrote:
> >
> > The branch, master has been updated
> > via e1f2c32 * Updated to
> > OpenMetaverse.StructuredData.dll that includes implicit
> > typecasts going in the other direction
> >from 53190e3 Updated to new
> > OpenMetaverse.StructuredData.dll that includes implicit
> typecasts
> >
> > Those revisions listed above that are new to this repository
> have
> > not appeared on any other notification email; so we list
> those
> > revisions in full, below.
> >
> > - Log
> > -
> 
> >
> > commit e1f2c32284b38bc1116239bc0c8d2d5010214449
> > Author: John Hurliman > >
> > Date:   Tue Aug 17 12:26:20 2010 -0700
> >
> >  * Updated to OpenMetaverse.StructuredData.dll that
> includes
> > implicit typecasts going in the other direction
> >
> > e1f2c32284b38bc1116239bc0c8d2d5010214449
> > diff --git a/bin/OpenMetaverse.StructuredData.dll
> > b/bin/OpenMetaverse.StructuredData.dll
> > index 1c55e2c..54681e4 100644
> > Binary files a/bin/OpenMetaverse.StructuredData.dll and
> > b/bin/OpenMetaverse.StructuredData.dll differ
> >
> > -
> --
> >
> > Summary of changes:
> >   bin/OpenMetaverse.StructuredData.dll |  Bin 102400 ->
> 102400
> > bytes
> >   1 files changed, 0 insertions(+), 0 deletions(-)
> > ___
> > Opensim-commits mailing list
> > opensim-comm...@lists.berlios.de
> > 
> > https://lists.berlios.de/mailman/listinfo/opensim-commits
> >
> >
> >
> > --
> > Justin Clark-Casey (justincc)
> > http://justincc.org
> > http://twitter.com/justincc
> > ___
> > Opensim-dev mailing list
> > Opensim-dev@lists.berlios.de  d...@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
> 
> 
> --
> Justin Clark-Casey (justincc)
> http://justincc.org
> http://twitter.com/justincc
> ___
> 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] LL Viewer code license change

[Frisby, Adam]

I think we should treat this cautiously, but optimistically – this is a big 
move for Linden to undertake; it is not quite as significant as a move to BSD 
would be, but it is a solid step forward and may eliminate our chief concerns, 
and I am of the personal belief it opens some doors to use as far as 
contributors co-developing goes.

I would however ask everyone to please hold from examining the code until we’ve 
got a legal opinion on the matter, but I am quietly optimistic that this may 
allow us to remove that clause from OpenSim’s own contributor agreement.

Regards,

Adam

From: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of David W Levine
Sent: Tuesday, 17 August 2010 6:44 AM
To: opensim-dev@lists.berlios.de
Cc: opensim-dev@lists.berlios.de; opensim-dev-boun...@lists.berlios.de
Subject: Re: [Opensim-dev] LL Viewer code license change


If I heard Oz and Esbee correctly, the whole of the viewer, with the exception 
of the proprietary libs they use (which I htink is the KDU jpeg2000 stuff and 
one or two media codecs at this point) go to LGPL. You can't mix LGPL and GPL 
deeply, as Adam's pointed out. I'm not enough of a LGPL wonk to know exactly 
where that takes things. I'd think the question is "does it change the dynamic 
on "derivative work" I know being LGPL means that one could link bits direclty 
into OpenSim legally. That's straightforward. What's less obvious is whether 
reading the LGPL code causes the same issues that
reading GPL code causes. They did point out that they still insist on the 
contribution agreement, and that the contribution agreement was why they could 
shift licenses.

- David
` Zha


[cid:image001.gif@01CB3DFB.138F38B0]"Frisby, Adam" ---08/17/2010 07:30:24 
AM---It'll have to be all LGPL if parts of it are - since the GPL wont accept 
redistribution of a mix of

From:


"Frisby, Adam" 


To:


"opensim-dev@lists.berlios.de" 


Date:


08/17/2010 07:30 AM


Subject:


Re: [Opensim-dev] LL Viewer code license change


Sent by:


opensim-dev-boun...@lists.berlios.de





It’ll have to be all LGPL if parts of it are – since the GPL wont accept 
redistribution of a mix of LGPL and GPL – only pure GPL.

Check the post on sldev about it – it looks to me from that one that the 
intention is for it all to be LGPL.

Adam

From: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Dahlia Trimble
Sent: Tuesday, 17 August 2010 3:53 AM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] LL Viewer code license change


On Tue, Aug 17, 2010 at 2:36 AM, Ai Austin 
mailto:ai.ai.aus...@gmail.com>> wrote:
From: Justin Clark-Casey 
mailto:jjusti...@googlemail.com>>

As regards to OpenSim contributions, I doubt that the viewer license change to 
LGPL will make any difference. LGPL just
makes it possible to link non-GPL code to the viewer code. The viewer co
de itself is still virally licensed.
Justin, where did you get this information? Its not the way it was presented at 
SLCC (I watched the entire announcement and read the postings afterwards by 
LL). So, its not the way I read it, but we need to check. They even amended the 
licence from GPL to LGPL for a lot of the top level parts of the viewer source 
code as I examined some of the key commitdiffs.


"for a lot of the top level parts"? Not the entire code base? I'm curious which 
parts are now LGPL and which are not, and if not, what license they are under?
___
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] LL Viewer code license change

[Frisby, Adam]

It'll have to be all LGPL if parts of it are - since the GPL wont accept 
redistribution of a mix of LGPL and GPL - only pure GPL.

Check the post on sldev about it - it looks to me from that one that the 
intention is for it all to be LGPL.

Adam

From: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Dahlia Trimble
Sent: Tuesday, 17 August 2010 3:53 AM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] LL Viewer code license change


On Tue, Aug 17, 2010 at 2:36 AM, Ai Austin 
mailto:ai.ai.aus...@gmail.com>> wrote:
From: Justin Clark-Casey 
mailto:jjusti...@googlemail.com>>

As regards to OpenSim contributions, I doubt that the viewer license change to 
LGPL will make any difference.  LGPL just
makes it possible to link non-GPL code to the viewer code.  The viewer co
de itself is still virally licensed.
Justin, where did you get this information?  Its not the way it was presented 
at SLCC (I watched the entire announcement and read the postings afterwards by 
LL).  So, its not the way I read it, but we need to check.  They even amended 
the licence from GPL to LGPL for a lot of the top level parts of the viewer 
source code as I examined some of the key commitdiffs.


"for a lot of the top level parts"? Not the entire code base? I'm curious which 
parts are now LGPL and which are not, and if not, what license they are under?

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

Re: [Opensim-dev] LL Viewer code license change

[Frisby, Adam]

Yes and no - it's a bit complex.

The LGPL is a much less risky license for us to work with - since if it turns 
out developer code is infringing, it is possible to convert that into a 
separate library and distribute accordingly under the LGPL. 

Nonetheless, it's a welcome change - but we might have to hold until we've got 
some formal advice before changing the contributor agreement.

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Justin Clark-Casey
> Sent: Monday, 16 August 2010 6:48 PM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] LL Viewer code license change
> 
> On 16/08/10 21:03, Dickson, Mike (ISS Software) wrote:
> > Thx Melanie.  I've actually not looked at the 1.x stuff in a few
> months, primarily focused on v2.x.  But I'll look for some sort of more
> formal communication from the team before I start communicating any
> patches, etc. to OpenSim.
> 
> As regards to OpenSim contributions, I doubt that the viewer license
> change to LGPL will make any difference.  LGPL just
> makes it possible to link non-GPL code to the viewer code.  The viewer
> code itself is still virally licensed.
> 
> >
> > Mike
> >
> > -Original Message-
> > From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Melanie
> > Sent: Monday, August 16, 2010 11:47 AM
> > To: opensim-dev@lists.berlios.de
> > Subject: Re: [Opensim-dev] LL Viewer code license change
> >
> > As the license has been changed, the project may revise the
> > contribution policy. However, this would not cancel out the 6 months
> > cooldown period that would be applied to your work with the 1.x
> > viewer code base, since that has not been relicensed, or  at least
> > not yet.
> >
> > Melanie
> >
> > Dickson, Mike (ISS Software) wrote:
> >> So, LL has released the viewer 2 codebase as LGPL v2 (as opposed to
> GPLv2 previously).   My interest in the viewer has in the past limited
> my ability to contribute to OpenSim.  I'm curious if this licensing
> change might not have an impact on that and I'd request that the core
> team consider it and respond with any changes in status as your time
> permits.
> >>
> >> 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 mailing list
> > Opensim-dev@lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> >
> 
> 
> --
> Justin Clark-Casey (justincc)
> http://justincc.org
> http://twitter.com/justincc
> ___
> 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] JSON or XML for serialization in the OpenSim database?

[Frisby, Adam]

Having just worked on a JSON project myself internally - I personally developed 
a bit of a loathing for the format. I'm personally partial to XML, ideally with 
a corresponding DTD.

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Teravus Ovares
> Sent: Monday, 5 July 2010 4:23 PM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] JSON or XML for serialization in the OpenSim
> database?
> 
> Not a whole lot of feedback here yet, maybe people are on a long
> weekend type camping vacation..
> 
> I'm partial to OSD/json, myself.I'd also like to, at some point,
> get a version number in there along with a definition of the format
> for people who want to write integration tools..however, that last
> bit may be more of a 1.0 thing.
> 
> I think a lot of tools are going to go the way of JavaScript in the
> future for various reasons...   one being that..   it's generally
> implemented in all web enabled devices.   Computers, 'tablets', 'smart
> phones'...   Another reason is it's more compact, while still being
> fairly human readable. One last reason that I can think of at this
> moment is there are no external dependencies that 'get lost and turn
> into a 404', like with XML Schemas.   I've done several XML based
> integrations using REST and noted that in 55% of the cases, the
> defining schema is a 404 which makes validation and automatic creation
> of XML Serialization classes impossible.  Worse, in 15% of the cases,
> extensions are defined in the schema and then used in the XML..  Only,
> you won't ever know what tags and parameters the extensions provide
> because the schema is 'missing'.
> 
> Regards
> 
> Teravus
> 
> On Sun, Jul 4, 2010 at 8:28 PM, Justin Clark-Casey
>  wrote:
> > Hi folks,
> >
> > As part of the media-on-a-prim implementation, I'm serializing the
> > parameters for a media texture to the database.  This seems better
> than
> > creating new database fields or even a whole new table for these
> parameters,
> > both because there are lots of them (url, scaling, controls,
> whitelist,
> > etc.) and because different future virtual environments may want to
> store
> > different things.
> >
> > I'm going to serialize them as an OSDArray or MediaEntrys using the
> > libopenmetaverse library.  However, the question then becomes whether
> to use
> > the JSON representation or the XML representation.
> >
> > I tend to prefer XML for storage representations.  I believe that
> it's
> > somewhat more human readable and that there is better tool support
> for
> > manipulating it.  However, I know other people would prefer storage
> in JSON
> > and I accept that serialization/deserialization there may be slightly
> > faster.
> >
> > The only other example of serialization that I know of in OpenSim
> currently
> > is that of SceneObjectGroups into inventory, which encompasses object
> > properties, object inventory properties and script state.  This is
> done in
> > XML and media entries would become part of that serialization.
> >
> > If there's a majority preference for JSON I don't mind using that
> instead,
> > though I would want a justification for going this route rather than
> XML.
> >  If there's no real argument then I will go with XML.
> >
> > Also, I believe that we should try and be consistent, so picking one
> or the
> > other now should make it more likely that the same approach would be
> used
> > for the next serialization case.
> >
> > Regards,
> >
> > --
> > Justin Clark-Casey (justincc)
> > http://justincc.org
> > http://twitter.com/justincc
> > ___
> > 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 change for contributor agreement

[Frisby, Adam]

Hi Rob,

I suspect the principles which allow the 6 month rule probably also allow an 
exemption to that rule (I would be surprised if they didn't.); but I would want 
to hear from legal advice before we could make any adjustments to the 
contributor agreement.

Regards,

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Robert A. Knop Jr.
> Sent: Wednesday, 30 June 2010 8:46 PM
> To: opensim-dev@lists.berlios.de
> Subject: [Opensim-dev] request change for contributor agreement
> 
> It is my hope in the next 6-9 months to be in a position where I'll be
> able to start making real contributions to OpenSim.  There are some
> things I have to work out -- I have to make sure that the IP policies
> of the Unviersity where I'm going won't create problems.  However,
> there's another issue:
> 
>   You have not witnessed, seen or been party to the development of the
>   official Linden Lab Server Software. If you have been involved in the
>   official server development your contributions may affect the
>   licensing of the main codebase and we cannot accept the contributions
>   without a waiver from Linden Lab disclaiming any interest in your
>   contributions.
> 
> Of course, I did see a bunch of that, way back when.  The part that I
> actively worked on myself was something that has no analog in OpenSim
> (the "region conductor", which dealt with figuring out which servers
> ran which regions).  And, it's been more than a year -- will likely
> have been more than 18 months by the time I'm in a position where I'll
> be able to start making contributions.
> 
> Six or eight months ago, I made some preliminary investigations into
> getting this sort of waiver, asking somebody who was most likely to be
> sympathetic to the need for it, and indications are that such a waiver
> is probably very difficult to get.  I honestly do not believe that
> Linden would want to sign such a thing.  However, I also don't think
> that they should have to.  It's been long enough since I had access to
> that code that there's no practical way I can steal any of it at this
> point.  Would it be possible to have some sort of timeout (say, 18
> months) added to this clause in the contributor agreement?
> 
> If that can't be done, then if I want to work on OpenSim I'm
> effectively going to have to make my own fork of it.  I know I'll want
> to be working on things related to the Physics engine, and it would be
> sad to me if I were not able to contribute what I did back to core
> OpenSim.  It would greatly undermine the value of what I hope to be
> able to do in the future.
> 
> --
> --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

Re: [Opensim-dev] SOG refactoring?

[Frisby, Adam]

Thanks Diva for digging that out - the plan hasn't changed from that document 
and the subsequent mailing list discussion (which follows that thread)

Adam

From: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Cristina Videira 
Lopes
Sent: Monday, 14 June 2010 3:46 PM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] SOG refactoring?

This concerns some internals of the simulator itself. When Adam is done with 
this, not much will be immediately visible to users. But it will allow OpenSim 
to play well with viewers that have completely different ways of representing 
of 3D objects (e.g. meshes).

http://lists.berlios.de/pipermail/opensim-dev/2009-December/008098.html


On Jun 14, 2010, at 1:27 PM, Karen Palen wrote:


How about a summary for  us confused peasants?

Karen
On Mon, Jun 14, 2010 at 9:03 AM, 
mailto:d...@metaverseink.com>> wrote:
Hey Adam,

That's great news! We were talking about it yesterday in the IRC; SOG 
reconceptualization seems like a daunting task, but it's very much needed.

It looks like you already have something going. Would it be possible that you 
make that work in a public branch, so that we all get psychologically 
conditioned for what's coming?

Thanks,
Crista


Frisby, Adam wrote:
Hey Diva,

Yep, I saw .7 get tagged - I'll be working pretty much to the original plan. 
Although I've got a lot of the groundwork already done, so this shouldn't take 
as long as the ROBUST/.69/7 work.
I'll make up a small plan and post it here tomorrow.

Regards,

Adam
-Original Message-
From: 
opensim-dev-boun...@lists.berlios.de<mailto:opensim-dev-boun...@lists.berlios.de>
 [mailto:opensim-dev-<mailto:opensim-dev->
boun...@lists.berlios.de<mailto:boun...@lists.berlios.de>] On Behalf Of 
d...@metaverseink.com<mailto:d...@metaverseink.com>
Sent: Sunday, 13 June 2010 9:58 PM
To: opensim-dev@lists.berlios.de<mailto:opensim-dev@lists.berlios.de>
Subject: [Opensim-dev] SOG refactoring?

Hey Adam,

What is the plan for the SOG refactoring that you nicely outlined here
a
few months ago?

0.7 is about to be tagged, we need some other massive change to keep
trunk unstable :-)

Diva / Crista

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

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

___
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] SOG refactoring?

[Frisby, Adam]

Yep - look for the sogrefactor branch. I'll be committing in there over the 
next week; until components are ready -- at which point, some of the more 
dramatic changes will be on the cards.

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of d...@metaverseink.com
> Sent: Monday, 14 June 2010 9:04 AM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] SOG refactoring?
> 
> Hey Adam,
> 
> That's great news! We were talking about it yesterday in the IRC; SOG
> reconceptualization seems like a daunting task, but it's very much
> needed.
> 
> It looks like you already have something going. Would it be possible
> that you make that work in a public branch, so that we all get
> psychologically conditioned for what's coming?
> 
> Thanks,
> Crista
> 
> Frisby, Adam wrote:
> > Hey Diva,
> >
> > Yep, I saw .7 get tagged - I'll be working pretty much to the
> original plan. Although I've got a lot of the groundwork already done,
> so this shouldn't take as long as the ROBUST/.69/7 work.
> >
> > I'll make up a small plan and post it here tomorrow.
> >
> > Regards,
> >
> > Adam
> >
> >> -Original Message-
> >> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> >> boun...@lists.berlios.de] On Behalf Of d...@metaverseink.com
> >> Sent: Sunday, 13 June 2010 9:58 PM
> >> To: opensim-dev@lists.berlios.de
> >> Subject: [Opensim-dev] SOG refactoring?
> >>
> >> Hey Adam,
> >>
> >> What is the plan for the SOG refactoring that you nicely outlined
> here
> >> a
> >> few months ago?
> >>
> >> 0.7 is about to be tagged, we need some other massive change to keep
> >> trunk unstable :-)
> >>
> >> Diva / Crista
> >>
> >> ___
> >> Opensim-dev mailing list
> >> Opensim-dev@lists.berlios.de
> >> https://lists.berlios.de/mailman/listinfo/opensim-dev
> >
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] SOG refactoring?

[Frisby, Adam]

Hey Diva,

Yep, I saw .7 get tagged - I'll be working pretty much to the original plan. 
Although I've got a lot of the groundwork already done, so this shouldn't take 
as long as the ROBUST/.69/7 work. 

I'll make up a small plan and post it here tomorrow.

Regards,

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of d...@metaverseink.com
> Sent: Sunday, 13 June 2010 9:58 PM
> To: opensim-dev@lists.berlios.de
> Subject: [Opensim-dev] SOG refactoring?
> 
> Hey Adam,
> 
> What is the plan for the SOG refactoring that you nicely outlined here
> a
> few months ago?
> 
> 0.7 is about to be tagged, we need some other massive change to keep
> trunk unstable :-)
> 
> Diva / Crista
> 
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] merge has happened

[Frisby, Adam]

Is it now safe to tag off the object-refactor branch?

Regards,

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of d...@metaverseink.com
> Sent: Monday, 1 March 2010 10:37 PM
> To: opensim-dev@lists.berlios.de
> Subject: [Opensim-dev] merge has happened
> 
> News!
> 
> Melanie tagged 0.6.9 from master with corresponding 0.6.9-post-fixes
> now
> waiting for improvements. Testers wanted for 0.6.9-post-fixes.
> 
> The presence-refactor branch has been merged onto master, which is now
> pre-0.7.
> 
> Anyone trying the master branch, please be aware of the architectural
> changes that happened:
> http://opensimulator.org/wiki/ROBUST#An_Example_Conversion_From_URM_To_
> R
> 
> The usual warning: don't use the master branch for anything that is
> vaguely similar to a production grid. We have been tagging releases for
> a reason...
> 
> ___
> 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] Status of presence refactor?

[Frisby, Adam]

Very cool!

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of d...@metaverseink.com
> Sent: Sunday, 21 February 2010 9:43 AM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] Status of presence refactor?
> 
> News: the SQLite connector is done and working in the presence-refactor
> branch.
> 
> UserAccount data is automatically migrated into the new table. People
> using SQLite-powered OpenSims will have to reset the passwords manually
> before they are able to login (with console command "reset user
> password"). This does not affect MySql-powered opensims, only SQLite.
> 
> Hopefully Melanie_t will finish Friends today.
> We'll be ready to merge any time now.
> 
> Frisby, Adam wrote:
> > I would like to start the SOP refactor fairly soon - what if once 0.7
> is tagged for the RC process; I go and and make a new branch; we can
> sic testers on the presence-branch, while dev happens on the branch I
> tag?
> >
> > Adam
> >
> >> -Original Message-
> >> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> >> boun...@lists.berlios.de] On Behalf Of Justin Clark-Casey
> >> Sent: Friday, 19 February 2010 3:25 PM
> >> To: opensim-dev@lists.berlios.de
> >> Subject: Re: [Opensim-dev] Status of presence refactor?
> >>
> >> Melanie wrote:
> >>> I would not like to see the refactor start in the branch, because
> >>> that would postpone a merge indefinitely.
> >> Yes, please whatever happens, do not start any sog refactoring in
> >> Master until presence-refactor has been merged and we've started a
> >> branch for 0.7.
> >>
> >> In fact, when presence-refactor is merged with Master I think that
> we
> >> should wait at least 2 weeks before branching for 0.7 in order for
> all
> >> active developers to iron out any significant bugs associated with
> the
> >> merge.
> >>
> >> At a minimum, the 0.7 branch itself would be subject to the same
> >> release candidate and bug triage procedure as was 0.6.8.  Only after
> >> this would 0.7 be tagged.  I think that this is the very minimum we
> >> need to do in order to be a credible project.
> >>
> >> This would also give us an opportunity to get the documentation into
> a
> >> shape where at least super-intelligent pandimensional mice can
> >> understand it :)
> >>
> >> At the same time as 0.7 is branched, I also think that it would be
> >> prudent to branch for a potential 0.7.0.1.  If all goes well with
> the
> >> sog refactor this will never see the light of day.  But I think we
> >> should give ourselves a means of working with the old sog code in
> case
> >> the refactor encounters trouble.  The sog refactor is far from
> trivial.
> >>
> >>> However, the refactor caould be started in a NEW branch that is
> >>> based off the current presence-refactor. The friends and SQLite
> >>> functionality could be merged back to that new branch when they are
> >>> completed. Git allows this easily.
> >> That sounds like a good idea.
> >>
> >>> Melanie
> >>>
> >>>
> >>> d...@metaverseink.com wrote:
> >>>> I could, but I'm hesitant to make diva distro releases from
> branches
> >>>> that aren't the master branch. Plus, so far the differences
> between
> >> the
> >>>> two branches are purely internal; there is no functional
> difference,
> >> or
> >>>> new bug fixes, or anything like that. The new architecture will
> >> allow
> >>>> for lots of exciting things to happen, but, again, I'm hesitant in
> >>>> making them happen in the branch. I'd rather merge this to master.
> >>>>
> >>>>
> >>>> Robert Martin wrote:
> >>>>> On Thu, Feb 18, 2010 at 10:15 AM,   wrote:
> >>>>>> Sigh.
> >>>>>> It's ready. It's been fully operational for several weeks,
> modulo
> >>>>>> buglets. It hasn't been merged because the SQLite connector
> hasn't
> >> been
> >>>>>> redone and at least Melanie doesn't want to merge without it.
> >>>>>>
> >>>>> could you release a copy of Diva with the updated code (since
> Diva
> >> of
> >>>>> co

Re: [Opensim-dev] Status of presence refactor?

[Frisby, Adam]

I would like to start the SOP refactor fairly soon - what if once 0.7 is tagged 
for the RC process; I go and and make a new branch; we can sic testers on the 
presence-branch, while dev happens on the branch I tag?

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Justin Clark-Casey
> Sent: Friday, 19 February 2010 3:25 PM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] Status of presence refactor?
> 
> Melanie wrote:
> >
> > I would not like to see the refactor start in the branch, because
> > that would postpone a merge indefinitely.
> 
> Yes, please whatever happens, do not start any sog refactoring in
> Master until presence-refactor has been merged and we've started a
> branch for 0.7.
> 
> In fact, when presence-refactor is merged with Master I think that we
> should wait at least 2 weeks before branching for 0.7 in order for all
> active developers to iron out any significant bugs associated with the
> merge.
> 
> At a minimum, the 0.7 branch itself would be subject to the same
> release candidate and bug triage procedure as was 0.6.8.  Only after
> this would 0.7 be tagged.  I think that this is the very minimum we
> need to do in order to be a credible project.
> 
> This would also give us an opportunity to get the documentation into a
> shape where at least super-intelligent pandimensional mice can
> understand it :)
> 
> At the same time as 0.7 is branched, I also think that it would be
> prudent to branch for a potential 0.7.0.1.  If all goes well with the
> sog refactor this will never see the light of day.  But I think we
> should give ourselves a means of working with the old sog code in case
> the refactor encounters trouble.  The sog refactor is far from trivial.
> 
> >
> > However, the refactor caould be started in a NEW branch that is
> > based off the current presence-refactor. The friends and SQLite
> > functionality could be merged back to that new branch when they are
> > completed. Git allows this easily.
> 
> That sounds like a good idea.
> 
> >
> > Melanie
> >
> >
> > d...@metaverseink.com wrote:
> >> I could, but I'm hesitant to make diva distro releases from branches
> >> that aren't the master branch. Plus, so far the differences between
> the
> >> two branches are purely internal; there is no functional difference,
> or
> >> new bug fixes, or anything like that. The new architecture will
> allow
> >> for lots of exciting things to happen, but, again, I'm hesitant in
> >> making them happen in the branch. I'd rather merge this to master.
> >>
> >>
> >> Robert Martin wrote:
> >>> On Thu, Feb 18, 2010 at 10:15 AM,   wrote:
>  Sigh.
>  It's ready. It's been fully operational for several weeks, modulo
>  buglets. It hasn't been merged because the SQLite connector hasn't
> been
>  redone and at least Melanie doesn't want to merge without it.
> 
> >>> could you release a copy of Diva with the updated code (since Diva
> of
> >>> course does not use SQlite)?
> >> ___
> >> 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
> >
> 
> 
> --
> Justin Clark-Casey (justincc)
> http://justincc.org
> http://twitter.com/justincc
> ___
> 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] Status of presence refactor?

[Frisby, Adam]

Does anyone know what is the current status of the presence refactor - is there 
any date on when that is going to hit trunk?

I'd really like to see 0.7 get tagged soon, so we can begin the big object 
model refactor.

Thanks!

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

Re: [Opensim-dev] How to retreive pictures from the inventory ?

[Frisby, Adam]

It's a JPEG2000 image, Bitmap doesn't support J2C. There's a Utility method for 
converting to a Bitmap however. (not sure what it is)

Regards,

Adam

From: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Valentin Castan
Sent: Wednesday, 17 February 2010 8:26 AM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] How to retreive pictures from the inventory ?

Thanks for your help, but I still have a problem, and I don't really know whats 
wrong. This is my code :

AssetBase asset = scene.AssetService.Get(item.AssetID.ToString());
byte[] byteArray = asset.Data;
using (MemoryStream ms = new MemoryStream(byteArray))
{
Bitmap img = (Bitmap)Image.FromStream(ms);   <-   
error, parameter is not valid
}

It seems that my MemoryStream is not valid, and I think it's because the byte 
array is not correct to convert to Image. But the object I retreive is an 
image, so I don't understand what's wrong. OpenSim does modification of this 
array ?

Thank you a lot,
Valentin
On Wed, Feb 17, 2010 at 1:45 AM, Alan M Webb 
mailto:alan_w...@us.ibm.com>> wrote:

Hi Valentin

If you look at the Rest application plug-in, it supports the retrieval and 
uploading of inventory data, both catalog data and the assets themselves.

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

From:

Valentin Castan mailto:valentin.cas...@gmail.com>>

To:

opensim-dev@lists.berlios.de

Date:

02/15/2010 02:16 AM

Subject:

[Opensim-dev] How to retreive pictures from the inventory ?





Dear all,

I'm working on a project where I have to process images, using another 
application, and then display something in OpenSim. I would like to let users 
to upload their pictures on OpenSim, but I have to retreive these pictures, and 
copy them in a special directory.
My problem is in the code of OpenSim, I only can find how to retreive an 
InventoryItemBase from the inventory, but I didn't find any way to retreive a 
picture, to be able to copy it.
Does someone know how can I retreive pictures from the Inventory, but not as an 
InventoryItemBase, but as something I can use as a picture ?

Thank you a lot for your help,
Best regards,
Valentin Castan___

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] How Was OpenSim "Born"?

[Frisby, Adam]

I think it's probably missing some of the really ancient history, eg:

Mid-2006: Me/JH work out chunks of the SL protocol from Ethereal dumps
... then we were told by another outside-of-SL [Rade someone?] developer that 
SL has its entire protocol stored in a file called 'message_template.dat' which 
is just a .txt file xor'd 0x43.
Slightly later: We (mostly JH) write a basic client in C++ using BOOST.
... which turned out to be a complete unmitigated mess of thread crashes ...
Then take 2 is written in C#/.NET and gets a lot further, a lot faster.
Jan 17th-ish 2007: Darren/MW writes a simple server using libsl as the base; a 
lot of it is based on 'repeating' captured packet dumps in response to 
situations.
Jan 2Xth 2007: LL releases the client code
Jan 25-9th: MW releases his server emulator onto one of the forums, me & a few 
others are intrigued.
Feb?: MW/lbsa/Gareth/me are the first committers
Feb->July: We rewrite the code from scratch at least 4 times.
... settling on '0.2' which forms the basis of a lot of the current 
architecture ...
July: SDague from IBM gets signoff to start committing code to OpenSim.
... *stuff happens* ...
Today.


Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Justin Clark-Casey
> Sent: Thursday, 11 February 2010 2:41 PM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] How Was OpenSim "Born"?
> 
> Len Brown wrote:
> > 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, have you seen this OpenSim history wiki page?
> 
> http://opensimulator.org/wiki/History
> 
> If you dig up any extra information it would be very welcome on there
> too.
> 
> --
> Justin Clark-Casey (justincc)
> http://justincc.org
> http://twitter.com/justincc
> ___
> 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] personal plea on patents

[Frisby, Adam]

Guys, I've said this before.

DO NOT POST PATENTS ON THIS MAILING LIST.
AVOID LOOKING AT THEM IF POSSIBLE.

Everyone who looks at them is now liable for wilful infringement if they submit 
code around that area after looking at it.

Regards,

Adam


From: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Mark Malewski
Sent: Wednesday, 3 February 2010 1:09 PM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] personal plea on patents

What exactly is going on?

Did someone apply for a patent?  Are ANY patents pending?  If so, please let us 
know what patents are currently pending, so we can at least look them over and 
contest them.

I've had virtual worlds running since 1991, with 3D shopping malls, online 
e-commerce, etc.

I'd really like to see if anyone is currently attempting to put a patent 
through, so we can at least work on contesting/disputing the validity of any 
pending patents.  Software patents are a bad idea, and it really hurts the 
creativity/innovation and development of 3D platforms.

If anyone is aware of ANY pending patents, please let me know and please post 
the pending patent numbers to this forum.  I'd be interested in working with 
legal counsel to dispute the validity of any pending patents, or at least begin 
work on shooting the patents down before they are approved.

It's much easier to shoot them down (before they get approved), so please post 
any information that you may have about any pending patents.

Are you referring to the patent that was filed by IBM?

http://www.freepatentsonline.com/20090300582.pdf

Is this the patent we are talking about?

There are only THREE types of patents (Design, Utility, and Plant).  I'm 
assuming that we're talking about "Design" patents, and in order for a patent 
to be "valid" it must be a NEW, or ORIGINAL idea.

Design patents may be granted to anyone who invents a new, ORIGINAL, and 
ornamental design for an article of manufacture; and

There is nothing new, and nothing original.  If IBM is looking to use the 
OpenSim Infrastructure as a basis for their patent, or even attempting to claim 
that the things we discuss (or implement/plan/roll out/develop) are part of 
IBM's "design" then it's certainly not new, or original.

I doubt that the patent application is valid, and I'll need to skim over their 
patent application, and see if we need to work on appealing the patent 
application.

Companies attempt to file patents (on other people's ideas) simply as a way to 
make money (by litigation) in hopes to stifle innovation, development, 
creativity and an attempt to kill off any competition.

As far as IBM's patent idea, it doesn't hold any water.  It's not new, and it's 
not original.  I'd developed platforms identical to that as early as 1991.  I'd 
been doing synchronization of offline 3D virtual content for 3D shoppings malls 
since 1991 and developed a platform for the U.S. Army's Battlefield 
Visualization program using synchronization of offline content (for 3D 
Battlefield Visualization) as early as 1994.

Even civilian projects like Active Worlds had been doing that (as part of their 
browser cache) as early as 1995/1996 (about 5+ years after work that I had 
done).

So I hardly believe that IBM's silly patent application really holds much 
water.  I'm willing to file an opposition to IBM's patent, if there are any 
other pending patent applications out there, then please let me know.  I'd be 
more than happy to help "nip" this in the butt before some silly greedy 
business manager (or company) attempts to try and file a patent and kill off 
the creativity, innovation, and development of 3D platforms.

James, I completely agree with your post, and we really do need to work on 
contesting this patent (if we're referring to the pending IBM patent).  Prior 
art and prior work is there.  There is nothing new or unique in IBM's pending 
patent application (if that is what this whole discussion is about).  If there 
are ANY pending patents out there, please post the patent application numbers 
here in this forum, and we'll begin to address the issues (legally).

I'd rather bring this silly patent nonsense to an end now, before this gets out 
of hand.  Looks like IBM is attempting to do a "smash and grab" by filling out 
a silly patent application to try and hinder widespread use, or development of 
advanced 3D platform.

It seems that managers ride on the coat tails of others and then attempt to go 
for the "get rich quick by grabbing the IP quicker" routine.  This is nothing 
but hogwash, and it's really sad to see companies (and individuals) that stoop 
to this kind of level.

Mark

On Wed, Feb 3, 2010 at 2:05 PM, James Stallings II 
mailto:james.stalli...@gmail.com>> wrote:
Some history may be in order here; I wont drag you through each and every phase 
of virtual world development, but I can tell you that googling 'virtual worlds' 
turns up prior art for almost e

Re: [Opensim-dev] Refactoring status (take 2)

[Frisby, Adam]

Any idea on when the final state will be done?

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Melanie
> Sent: Tuesday, 19 January 2010 7:17 PM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] Refactoring status (take 2)
> 
> Almost there. There may be some HG related changed needed, but they
> will likely just be additional fields.
> 
> Melanie
> 
> Frisby, Adam wrote:
> > Are the database schemas now defined? (I wanted to know this before I
> begun the process of updating the OSgrid Elgg to use the new schema,
> ditto Gridmix).
> >
> > Regards,
> >
> > Adam
> >
> >> -Original Message-
> >> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> >> boun...@lists.berlios.de] On Behalf Of d...@metaverseink.com
> >> Sent: Tuesday, 19 January 2010 6:59 PM
> >> To: opensim-dev@lists.berlios.de
> >> Subject: [Opensim-dev] Refactoring status (take 2)
> >>
> >> An FYI on the progress of the presence-refactor branch.
> >>
> >> Everything has been rewritten in the new style, and things are
> working.
> >> The branch has been in testing for the past week, and it's nice to
> see
> >> some people not being afraid to check that branch out and have a go
> at
> >> it.
> >>
> >> The merge with master hasn't happened yet, because of two and a half
> >> outstanding issues: (1) the friends feature hasn't been redone,
> >> therefore friends don't work in the branch yet; (2) SQLite, same;
> (0.5)
> >> HG is still in the process of being redone, it doesn't completely
> work
> >> in the branch yet.
> >>
> >> HG is only 0.5-an-issue because I don't hold the merge back on
> account
> >> of HG not working, and I don't think anyone does either; it can be
> >> fixed
> >> after the merge and before 0.7 is tagged. However, the other two,
> >> especially SQLite, seem to worry people a lot, including Melanie who
> >> wants to take care of it before the merge happens.
> >>
> >> For now, it would be great if people who can do it on their own,
> check
> >> the branch out and test things  (on test DBs only please!).
> >> If anyone is in a hurry, help with SQLite and Friends would be most
> >> welcome, so that we get the merge done sooner. Melanie probably
> won't
> >> do
> >> it before next week.
> >>
> >> Crista / Diva
> >> ___
> >> 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] Refactoring status (take 2)

[Frisby, Adam]

Are the database schemas now defined? (I wanted to know this before I begun the 
process of updating the OSgrid Elgg to use the new schema, ditto Gridmix).

Regards,

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of d...@metaverseink.com
> Sent: Tuesday, 19 January 2010 6:59 PM
> To: opensim-dev@lists.berlios.de
> Subject: [Opensim-dev] Refactoring status (take 2)
> 
> An FYI on the progress of the presence-refactor branch.
> 
> Everything has been rewritten in the new style, and things are working.
> The branch has been in testing for the past week, and it's nice to see
> some people not being afraid to check that branch out and have a go at
> it.
> 
> The merge with master hasn't happened yet, because of two and a half
> outstanding issues: (1) the friends feature hasn't been redone,
> therefore friends don't work in the branch yet; (2) SQLite, same; (0.5)
> HG is still in the process of being redone, it doesn't completely work
> in the branch yet.
> 
> HG is only 0.5-an-issue because I don't hold the merge back on account
> of HG not working, and I don't think anyone does either; it can be
> fixed
> after the merge and before 0.7 is tagged. However, the other two,
> especially SQLite, seem to worry people a lot, including Melanie who
> wants to take care of it before the merge happens.
> 
> For now, it would be great if people who can do it on their own, check
> the branch out and test things  (on test DBs only please!).
> If anyone is in a hurry, help with SQLite and Friends would be most
> welcome, so that we get the merge done sooner. Melanie probably won't
> do
> it before next week.
> 
> Crista / Diva
> ___
> 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] Refactoring SceneObjectGroup - Introducing Components

[Frisby, Adam]

It's been a little while since I put this up - assuming there are no other 
comments or feedback, I'm going to begin working on this as soon as the 0.7 
release has been tagged.

Regards,

Adam

From: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Frisby, Adam
Sent: Saturday, 19 December 2009 10:09 AM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Refactoring SceneObjectGroup - Introducing Components

It's in the PDF attached to the original post - basically we merge 
SceneObjectGroup+Part together; then make it possible to chain them directly.

IE:
SceneObject.Parent
SceneObject.Children[]

Then you can represent hierarchies by making a group a parent of another group.

Adam

From: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Morgaine
Sent: Saturday, 19 December 2009 12:36 AM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Refactoring SceneObjectGroup - Introducing Components

On Fri, Dec 11, 2009 at 11:47 AM, Frisby, Adam 
mailto:a...@deepthink.com.au>> wrote:

* Enable full inheritance & linking (ie, hierarchical linking)

This is terrific news, Adam!

There's a bunch of us who have been "hierarchical object activists" in SL for 
some years, regularly trying to get the benefits of hierarchical objects across 
to Linden developers at their Office Hours.  We have a wiki page on Prim and 
Object Hierarchy<https://wiki.secondlife.com/wiki/Prim_and_Object_Hierarchy> , 
and a number of Jiras also address the issue, including 
MISC-428<http://jira.secondlife.com/browse/MISC-428>, 
MISC-1434<http://jira.secondlife.com/browse/MISC-1434>, and 
MISC-2237<http://jira.secondlife.com/browse/MISC-2237>.

We've been successful on the principle (several LL devs now support it 
wholeheartedly) but not in practice, because the development process within the 
Labs appears to be quite logjammed and stifled so that individual developer 
opinion has no effect.  As noted on the wiki page above though, Lindens know  
that they made a mistake in not supporting object hierarchy.  They just can't 
do anything about it now.

Hierarchical objects provide many different types of benefit, so you'll hear 
different people advocate different aspects about them, but they're all 
complementary.  My angle stems from the needs of pure engineering, in that 
hierarchical object composition is the basis of all engineered products in RL.  
Almost everything in modern life is manufactured by putting together complex 
components, not from raw materials, and that's how you ride on the shoulders of 
giants.  You can't do that in SL.

It's wonderful to see hierarchical objects finally gaining in profile in 
Opensim.  Is there a design for this?

We've been examining the pro's and con's of various approaches, including 
evolutionary ones that extend the current very poor linkset paradigm, as well 
as new designs that either encapsulate linksets transparently or else create a 
completely new and separate hierarchical object system in parallel with the 
current non-hierarchical one.  Each approach has its own advantages and 
disadvantages.

More info on your current thinking would be very welcome.  Designs tend to 
stick around for longer than planned, and getting it partially right from the 
start would be a good idea.

Morgaine.




==
On Fri, Dec 11, 2009 at 11:47 AM, Frisby, Adam 
mailto:a...@deepthink.com.au>> wrote:
Hi Folks,

I've got a fairly complicated proposal to deliver here today - the short of it 
is; I'd like to go ahead and replace the current Scene Object representation 
model - at a fairly comprehensive & complete level. Some of you have had the 
misfortune of working with SceneObjectPart/SceneObjectGroup and should 
understand what I am talking about.

There are several stages to this proposal - but I would like to talk about 
today the first big one (and a small outline of the larger project - the reason 
for this being some of the later details require a little more nutting out 
before I have a complete proposal for them).

So - the larger proposal in a nutshell; I would like to:

* Merge SceneObjectGroup & SceneObjectPart

* Enable full inheritance & linking (ie, hierarchical linking)

* Make programming with SceneObjects possible & reasonable from the 
outside (ie have a clean API).

* Provide the ability to extend SceneObjects with "components" to 
introduce new properties and behaviours.

The item I'd like to talk about today would be implementing Components. 
Components are small C# classes that may be attached to any SceneObject 
arbitrarily.

A component is any class inheriting from IComponent - IComponent carries only 
two properties; a serialisation property (retu

Re: [Opensim-dev] Refactoring SceneObjectGroup - Introducing Components

[Frisby, Adam]

It's in the PDF attached to the original post - basically we merge 
SceneObjectGroup+Part together; then make it possible to chain them directly.

IE:
SceneObject.Parent
SceneObject.Children[]

Then you can represent hierarchies by making a group a parent of another group.

Adam

From: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Morgaine
Sent: Saturday, 19 December 2009 12:36 AM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Refactoring SceneObjectGroup - Introducing Components

On Fri, Dec 11, 2009 at 11:47 AM, Frisby, Adam 
mailto:a...@deepthink.com.au>> wrote:

* Enable full inheritance & linking (ie, hierarchical linking)

This is terrific news, Adam!

There's a bunch of us who have been "hierarchical object activists" in SL for 
some years, regularly trying to get the benefits of hierarchical objects across 
to Linden developers at their Office Hours.  We have a wiki page on Prim and 
Object Hierarchy<https://wiki.secondlife.com/wiki/Prim_and_Object_Hierarchy> , 
and a number of Jiras also address the issue, including 
MISC-428<http://jira.secondlife.com/browse/MISC-428>, 
MISC-1434<http://jira.secondlife.com/browse/MISC-1434>, and 
MISC-2237<http://jira.secondlife.com/browse/MISC-2237>.

We've been successful on the principle (several LL devs now support it 
wholeheartedly) but not in practice, because the development process within the 
Labs appears to be quite logjammed and stifled so that individual developer 
opinion has no effect.  As noted on the wiki page above though, Lindens know  
that they made a mistake in not supporting object hierarchy.  They just can't 
do anything about it now.

Hierarchical objects provide many different types of benefit, so you'll hear 
different people advocate different aspects about them, but they're all 
complementary.  My angle stems from the needs of pure engineering, in that 
hierarchical object composition is the basis of all engineered products in RL.  
Almost everything in modern life is manufactured by putting together complex 
components, not from raw materials, and that's how you ride on the shoulders of 
giants.  You can't do that in SL.

It's wonderful to see hierarchical objects finally gaining in profile in 
Opensim.  Is there a design for this?

We've been examining the pro's and con's of various approaches, including 
evolutionary ones that extend the current very poor linkset paradigm, as well 
as new designs that either encapsulate linksets transparently or else create a 
completely new and separate hierarchical object system in parallel with the 
current non-hierarchical one.  Each approach has its own advantages and 
disadvantages.

More info on your current thinking would be very welcome.  Designs tend to 
stick around for longer than planned, and getting it partially right from the 
start would be a good idea.

Morgaine.




==
On Fri, Dec 11, 2009 at 11:47 AM, Frisby, Adam 
mailto:a...@deepthink.com.au>> wrote:
Hi Folks,

I've got a fairly complicated proposal to deliver here today - the short of it 
is; I'd like to go ahead and replace the current Scene Object representation 
model - at a fairly comprehensive & complete level. Some of you have had the 
misfortune of working with SceneObjectPart/SceneObjectGroup and should 
understand what I am talking about.

There are several stages to this proposal - but I would like to talk about 
today the first big one (and a small outline of the larger project - the reason 
for this being some of the later details require a little more nutting out 
before I have a complete proposal for them).

So - the larger proposal in a nutshell; I would like to:

* Merge SceneObjectGroup & SceneObjectPart

* Enable full inheritance & linking (ie, hierarchical linking)

* Make programming with SceneObjects possible & reasonable from the 
outside (ie have a clean API).

* Provide the ability to extend SceneObjects with "components" to 
introduce new properties and behaviours.

The item I'd like to talk about today would be implementing Components. 
Components are small C# classes that may be attached to any SceneObject 
arbitrarily.

A component is any class inheriting from IComponent - IComponent carries only 
two properties; a serialisation property (returns the current 'state' for 
serialisation purposes), and a type property (which recognises the 'type' of 
component that it is) - components allow you to attach arbitrary data to an 
object for the purposes of interacting with a region module. For instance, a 
"Mesh" module (which is my current best example) would have a MeshComponent 
that included all the extra data to tag an object with related to meshes - 
which would get serialised and passed aro

Re: [Opensim-dev] Refactoring SceneObjectGroup - Introducing Components

[Frisby, Adam]

Not too too painful. The vast majority should be cut&paste-able.

The big stuff will be people who have code tied to SOG/SOP on any deep level - 
however again, a lot of it should be transportable; it's going to require a 
healthy amount of refactoring unfortunately however.

I had a longer reply to this which is still sitting open - I'll get to it once 
I finish a little accounting work.

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Melanie
> Sent: Tuesday, 15 December 2009 8:05 AM
> To: d...@metaverseink.com; opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] Refactoring SceneObjectGroup - Introducing
> Components
> 
> Hi,
> 
> in fact, yes. Anyone who has private modules is in for a rather
> painful rewrite. That goes double for SOP/SOG extensions.
> 
> Ommelettes and eggs...
> 
> Melanie
> 
> d...@metaverseink.com wrote:
> > I have a question. How does this impact, if it does, extensions of
> > SceneObjectGroup? For example, I have a traffic simulation where
> > Vehicles extend SOG. How will this be affected? Will I be using
> > components instead?
> >
> > Frisby, Adam wrote:
> >> Bumpity Bump. If I don't hear any comments on this, I'm going to
> assume
> >> the proposal is sound and have carte blanche to break OpenSim at my
> >> whim. ;)
> >>
> >>
> >>
> >> (find the original post for the attachment.)
> >>
> >>
> >>
> >> Regards,
> >>
> >>
> >>
> >> Adam
> >>
> >>
> >>
> >> *From:* opensim-dev-boun...@lists.berlios.de
> >> [mailto:opensim-dev-boun...@lists.berlios.de] *On Behalf Of *Frisby,
> Adam
> >> *Sent:* Friday, 11 December 2009 3:48 AM
> >> *To:* opensim-dev@lists.berlios.de
> >> *Subject:* [Opensim-dev] Refactoring SceneObjectGroup - Introducing
> >> Components
> >>
> >>
> >>
> >> Hi Folks,
> >>
> >>
> >>
> >> I've got a fairly complicated proposal to deliver here today - the
> short
> >> of it is; I'd like to go ahead and replace the current Scene Object
> >> representation model - at a fairly comprehensive & complete level.
> Some
> >> of you have had the misfortune of working with
> >> SceneObjectPart/SceneObjectGroup and should understand what I am
> talking
> >> about.
> >>
> >>
> >>
> >> There are several stages to this proposal - but I would like to talk
> >> about today the first big one (and a small outline of the larger
> project
> >> - the reason for this being some of the later details require a
> little
> >> more nutting out before I have a complete proposal for them).
> >>
> >>
> >>
> >> So - the larger proposal in a nutshell; I would like to:
> >>
> >> * Merge SceneObjectGroup & SceneObjectPart
> >>
> >> * Enable full inheritance & linking (ie, hierarchical
> linking)
> >>
> >> * Make programming with SceneObjects possible & reasonable
> from
> >> the outside (ie have a clean API).
> >>
> >> * Provide the ability to extend SceneObjects with
> "components"
> >> to introduce new properties and behaviours.
> >>
> >>
> >>
> >> The item I'd like to talk about today would be implementing
> Components.
> >> Components are small C# classes that may be attached to any
> SceneObject
> >> arbitrarily.
> >>
> >>
> >>
> >> A component is any class inheriting from IComponent - IComponent
> carries
> >> only two properties; a serialisation property (returns the current
> >> 'state' for serialisation purposes), and a type property (which
> >> recognises the 'type' of component that it is) - components allow
> you to
> >> attach arbitrary data to an object for the purposes of interacting
> with
> >> a region module. For instance, a "Mesh" module (which is my current
> best
> >> example) would have a MeshComponent that included all the extra data
> to
> >> tag an object with related to meshes - which would get serialised
> and
> >> passed around with the main object. When deserialized - a "Factory"
> >> handles making sure the MeshComponent is deserialized with the main
> object.
> >>
> >>
> >>
> &g

Re: [Opensim-dev] Refactoring SceneObjectGroup - Introducing Components

[Frisby, Adam]

Bumpity Bump. If I don't hear any comments on this, I'm going to assume the 
proposal is sound and have carte blanche to break OpenSim at my whim. ;)

(find the original post for the attachment.)

Regards,

Adam

From: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Frisby, Adam
Sent: Friday, 11 December 2009 3:48 AM
To: opensim-dev@lists.berlios.de
Subject: [Opensim-dev] Refactoring SceneObjectGroup - Introducing Components

Hi Folks,

I've got a fairly complicated proposal to deliver here today - the short of it 
is; I'd like to go ahead and replace the current Scene Object representation 
model - at a fairly comprehensive & complete level. Some of you have had the 
misfortune of working with SceneObjectPart/SceneObjectGroup and should 
understand what I am talking about.

There are several stages to this proposal - but I would like to talk about 
today the first big one (and a small outline of the larger project - the reason 
for this being some of the later details require a little more nutting out 
before I have a complete proposal for them).

So - the larger proposal in a nutshell; I would like to:

* Merge SceneObjectGroup & SceneObjectPart

* Enable full inheritance & linking (ie, hierarchical linking)

* Make programming with SceneObjects possible & reasonable from the 
outside (ie have a clean API).

* Provide the ability to extend SceneObjects with "components" to 
introduce new properties and behaviours.

The item I'd like to talk about today would be implementing Components. 
Components are small C# classes that may be attached to any SceneObject 
arbitrarily.

A component is any class inheriting from IComponent - IComponent carries only 
two properties; a serialisation property (returns the current 'state' for 
serialisation purposes), and a type property (which recognises the 'type' of 
component that it is) - components allow you to attach arbitrary data to an 
object for the purposes of interacting with a region module. For instance, a 
"Mesh" module (which is my current best example) would have a MeshComponent 
that included all the extra data to tag an object with related to meshes - 
which would get serialised and passed around with the main object. When 
deserialized - a "Factory" handles making sure the MeshComponent is 
deserialized with the main object.

I've attached a document which is my current state of the whole proposal which 
includes some examples & more detail. Please note that Phase 2 is not finalised 
yet - and some decisions were discussed about changing two facets in particular.

* Enabling inheritance of components+sceneobject to make speedy-classes 
for common use cases (eg PrimObject inherits PrimComponent and SceneObject)

* Allowing more than one factory potentially; for manufacturing said 
speedy-classes.

* Note that these shorthand classes would still use the standard .Has / 
.Get methods; they would just return 'this' where the particular component type 
is concerned.

To begin with - I would like to implement components as an extra non-serialised 
property of the SceneObjectPart; this will occur very shortly after 0.7 is 
tagged; which I would like to do once ROBUST covers all the main services (I 
heard something about late-december/early-jan); this first stage should not 
break anything in particular - however once that Is complete, I would like to 
migrate properties into components in order to modularised the codebase better.

An example of this would be PrimData - primdata is unique to the Second Life 
use case, and irrelevant to others; in this case, we'll move PrimData into a 
commonly accessed component (eg "SceneObject.Get.Hollow = 0.9f;") - 
once the move to components is complete for the common data; then creating the 
final SceneObject class which merges SceneObjectGroup+Part should be a fairly 
painless process.

Please take a read of the document attached for more information - and I am 
very keen to hear anyones thoughts as to use cases that this model will make 
more difficult; or could not support. The goal with this project is to make 
OpenSim support more with less - allowing third party modules to really take 
OpenSim as a framework to the next level; and make a more modular server for 
other clients & platforms.

Thanks!

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

Re: [Opensim-dev] Do we have any record of the patches applied to the XMLRPC library?

[Frisby, Adam]

I have a feeling it came from another site than the SF one you posted. I'd 
check the namespace "Nwc" for clues. But yeah, that library is veritably 
ancient - it's worked well so no-one has touched it in quite some time.

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Justin Clark-Casey
> Sent: Monday, 14 December 2009 2:54 PM
> To: opensim-dev@lists.berlios.de
> Subject: [Opensim-dev] Do we have any record of the patches applied to
> the XMLRPC library?
> 
> Hi folks,
> 
> As part of trying to fix remaining issues in 0.6.8.RC1, I've been
> digging into
> our XMLRPC.dll library that comes from
> 
> http://xmlrpccs.sourceforge.net/
> 
> Our version differs from the last released 1.10 (which is the version
> mentioned
> in CONTRIBUTORS.txt).  For example, the XmlRpcRequest.Send() method
> takes two
> parameters (url and a timeout) rather than 1.
> 
> The git log for XMLRPC.dll shows that it was last touched back in July
> 2007.
> Does anybody remember anything about this or where the patch changes
> might be
> found?  I looked for the xmlrpccs repository but it appears to be
> missing (!)
> from sourceforge where it is apparantly hosted.
> 
> Thanks,
> 
> --
> Justin Clark-Casey (justincc)
> http://justincc.org
> http://twitter.com/justincc
> ___
> 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] Synchronous or Asynchronous.. Packet handler synchronicity

[Frisby, Adam]

Since we're defaulting to async - we should probably only make a list of what 
is known to run fast and what isn't.

Just as a quick example - all the terrain packets require some heavyish number 
crunching and should all be async.

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Teravus Ovares
> Sent: Sunday, 13 December 2009 12:08 AM
> To: opensim-dev
> Subject: [Opensim-dev] Synchronous or Asynchronous.. Packet handler
> synchronicity
> 
> Hello Again
> 
> I just wanted to update the people subscribed to opensim-dev about the
> current situation with regards to packet handler synchronicity and
> thread context.
> 
> The History:
> Shortly after OpenSimulator started, it was decided that each user
> should have it's own packet processing thread.  This worked well at
> the time, but limited concurrency because of lock and thread
> contention.   5 UDP connections = 5 dedicated threads that spent most
> of their time waiting(this got expensive when child agents were
> considered).
> 
> Recently:
> A few months ago, Intel provided some test results and provided a few
> developers to re-write the UDP server and client handling stack.
> One of the things that they did was make each UDP server use two
> threads.  One for the incoming packet processing and one for the
> outgoing packet processing, regardless of how many clients were
> connected to OpenSimulator.Essentially, this made it 'one thread
> per network connection resource'.   This was great because it reduced
> the amount of threads that opensimulator uses quite significantly.
> There were some problems though.  Some code handling the upper level
> processing (Scene, SceneObjectGroup, SceneObjectPart..  etc.. )  of
> the data in the packet took long enough to process..   to cause the
> simulator to slowly come to a crawl over time and disconnect users.
> 
> Because the infrastructure wasn't in place to selectively delegate
> which packets are handled asynchronously and synchronously, the choice
> was made to process each packet on the threadpool so that a long
> running packet processor wouldn't cause the UDP server to get
> backlogged and cause all users connected to get disconnected.   This
> solution wasn't really optimal..because a single client, moving
> around, causes ~15 AgentUpdate packets to be sent to the server per
> second.  15 packets means that up to 15 threadpool requests were
> happening a second per connected root agent.   There are various
> reasons why this isn't optimal, I won't go into them here :).
> 
> Now:
> I'm happy to announce, that the infrastructure for selectively
> delegating whether a packet will be processed synchronously or
> asynchronously is in place as of
> 4ef8dc7d96fa2d4efd992ff7d304b8894f004c4f.   You can find the way to
> set a packet handler as synchronous in
> OpenSim.Region.ClientStack.LindenUDP.LLClientView.RegisterLocalPacketHa
> ndler.
>   Note that packet handlers with 3 parameters with the third one
> set to 'false' means that the packet handler is synchronous.Packet
> handlers in that method with 2 parameters or 3 parameters and the
> third one set to 'true' means that the packet is processed
> asynchronously on the threadpool using the method defined by
> async_call_method in OpenSim.ini
> 
> I've also taken the liberty of setting the AgentUpdate Packet, the
> ViewerEffect Packet, and a few others as synchronous.   The
> AgentUpdate Packet and ViewerEffect Packet are the two packets that
> are sent from the client the most often, so, these alone should reduce
> the threads required per client significantly.
> 
> Testers:
> What users and testers should look for, however, is the Simulator
> suddenly disconnecting all users.If this occurs, then, likely, the
> UDP server is not moving fast enough to effectively process packets
> for the current amount of users.
> 
> Developers:
> It's time to look at the length of time it takes for packet processors
> to finish processing and decide if the packet handler should be
> executed synchronously or asynchronously.
> Any synchronously processed packet is processed in the thread context
> beginning with the UDPServer.
> 
> Hopefully, this will allow us to increase the number of concurrently
> connected users further.
> 
> Regards
> 
> Teravus
> ___
> 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] Designing with reusability in mind

[Frisby, Adam]

Why not push the first time a file is added; then add some sort of marker 
'assets from IAR with filesize X are already imported'.

Frankly though - even on a big grid the time to import probably isn't that 
significant.

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Melanie
> Sent: Wednesday, 9 December 2009 4:34 PM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] Designing with reusability in mind
> 
> IARs also contain the assets, which would be stored to the asset
> server again and again. On large servers, this could take ages. So,
> I don't think IAR is a good idea, unless it's stipulated that the
> IAR must have been made on the same server/grid, and that any assets
> contained inside are ignored for the purpose of building the
> library, and are assumed to be present in the asset server.
> 
> Melanie
> 
> Frisby, Adam wrote:
> > Re: Library
> >
> > My thought was to have a directory where we can save .iar files - and
> the library is built from all the IARs in that directory at time the
> inventory server is started.
> >
> > Adam
> >
> >> -Original Message-
> >> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> >> boun...@lists.berlios.de] On Behalf Of d...@metaverseink.com
> >> Sent: Wednesday, 9 December 2009 10:39 AM
> >> To: opensim-dev@lists.berlios.de
> >> Subject: [Opensim-dev] Designing with reusability in mind
> >>
> >> In the same vein as Teravus' message about designing with
> >> instrumentation in mind...
> >>
> >> I would like to ask for us to design with reusability in mind. Let's
> >> get
> >> out of the model that we are developing an application, and always
> >> think
> >> that we are developing components that can be used both for putting
> >> together an application that looks like SL, and for other
> applications
> >> as well.
> >>
> >> Case in point: in the sequence of the conversation about free IARs,
> >> OARs, etc., I have been putting together a package with freebies. I
> >> thought about releasing it as an IAR, like everyone else is doing,
> but
> >> this has a problem: it requires operator access to the server -- not
> >> all
> >> users can take advantage of this free content.
> >>
> >> Solution: let's use the underused OpenSim Library and add more stuff
> in
> >> there. No one has changed that part of OpenSim for ages! There's a
> good
> >> reason for it: adding content to it manually is a huge PITA and
> >> extremely error-prone. So, idea: let's take any IAR and write an
> >> external tool that converts it into the OpenSim Library format. That
> >> way
> >> different operators can provide different libraries very easily:
> just
> >> take your favorite IAR and dump it into your OpenSim Library,
> therefore
> >> making it available to all of your users.
> >>
> >> This sounds easy enough. Justin has the code for unarchiving IARs...
> >> except that it's all tangled up with Scenes. :-/
> >>
> >> The rule of thumb for reusability in the context of OpenSim is very
> >> easy: the region modules that come in OpenSim.Region.CoreModules.dll
> >> should be as thin as possible. They should only have enough meat to
> >> bridge between Scenes and whatever it is those modules actually do.
> >> "Whatever it is they do", for the most part, is relatively generic
> and
> >> should be factored out into their own dll, so that it can be reused
> >> from
> >> elsewhere that has nothing to do with scenes. Example: all the
> service
> >> connectors now can be reused out of the box by other tools to access
> >> remote OpenSim servers. (OpenSim.Service.Connectors.dll)
> >>
> >> Counter-Example: inventory archiving/dearchiving. From looking at
> that
> >> code, the only reason why the actual worker code needs the Scene
> object
> >> is to be able to get to IInventoryService and IAssetService. So...
> it
> >> should get those instead of Scene, and it should be factored out
> from
> >> Region.CoreModules, because inventory archiving/dearchiving is a lot
> >> more generic than a Scene utility.
> >>
> >> That way I could write this tool that I want in 4 hours reusing
> >> Justin's
> >> code as a dll, instead of having to copy-and-paste Justin&#

Re: [Opensim-dev] Designing with reusability in mind

[Frisby, Adam]

Re: Library

My thought was to have a directory where we can save .iar files - and the 
library is built from all the IARs in that directory at time the inventory 
server is started.

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of d...@metaverseink.com
> Sent: Wednesday, 9 December 2009 10:39 AM
> To: opensim-dev@lists.berlios.de
> Subject: [Opensim-dev] Designing with reusability in mind
> 
> In the same vein as Teravus' message about designing with
> instrumentation in mind...
> 
> I would like to ask for us to design with reusability in mind. Let's
> get
> out of the model that we are developing an application, and always
> think
> that we are developing components that can be used both for putting
> together an application that looks like SL, and for other applications
> as well.
> 
> Case in point: in the sequence of the conversation about free IARs,
> OARs, etc., I have been putting together a package with freebies. I
> thought about releasing it as an IAR, like everyone else is doing, but
> this has a problem: it requires operator access to the server -- not
> all
> users can take advantage of this free content.
> 
> Solution: let's use the underused OpenSim Library and add more stuff in
> there. No one has changed that part of OpenSim for ages! There's a good
> reason for it: adding content to it manually is a huge PITA and
> extremely error-prone. So, idea: let's take any IAR and write an
> external tool that converts it into the OpenSim Library format. That
> way
> different operators can provide different libraries very easily: just
> take your favorite IAR and dump it into your OpenSim Library, therefore
> making it available to all of your users.
> 
> This sounds easy enough. Justin has the code for unarchiving IARs...
> except that it's all tangled up with Scenes. :-/
> 
> The rule of thumb for reusability in the context of OpenSim is very
> easy: the region modules that come in OpenSim.Region.CoreModules.dll
> should be as thin as possible. They should only have enough meat to
> bridge between Scenes and whatever it is those modules actually do.
> "Whatever it is they do", for the most part, is relatively generic and
> should be factored out into their own dll, so that it can be reused
> from
> elsewhere that has nothing to do with scenes. Example: all the service
> connectors now can be reused out of the box by other tools to access
> remote OpenSim servers. (OpenSim.Service.Connectors.dll)
> 
> Counter-Example: inventory archiving/dearchiving. From looking at that
> code, the only reason why the actual worker code needs the Scene object
> is to be able to get to IInventoryService and IAssetService. So... it
> should get those instead of Scene, and it should be factored out from
> Region.CoreModules, because inventory archiving/dearchiving is a lot
> more generic than a Scene utility.
> 
> That way I could write this tool that I want in 4 hours reusing
> Justin's
> code as a dll, instead of having to copy-and-paste Justin's code and
> purge it from all references to Scene. I would simply need to provide
> my
> own implementation of IInventoryService and IAssetService that would
> write things in bin/assets and bin/inventory instead of sending them to
> a server.
> 
> The general request is this: let's not hide useful code under
> OpenSim.Region.*, which are components that only make sense for the
> live
> VW server. There's so many more tools/applications that can be done
> around it! -- let's not hide good code under there, where it can never
> be reused.
> 
> Crista / Diva
> 
> ___
> 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] FOSDEM 2010 Mono Developer Room CFP

[Frisby, Adam]

Since it's in Europe - I think there's probably at least a few of the devs who 
could attend.

Adam

From: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of BlueWall Slade
Sent: Monday, 7 December 2009 10:00 PM
To: opensim-dev@lists.berlios.de
Subject: [Opensim-dev] FOSDEM 2010 Mono Developer Room CFP

Mono developers room talk registration for developers to give talks about their 
projects developed on Mono

http://tirania.org/blog/archive/2009/Dec-02.html
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Mumble & Voice

[Frisby, Adam]

*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

Re: [Opensim-dev] [Opensim-users] OpenSim turns Three

[Frisby, Adam]

You get some of the blame too! =p

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Melanie
> Sent: Wednesday, 2 December 2009 1:23 PM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] [Opensim-users] OpenSim turns Three
> 
> Yeah, go on blame John. Everyone does, lately :)
> 
> Melanie
> 
> Frisby, Adam wrote:
> > I'd say some celebrations are in order definitely. It's pretty rare
> for an OSS project to maintain such momentum over a period as long -
> and the last 6 months have really begun to stabilise the codebase in a
> serious way (I blame John.).
> >
> > Adam
> >
> > From: opensim-users-boun...@lists.berlios.de [mailto:opensim-users-
> boun...@lists.berlios.de] On Behalf Of Stefan Andersson
> > Sent: Wednesday, 2 December 2009 12:37 PM
> > To: opensim-dev@lists.berlios.de; opensim-us...@lists.berlios.de
> > Subject: [Opensim-users] OpenSim turns Three
> >
> > 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
> ___
> 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-users] OpenSim turns Three

[Frisby, Adam]

I'd say some celebrations are in order definitely. It's pretty rare for an OSS 
project to maintain such momentum over a period as long - and the last 6 months 
have really begun to stabilise the codebase in a serious way (I blame John.).

Adam

From: opensim-users-boun...@lists.berlios.de 
[mailto:opensim-users-boun...@lists.berlios.de] On Behalf Of Stefan Andersson
Sent: Wednesday, 2 December 2009 12:37 PM
To: opensim-dev@lists.berlios.de; opensim-us...@lists.berlios.de
Subject: [Opensim-users] OpenSim turns Three

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] Designing with Instrumentation in mind.

[Frisby, Adam]

I recently had the same idea - I started implementing the new MonitorModule in 
core, it should be pretty easy to extend with new instrumentation. The only 
gotcha is I have every instrument return a 'double' value so we can easily 
chart it externally (and make easy comparisons).

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Teravus Ovares
> Sent: Friday, 27 November 2009 6:10 PM
> To: opensim-dev@lists.berlios.de
> Subject: [Opensim-dev] Designing with Instrumentation in mind.
> 
> Hey there,
> 
> A while back, we had somewhat reasonable statistics being generated
> and presented to the client.They were not always accurate, but
> based on what I saw, I could, pretty much pin certain parts of the
> simulator as the limiting factor during load tests.  I'd say, the
> number 1 reason that they were semi-accurate and not accurate..  in
> the past..   is because nobody ever thought about instrumentation
> during the functionality design. It was always 'tacked on later'.
>   One example of this..is the current AssetCache implementation.
>   There's no way, currently, to know, at a glance..   how many
> external requests it has open.   Additionally, it will be extremely
> difficult to put one in because of the way the objects are designed
> and accessed.  To put one in, an event needs to be added to the
> IAssetService interface and each AssetCache implementation will need
> an interlocked int to count how many gets and puts it currently has
> open to the external data source as well as it's own event calling
> schedule.   Then, the IAssetService property in Scene, (AssetService)
> will need an event handler..   which updates the values in
> SimStatsReporter in Scene (StatsReporter).   This idea of external
> access resource instrumentation should really have been built in to
> the design of the AssetService.
> 
> This last recent load test, there were no real statistics that I could
> use to determine what the limiting factor was.
> Time Dilation was pegged at 1.0..even when the simulator was
> obviously struggling.Total Frame time (MS) was -50ms even when the
> simulation MS was 850ms and the Physics ms was 250ms, so the
> inconsistencies made it impossible to know what part of the simulator
> was struggling.  Agent Updates were erratic..   sometimes high..
> sometimes low when the simulator was fine and when it was struggling.
> Pending Uploads and Downloads were always 0, so there was no way to
> know how well the simulator was downloading and uploading assets to
> and from the grid.   Packet stats were non-existant, so there was no
> way to know how well the UDP handlers were faring under the load.
> When it crashed, it crashed with a mono based stack trace which
> pointed to out of memory errors, so the only way that you could,
> scientifically, find out what the issue is..   is to run a load test
> under a memory profiler. We know, that running a public load test
> under a memory profiler is quite impractical.
> 
> To make something better, I need to know two things, where it is, and
> where I want it to be.How can we make OpenSimulator better if we
> don't have statistics that point to where we are currently?
> 
> On that note, I propose that, when designing objects for functionality
> in OpenSimulator, that we also consider if the objects should be
> instrumented and, what would be the best way to go about instrumenting
> the objects.  We should incorporate instrumentation into the design of
> the objects.   Some of that instrumentation is appropriate for a
> client to see, some of it might not be.   Consider that, many of them
> should be client facing and be included in the SimStats that get sent
> to the client..so that we can have a reasonable idea of what's
> going on with a simulator at a glance.   Also, in the design of the
> instrumentation, we make sure that the instrumentation is accurate and
> lightweight.
> 
> The load test went reasonably...  but, we didn't get half of the
> information on the simulator that we needed to be able to improve it.
> 
> 
> Please comment :) I look forward to hearing your responses.
> 
> Regards
> 
> Teravus
> ___
> 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] Any objections to starting the OpenSim 0.6.8 release process?

[Frisby, Adam]

What is missing right now?

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Teravus Ovares
> Sent: Tuesday, 24 November 2009 2:42 PM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] Any objections to starting the OpenSim 0.6.8
> release process?
> 
> I'm definitely OK with 0.6.8 RC1 being tagged now.   The only thing
> that I'm hesitant about with 0.7 is..  Meldiva wanted to have all
> services on ROBUST before 0.7 was released.
> 
> Regards
> 
> Teravus
> 
> On Tue, Nov 24, 2009 at 5:24 PM, Frisby, Adam 
> wrote:
> > I would like to start the ball rolling about tagging 0.7 soon. It's
> been
> > well over a year since 0.6 was tagged, and a huge number of
> improvements. If
> > we're averse to hitting 1.0, let's go to 0.25 if we have to, but I
> think
> > with all the services now running under ROBUST and the wealth of
> features in
> > trunk right now, 0.7 is the way to go.
> >
> >
> >
> > Adam
> >
> >
> >
> > From: opensim-dev-boun...@lists.berlios.de
> > [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of orion hax
> > Sent: Tuesday, 24 November 2009 2:20 PM
> > To: opensim-dev@lists.berlios.de
> > Subject: Re: [Opensim-dev] Any objections to starting the OpenSim
> 0.6.8
> > release process?
> >
> >
> >
> > been very well for all my sims +1.
> >
> > On Tue, Nov 24, 2009 at 4:06 PM, Michael Cerquoni
> 
> > wrote:
> >
> > I think its a good idea, i have gotten wide spread reports of better
> > stability and uptimes. +1
> >
> >
> >
> > On Tue, Nov 24, 2009 at 1:37 PM, Justin Clark-Casey
> >  wrote:
> >
> > Hi folks,
> >
> > It seems that we've reached a good level of stability after the most
> recent
> > set
> > of changes and fixes.
> >
> > Therefore, I'd like to start the ball rolling on releasing OpenSim
> 0.6.8.
> >  As
> > happened with 0.6.7, I think that we should branch from git master
> sometime
> > in
> > the next few days and spend a week or so testing the release
> candidate for
> > super-critical show-stopping failures before making it official.
> >
> > I think that 0.6.8 will be considerably better than 0.6.7 due to the
> many
> > recent
> > stability fixes.  Therefore, I'm keen to see the production of
> > installers/binaries this time so any help in this area would be great
> when
> > the
> > time comes.
> >
> > The major configuration change for 0.6.8 is the addition of the grid
> service
> > to
> > the ROBUST framework (making the user service the only remaining
> hardcoded
> > standalone grid service executable).  I intend to update the existing
> > configuration documentation to reflect this and hopefully improve it
> a bit,
> > even
> > if such documentation may be rewritten soon.
> >
> > I documented this lightweight release process at
> >
> > http://opensimulator.org/wiki/Release_Cycle
> >
> > Any thoughts about making a release at this time?
> >
> > --
> > Justin Clark-Casey (justincc)
> > http://justincc.org
> > http://twitter.com/justincc
> > ___
> > 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 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] Any objections to starting the OpenSim 0.6.8 release process?

[Frisby, Adam]

I would like to start the ball rolling about tagging 0.7 soon. It's been well 
over a year since 0.6 was tagged, and a huge number of improvements. If we're 
averse to hitting 1.0, let's go to 0.25 if we have to, but I think with all the 
services now running under ROBUST and the wealth of features in trunk right 
now, 0.7 is the way to go.

Adam

From: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of orion hax
Sent: Tuesday, 24 November 2009 2:20 PM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Any objections to starting the OpenSim 0.6.8 release 
process?

been very well for all my sims +1.
On Tue, Nov 24, 2009 at 4:06 PM, Michael Cerquoni 
mailto:nebadon2...@gmail.com>> wrote:
I think its a good idea, i have gotten wide spread reports of better stability 
and uptimes. +1

On Tue, Nov 24, 2009 at 1:37 PM, Justin Clark-Casey 
mailto:jjusti...@googlemail.com>> wrote:
Hi folks,

It seems that we've reached a good level of stability after the most recent set
of changes and fixes.

Therefore, I'd like to start the ball rolling on releasing OpenSim 0.6.8.  As
happened with 0.6.7, I think that we should branch from git master sometime in
the next few days and spend a week or so testing the release candidate for
super-critical show-stopping failures before making it official.

I think that 0.6.8 will be considerably better than 0.6.7 due to the many recent
stability fixes.  Therefore, I'm keen to see the production of
installers/binaries this time so any help in this area would be great when the
time comes.

The major configuration change for 0.6.8 is the addition of the grid service to
the ROBUST framework (making the user service the only remaining hardcoded
standalone grid service executable).  I intend to update the existing
configuration documentation to reflect this and hopefully improve it a bit, even
if such documentation may be rewritten soon.

I documented this lightweight release process at

http://opensimulator.org/wiki/Release_Cycle

Any thoughts about making a release at this time?

--
Justin Clark-Casey (justincc)
http://justincc.org
http://twitter.com/justincc
___
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 mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] New Website (was "Leaving Project")

[Frisby, Adam]

OK, last thing - I know everyone is complaining about the website. 

Infact the core devs (specifically me & Melanie) spent some time last weekend 
setting up a new website - it is not done yet however; but we'll be seeking 
people to submit documentation & articles - if you have any of the following, 
please send me (a...@deepthink.com.au) the text + images for inclusion.

- Use cases ("We at  are using OpenSim for , these are the features we 
use , , ... OpenSim works well for this because of .")
- Screenshots & Multimedia
- Documentation - full format 'HOWTO' articles, and the versions those articles 
are compatible against.
- Technical References - "Component Foo works like this".
- Developer Tutorials (building & programming)

If you have any of the above you want to contribute, please send them to me - 
with the usual disclaimer that the final content on the site is at the whims of 
the core developers.

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Kyle Hamilton
> Sent: Monday, 23 November 2009 3:46 PM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] Leaving Project
> 
> I've already explained the futility of the concept of "trade secret"
> protection when LL already released the viewer code, and the
> specifications for connecting to a server -- they told the secret,
> themselves, and to be a trade secret first something must be secret.
> The only thing they can claim is copyright protection, and since
> there's no means of automatedly transforming C++ code into C# code
> there's no transformation without reinterpretation and recreation,
> thus preventing any copyright claim from succeeding.  (I am not a
> lawyer, but I've read Eben Moglen's essays.  You know, the general
> counsel for the FSF?)
> 
> -Kyle H
> 
> On Mon, Nov 23, 2009 at 8:43 AM, Fly Man 
> wrote:
> > Adam,
> >
> > You hit the nail right on his head with this passage:
> >
> > The big problem here is there’s a very real lack of viewer developers
> in
> > this community – there is some overlap between server & network
> engineers
> > (like the OS community) and 3D Viewer Developers here, but not much.
> If we
> > do have 3D devs in the community who haven’t done anything and feel
> like
> > contributing – you really should be talking to some of the ‘next gen
> viewer’
> >  projects and seeing if we can get something awesome done faster.
> >
> > And maybe someone should explain WHY people won't burn their hands on
> the
> > viewer
> >
> > Main reason: There's a clausule on the Website and internally about
> "Look at
> > viewer code, and there's 6 months no working on OpenSim"
> >
> > So any person that would like to keep working on OpenSim doesn't look
> at
> > viewer code, and vice versa.
> >
> > That's about the main reason that some viewer developers won't co-
> operate
> > with OpenSim and the other way, developers from OpenSim can't help
> viewer
> > developers
> >
> > But that's just my 2 cents about that passage.
> >
> > ___
> > 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] Leaving Project

[Frisby, Adam]

The problem is recreation & reinterpretation may not be copyright-transfer 
free. 

Looking at the code, then reimplementing the mechanism may trans-include the 
copyright on the original into the new implementation. 

We've had umpteen different lawyers look into this problem for us and they all 
pretty much say the same thing. "Ask Linden Lab for an indemnification against 
this or don't look at the viewer code for 3-6 months when moving projects." - 
we did the first, they said no, so we're doing the second. 

Unless you can get a qualified lawyer to say otherwise, that's the way the 
policy is going to stay.

Regards,

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Kyle Hamilton
> Sent: Monday, 23 November 2009 3:46 PM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] Leaving Project
> 
> I've already explained the futility of the concept of "trade secret"
> protection when LL already released the viewer code, and the
> specifications for connecting to a server -- they told the secret,
> themselves, and to be a trade secret first something must be secret.
> The only thing they can claim is copyright protection, and since
> there's no means of automatedly transforming C++ code into C# code
> there's no transformation without reinterpretation and recreation,
> thus preventing any copyright claim from succeeding.  (I am not a
> lawyer, but I've read Eben Moglen's essays.  You know, the general
> counsel for the FSF?)
> 
> -Kyle H
> 
> On Mon, Nov 23, 2009 at 8:43 AM, Fly Man 
> wrote:
> > Adam,
> >
> > You hit the nail right on his head with this passage:
> >
> > The big problem here is there’s a very real lack of viewer developers
> in
> > this community – there is some overlap between server & network
> engineers
> > (like the OS community) and 3D Viewer Developers here, but not much.
> If we
> > do have 3D devs in the community who haven’t done anything and feel
> like
> > contributing – you really should be talking to some of the ‘next gen
> viewer’
> >  projects and seeing if we can get something awesome done faster.
> >
> > And maybe someone should explain WHY people won't burn their hands on
> the
> > viewer
> >
> > Main reason: There's a clausule on the Website and internally about
> "Look at
> > viewer code, and there's 6 months no working on OpenSim"
> >
> > So any person that would like to keep working on OpenSim doesn't look
> at
> > viewer code, and vice versa.
> >
> > That's about the main reason that some viewer developers won't co-
> operate
> > with OpenSim and the other way, developers from OpenSim can't help
> viewer
> > developers
> >
> > But that's just my 2 cents about that passage.
> >
> > ___
> > 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] Leaving Project

[Frisby, Adam]

"OpenSim is not Second Life, is not intended to be like Second Life, nor ever 
will."

I'll repeat that - most (all?) of the core devs will too. The Second Live 
viewer is convenient - since the protocol is documented and it gives us a good 
feature base to start with; but it's not the be-all-and-end-all. OpenSim is 
more like a series of tubes - events & inputs go in one direction, get mashed 
around in the modules, then spat back out other tubes to be sent to clients. 
Second Life compatibility modules are definitely well numbered - but 
internally, we're not really aiming for a SL wannabe-world simulator.

SL compatibility is the most prominent use of this - since there's been a lot 
of people interested in that; but Rock's original complaints are exactly spot 
on the mark - sticking to the SL feature set is a complete waste of time. SL's 
technology is dated - LL's inability to implement modern 3D graphics standards 
is going to bite them in the arse over the next few years.

This is where OpenSim's internal commitment to moving towards things like 
IClientCore over IClientAPI - means we'll be supporting more advanced viewers 
as time goes on, and those are developed. I've got my eye personally on the Rex 
Naali project, even if it is 12 months away from having something user-friendly.

But that ultimately said; right now there is pretty much nothing stopping you 
from building a kickass viewer with say the UDK, hooking up a decent 
clientstack and running with it (see the MXP implementation for a good example 
on how to implement a foreign clientstack using another viewer's protocol). I 
know some people have been doing just that with Unity lately.

The big problem here is there's a very real lack of viewer developers in this 
community - there is some overlap between server & network engineers (like the 
OS community) and 3D Viewer Developers here, but not much. If we do have 3D 
devs in the community who haven't done anything and feel like contributing - 
you really should be talking to some of the 'next gen viewer' projects and 
seeing if we can get something awesome done faster.

Regards,

Adam

From: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Len Brown
Sent: Monday, 23 November 2009 5:07 AM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Leaving Project

Rock,

 I sympathize with you on many levels.  I've also had my doubts regarding 
the future of OpenSim, but I have also maintained some degree of faith that 
things will pull through in the end.

 For me the shock came when I was abruptly informed that "OpenSim is not 
Second Life, is not intended to be like Second Life, nor ever will."  I still 
haven't the foggiest idea what this developer had smoked for them to so 
strongly assert that incredibly false statement.

 For me, the enjoyment of OpenSim has come from my intense devotion to 
building and skinning.  In fact, for the last few months I've been working on a 
full region that has many hundreds of skins, clothes, hair, furniture, etc, 
etc, that I'd like to package up as an OAR and give out freely, since 
repeatedly I've been told that instead of giving money to help further OpenSim 
I'd do more proactively by giving content.  So I plan to do just that and give 
my money to other open source initiatives that matter to me.

 I have a passion for writing, and have thought many times that one of the 
greatest powers OpenSim would gain is having simple, straightforward, 
step-by-step instructions on how to download, compile, install, administer and 
overall just plain operate the core applications.  What kills me is that 
everyone who does a search for OpenSim inevitably hits the 
opensimulator.org site and that is where the massive 
roadblock presents itself.  It's useless for most and irrelevant to the few who 
consider themselves OpenSim experts.

 Heck, even now on the configuration page it still displays info for 0.6.6 
including (months old) known bugs in setting up region xml files.  If there was 
appointed a volunteer whose sole job was to keep information on 
opensimulator.org relevant that one task would 
resolve a mountain of negativity right there.  I sit here in front of my 
computers a good 10 to 12 hours a day.

 I would sincerely love to contribute to the OpenSim project, especially in 
documentation support.  But the thing holding me back is communication.  If I 
cannot get a straight answer on who to GIVE money to in order to help, then I 
stand little chance of getting clear, straight answers from developers when 
asking about issues I need to consider and incorporate in documentation.

 If communication is a hurdle we can all overcome, with a genuine and 
heart-felt effort to relay information, motives, and plans with one another, 
then I'd sincerely appreciate having the opportunity to personally contribute.  
I'm not a programm

Re: [Opensim-dev] how to get hold of OpenSimBase

[Frisby, Adam]

You need to build a special type of module called an ApplicationModule - they 
aren't used that much so the documentation is a little lacking; but take a look 
at the RemoteAdminModule for an example of a AppModule.

Adam

From: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Olli Aro
Sent: Wednesday, 28 October 2009 3:32 PM
To: opensim-dev@lists.berlios.de
Subject: [Opensim-dev] how to get hold of OpenSimBase

Hi,

Does anyone know if it is possible to get hold of OpenSimBase somehow from a 
region module or if I need to build a plugin instead?

Regards,

Olli


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

Re: [Opensim-dev] The notion of "core"

[Frisby, Adam]

OK, since I have a nagging feeling no-one read Teravus's original post in this 
long thread (and with a hope of putting this to rest).

There are guidelines for the -core list, which are the following: 
If the topic can be discussed on dev, it should be. Core's scope is limited to 
issues related to commit access, licensing, money, server administrator and 
other 'meta' issues relating to running the project. No-one on dev is missing 
out on any development or code related discussion. Membership is limited to 
active committers (min. one commit in last 6 mo to maintain commit access & ML 
access). 'Votes' are done on consensus with any committer having full veto 
power.

That said, DSVC is not a panacea to programming. Git is better than SVN at 
merging files; but it's still not excellent - Melanie puts in a ton of work 
each week in managing our various branches and bringing them together, 
conflicts and all. 

Until someone realises that DSVC needs to include language specific patterns 
(such as refactorings), there is still going to need to be a core project at 
the middle making sure the base works, and still a bunch more people who can 
update branches & forks accordingly. Otherwise maintaining distributions 
becomes an effort in trying to hit moving targets.

Since it'll probably satisfy some of the people who are curious about what is 
discussed on core, here's the last 10 threads. (this represents probably 3-5 
months of traffic, as I said before, it's low volume.) - as you can see, they 
all do fall into the guidelines listed above.

Last 10 threads on opensim-core:
1. Snowcrash's contributions - whether his eclectic license on SCEngine affects 
contributions to opensim master and specifically whether to accept patches 
relating to it. (Licensing.)
2. Mantis stopped sending emails, can someone look?
3. Where is the CS2JK license?
4. Forwarded a request for a spokesperson to speak to someone studying OSS 
communities.
5. Stefan announcing his resignation (cc:'d to dev)
6. JHurliman commit access [redux]?
7. Sean changing projects at IBM, resignation.
8. JHurliman commit access?
9. Request for moderator access on the wiki.
10. Vote on go/no-go on git after trial.

Regards,

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Dr Scofield
> Sent: Tuesday, 20 October 2009 6:50 AM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] The notion of "core"
> 
> 
> Edward Middleton wrote:
> > Teravus Ovares wrote:
> >> ... Your argument was that the advent of the distributed source
> control
> >> system made the 'commit right vote' obsolite, ...
> >
> > My point was that,  with a DVCS, "commit rights" are really just the
> > right to release manage the official repository.
> 
> right. opensim-core is just a bunch of dudes and dudettes that manage
> the
> official repository.
> 
>   DrS
> 
> --
> dr dirk husemann  virtual worlds research  ibm zurich research
> lab
> SL: dr scofield  drscofi...@xyzzyxyzzy.net 
> http://xyzzyxyzzy.net/
> RL: h...@zurich.ibm.com - +41 44 724 8573 -
> http://www.zurich.ibm.com/~hud/
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] The notion of "core"

[Frisby, Adam]

I disagree.

* Commit Rights - those discussions cannot occur in public (although the 
discussion archives are open to committers after being invited), the reason for 
this is no-one can be frank & honest without hurting people's feelings.

---
>From the excellent F/OSS guidebook: 
>http://producingoss.com/en/consensus-democracy.html#electorate
"The voting system itself should be used to choose new committers, both full 
and partial. But here is one of the rare instances where secrecy is 
appropriate. You can't have votes about potential committers posted to a public 
mailing list, because the candidate's feelings (and reputation) could be hurt. 
Instead, the usual way is that an existing committer posts to a private mailing 
list consisting only of the other committers, proposing that someone be granted 
commit access. The other committers speak their minds freely, knowing the 
discussion is private. Often there will be no disagreement, and therefore no 
vote necessary. After waiting a few days to make sure every committer has had a 
chance to respond, the proposer mails the candidate and offers him commit 
access. If there is disagreement, discussion ensues as for any other question, 
possibly resulting in a vote. For this process to be open and frank, the mere 
fact that the discussion is taking place at all should be secret
 . If the person under consideration knew it was going on, and then were never 
offered commit access, he could conclude that he had lost the vote, and would 
likely feel hurt. Of course, if someone explicitly asks for commit access, then 
there is no choice but to consider the proposal and explicitly accept or reject 
him. If the latter, then it should be done as politely as possible, with a 
clear explanation: "We liked your patches, but haven't seen enough of them 
yet," or "We appreciate all your patches, but they required considerable 
adjustments before they could be applied, so we don't feel comfortable giving 
you commit access yet. We hope that this will change over time, though." 
Remember, what you're saying could come as a blow, depending on the person's 
level of confidence. Try to see it from their point of view as you write the 
mail."
---

I personally suggest reading that whole chapter (#4) for reasons why a lot of 
projects have a committers mailing list (and yes it is a standard practice.)

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Ryan McDougall
> Sent: Monday, 19 October 2009 9:33 PM
> To: opensim-dev@lists.berlios.de
> Subject: [Opensim-dev] The notion of "core"
> 
> On Tue, Oct 20, 2009 at 2:49 AM, Frisby, Adam 
> wrote:
> > Ter pretty much summed it up - both it and the irc channel are fairly
> low-volume, and the 'topic' is restricted to only 'personal' or 'meta'
> matters; such as discussion of approval of commit rights.
> >
> > It's pretty standard practice across open source projects with more
> than 5 committers for the committers to have a mailing list for these
> purposes, since realtime chats aren't practical across timezones.
> >
> > Adam
> >
> 
> I am not sure I'd agree just how standard a process it is.
> 
> The one's I've been involved with or otherwise have some detailed
> knowledge of, have never had them; including such big names as GNOME,
> Fedora, and Linux. For example the GNOME foundation list is not only
> world-readable, but anyone can join:
> http://mail.gnome.org/mailman/listinfo/foundation-list . Actual
> foundation members are voted by the community at large.
> 
> Basically the way they are able to operate is, they don't distribute
> commit access according to monolithic vote of knighted members; they
> have a system of maintainership, and each maintainer gives access
> rights to his module/repo as she sees fit, in a web of trust.
> 
> One of the complaints one sometimes hears is how monolithic the
> project is (even if the code-base is modular). Maybe the move to git,
> and the maturation of the code allows more distribution and
> specialization of responsibility?
> 
> My concerns with core mailing list are:
> 
> 1. It's "secret", ie. not world readable. I can understand limiting
> membership to voting partners to avoid bikeshedding, but I can't
> understand secrecy of any kind in an open source project.
> 
> 2. Decisions made there (aside from commit rights) affect other
> people, and they not only have no voice to represent themselves, they
> don't even get to know what is being said about them. That doesn't
> seem fair somehow.
> 
> The knowledge that someone can read what you write makes y

Re: [Opensim-dev] [opensim-core] snowcrash's contributions

[Frisby, Adam]

Ter pretty much summed it up - both it and the irc channel are fairly 
low-volume, and the 'topic' is restricted to only 'personal' or 'meta' matters; 
such as discussion of approval of commit rights. 

It's pretty standard practice across open source projects with more than 5 
committers for the committers to have a mailing list for these purposes, since 
realtime chats aren't practical across timezones.

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Teravus Ovares
> Sent: Monday, 19 October 2009 12:22 PM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] [opensim-core] snowcrash's contributions
> 
> As far as there being opensim-core, yes.  It exists.   As far as it
> being Secret..   it's not ..Nor it it intended to be secret.
> It's been discussed before on IRC and in previous e-mail on
> opensim-dev.   It has OpenSimulator core as it's members.
> 
> It has a purpose as well,
> Just to be clear:
> 
> * The core list is a list where interpersonal and political issues
> between the core developers are discussed.   Despite how it may
> appear, we don't always agree on everything or even like each other
> from time to time.  We would prefer to keep this interpersonal drama
> from distracting development.
> 
> * The core list is also where core actions are decided upon, like
> voting on a new user's entry into core
> 
> * We also discuss opensimulator.org server configurations (like using
> git for our repository)
> 
> * Discussing the Development of OpenSimulator, however, is not
> appropriate in opensim-core.  That's what opensim-dev is for.
> 
> We also have a core IRC channel #opensim-core on freenode where the
> same rules apply.
> 
> Regards
> 
> Teravus
> 
> On Mon, Oct 19, 2009 at 2:59 PM, Nebadon Izumi 
> wrote:
> > there is no secret mailing list, i don't know what he is talking
> about I
> > suspect that email came from the opensim-users email list.  Lets not
> keep
> > feeding this thread, Crista asked everyone to ignore it. so lets not
> have
> > this blow up, its not related to OpenSimulator development.
> >
> > On Mon, Oct 19, 2009 at 11:54 AM, Kyle G 
> wrote:
> >>
> >> There's a secret mailing list to discuss such issue? Wow. That's
> >> interesting.  I feel like Ryan now too.
> >>
> >> -Original Message-
> >> From: opensim-dev-boun...@lists.berlios.de
> >> [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Ryan
> McDougall
> >> Sent: Monday, October 19, 2009 2:26 PM
> >> To: opensim-dev@lists.berlios.de
> >> Subject: Re: [Opensim-dev] [opensim-core] snowcrash's contributions
> >>
> >> On Mon, Oct 19, 2009 at 8:30 PM, Cristina Videira Lopes
> >>  wrote:
> >> > dr scofield wrote:
> >> >
> >> > to me this is another piece from the legal FUD department
> (reminiscent
> >> > of the "money" discussions).
> >> >
> >> >
> >> > It's very easy to brush difficult issues under the rug of "I don't
> care,
> >> > this is ethics, not technical, hence it's FUD". You're entitled to
> that
> >> > stand. Give your -1 on whatever is being proposed and stay out of
> the
> >> > rest
> >> > of the conversation, instead of trying to "FUD the FUD." Some of
> us care
> >> > about these difficult issues. Having a co-copyright holder who
> releases
> >> > an
> >> > addon to opensim under a discriminatory license (in this case
> based on
> >> > country, but could be based on race, gender, sexual
> orientation,...) is
> >> not
> >> > something some of us can ignore. Unclear if/what we should do
> about it,
> >> but
> >> > clear that this is bugging a lot of people, not just core devs,
> and
> >> > hence
> >> it
> >> > should be discussed not ignored.
> >> >
> >> > Crista
> >>
> >> Nationality, or more to the point of the clause, political
> >> disposition, can be changed; unlike race or gender -- which is the
> >> kind of the point, to make a political stand in the face of
> potential
> >> human catastrophe. :D
> >>
> >> Have I mentioned that I'm not a fan of the secret mailing list? ...
> >> Here I am feeling like a member of a community, but largely without
> >> voice on the crucial matter of eccentric licenses(?)! :P
> >>
> >> 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
> >
> >
> >
> > --
> > 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/mailma

Re: [Opensim-dev] VNC on CLient

[Frisby, Adam]

Usual warning - please don’t link to anything involving viewer sourcecode on 
this list due to the problematic licensing conditions. (ie if you plan to 
submit patches to OpenSim, don’t go look at viewer code please)

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Mike Dickson
> Sent: Sunday, 18 October 2009 7:25 AM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] VNC on CLient
> 
> On Sun, 2009-10-18 at 13:08 +, André Filipe wrote:
> >
> >
> > I`d like to know HOW TO do it... the video shows the results of it.
> >
> >
> http://wiki.secondlife.com/wiki/Media_Rendering_Plugin_Framework
> 
> 
> Mike
> 
> 
> 
> 
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] open sim UUID and Passwordhash

[Frisby, Adam]

Seconded. There are other weak points which could be more easily addressed at 
the current point in time; but I do expect many of those to finally get ironed 
out.

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of d...@metaverseink.com
> Sent: Friday, 16 October 2009 9:22 AM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] open sim UUID and Passwordhash
> 
> The usual warning, I'm a broken record:
> there is very little security in open OpenSim grids right now.
> 
> Daniel Smith wrote:
> >
> > Not the best place to go over crypto 101, but for those unfamiliar
> with
> > the insecurity of md5("password") by itself, you owe yourself a visit
> to
> > some place like http://www.md5crack.com/crackmd5.php.  It'll open
> your
> > eyes quickly.
> >
> > Try "20ee80e63596799a1543bc9fd88d8878"  -- it's ok, just a rabbit.
> Not
> > my password.
> >
> > The point that others here are making about salt is pretty valid
> > (incoming IP address + timestamp + username can be a good start).
> > You'll have to store the salt somewhere, because you'll never get the
> > same one again, and you'll need to add it to the users incoming pw to
> > hash again and compare...
> >
> > And +1 to Adam's comment on transmission and storage requirements.
> Not
> > addressing security 101 will leave you with a site incapable of
> > transmitting anything (or much worse..)
> >
> > Daniel
> >
> > --
> > Daniel Smith - Sonoma County, California
> > http://daniel.org/resume
> >
> >
> > -
> ---
> >
> > ___
> > 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] open sim UUID and Passwordhash

[Frisby, Adam]

Technically, the client only mandates the first MD5.

It is possible for us to consider SHA256(MD5() . ':' . salt) instead.

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Dr Scofield
> Sent: Friday, 16 October 2009 8:20 AM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] open sim UUID and Passwordhash
> 
> 
> Alan M Webb wrote:
> >
> > If everyone is really concerned about security, then perhaps we
> should
> > stop using MD5?
> 
> ;-) who's going to tell the LL clients that?
> 
>   cheers,
>   DrS/dirk
> 
> 
> >
> > Best regards
> > Alan
> > ---
> > T.J. Watson Research Center, Hawthorne, NY
> > 1-914-784-7286
> > alan_w...@us.ibm.com
> >
> >
> > From:   "Frisby, Adam" 
> > To: "opensim-dev@lists.berlios.de"  d...@lists.berlios.de>
> > Date:   10/16/2009 09:06 AM
> > Subject:Re: [Opensim-dev] open sim UUID and Passwordhash
> >
> >
> > -
> ---
> >
> >
> >
> > Just because other software may do it wrong does not mean it is
> secure.
> >
> > Drupal using a plain MD5 is alarming – since it allows for very quick
> > plain lookups in existing databases (no need to calculate the
> dictionary
> > + permuation with your fixed salt). Storing a custom salt for each
> user
> > is essential if you wish to make dictionary attacks significantly
> more
> > expensive. (Actually it also allows for plain collision attacks too.)
> >
> > Consider this case:
> > · Calculate Every Permutation of the Dictionary plus a couple
> of
> > common modifications, plus your fixed salt. (this will get ~80%+ of
> user
> > passwords).
> > Versus
> > · Do the above, but for each user – since the salt is
> changing
> > per user.
> >
> > The second will take ‘n’ times longer to calculate (where N is
> > equivalent to the size of your database), it also works in the
> inverse –
> > if you have a 10 million user database, it means you need
> 1/10millionth
> > of the time to try calculate a valid hit. It adds up. Bigtime.
> >
> > A unique hash for the whole application helps against global world-
> wide
> > MD5 databases, but it still does not help the above situation.
> >
> > Frankly the storage and transmission size arguments are complete
> bunk.
> > We are talking 128-bits extra data per user for a good salt which
> adds
> > up to about ‘jack shit’ when summed over the lifetime of the
> > application. It takes very little extra time, and we already stuff
> that
> > data into our default database schemas.
> >
> > Likewise, having a long salt versus a short salt makes very little
> > difference – because it’s the uniqueness that counts (see the two
> cases
> > above.)
> >
> > Short summary of the above: Do it if you have any desire to follow
> good
> > security practices with your users. It takes almost no extra time and
> > gives you appreciable benefits.
> >
> > Adam
> >
> > *From:* opensim-dev-boun...@lists.berlios.de
> > [mailto:opensim-dev-boun...@lists.berlios.de] *On Behalf Of *Impalah
> > Shenzhou*
> > Sent:* Friday, 16 October 2009 4:37 AM*
> > To:* opensim-...@lists.berlios.de*
> > Subject:* Re: [Opensim-dev] open sim UUID and Passwordhash
> >
> > Thanks for the info Melanie.
> >
> > Adam, I consider Drupal, for example, a CMS with a decent security
> and
> > it only uses md5(plain_password) to store user passwords. Some php
> > frameworks (for example Code Igniter, Cake php...) use, but not
> > mandatory, an unique hash for all the application.
> >
> > A random hash for every user improves security, you're right, but
> > increases the data sent between DB and servers for every
> authentication.
> > I prefer not to overload data transmission for something I think is
> > overprotection. Maybe for 10 or 100 users there won't be no problems,
> > but think on 1 and each byte will count (they aren't cheap).
> >
> > If you have a long, secret and unique hash for your servers, who can
> > make an effective attack to you (at least in reasonable time)?
> >
> > Maybe the difference could be that Drupal used to be deployed over
> > Apache, and it can be protected against dictionary attacks activating
> > some modules, while Opensim/

Re: [Opensim-dev] open sim UUID and Passwordhash

[Frisby, Adam]

Just because other software may do it wrong does not mean it is secure.

Drupal using a plain MD5 is alarming - since it allows for very quick plain 
lookups in existing databases (no need to calculate the dictionary + permuation 
with your fixed salt). Storing a custom salt for each user is essential if you 
wish to make dictionary attacks significantly more expensive. (Actually it also 
allows for plain collision attacks too.)

Consider this case:

· Calculate Every Permutation of the Dictionary plus a couple of common 
modifications, plus your fixed salt. (this will get ~80%+ of user passwords).
Versus

· Do the above, but for each user - since the salt is changing per user.

The second will take 'n' times longer to calculate (where N is equivalent to 
the size of your database), it also works in the inverse - if you have a 10 
million user database, it means you need 1/10millionth of the time to try 
calculate a valid hit. It adds up. Bigtime.

A unique hash for the whole application helps against global world-wide MD5 
databases, but it still does not help the above situation.

Frankly the storage and transmission size arguments are complete bunk. We are 
talking 128-bits extra data per user for a good salt which adds up to about 
'jack shit' when summed over the lifetime of the application. It takes very 
little extra time, and we already stuff that data into our default database 
schemas.

Likewise, having a long salt versus a short salt makes very little difference - 
because it's the uniqueness that counts (see the two cases above.)

Short summary of the above: Do it if you have any desire to follow good 
security practices with your users. It takes almost no extra time and gives you 
appreciable benefits.

Adam

From: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Impalah Shenzhou
Sent: Friday, 16 October 2009 4:37 AM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] open sim UUID and Passwordhash

Thanks for the info Melanie.

Adam, I consider Drupal, for example, a CMS with a decent security and it only 
uses md5(plain_password) to store user passwords. Some php frameworks (for 
example Code Igniter, Cake php...) use, but not mandatory, an unique hash for 
all the application.

A random hash for every user improves security, you're right, but increases the 
data sent between DB and servers for every authentication. I prefer not to 
overload data transmission for something I think is overprotection. Maybe for 
10 or 100 users there won't be no problems, but think on 1 and each byte 
will count (they aren't cheap).

If you have a long, secret and unique hash for your servers, who can make an 
effective attack to you (at least in reasonable time)?

Maybe the difference could be that Drupal used to be deployed over Apache, and 
it can be protected against dictionary attacks activating some modules, while 
Opensim/UGAIM are servers "per se", basic servers.

It's my opinion, if you don't like it, I have more :-P

Greetings

2009/10/16 Frisby, Adam mailto:a...@deepthink.com.au>>
A long fixed salt doesn't help over the simple ":" in any practical way. The 
salt must be unique for each user for decent security.

Adam

From: 
opensim-dev-boun...@lists.berlios.de<mailto:opensim-dev-boun...@lists.berlios.de>
 
[mailto:opensim-dev-boun...@lists.berlios.de<mailto:opensim-dev-boun...@lists.berlios.de>]
 On Behalf Of Impalah Shenzhou
Sent: Friday, 16 October 2009 3:44 AM

To: opensim-dev@lists.berlios.de<mailto:opensim-dev@lists.berlios.de>
Subject: Re: [Opensim-dev] open sim UUID and Passwordhash

This comes from UserManagerBase.AddUser (0.6.6):

string md5PasswdHash = Util.Md5Hash(Util.Md5Hash(password) + ":" + 
String.Empty);

The salt should be where String.Empty is.

I think it doesn't change in the most recent versions, so the "create user" 
method of the console (both standalone and ugaim) are unsecure by default.


Anyway, I agree with Melanie and Adam that the salt is needed for improving 
security, if not a random salt every time you create an user, at least a long 
and secret unique salt.

Greetings

2009/10/16 Frisby, Adam mailto:a...@deepthink.com.au>>
+1 to Melanie, that code is *not* secure. It is salted with a ":" but that's a 
fixed known salt.

This is what I suggest:

$passwordSalt = md5(time() . utime() . mt_rand(0,mt_getrandmax())); // or any 
other good random source
$passwordHash = md5(md5($password) . ':' . $passwordSalt);

$passwordSalt should be unique among your database (very likely with the above 
code); if there are duplicates, then it allows dictionary attacks to be done, 
the more duplicates, the more effective it is.

Adam

> -Original Message-
> From: 
> opensim-dev-boun...@lists.berlios.de<mailto:opensim-dev-boun...@l

Re: [Opensim-dev] open sim UUID and Passwordhash

[Frisby, Adam]

A long fixed salt doesn't help over the simple ":" in any practical way. The 
salt must be unique for each user for decent security.

Adam

From: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Impalah Shenzhou
Sent: Friday, 16 October 2009 3:44 AM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] open sim UUID and Passwordhash

This comes from UserManagerBase.AddUser (0.6.6):

string md5PasswdHash = Util.Md5Hash(Util.Md5Hash(password) + ":" + 
String.Empty);

The salt should be where String.Empty is.

I think it doesn't change in the most recent versions, so the "create user" 
method of the console (both standalone and ugaim) are unsecure by default.


Anyway, I agree with Melanie and Adam that the salt is needed for improving 
security, if not a random salt every time you create an user, at least a long 
and secret unique salt.

Greetings


2009/10/16 Frisby, Adam mailto:a...@deepthink.com.au>>
+1 to Melanie, that code is *not* secure. It is salted with a ":" but that's a 
fixed known salt.

This is what I suggest:

$passwordSalt = md5(time() . utime() . mt_rand(0,mt_getrandmax())); // or any 
other good random source
$passwordHash = md5(md5($password) . ':' . $passwordSalt);

$passwordSalt should be unique among your database (very likely with the above 
code); if there are duplicates, then it allows dictionary attacks to be done, 
the more duplicates, the more effective it is.

Adam

> -Original Message-
> From: 
> opensim-dev-boun...@lists.berlios.de<mailto:opensim-dev-boun...@lists.berlios.de>
>  [mailto:opensim-dev-<mailto:opensim-dev->
> boun...@lists.berlios.de<mailto:boun...@lists.berlios.de>] On Behalf Of 
> Melanie
> Sent: Thursday, 15 October 2009 4:14 PM
> To: opensim-dev@lists.berlios.de<mailto:opensim-dev@lists.berlios.de>
> Subject: Re: [Opensim-dev] open sim UUID and Passwordhash
>
> Please don't use that code. It creates unsalted hashes, which are
> not secure.
> The "" should be a ranndom salt, stored in the passwordSalt field in
> the DB. If that is blank, you're running a very insecure system
>
>
> Melanie
>
>
> Rich White wrote:
> > here is the PHP code - $password_hash = md5(md5($password) . ":"
> ."");
> >
> > an md5 hash of an md5 hash
> >
> > =
> >
> > 2009/10/15 Márcio Cardoso 
> > mailto:marciomai...@gmail.com>>:
> >> Good night,
> >>
> >> will be possible that someone could help me with 2 problems I have?
> I'm
> >> trying to create a stored procedure in mysql to add users, but do
> not know
> >> how UUID  is generated. anyone have any idea how this happens?
> Another
> >> problem is how is the encoding of the password.
> >>
> >> The ideal was to have access to the code that  opensim uses to add
> avatars.
> >> but I got tired of looking and nothing. I thank you for your help.
> >>
> >> Greetings,
> >>
> >> Márcio Cardoso
> >>
> >> ___
> >> Opensim-dev mailing list
> >> Opensim-dev@lists.berlios.de<mailto:Opensim-dev@lists.berlios.de>
> >> https://lists.berlios.de/mailman/listinfo/opensim-dev
> >>
> >>
> > ___
> > Opensim-dev mailing list
> > Opensim-dev@lists.berlios.de<mailto:Opensim-dev@lists.berlios.de>
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de<mailto:Opensim-dev@lists.berlios.de>
> https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de<mailto:Opensim-dev@lists.berlios.de>
https://lists.berlios.de/mailman/listinfo/opensim-dev

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

Re: [Opensim-dev] open sim UUID and Passwordhash

[Frisby, Adam]

+1 to Melanie, that code is *not* secure. It is salted with a ":" but that's a 
fixed known salt.

This is what I suggest:

$passwordSalt = md5(time() . utime() . mt_rand(0,mt_getrandmax())); // or any 
other good random source
$passwordHash = md5(md5($password) . ':' . $passwordSalt);

$passwordSalt should be unique among your database (very likely with the above 
code); if there are duplicates, then it allows dictionary attacks to be done, 
the more duplicates, the more effective it is.

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Melanie
> Sent: Thursday, 15 October 2009 4:14 PM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] open sim UUID and Passwordhash
> 
> Please don't use that code. It creates unsalted hashes, which are
> not secure.
> The "" should be a ranndom salt, stored in the passwordSalt field in
> the DB. If that is blank, you're running a very insecure system
> 
> 
> Melanie
> 
> 
> Rich White wrote:
> > here is the PHP code - $password_hash = md5(md5($password) . ":"
> ."");
> >
> > an md5 hash of an md5 hash
> >
> > =
> >
> > 2009/10/15 Márcio Cardoso :
> >> Good night,
> >>
> >> will be possible that someone could help me with 2 problems I have?
> I'm
> >> trying to create a stored procedure in mysql to add users, but do
> not know
> >> how UUID  is generated. anyone have any idea how this happens?
> Another
> >> problem is how is the encoding of the password.
> >>
> >> The ideal was to have access to the code that  opensim uses to add
> avatars.
> >> but I got tired of looking and nothing. I thank you for your help.
> >>
> >> Greetings,
> >>
> >> Márcio Cardoso
> >>
> >> ___
> >> Opensim-dev mailing list
> >> Opensim-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] [Opensim-users] prolog scripting

[Frisby, Adam]

Schrodinger's Script Engine!

Quick, someone find a cat.

Adam

> -Original Message-
> From: opensim-users-boun...@lists.berlios.de [mailto:opensim-users-
> boun...@lists.berlios.de] On Behalf Of d...@metaverseink.com
> Sent: Sunday, 11 October 2009 5:32 PM
> To: opensim-dev@lists.berlios.de; opensim-us...@lists.berlios.de
> Subject: [Opensim-users] prolog scripting
> 
> Is anyone using Prolog for scripting?
> I see that code in OpenSim, but I'm unsure whether it's dead or alive.
> ___
> Opensim-users mailing list
> opensim-us...@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-users
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] 50+ avies

[Frisby, Adam]

Adding to the impressiveness, this was achieved on Mono. I suspect by 
consequence we'll see 1000 on .NET. :P

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Kyle G
> Sent: Thursday, 8 October 2009 3:39 PM
> To: d...@metaverseink.com; opensim-dev@lists.berlios.de; opensim-
> us...@lists.berlios.de
> Subject: Re: [Opensim-dev] 50+ avies
> 
> Fantastic!
> 
> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de
> [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of
> d...@metaverseink.com
> Sent: Thursday, October 08, 2009 5:22 PM
> To: opensim-dev@lists.berlios.de; opensim-us...@lists.berlios.de
> Subject: [Opensim-dev] 50+ avies
> 
> In case you are missing all the excitement, this morning we were able
> to
> pile 52 people-driven avies in OSGrid's Wright Plaza under 600M of RAM,
> and after that sim had been up for 10 hours, with a previous peak
> presence of 36. This sim is running on average hardware, nothing fancy.
> 
> It eventually crashed, likely due to an overly conservative lock still
> present somewhere. But I think we just turned an important corner on
> the
> way to 1.0.
> ___
> 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-users] 50+ avies

[Frisby, Adam]

No, we're going to discontinue the old hardware (donating 4 boxes to 
opensim/osgrid is probably our limit, sorry!)

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Fly Man
> Sent: Thursday, 8 October 2009 2:59 PM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] [Opensim-users] 50+ avies
> 
> Adam, will this mean a new machine in the datacenter next to the old
> one or a replacement machine ?
> 
> Because if the old machine keeps running, it might make a good
> comparison machine for testing
> 
> 2009/10/8 Frisby, Adam :
> > Actually, WP is running on positively ancient hardware. We're
> (DeepThink+simhost) scheduled to donate a new box to replace it this
> month coming (along with plaza03 which will also be getting an update).
> >
> > Adam
> >
> >> -Original Message-
> >> From: opensim-users-boun...@lists.berlios.de [mailto:opensim-users-
> >> boun...@lists.berlios.de] On Behalf Of d...@metaverseink.com
> >> Sent: Thursday, 8 October 2009 2:22 PM
> >> To: opensim-dev@lists.berlios.de; opensim-us...@lists.berlios.de
> >> Subject: [Opensim-users] 50+ avies
> >>
> >> In case you are missing all the excitement, this morning we were
> able
> >> to
> >> pile 52 people-driven avies in OSGrid's Wright Plaza under 600M of
> RAM,
> >> and after that sim had been up for 10 hours, with a previous peak
> >> presence of 36. This sim is running on average hardware, nothing
> fancy.
> >>
> >> It eventually crashed, likely due to an overly conservative lock
> still
> >> present somewhere. But I think we just turned an important corner on
> >> the
> >> way to 1.0.
> >> ___
> >> Opensim-users mailing list
> >> opensim-us...@lists.berlios.de
> >> https://lists.berlios.de/mailman/listinfo/opensim-users
> > ___
> > Opensim-dev mailing list
> > Opensim-dev@lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> >
> ___
> 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-users] 50+ avies

[Frisby, Adam]

Actually, WP is running on positively ancient hardware. We're 
(DeepThink+simhost) scheduled to donate a new box to replace it this month 
coming (along with plaza03 which will also be getting an update).

Adam

> -Original Message-
> From: opensim-users-boun...@lists.berlios.de [mailto:opensim-users-
> boun...@lists.berlios.de] On Behalf Of d...@metaverseink.com
> Sent: Thursday, 8 October 2009 2:22 PM
> To: opensim-dev@lists.berlios.de; opensim-us...@lists.berlios.de
> Subject: [Opensim-users] 50+ avies
> 
> In case you are missing all the excitement, this morning we were able
> to
> pile 52 people-driven avies in OSGrid's Wright Plaza under 600M of RAM,
> and after that sim had been up for 10 hours, with a previous peak
> presence of 36. This sim is running on average hardware, nothing fancy.
> 
> It eventually crashed, likely due to an overly conservative lock still
> present somewhere. But I think we just turned an important corner on
> the
> way to 1.0.
> ___
> Opensim-users mailing list
> opensim-us...@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-users
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Protocol Gateways

[Frisby, Adam]

If you want to feed the data into the sim, your best bet might be a region 
module (or look at MRM scripting for a more powerful script engine).

If you are feeding this data both in and out to clients speaking a special 
protocol, you want to write a ClientStack / ClientView. (see the IRCClientView 
for a good simple clientview example)

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Don McGregor
> Sent: Wednesday, 7 October 2009 9:52 AM
> To: opensim-dev@lists.berlios.de
> Subject: [Opensim-dev] Protocol Gateways
> 
> I'm kicking around the idea of gatewaying into OpenSimulator an
> existing DoD Modeling and Simulation
> protocol, Distributed Interactive Simulation (DIS). DIS is used for
> virtual worlds in military
> simulations. Primarily it describes the position, orientation,
> velocity, etc, of entities in a
> virtual world.
> 
> There may be multiple entities on the DIS side of the gateway; I want
> to inject them into
> the OpenSimulator server side.
> 
> I've been poking around the various wikis for a while and haven't seen
> a good description
> of the (or a) client-server protocol for movement. What's a reasonable
> approach to this?
> Should I translate the DIS packets into an OpenSimualtor client/server
> protocol? Try to
> write a server-side module that speaks DIS? And, most importantly,
> where can I find
> some documentation on how to do 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

Re: [Opensim-dev] git branches

[Frisby, Adam]

Nix anything from 07/08 - the code isn't used anymore.

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Jeff Ames
> Sent: Wednesday, 30 September 2009 5:32 PM
> To: opensim-dev@lists.berlios.de
> Subject: [Opensim-dev] git branches
> 
> Hello,
> 
> Looking at the git branches on the server, many of them are rather
> old.  Do we really want to keep all of them?
> 
> The dates listed are the date of the last commit to the branch.
> 
> Releases / post-fixes, presumably want to keep:
>   origin/0.6.0-stable Dec 18 2008
>   origin/0.6.1-post-fixes Jan 14 2009
>   origin/0.6.2-post-fixes Mar 17 2009
>   origin/0.6.3-post-fixes Feb 21 2009
>   origin/0.6.4-post-fixes Apr 3 2009
>   origin/0.6.4-rc1Mar 11 2009
>   origin/0.6.5-post-fixes Jun 24 2009
>   origin/0.6.5-rc1May 24 2009
>   origin/0.6.6-post-fixes Aug 8 2009
>   origin/0.6.7-post-fixes Sep 29 2009
>   origin/0.6b-realxtend   Feb 26 2008
> 
> Updated recently, presumably want to keep:
>   origin/inventory-connector  Aug 16 2009
>   origin/arthursv Aug 21 2009
>   origin/diva-texturesSep 30 2009
>   origin/diva-textures-osgrid Sep 30 2009
>   origin/grid-service-redux   Sep 28 2009
>   origin/vehicles Sep 30 2009
> 
> Last updated in 2007:
>   origin/standalone   Feb 19 2007
>   origin/ogs...@86Feb 26 2007
>   origin/gareth   Mar 1 2007
>   origin/brokenpluginsMar 2 2007
>   origin/ogs...@151   Mar 2 2007
>   origin/physicsExample   Mar 5 2007
>   origin/railsMar 7 2007
>   origin/ConvertToPlugins Mar 7 2007
>   origin/ogs...@155   Mar 7 2007
>   origin/ogs...@160   Mar 7 2007
>   origin/ogs-cs   Mar 14 2007
>   origin/adam-ogscs   Mar 20 2007
>   origin/adam Mar 20 2007
>   origin/physics-inventorytesting Mar 20 2007
>   origin/LLdemo   Mar 27 2007
>   origin/tourmaline   Mar 28 2007
>   origin/scripting-jvmApr 10 2007
>   origin/0.1-prestableMay 7 2007
>   origin/remotingTest May 27 2007
>   origin/mergeJun 8 2007
>   origin/zircon   Jun 12 2007
>   origin/NameSpaceChanges Jun 29 2007
>   origin/ruby Jul 8 2007
>   origin/OGSMerge Jul 10 2007
>   origin/Sugilite Jul 11 2007
>   origin/physics  Aug 19 2007
>   origin/update-to-latest-libsl   Oct 1 2007
> 
> Last updated in 2008:
>   origin/ThreadPoolClientBranch   Feb 24 2008
>   origin/afrisby  Feb 22 2008
>   origin/afrisby-3Feb 25 2008
>   origin/afrisby-rexmerge Feb 22 2008
>   origin/rexserver_r830   Feb 29 2008
> 
> Last updated in early 2009:
>   origin/GenericGridServerConcept May 15 2009
> 
> Probably a relic of the svn-git changeover:
>   origin/trunkAug 2 2009
> 
> There are also a few tags that look like they might not be needed:
>   archive Feb 27 2007
>   archive2Mar 7 2007
> 
> Any thoughts?
> 
> Jeff
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Mega Regions and PAL support in OpenSim?

[Frisby, Adam]

There are four people I know of who have done fairly substantial work with 
OpenSim's physics engines:
- MW (wrote the original interfaces)
- Teravus (made ODE 'not suck' ... as much)
- Jeff Ames (wrote the MICA one)
- Leon Zhu (works for me, did some substantial work on the BulletX 
plugin, but is currently a bit busy to field questions on this list)

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Robert A. Knop Jr.
> Sent: Wednesday, 30 September 2009 6:36 PM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] Mega Regions and PAL support in OpenSim?
> 
> On Wed, Sep 30, 2009 at 06:23:56PM -0700, Dahlia Trimble wrote:
> > We're watching PAL and may consider it when we find it to be
> sufficient for
> > use with OpenSim. Another factor to consider is the majority of
> OpenSim
> > developers are unpaid volunteers and it's difficult to find people
> who have
> > the knowledge and expertise for implementing physics simulations and
> are
> > willing to donate their time and services. If you have this expertise
> or
> > know of someone else who would be willing to help implement PAL then
> please
> > do consider creating a PAL module and donating it to the community.
> 
> I fully understand (at this point) the MICASim Physics module and how
> it
> interacts; thanks to ter_afk (on IRC-- I wish I knew his real name!)
> for
> some pointers on getting the message back that the scene needs to get
> updated info from the physics sim.
> 
> I have figured out a bunch of what needs to happen, but not all of it.
> Could somebody point me to where I'd look to understand what taints are
> all about WRT a physics engine?
> 
> I have various interests in physics engines, what with being a
> physicist and the last one to hack the MICA code
> 
> --
> --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

Re: [Opensim-dev] Mega Regions and PAL support in OpenSim?

[Frisby, Adam]

I wont speak for him here, but Teravus has looked at PAL repeatedly in the past 
with a general result of 'Not ready yet, check again later.'

Adam

From: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Dahlia Trimble
Sent: Wednesday, 30 September 2009 6:24 PM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Mega Regions and PAL support in OpenSim?

OpenSim already has an abstraction layer for physics engines, and several 
engines have been interfaced already. ODE is probably the most complete 
implementation. There are also some implementations that exist outside of core, 
most notably the Mica N-body simulation on forge.

We're watching PAL and may consider it when we find it to be sufficient for use 
with OpenSim. Another factor to consider is the majority of OpenSim developers 
are unpaid volunteers and it's difficult to find people who have the knowledge 
and expertise for implementing physics simulations and are willing to donate 
their time and services. If you have this expertise or know of someone else who 
would be willing to help implement PAL then please do consider creating a PAL 
module and donating it to the community.
On Wed, Sep 30, 2009 at 5:24 PM, Mark Malewski 
mailto:mark.malew...@gmail.com>> wrote:


What are your thoughts about implementing PAL into OpenSim?




The Physics Abstraction Layer (PAL) provides a 
unified interface to a number of different physics engines. This enables the 
use of multiple physics engines within one application. It is not just a simple 
physics wrapper, but provides an extensible plug-in architecture for the 
physics system, as well as extended functionality for common simulation 
components.

PAL provides a number of benefits to game and simulation developers. First of 
all PAL is veryeasy to use, so you can easily integrate physics into your 
application. Secondly, it does not restrict you to one particular physics 
engine. This gives you more flexibility, allowing you to easily upgrade your 
physics system if you decide to pursue a commercial engine, select different 
engines for alternative platforms, or swap to another engine if the physics 
engine developers stop development and support for their engine. This 
flexibility allows you to choose the engine that gives you the best performance 
for your application. Finally, PAL has an extensive set of common features such 
as simulating different devices or loading physics configurations from XML, 
COLLADA and Scythe 
files.

PAL makes physics development FLEXIBLE, FAST and EASY.
PAL supports a large number of physics 
engines. It provides a unique 
interface for:

 *   Physics Engines

*   Box2D (experimental)
*   Bullet
*   
Dynamechs(deprecated)
*   Havok (experimental)
*   IBDS (experimental)
*   JigLib
*   Meqon(deprecated)
*   Newton
*   ODE
*   OpenTissue
*   PhysX (a.k.a Novodex, Ageia PhysX, nVidia 
PhysX)
*   Simple Physics Engine
*   Tokamak
*   TrueAxis

 *   File Formats

*   Collada
*   Scythe
*   PAL XML(deprecated)

 *   Collision subsystem
 *   Solver subsystem (Multithreaded / Hardware acceleration)
 *   Bodies (Static and Dynamic)

*   Box
*   Capsule
*   Compound Bodies
*   Convex
*   Sphere

 *   Geometries

*   Box
*   Capsule
*   Convex Mesh
*   Concave Mesh (Terrain)
*   Height field (Terrain)
*   Plane (Terrain)
*   Sphere

 *   Links

*   Spherical (Ball and Socket) Link
*   Revolute (Hinge) Link
*   Prismatic (Slider) Link
*   Generic 6DOF Link

 *   Sensors

*   Contact
*   Compass (Angular position)
*   GPS (Global Positioning System - Position)
*   Gyroscope (Angular velocity)
*   Inclinometer (Angular position)
*   PSD (Position Sensitive Device - Ray casting)
*   Sonar (Ray casting)
*   Velocimeter (Linear velocity)
*   Transponder (Distance between two objects)

 *   Actuators

*   Force a

Re: [Opensim-dev] OpenSim 0.7 Release Candidate with ALL working OpenSim Modules

[Frisby, Adam]

Well, to be honest OpenSim is designed so you don't need to compile something 
to install a module.

It should be just dumped into the OpenSim dir as a .dll, and it should be 
picked up and loaded automatically - so people doing modules; you can ship 
binaries, and they will be reasonably compatible with a range of OpenSim 
versions (but occasionally yes they will need to be recompiled to work against 
trunk - especially during big internal shakeups). But that's up to you.

Adam

From: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Joshua Garvin
Sent: Wednesday, 30 September 2009 4:28 PM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] OpenSim 0.7 Release Candidate with ALL working 
OpenSim Modules

Mark's comment wasn't very well organized or thought out.  It was basically 
just an explosion of his frustration with OpenSim.

But that doesn't mean that he doesn't have a few good points hidden in there.

I believe that looking at most other software projects in the world, you would 
find that "core" or "base" products did not come into existence in a vacuum.  
They were developed with a specific end product in mind that solved an 
immediate need and/or desire.  The developers of the end product most likely 
worked heavily on the core products. The effect of that end product was the 
world getting to see how great the technology is.  Once people see the 
possibilities your core provides, they will build other great products from it.

I don't intend to say that the first end product has to share a repository with 
the core code.  Just that there needs to be an end product being work on by 
core developers.

Do you need to include _every_ module in your releases?  No.  But you have to 
do whatever it takes to make using the most common modules as easy as possible. 
 If half or even a 5th of your potential users want module X, then it's fairly 
important that it's easy to install without knowing c#.

You can do all of this the other way around -- but you're only hurting your own 
popularity.

Be excellent to each other and party on dudes!
- Joshua
___
Joshua Garvin

On Wed, Sep 30, 2009 at 5:51 PM, Melanie 
mailto:mela...@t-data.com>> wrote:
Holdit!

OpenSim is NOT A PRODUCT. OpenSim is a BASE other people can make a
product out of. So, OpenSim aims to include as little as possible,
distros are the ones who will put it together and relicense it as
they see fit.

OpenSim Core is not a maker of distros. We are not a product
company. We are a loose association of people who share an interest.
We don't _want_ to make a "product", because we can't support a
product. We make "bits and pieces" and let those with support staff
handle productizing it.

Melanie

Mark Malewski wrote:
> Diva,
>
> *>> It would just be nice to get everything integrated back into core (or as
>>> OpenSim modules).
>>*
> *>This would be terrible. *
>
> Diva, please explain WHY would having a working OpenSim distro be terrible?
>  Having something that actually "works" is terrible?  In my opinion, just
> the opposite is true.
>
> You can spend your whole life developing things (that no one actually uses,
> and that don't actually work or do much of anything, and that no one will
> ever use) or you can make a WORKING product that is usable, and that is EASY
> to use, and that people will use.
>
> You seem to prefer the latter.
>
>
> *> I think you, and maybe others here, may need to understand better this
>>concept of extensible systems. That's at the very core of OpenSim from
>>the beginning, even before I started contributing -- OpenSim is not an
>>application, it's a platform with which to build applications.
> *
> I think you need to sit down and understand the concept of "working
> product".  You also need to stop confusing "extensible system" with "not
> working" product.
>
> PHP, and Apache are what I would consider "extensible systems".  PHP is
> easily downloaded, and it works (out of the box).  Yet it comes with many
> different modules (as part of the default distro) and those modules have all
> been thoroughly tested, and can easily be enabled by simply uncommenting out
> the module name in the default.ini file.
>
> to include hooks and mechanisms for expanding/enhancing the system with new
> capabilities WITHOUT having to make major changes to the system
> infrastructure.
>
> OpenSim doesn't seem to be "extensible".  OpenSim seems to be "broken".
>  There is a big difference.  Maybe your definition of "extensible" means
> that it requires a rocket scientist just to get the trunk to even compile
> (or even work), and takes hours and hours of debugging code, just to get a
> module to even work.  That isn't my idea of "extensible".
>
> I understand over the past few months, the server infrastructure (and
> architecture) has been changing quite a bit.  It's hard to even tell if
> ModRex (or any other modules) even work with th

Re: [Opensim-dev] OpenSim 0.7 Release Candidate with ALL working OpenSim Modules

[Frisby, Adam]

There's only a handful of those at best (diva, osgrid, new world grid, 
realXtend,...). But it's probably really not a bad idea.

I think what Diva is doing (the 'Diva Distribution') is exactly where things 
should be heading.

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Robert A. Knop Jr.
> Sent: Wednesday, 30 September 2009 4:12 PM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] OpenSim 0.7 Release Candidate with ALL
> working OpenSim Modules
> 
> On Thu, Oct 01, 2009 at 12:51:49AM +0200, Melanie wrote:
> > OpenSim Core is not a maker of distros. We are not a product
> > company. We are a loose association of people who share an interest.
> > We don't _want_ to make a "product", because we can't support a
> > product. We make "bits and pieces" and let those with support staff
> > handle productizing it.
> 
> It would be *great*, though, if the front page of opensimulator.org
> pointed folks to places where they could download and get a product.
> People come there looking to experiment with running opensimulator.  If
> the page can point them to an easy as possible place to get and install
> a distribution, that'd be a benefit for 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

Re: [Opensim-dev] OpenSim 0.7 Release Candidate with ALL working OpenSim Modules

[Frisby, Adam]

tl; dr.

Adam

From: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Mark Malewski
Sent: Wednesday, 30 September 2009 3:45 PM
To: d...@metaverseink.com; opensim-dev@lists.berlios.de
Subject: [Opensim-dev] OpenSim 0.7 Release Candidate with ALL working OpenSim 
Modules

Diva,

>> It would just be nice to get everything integrated back into core (or as
>> OpenSim modules).
>
>This would be terrible.

Diva, please explain WHY would having a working OpenSim distro be terrible?  
Having something that actually "works" is terrible?  In my opinion, just the 
opposite is true.

You can spend your whole life developing things (that no one actually uses, and 
that don't actually work or do much of anything, and that no one will ever use) 
or you can make a WORKING product that is usable, and that is EASY to use, and 
that people will use.

You seem to prefer the latter.


> I think you, and maybe others here, may need to understand better this
>concept of extensible systems. That's at the very core of OpenSim from
>the beginning, even before I started contributing -- OpenSim is not an
>application, it's a platform with which to build applications.
I think you need to sit down and understand the concept of "working product".  
You also need to stop confusing "extensible system" with "not working" product.

PHP, and Apache are what I would consider "extensible systems".  PHP is easily 
downloaded, and it works (out of the box).  Yet it comes with many different 
modules (as part of the default distro) and those modules have all been 
thoroughly tested, and can easily be enabled by simply uncommenting out the 
module name in the default.ini file.

>From an engineering standpoint, extensibility means the system is designed to 
>include hooks and mechanisms for expanding/enhancing the system with new 
>capabilities WITHOUT having to make major changes to the system infrastructure.

OpenSim doesn't seem to be "extensible".  OpenSim seems to be "broken".  There 
is a big difference.  Maybe your definition of "extensible" means that it 
requires a rocket scientist just to get the trunk to even compile (or even 
work), and takes hours and hours of debugging code, just to get a module to 
even work.  That isn't my idea of "extensible".

I understand over the past few months, the server infrastructure (and 
architecture) has been changing quite a bit.  It's hard to even tell if ModRex 
(or any other modules) even work with the current OpenSim trunk (or latest 
build) at this point.

The average layperson doesn't want to spend hours and hours trying to compile 
from source, or debugging code, or searching for plugins/modules that may (or 
may not) exist, and even worse many of them may not be updated, or may not even 
work with the current OpenSim as "core" evolves.  Often times many of these 
modules are not updated, and most have no clue how to even build from source, 
and for this reason it might be good to just have VERY simple "turn-key" 
distributions available for download. (Stable releases)

Similar to how RealXtend has done in the past.

I supposed I could sit down and begin working on creating a fully configured 
VMWare image  of OpenSim with various modules installed and configured, that 
people could easily download, and be up and running in a few minutes (without 
having to hunt for various modules, or applications), or sifting through 
outdated wiki pages trying to figure out how to even get started or even get up 
and running, but to be honest most people just want something VERY easy to use, 
VERY easy to setup, and would love a nice GUI interface (like WixTD, etc.) that 
they can use to administer the server, add users, etc.

Most laypeople don't want to hire a software engineer, or a programmer, just to 
get OpenSim to compile, or even get a module working, or just to get OpenSim 
running on a machine.

If I want to use a plugin with Firefox, I've NEVER had to compile or debug 
code.  If I want to enable a PHP module, I've NEVER had to debug any code.  
Most modules are included in the default distro, and modules can easily be 
turned on and off, by simply "enabling" them in the default ini (configuration) 
file.

In my opinion, you may be confusing "extensible system" as an excuse as to why 
nothing should work properly.

In my opinion, EVERY single working module that exists for OpenSim should be 
included in the default distro (in the modules directory), and these modules 
should ALL be disabled by default, but can be easily enabled by simply 
uncommenting out ONE single line in the default.ini configuration file.

Include EVERY single working module with the default OpenSim distro, so users 
have a list of default working modules that are regularly updated so that they 
actually work (and are not broken), so that when a stable release comes out, a 
user can just enable or disable whatever modules they wish to use (by 
uncommenting out a line or two in the de

Re: [Opensim-dev] [realXtend] Re: 3Di Viewer "Rei" goes open source (BSD licensed in-browser viewer)

[Frisby, Adam]

VRML suffers from filesize issues too however; and frankly I've never been 
impressed by what it can support as a format.

Don't look to it if you want to do things like shader based materials; which 
are essential for the gaming/entertainment side.

Adam

From: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Daniel Smith
Sent: Wednesday, 30 September 2009 11:09 AM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] [realXtend] Re: 3Di Viewer "Rei" goes open source 
(BSD licensed in-browser viewer)


On Wed, Sep 30, 2009 at 10:51 AM, Ryan McDougall 
mailto:sempu...@gmail.com>> wrote:


[1] I guess there is VRML/X3D, but they appear to have died for a reason?


X3D + JavaScript is what drives Vivaty (as in Vivaty.com).  I dont expect it's 
going to go very far (I did some work with it).  The co-author of X3D (formerly 
VRML) is Tony Parisi, and he's at Vivaty.

Daniel

--
Daniel Smith - Sonoma County, California
http://daniel.org/resume
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] [realXtend] Re: 3Di Viewer "Rei" goes open source (BSD licensed in-browser viewer)

[Frisby, Adam]

a perfect world, I'd really
> like to see some of these technologies that 3Di and Tribal Media
> are/were working on, slowly come back to the OpenSim Community as
> OpenSource Modules (similar to the RealXtend/ModRex module).
>
> That way we just have ONE single OpenSim core distribution, and then
> have various modules (like "ModRex" or a "3Di" module, or a
> "Tribal_Media" module) that can be installed on top of OpenSim core?
>
> This would seem to make MUCH more sense, instead of all the various
> forks out there.  I really do like the idea of "standardization", and
> would really like to see Modules created instead of completely different
> OpenSim "forks".
>
> Then it would be great to see the Viewers designed so that all the
> various viewers will work with all the different platform modules
> (ModRex, 3Di, Tribal Media Server, etc.)
>
> Mark
>
>
> On Wed, Sep 30, 2009 at 11:07 AM, Frisby, Adam 
> mailto:a...@deepthink.com.au>
> <mailto:a...@deepthink.com.au<mailto:a...@deepthink.com.au>>> wrote:
>
> It works with vanilla but from my understanding not ModRex; the
> meshes are handled as Irrlicht meshes if I understand correctly.
> Synchronising these mesh standards (in both rex & 3diov) might be a
> good idea methinks.
>
>
>
> ... then if we can get someone to adjust the full viewer, we'd have
> somewhat of a standard on our hands.
>
>
>
> Adam
>
>
>
> *From:* 
> opensim-dev-boun...@lists.berlios.de<mailto:opensim-dev-boun...@lists.berlios.de>
> 
> <mailto:opensim-dev-boun...@lists.berlios.de<mailto:opensim-dev-boun...@lists.berlios.de>>
> 
> [mailto:opensim-dev-boun...@lists.berlios.de<mailto:opensim-dev-boun...@lists.berlios.de>
> 
> <mailto:opensim-dev-boun...@lists.berlios.de<mailto:opensim-dev-boun...@lists.berlios.de>>]
>  *On Behalf Of *Mark
> Malewski
> *Sent:* Wednesday, 30 September 2009 9:02 AM
> *To:* realxt...@googlegroups.com<mailto:realxt...@googlegroups.com>
> <mailto:realxt...@googlegroups.com<mailto:realxt...@googlegroups.com>>; 
> Opensim-dev@lists.berlios.de<mailto:Opensim-dev@lists.berlios.de>
> <mailto:Opensim-dev@lists.berlios.de<mailto:Opensim-dev@lists.berlios.de>>
> *Subject:* Re: [Opensim-dev] [realXtend] Re: 3Di Viewer "Rei" goes
> open source (BSD licensed in-browser viewer)
>
>
>
> Nlin,
>
>
>
> Does the "Rei" Viewer work with the OpenSim + ModRex (RealXtend) as
> well?
>
> Could you please explain the differences between a plain vanilla
> OpenSim Server, a OpenSim + ModRex (realXtend) server, and a 3di server?
>
>
>
>
>
>   Thank-you for all that you do,
>
>
>
> Mark
>
>
>
>
>
> On Wed, Sep 30, 2009 at 8:36 AM, Anu Mishra 
> mailto:anuranj...@gmail.com>
> <mailto:anuranj...@gmail.com<mailto:anuranj...@gmail.com>>> wrote:
>
> Nlin
>
>
>
> Do you know if this viewer works with Realxtend server as well?
>
>
>
> Anu
>
>
>
> On 9/30/09, *Mark Malewski* 
> mailto:mark.malew...@gmail.com>
> <mailto:mark.malew...@gmail.com<mailto:mark.malew...@gmail.com>>> wrote:
>
> RealXtend,
>
>
>
>
> Have any of the RealXtend core developer's had a chance to look
> at this OpenSource "Rei" viewer yet?
>
>
>
>
> It seems to be an OpenSource web-based viewer.  It looks pretty
> cool.  Would this OpenSource contribution help RealXtend's
> Viewer project in any way?  Could this viewer be easily modified
> to work with BOTH the stock OpenSim AND also work with RealXtend
> & ModRex?
>
>
>
>
>   Mark
>
>
>
> On Wed, Sep 30, 2009 at 2:07 AM, Mark Malewski
> mailto:mark.malew...@gmail.com> 
> <mailto:mark.malew...@gmail.com<mailto:mark.malew...@gmail.com>>> wrote:
>
> Nlin,
>
>
>
>
> Thank-you very much for the post, that seems like an excellent
> contribution to the OpenSim Community!
>
>
>
>
> I'm wondering what type of effect this might have on RealXtend's
> project development of a new viewer?
>
>
>
>
> Will this "Rei" viewer work with the latest stock OpenSim server?
>
>
>
>
> Mark
>
>
>
> On 

Re: [Opensim-dev] [realXtend] Re: 3Di Viewer "Rei" goes open source (BSD licensed in-browser viewer)

[Frisby, Adam]

I'm partial to the .X format myself:

- Yes, it originated proprietarily, but it's fully documented & standardised. 
The original source no longer uses it.
- It's binary and easy to parse. (low filesizes)
- Features a lot of things that would be good for VWs (mesh animations, 
skeletons, etc)
- There's importers and exporters for just about every 3D package. (probably 
better supported than COLLADA)

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Ryan McDougall
> Sent: Wednesday, 30 September 2009 10:52 AM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] [realXtend] Re: 3Di Viewer "Rei" goes open
> source (BSD licensed in-browser viewer)
> 
> Yes that was kinda implied, but I can go one step further:
> 
> There is only one format not tied to a particular engine[1], COLLADA,
> as that's it's main design goal. However since it's not the most
> binary efficient format, there are questions about how suitable it is
> for real-time use.
> 
> Sirikata is going ahead with COLLADA and have hired some chair of a
> COLLADA group to implement, but I am unclear how they've solved those
> concerns.
> 
> So, yeah, I am presuming that the author of said proposal (as I myself
> don't have one on hand) would sort out how to handle both native
> efficient formats, and portable interchange formats.
> 
> Cheers,
> 
> [1] I guess there is VRML/X3D, but they appear to have died for a
> reason?
> 
> On Wed, Sep 30, 2009 at 8:40 PM, Dahlia Trimble
>  wrote:
> > I'd personally rather see a standard that was *not* tied to a
> particular
> > game or rendering engine.
> >
> >
> > On Wed, Sep 30, 2009 at 9:15 AM, Ryan McDougall 
> wrote:
> >>
> >> On Wed, Sep 30, 2009 at 7:07 PM, Frisby, Adam
> 
> >> wrote:
> >> > It works with vanilla but from my understanding not ModRex; the
> meshes
> >> > are
> >> > handled as Irrlicht meshes if I understand correctly.
> Synchronising
> >> > these
> >> > mesh standards (in both rex & 3diov) might be a good idea
> methinks.
> >> >
> >> >
> >> >
> >> > . then if we can get someone to adjust the full viewer, we'd have
> >> > somewhat
> >> > of a standard on our hands.
> >> >
> >> >
> >> >
> >> > Adam
> >>
> >> I agree with this completely. I'd love to see modrex modified to
> >> handle Rei (and a suitable name-change is also no problem).
> >>
> >> If 3Di releases their specs, or someone reverse engineers what
> they're
> >> doing, and wraps it up in a proposal that *increases*
> standardization,
> >> we might be able to find funding for it.
> >>
> >> Cheers,
> >>
> >> >
> >> >
> >> >
> >> > From: opensim-dev-boun...@lists.berlios.de
> >> > [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Mark
> Malewski
> >> > Sent: Wednesday, 30 September 2009 9:02 AM
> >> > To: realxt...@googlegroups.com; Opensim-dev@lists.berlios.de
> >> > Subject: Re: [Opensim-dev] [realXtend] Re: 3Di Viewer "Rei" goes
> open
> >> > source
> >> > (BSD licensed in-browser viewer)
> >> >
> >> >
> >> >
> >> > Nlin,
> >> >
> >> >
> >> >
> >> > Does the "Rei" Viewer work with the OpenSim + ModRex (RealXtend)
> as
> >> > well?
> >> >
> >> > Could you please explain the differences between a plain vanilla
> OpenSim
> >> > Server, a OpenSim + ModRex (realXtend) server, and a 3di server?
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >       Thank-you for all that you do,
> >> >
> >> >
> >> >
> >> >                 Mark
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > On Wed, Sep 30, 2009 at 8:36 AM, Anu Mishra 
> >> > wrote:
> >> >
> >> > Nlin
> >> >
> >> >
> >> >
> >> > Do you know if this viewer works with Realxtend server as well?
> >> >
> >> >
> >> >
> >> > Anu
> >> >
> >> >
> >> >
> >> > On 9/30/09, Mark Malewski  wrote:
> >> >
> >> >

Re: [Opensim-dev] [realXtend] Re: 3Di Viewer "Rei" goes open source (BSD licensed in-browser viewer)

[Frisby, Adam]

It works with vanilla but from my understanding not ModRex; the meshes are 
handled as Irrlicht meshes if I understand correctly. Synchronising these mesh 
standards (in both rex & 3diov) might be a good idea methinks.

... then if we can get someone to adjust the full viewer, we'd have somewhat of 
a standard on our hands.

Adam

From: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Mark Malewski
Sent: Wednesday, 30 September 2009 9:02 AM
To: realxt...@googlegroups.com; Opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] [realXtend] Re: 3Di Viewer "Rei" goes open source 
(BSD licensed in-browser viewer)

Nlin,

Does the "Rei" Viewer work with the OpenSim + ModRex (RealXtend) as well?
Could you please explain the differences between a plain vanilla OpenSim 
Server, a OpenSim + ModRex (realXtend) server, and a 3di server?


  Thank-you for all that you do,

Mark


On Wed, Sep 30, 2009 at 8:36 AM, Anu Mishra 
mailto:anuranj...@gmail.com>> wrote:
Nlin

Do you know if this viewer works with Realxtend server as well?

Anu


On 9/30/09, Mark Malewski 
mailto:mark.malew...@gmail.com>> wrote:
RealXtend,


Have any of the RealXtend core developer's had a chance to look at this 
OpenSource "Rei" viewer yet?


It seems to be an OpenSource web-based viewer.  It looks pretty cool.  Would 
this OpenSource contribution help RealXtend's Viewer project in any way?  Could 
this viewer be easily modified to work with BOTH the stock OpenSim AND also 
work with RealXtend & ModRex?


  Mark

On Wed, Sep 30, 2009 at 2:07 AM, Mark Malewski 
mailto:mark.malew...@gmail.com>> wrote:
Nlin,


Thank-you very much for the post, that seems like an excellent contribution to 
the OpenSim Community!


I'm wondering what type of effect this might have on RealXtend's project 
development of a new viewer?


Will this "Rei" viewer work with the latest stock OpenSim server?


Mark

On Tue, Sep 29, 2009 at 8:24 PM, nlin 
mailto:nlin.mess...@gmail.com>> wrote:

Hello,

Today 3Di's in-browser viewer source code has been opened up, as the project 
3Di Viewer "Rei". The license is BSD. Please have a look if you are interested!

Project home page: http://3di-rei.org
Press release: http://3di.jp/en/news/2009093001.html

We're very interested in further development of this open source viewer with 
the community. Thanks to the IdealistViewer developers, as portions of Rei use 
source code from an early version of IdealistViewer. Rei uses no code from 
GPL-licensed viewers.

The Rei source code is in git at github, with the main repository at: 
http://github.com/3di/3di-viewer-rei

Thanks,
-nlin





--~--~-~--~~~---~--~~

http://groups.google.com/group/realxtend
http://www.realxtend.org
-~--~~~~--~~--~--~---

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

Re: [Opensim-dev] [Opensim-users] Exception: System.IO.FileNotFoundException:

[Frisby, Adam]

You need .NET 3.5 installed. Grab it from Windows Update.

Adam

From: opensim-users-boun...@lists.berlios.de 
[mailto:opensim-users-boun...@lists.berlios.de] On Behalf Of Huan Dau
Sent: Wednesday, 30 September 2009 7:08 AM
To: opensim-dev@lists.berlios.de; opensim-us...@lists.berlios.de
Subject: [Opensim-users] Exception: System.IO.FileNotFoundException:

Hi all

I config to run Opensim as Grid Mode but have an error below

2009-09-30 08:58:35,187 INFO  - 
OpenSim.Region.Physics.Manager.PhysicsPluginManager [PHYSICS]: creating meshing 
engine Meshmerizer
2009-09-30 08:58:35,187 INFO  - 
OpenSim.Region.Physics.Manager.PhysicsPluginManager [PHYSICS]: creating 
OpenDynamicsEngine
2009-09-30 08:58:35,484 ERROR - OpenSim.Application [APPLICATION]:
APPLICATION EXCEPTION DETECTED: System.UnhandledExceptionEventArgs

Exception: System.IO.FileNotFoundException: Could not load file or assembly 
'System.Core, Version=3.5.0.0, Culture=neutral, 
PublicKeyToken=b77a5c561934e089' or one of its dependencies. The system cannot 
find the file specified.
File name: 'System.Core, Version=3.5.0.0, Culture=neutral, 
PublicKeyToken=b77a5c561934e089'
   at OpenSim.Region.Physics.OdePlugin.OdeScene..ctor(CollisionLocker dode, 
String sceneIdentifier)
   at OpenSim.Region.Physics.OdePlugin.OdePlugin.GetScene(String 
sceneIdentifier) in d:\OSGRID\OSGRID 
RELEASES\git.release\OpenSim\Region\Physics\OdePlugin\OdePlugin.cs:line 79
   at 
OpenSim.Region.Physics.Manager.PhysicsPluginManager.GetPhysicsScene(String 
physEngineName, String meshEngineName, IConfigSource config, String regionName) 
in d:\OSGRID\OSGRID 
RELEASES\git.release\OpenSim\Region\Physics\Manager\PhysicsPluginManager.cs:line
 95
   at OpenSim.Region.ClientStack.RegionApplicationBase.GetPhysicsScene(String 
engine, String meshEngine, IConfigSource config, String osSceneIdentifier) in 
d:\OSGRID\OSGRID 
RELEASES\git.release\OpenSim\Region\ClientStack\RegionApplicationBase.cs:line 
134
   at OpenSim.OpenSimBase.GetPhysicsScene(String osSceneIdentifier) in 
d:\OSGRID\OSGRID 
RELEASES\git.release\OpenSim\Region\Application\OpenSimBase.cs:line 689
   at OpenSim.OpenSimBase.SetupScene(RegionInfo regionInfo, Int32 proxyOffset, 
IConfigSource configSource, IClientNetworkServer& clientServer) in 
d:\OSGRID\OSGRID 
RELEASES\git.release\OpenSim\Region\Application\OpenSimBase.cs:line 589
   at OpenSim.OpenSimBase.CreateRegion(RegionInfo regionInfo, Boolean 
portadd_flag, Boolean do_post_init, IScene& mscene) in d:\OSGRID\OSGRID 
RELEASES\git.release\OpenSim\Region\Application\OpenSimBase.cs:line 365
   at OpenSim.OpenSimBase.CreateRegion(RegionInfo regionInfo, Boolean 
portadd_flag, IScene& scene) in d:\OSGRID\OSGRID 
RELEASES\git.release\OpenSim\Region\Application\OpenSimBase.cs:line 319
   at OpenSim.ApplicationPlugins.LoadRegions.LoadRegionsPlugin.PostInitialise() 
in d:\OSGRID\OSGRID 
RELEASES\git.release\OpenSim\ApplicationPlugins\LoadRegions\LoadRegionsPlugin.cs:line
 127
   at OpenSim.OpenSimBase.StartupSpecific() in d:\OSGRID\OSGRID 
RELEASES\git.release\OpenSim\Region\Application\OpenSimBase.cs:line 208
   at OpenSim.OpenSim.StartupSpecific() in d:\OSGRID\OSGRID 
RELEASES\git.release\OpenSim\Region\Application\OpenSim.cs:line 137
   at OpenSim.Framework.Servers.BaseOpenSimServer.Startup() in d:\OSGRID\OSGRID 
RELEASES\git.release\OpenSim\Framework\Servers\BaseOpenSimServer.cs:line 295
   at OpenSim.Application.Main(String[] args) in d:\OSGRID\OSGRID 
RELEASES\git.release\OpenSim\Region\Application\Application.cs:line 146

WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value 
[HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure 
logging.
To turn this feature off, remove the registry value 
[HKLM\Software\Microsoft\Fusion!EnableLog].


Application is terminating: True

Please tell me how to fix this error?

thank and best regards.
 --
Dau Huan
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] OpenSim content format decoding

[Frisby, Adam]

It's plain old JPEG2000 format - used on both sculptmaps and texmaps. You can 
export the data as a .j2c file and it should load fine in any J2C viewer.

Adam

From: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Shun-Yun Hu
Sent: Tuesday, 29 September 2009 8:23 PM
To: opensim-dev@lists.berlios.de
Subject: [Opensim-dev] OpenSim content format decoding


Hello all,

We've been trying to develop a light-weight Opensim-compatible viewer that 
might work like an IM, while being scalable in the number of concurrent users 
inside a region (based on http://vast.sf.net).

To make the client as thin as possible, we tried to handle the few supported 
tasks with native programming (not using 3rd party libraries).

We understand that libomv is the main channel between a server and client and 
have looked into its code to understand the content format. However, right now 
we've encountered the problem of decoding certain texture formats, as well as 
the 2nd life scruptedprim format.

Is there any documentation available on these formats? and what might be the 
best way to go about our experimentation?

Any suggestions / pointers are appreciated.

Thanks!

Shun-Yun

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

[Frisby, Adam]

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

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Stefan Andersson
> Sent: Monday, 21 September 2009 10:36 PM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] Thoughts on adding a generic key-value
> storage system to OpenSim?
> 
> 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
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/

Re: [Opensim-dev] Prepackaged OpenSim installs

[Frisby, Adam]

The OSGrid Binary Installs are generally pretty good - Neb does a good job with 
them. I generally use them whenever I need a quick region setup.

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Robert A. Knop Jr.
> Sent: Saturday, 19 September 2009 8:23 AM
> To: opensim-dev@lists.berlios.de
> Subject: [Opensim-dev] Prepackaged OpenSim installs
> 
> On Sat, Sep 19, 2009 at 04:31:26AM -0500, Len Brown wrote:
> >  Surely, a single page step by step account of (at least) how to
> > configure and run OpenSim is, in essence, MANDATORY.  Otherwise all
> > the hard work and effort on the project is absolutely worthless.  If
> > the average person cannot get a single stand-alone region running on
> > their home computer within 5 or 10 minutes then it's all in vain.
> 
> I'm entirely a Linux user myself, so I don't know the answer to this,
> but -- there are binary distros for windows available, are there not,
> for OpenSim?  How friendly are they to get started?
> 
> Next question : is there somebody in the OpenSim team who's taken on
> the mantle of providing binary distros and making it easy to install?
> 
> I'll look into it, but I might be willing to try to take up the job of
> providing at least some of that for Linux builds.
> 
> (Aside: I'm a n00b to opensim-dev.  To those who haven't met me on IRC,
> I'm Rob Knop, itenerant astrophysicist & computer engineer.  I was a
> professor of Physics & Astronomy at Vanderbilt until 2007, and from
> 2007 to 2009 was Prospero Linden, production operations engineer and
> later server release manager for Linden Lab.  I currently don't have
> long-term employement, but am working with MICA (www.mica-vw.org) on N-
> body simulations, and using virtual worlds as both a collaboration
> platform and a visualization platform.  This has naturally led me to
> OpenSim as an open source server that lets us do fun things you can't
> do without source code and your own servers running the code)
> 
> --
> --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

Re: [Opensim-dev] The return of short version numbers (as tags)

[Frisby, Adam]

Handy!

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Teravus Ovares
> Sent: Tuesday, 8 September 2009 7:18 AM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] The return of short version numbers (as
> tags)
> 
> http://teravus.wmcv.com/googletester/GitLog.jpg
> 
> Regards
> 
> Teravus
> 
> On Tue, Sep 8, 2009 at 10:10 AM, Frisby, Adam
> wrote:
> > Where do we see this number? And is there any way to easily translate
> between the two?
> >
> > Adam
> >
> >> -Original Message-
> >> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> >> boun...@lists.berlios.de] On Behalf Of Sean Dague
> >> Sent: Tuesday, 8 September 2009 5:14 AM
> >> To: opensim-dev
> >> Subject: [Opensim-dev] The return of short version numbers (as tags)
> >>
> >> Late last week I found a script that tags each changeset that comes
> >> into the server with an increasing number.  When you pull on master,
> >> you'll see these tags now flow down.
> >>
> >> Because the nature of distributed version control, this is only
> going
> >> to give you a rough idea of forward or backward in time.  Commits
> are
> >> made locally, and only when merged into the master server do they
> get
> >> an id.
> >>
> >> http://github.com/opensim/opensim/network will give an idea of the
> >> complex dance of changesets and why this is never going to be fully
> >> linear.
> >>
> >> But, that being said, the lack of a short version number like that
> is
> >> the #1 issue (by vocalness) that people were having with git.
> >> Hopefully this helps that.
> >>
> >> This short version number only means anything if you are getting
> your
> >> tree from the main opensim archive.
> >>
> >>       -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 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 return of short version numbers (as tags)

[Frisby, Adam]

Where do we see this number? And is there any way to easily translate between 
the two?

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Sean Dague
> Sent: Tuesday, 8 September 2009 5:14 AM
> To: opensim-dev
> Subject: [Opensim-dev] The return of short version numbers (as tags)
> 
> Late last week I found a script that tags each changeset that comes
> into the server with an increasing number.  When you pull on master,
> you'll see these tags now flow down.
> 
> Because the nature of distributed version control, this is only going
> to give you a rough idea of forward or backward in time.  Commits are
> made locally, and only when merged into the master server do they get
> an id.
> 
> http://github.com/opensim/opensim/network will give an idea of the
> complex dance of changesets and why this is never going to be fully
> linear.
> 
> But, that being said, the lack of a short version number like that is
> the #1 issue (by vocalness) that people were having with git.
> Hopefully this helps that.
> 
> This short version number only means anything if you are getting your
> tree from the main opensim archive.
> 
>   -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] ConsoleClient -pass option

[Frisby, Adam]

I have to second this motion - XMLRPC in my opinion is a lot better for remote 
programming than "REST" which doesn't really define the wire formats nor 
datatypes.

The ICommander interface we are now using on the console really suits XMLRPC 
well - since we already have a list of defined arguments available, and can 
build nice remote-access documentation from them automatically.

In addition, we can use the exact same format & arguments as the console 
commands.

Regards,

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Dickson, Mike (ISS Software)
> Sent: Friday, 4 September 2009 8:05 AM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] ConsoleClient -pass option
> 
> Thanks for the pointer Melanie. No I wasn't aware of it.  I'll have a
> look.
> 
> I'm pretty sure I don't agree however that a simple GET/PUT interface
> is somehow just better than (dated!) XML/RPC (or some other protocol
> where the on the wire data types are actually defined). That's creeping
> towards a religious discussion however so I'll drop it. Having the
> console functionality packages separate like this is the important
> "feature" IMO.
> 
> Mike
> 
> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Melanie
> Sent: Friday, September 04, 2009 9:59 AM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] ConsoleClient -pass option
> 
> Have you ever looked at the REST console? That is precisely what it
> does, it removes the local console, enabling the process to run as a
> daemon, and allows remote connections from a console application.
> 
> Only, it doesn't use the (dated) XMLRPC, it uses RESTful requests.
> 
> XMLRPC admin is only available in region servers, and is too limited
> a tool even if "beefed up" to ever replace a console.
> 
> Melanie
> 
> Dickson, Mike (ISS Software) wrote:
> > Right.  That gets around the issue.  BTW, if the server is running
> SNMP or something that gives access to the process list this problem
> can leak outside the local machine.  I don't for sure but I'm guessing
> you could have the same issue in Windows with WMI.
> >
> > IMO, the right answer is to dump the consoles, beef up the XML/RPC
> admin interface and if desired do a separate "console app" that parses
> and sends the XML/RPC to the server.  I've been noodling on that but
> still struggling with a stable config with the new "BUST" architecture.
> >
> > Mike
> >
> > -Original Message-
> > From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Dr Scofield
> > Sent: Friday, September 04, 2009 3:19 AM
> > To: opensim-dev@lists.berlios.de
> > Subject: Re: [Opensim-dev] ConsoleClient -pass option
> >
> >
> > Dickson, Mike (ISS Software) wrote:
> >> I'd agree with Dave on this one.  Just a simple long ps listing gets
> you the password if its on cleartext on the command line.  At least the
> file can be locked down via permissions.  A password on the command
> line is pretty much insecure. Might as well not have one.
> >
> > ...unless you rewrite argv (which is standard practise for stuff like
> that).
> >
> > DrS/dirk
> >
> >>
> >> Mike
> >>
> >> -Original Message-
> >> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Melanie
> >> Sent: Thursday, September 03, 2009 10:02 PM
> >> To: opensim-dev@lists.berlios.de
> >> Subject: Re: [Opensim-dev] ConsoleClient -pass option
> >>
> >> It's choosing the lesser evil.
> >>
> >> Melanie
> >>
> >>
> >> Dave Coyle wrote:
> >>> On Thursday 03 September 2009 03:00:46 pm  wrote:
>  commit 6b70b5709913e9734f5864560e997b34dfd58b85
>  Author: Justin Clark-Casey (justincc) 
>  Date:   Thu Sep 3 20:00:18 2009 +0100
> 
>  * Add extra warning about using -pass in
>  OpenSim.ConsoleClient.ini.example
> 
>  <...>
> 
>  +; Please be aware that this is not secure since the password
> is in the
>  clear +; we recommend the use of -pass wherever possible
>   ;pass = secret
> >>>
> >>> Is the password not also in the clear, visible to any local user
> who does a
> >>> 'ps', if you use the -pass switch?  Access to
> OpenSim.ConsoleClient.ini can at
> >>> least be restricted to specific user(s).  I don't see how -pass is
> the lesser
> >>> of the two evils.
> >>>
> >>> -coyled
> >>>
> >>>
> >>> ---
> -
> >>>
> >>> ___
> >>> Opensim-dev mailing list
> >>> Opensim-dev@lists.berlios.de
> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev
> >> ___
> >> Opensim-dev mailing list
> >> Opensim-dev@lists.berlios.de
> >> https://lists.berlios.de/mailman/listinfo/opensim-dev
> >> _

Re: [Opensim-dev] OpenSim-Commits question

[Frisby, Adam]

I think it's berlios that might be rejecting - nonetheless, I requested the 
subdomain get added, so it should be there soon.

Adam

> -Original Message-
> From: Teravus Ovares [mailto:tera...@gmail.com]
> Sent: Monday, 31 August 2009 10:15 AM
> To: opensim-dev@lists.berlios.de
> Cc: Frisby, Adam
> Subject: Re: [Opensim-dev] OpenSim-Commits question
> 
> Is this something that we can add an /etc/hosts entry in temporarily?
> 
> Regards
> 
> Teravus
> 
> On Mon, Aug 31, 2009 at 12:00 PM, Sean Dague wrote:
> > Ursula MATOVA wrote:
> >> Hi All,
> >>
> >> Just a basic question ... :)
> >>
> >> Is it normal that I didn't receive any more messages on the opensim-
> >> commits mailing list ?
> >> Last I have received is from 2009/08/22 ( Git #1e4238af... )
> >>
> >> Regards,
> >> Ursula.
> >
> > The email is all being held because the sending domain
> > 'pinky.opensimulator.org' no longer exists.
> >
> > Adam, can you fix this when you get a chance?  The email should flow
> > after that point.
> >
> >        -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 mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] OpenSim-Commits question

[Frisby, Adam]

I think it's done via CIA actually automatically (don't quote me)

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Teravus Ovares
> Sent: Thursday, 27 August 2009 6:25 PM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] OpenSim-Commits question
> 
> That might be a cron job that sdague setup.  He's on vacation though,
> so, if it isn't working at the moment, then it may be down until he's
> back.I was able to get the svn mirror,  mantisbot and panda builds
> running again but I didn't see one for the opensim-commits list yet.
> If I spot it, I'll get it running again.   If not, it'll be running
> again shortly after sdague gets back.
> 
> Regards
> 
> Teravus
> 
> On Thu, Aug 27, 2009 at 7:32 PM, Ursula
> MATOVA wrote:
> > Hi All,
> >
> > Just a basic question ... :)
> >
> > Is it normal that I didn't receive any more messages on the opensim-
> > commits mailing list ?
> > Last I have received is from 2009/08/22 ( Git #1e4238af... )
> >
> > Regards,
> > Ursula.
> > ___
> > 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] LookingGlass in Wright Plaza

[Frisby, Adam]

Second suggestion - don't run debug builds. At stuff like geometry 
manipulation, the lack of inlining functions/etc causes a major major 
performance penalty.

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Mister Blue
> Sent: Tuesday, 25 August 2009 10:17 PM
> To: opensim-dev
> Subject: [Opensim-dev] LookingGlass in Wright Plaza
> 
> The LookingGlass viewer forge project[1] reached a milestone last
> night of allowing me to walk and fly around Wright Plaza. If you ever
> see an avatar by the name of Charm DeSnoozle stumbling around OSGrid,
> that's me testing LookingGlass.
> 
> I made a video of the experience [2]. You can see that the frame rate
> is very low and my overly aggressive object culling makes turning a
> reloading experience. My work so far has been getting correct prim
> representation and the framework in place. There are some texturing
> errors (some textures are upside down and the textures on the tree
> leaves are on the wrong sides of the prims) but, in general, the
> current display is pretty close.
> 
> I hope to get the frame rate up and package this so there is a viewer
> framework for people to build on. More information is available at the
> LookingGlass web site[3].
> 
> -- ra
> 
> [1] http://forge.opensimulator.org/gf/project/lookingglass/
> [2] http://www.youtube.com/watch?v=88TZdYZTOkw
> [3] http://lookingglassviewer.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] LookingGlass in Wright Plaza

[Frisby, Adam]

This is very cool.

Re: culling & memory usage for primitives:

Can you recycle classes? That is make a dictionary for the geometry using a 
index derived from a combination of the primitive parameters? Materials will 
obviously vary - but you might be able to shave significant amounts of memory 
back through geometry re-use. (Given that most prims in a sim are of a few 
common varieties)

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Mister Blue
> Sent: Tuesday, 25 August 2009 10:17 PM
> To: opensim-dev
> Subject: [Opensim-dev] LookingGlass in Wright Plaza
> 
> The LookingGlass viewer forge project[1] reached a milestone last
> night of allowing me to walk and fly around Wright Plaza. If you ever
> see an avatar by the name of Charm DeSnoozle stumbling around OSGrid,
> that's me testing LookingGlass.
> 
> I made a video of the experience [2]. You can see that the frame rate
> is very low and my overly aggressive object culling makes turning a
> reloading experience. My work so far has been getting correct prim
> representation and the framework in place. There are some texturing
> errors (some textures are upside down and the textures on the tree
> leaves are on the wrong sides of the prims) but, in general, the
> current display is pretty close.
> 
> I hope to get the frame rate up and package this so there is a viewer
> framework for people to build on. More information is available at the
> LookingGlass web site[3].
> 
> -- ra
> 
> [1] http://forge.opensimulator.org/gf/project/lookingglass/
> [2] http://www.youtube.com/watch?v=88TZdYZTOkw
> [3] http://lookingglassviewer.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] DNS Notice

[Frisby, Adam]

This has been transferred, however there is a glitch with the wildcard record - 
getting that fixed.

Adam

From: opensim-core-boun...@lists.berlios.de 
[mailto:opensim-core-boun...@lists.berlios.de] On Behalf Of Frisby, Adam
Sent: Saturday, 22 August 2009 2:24 PM
To: opensim-dev@lists.berlios.de; opensim-us...@lists.berlios.de; 
opensim-c...@lists.berlios.de
Subject: [opensim-core] DNS Notice

Hi everyone,

We're going to be switching the nameservers for opensimulator.org and 
forge.opensimulator.org domains on Monday the 24th. (ie, this Monday). In 
theory there should be no disruption to the services; however the chance exists 
that sometime during Monday, the site will be inaccessible. (It's just going 
between different nameservers on the same ISP, so should be relatively safe)

The IPs for the site should be:
opensimulator.org 71.6.131.152
forge.opensimulator.org 66.240.236.69

If you have any trouble accessing the sites on Monday - you can put the above 
into your hosts file.

Regards,

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

[Opensim-dev] DNS Notice

[Frisby, Adam]

Hi everyone,

We're going to be switching the nameservers for opensimulator.org and 
forge.opensimulator.org domains on Monday the 24th. (ie, this Monday). In 
theory there should be no disruption to the services; however the chance exists 
that sometime during Monday, the site will be inaccessible. (It's just going 
between different nameservers on the same ISP, so should be relatively safe)

The IPs for the site should be:
opensimulator.org 71.6.131.152
forge.opensimulator.org 66.240.236.69

If you have any trouble accessing the sites on Monday - you can put the above 
into your hosts file.

Regards,

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

Re: [Opensim-dev] .NET 3.5 support

[Frisby, Adam]

We're on the subset Mono 2.0.1 supports. As soon as 2.4 becomes standard, we 
may upgrade to 2.4 (which is fairly complete as far as 3.5 is concerned)

I believe HashSet is safe to use however. The buildbot on Panda is the ultimate 
arbiter - if it compiles there, it's safe to use.

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Lake, Dan
> Sent: Tuesday, 18 August 2009 6:13 PM
> To: opensim-dev@lists.berlios.de
> Subject: [Opensim-dev] .NET 3.5 support
> 
> It looks like the default build for OpenSim projects was recently
> changed to .NET 3.5. Can a submitted patch include features from .NET
> 3.5 such as HashSet? Are all 3.5 features supported by Mono? Thanks,
> 
> Dan lake
> Software Engineer
> Visual Applications Research
> Microprocessor & Programming Research
> Intel Labs
> 503.712.8318
> dan.l...@intel.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] pruning reference servers in core

[Frisby, Adam]

Update: apparently we're already running it - at least for Inventory.

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Frisby, Adam
> Sent: Thursday, 13 August 2009 8:06 PM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] pruning reference servers in core
> 
> If OSGrid isn't already, we may begin doing testing on ROBUST. We have
> pretty decent stats on things such as memory leaks over time, so we can
> observe how it performs in a high usage environment.
> 
> Adam
> 
> > -Original Message-
> > From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> > boun...@lists.berlios.de] On Behalf Of Melanie
> > Sent: Thursday, 13 August 2009 12:43 PM
> > To: opensim-dev@lists.berlios.de
> > Subject: Re: [Opensim-dev] pruning reference servers in core
> >
> > Thing is, that would make the new "old" servers actually be ROBUST.
> > The concern that has been voiced is that ROBUST needs more testing
> > and not all grids are willing to switch yet.
> > What you propose would force them to switch, through the back door.
> > While I'm all for that, it would achieve the same thing as simply
> > removing A and I, namely, make people use ROBUST. Some don't want
> > that yet.
> >
> > Melanie
> >
> > Fly Man wrote:
> > > Why wait until September when the solution is already on the Wiki:
> > >
> > > 1) Delete the old Grid.Asset and Grid.Inventory servers
> > >
> > > 2) Copy the new OpenSim.Server.exe to OpenSim.Grid.AssetServer.exe
> > and
> > > OpenSim.Grid.InventoryServer.exe
> > >
> > > 3) Copy the .config files: OpenSim.Grid.AssetServer.exe.config and
> > > OpenSim.Grid.InventoryServer.exe.config and edit them so they'll
> use
> > > the same log file like they did before
> > >
> > > 4) Create the new OpenSim.Grid.AssetServer.ini and
> > > OpenSim.Grid.InventoryServer.ini like mentioned on the Wiki
> > >
> > > 5) Edit those like mentioned and run them
> > >
> > > I think the solution to this "problem" is easily fixed by doing
> this
> > > and commiting the whole bunch again then waiting until September
> > >
> > > 2009/8/13  :
> > >> I'm fine with waiting until September before pruning reference
> > >> implementations down to one of each. But someone needs to give
> love
> > to
> > >> Grid.Inventory, because I don't have time for loving so many
> servers
> > :-)
> > >>
> > >> The current improvement I'm doing right now (eliminating the need
> to
> > >> pass the entire inventory around) only works for the new-style
> > inventory
> > >> service. It can easily be made to work for the old one. Whoever
> > wants
> > >> Grid.Inventory to support the simulators' [much more reasonable]
> > needs
> > >> should make the necessary improvements to it. I'll be happy to
> > explain
> > >> what the server needs to do -- 2 additional service handlers. I
> > still
> > >> haven't pushed my local commits, and I can wait a little bit for a
> > >> Grid.InventoryServer lover to step up and volunteer. But I don't
> > think
> > >> it's reasonable to hold this improvement until September; I
> already
> > have
> > >> it, and it's almost ready to be pushed out to grids out there.
> > Passing
> > >> thousands of inventory items upon region crossings and TPs is
> > probably
> > >> one of the worst things in OpenSim right now, and needs fixing.
> > >>
> > >>
> > >> MW wrote:
> > >>> I'm fine with the AssetInventoryServer being removed as soon as
> > possible
> > >>> because I don't think anyone uses it.
> > >>>
> > >>> But believe we should at least wait a couple of more weeks before
> > the
> > >>> Grid.InventoryServer
> > >>> and Grid.AssetServer are removed, so that everyone gets a chance
> to
> > have
> > >>> their say/vote. As a number of people are on vacation around this
> > time.
> > >>>
> > >>> Personally as long as the ROBUST servers are fully tested on
> > multiple
> > >>> grids that have a quite heavy load/userbase, then I'm okay with
> > removing
> > >>> the old servers, as long 

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

[Frisby, Adam]

If OSGrid isn't already, we may begin doing testing on ROBUST. We have pretty 
decent stats on things such as memory leaks over time, so we can observe how it 
performs in a high usage environment.

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Melanie
> Sent: Thursday, 13 August 2009 12:43 PM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] pruning reference servers in core
> 
> Thing is, that would make the new "old" servers actually be ROBUST.
> The concern that has been voiced is that ROBUST needs more testing
> and not all grids are willing to switch yet.
> What you propose would force them to switch, through the back door.
> While I'm all for that, it would achieve the same thing as simply
> removing A and I, namely, make people use ROBUST. Some don't want
> that yet.
> 
> Melanie
> 
> Fly Man wrote:
> > Why wait until September when the solution is already on the Wiki:
> >
> > 1) Delete the old Grid.Asset and Grid.Inventory servers
> >
> > 2) Copy the new OpenSim.Server.exe to OpenSim.Grid.AssetServer.exe
> and
> > OpenSim.Grid.InventoryServer.exe
> >
> > 3) Copy the .config files: OpenSim.Grid.AssetServer.exe.config and
> > OpenSim.Grid.InventoryServer.exe.config and edit them so they'll use
> > the same log file like they did before
> >
> > 4) Create the new OpenSim.Grid.AssetServer.ini and
> > OpenSim.Grid.InventoryServer.ini like mentioned on the Wiki
> >
> > 5) Edit those like mentioned and run them
> >
> > I think the solution to this "problem" is easily fixed by doing this
> > and commiting the whole bunch again then waiting until September
> >
> > 2009/8/13  :
> >> I'm fine with waiting until September before pruning reference
> >> implementations down to one of each. But someone needs to give love
> to
> >> Grid.Inventory, because I don't have time for loving so many servers
> :-)
> >>
> >> The current improvement I'm doing right now (eliminating the need to
> >> pass the entire inventory around) only works for the new-style
> inventory
> >> service. It can easily be made to work for the old one. Whoever
> wants
> >> Grid.Inventory to support the simulators' [much more reasonable]
> needs
> >> should make the necessary improvements to it. I'll be happy to
> explain
> >> what the server needs to do -- 2 additional service handlers. I
> still
> >> haven't pushed my local commits, and I can wait a little bit for a
> >> Grid.InventoryServer lover to step up and volunteer. But I don't
> think
> >> it's reasonable to hold this improvement until September; I already
> have
> >> it, and it's almost ready to be pushed out to grids out there.
> Passing
> >> thousands of inventory items upon region crossings and TPs is
> probably
> >> one of the worst things in OpenSim right now, and needs fixing.
> >>
> >>
> >> MW wrote:
> >>> I'm fine with the AssetInventoryServer being removed as soon as
> possible
> >>> because I don't think anyone uses it.
> >>>
> >>> But believe we should at least wait a couple of more weeks before
> the
> >>> Grid.InventoryServer
> >>> and Grid.AssetServer are removed, so that everyone gets a chance to
> have
> >>> their say/vote. As a number of people are on vacation around this
> time.
> >>>
> >>> Personally as long as the ROBUST servers are fully tested on
> multiple
> >>> grids that have a quite heavy load/userbase, then I'm okay with
> removing
> >>> the old servers, as long as there is total agreement; I know a few
> >>> people have said they don't want to swap to ROBUST.
> >>>
> >>>
> >>> --- On *Tue, 11/8/09, Frisby, Adam //*
> wrote:
> >>>
> >>>
> >>> From: Frisby, Adam 
> >>> Subject: Re: [Opensim-dev] pruning reference servers in core
> >>> To: "opensim-dev@lists.berlios.de"  d...@lists.berlios.de>
> >>> Date: Tuesday, 11 August, 2009, 10:09 PM
> >>>
> >>> Please do. I'd like a 0.6.X release shortly after every
> >>> networkinterface version change if possible - since it makes
> compat
> >>> with the latest stable release always a headache.
> >>>
> >>> Adam
> >>>
> >>&

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

[Frisby, Adam]

Release fairy is any core dev, but usually ckrinke lately. I hear r10108 was a 
decent release, but might be a little bit behind.

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of d...@metaverseink.com
> Sent: Tuesday, 11 August 2009 2:48 PM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] pruning reference servers in core
> 
> I would really appreciate it if the release fairy would do her magic
> again! -- around now. Who is the release fairy?
> 
> Frisby, Adam wrote:
> > Please do. I'd like a 0.6.X release shortly after every
> networkinterface version change if possible - since it makes compat
> with the latest stable release always a headache.
> >
> > Adam
> >
> >> -Original Message-
> >> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> >> boun...@lists.berlios.de] On Behalf Of Justin Clark-Casey
> >> Sent: Tuesday, 11 August 2009 12:04 PM
> >> To: opensim-dev@lists.berlios.de
> >> Subject: Re: [Opensim-dev] pruning reference servers in core
> >>
> >> d...@metaverseink.com wrote:
> >>> Dear devs,
> >>>
> >>> I'm finally changing the way the simulator caches inventory. This
> is
> >> all
> >>> good, and it's the beginning of the much awaited user services
> >>> refactoring. This requires a few small changes in the inventory
> >> services
> >>> interface, as well as additions to the implementation(s). So...
> >>>
> >>> We now have 3 -- yes 3! -- different inventory servers in core.
> (and
> >> 3
> >>> asset servers too). I think it's time to make a decision on what to
> >> keep
> >>> and what to drop, because evolving this ecosystem of
> implementations
> >> in
> >>> core is unscalable.
> >>>
> >>> With this, I'm proposing that we drop the old Grid.InventoryServer,
> >> the
> >>> old Grid.AssetServer and the AssetInventoryServer (CB1). Some
> people
> >> may
> >>> still be using the old servers, so it's time to switch everybody to
> >>> ROBUST. Asking in the IRC, it looks like no one is using
> >>> AssetInventoryServer.
> >>>
> >>> Comments? Objections?
> >> Might be an idea to knock out a 0.6.7 first before making that
> switch.
> >>
> >> --
> >> 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
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

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

[Frisby, Adam]

Please do. I'd like a 0.6.X release shortly after every networkinterface 
version change if possible - since it makes compat with the latest stable 
release always a headache.

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Justin Clark-Casey
> Sent: Tuesday, 11 August 2009 12:04 PM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] pruning reference servers in core
> 
> d...@metaverseink.com wrote:
> > Dear devs,
> >
> > I'm finally changing the way the simulator caches inventory. This is
> all
> > good, and it's the beginning of the much awaited user services
> > refactoring. This requires a few small changes in the inventory
> services
> > interface, as well as additions to the implementation(s). So...
> >
> > We now have 3 -- yes 3! -- different inventory servers in core. (and
> 3
> > asset servers too). I think it's time to make a decision on what to
> keep
> > and what to drop, because evolving this ecosystem of implementations
> in
> > core is unscalable.
> >
> > With this, I'm proposing that we drop the old Grid.InventoryServer,
> the
> > old Grid.AssetServer and the AssetInventoryServer (CB1). Some people
> may
> > still be using the old servers, so it's time to switch everybody to
> > ROBUST. Asking in the IRC, it looks like no one is using
> > AssetInventoryServer.
> >
> > Comments? Objections?
> 
> Might be an idea to knock out a 0.6.7 first before making that switch.
> 
> --
> 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] Main Repository now in Git

[Frisby, Adam]

Does that store the date of last 'commit' or current revision?

If we're replacing the version number from 0.X.Y.SVNNUM - I think we should 
probably use:

0.X.DDMM.GITHASH - since the DDMM is going to be a lot easier to type.

Adam

From: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of James Stallings II
Sent: Thursday, 6 August 2009 4:39 PM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Main Repository now in Git

Greetings List  :)

Just wanted to drop a line to the list and let you all know that we've (OSGrid 
Core Team) done a bit of research and determined the location of the file in 
the which git stores the hash for the the checked out tree (for lack of better 
terminology).

I am personally finishing up a patch at the moment to replace the appearance of 
the svn revision number with the git hash where it has been present before (in 
the client, at region server startup and at in the region server's 'show 
version' command output).

Please bear with me, I am not a core dev either and fumble a bit here and there 
with the tools, but I am rapidly improving my skills ;)

I will notify the list as soon as I have the patch ready.

ETA: sometime this evening CST.

Hope this eases some concerns among you.

Cheers!
James

On Thu, Aug 6, 2009 at 6:20 PM, Ursula MATOVA 
mailto:ursula.mat...@klintcentral.net>> wrote:
Hey Sean ... I know it's hard work ...
My post was just "comments/feeling" about the migration from svn to
git ...
`
On my side ( I'm not a core-dev, just trying to be an active
reporter ) I need to be able to migrate my OpenSim server to the
latest current release to test some new feature/improvments and to be
able to quick reverse to the previous release in case of problems
( it's normal when working with dev branch ) ... And all is based on
the "release number" ... ...
We were in SVN. #10115 ... Then what about now ?
It's not clear at all, don't know the current release number ... ...
do you know it ?
What changes ?
.../...
When checking the git repository, I'm not sure to checkout the latest
dev release ... is it ? or is it the stable branch ?
Sorry, maybe my english is not good enough to follow the git/wiki
instructions ...

Could you provide a kind of "digest" for "git noobs" ( like me ) to
keep track of the latest release ? or some specific release ?

Anyway, I really appreciate everybody's work ... ( even 1st April
jokes ) ... ... ...
So, my feeling is not really important, I'll adapt myself, it'll be
only a bit more difficult for "us" to report bugs ...

Regards,
Ursula.

Le 6 août 09 à 13:42, Sean Dague a écrit :

> Ursula MATOVA wrote:
>> Sure you're right ... let's go to "git" then :)
>>
>> But, is it possible to change the "OpenSim Commits" posts ?
>> Really, it's un-useful and unreadable ...
>
> Yes, I'm working at changing that to something more readable, we'll
> need
> a few more commits going through before I figure out if I've fixed
> that.
>
> Also, there is an rss feed off of http://opensimulator.org/viewgit.
> I've found that to be a very useful way to keep up on things as well.
>
>   -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 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] Temporary Assets now being pushed to grid

[Frisby, Adam]

Hey folks,

Myself and Nebadon have been curious about why OSGrid's asset server has been 
growing assets at a quadrupled rate in the last 2 weeks. It seems we're getting 
entries marked temporary being committed to the central server. (stats 
available at http://assets.osgrid.org/stats/ - look at Total Assets # on the 
year chart)

Temporary assets should be being committed only to local asset caches, and not 
pushed upstream further - can someone take a look at this?

Thanks

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

Re: [Opensim-dev] Very Good Git Book

[Frisby, Adam]

I can tell you pretty safely; OpenSim’s SVN repository is probably several GB. 
Our standard distribution at several points in time was >= 100mb. (a lot of 
binaries).

So we’re going to be hosting ourselves for the foreseeable future I think.

Adam

From: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Christophe, 
Jean-Charles Narbonne
Sent: Tuesday, 28 July 2009 6:02 AM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Very Good Git Book

GitHub allow 300MB, it as a bigger community, it has more feature and stats, a 
fork create a new branch but it cost no place because it's linked to the 
original project (only diff added is counted in the 300 Mo)...

I'm not sure it would be limitant...

but Git hub is probably today the best free GUI for git. (free as free bear)


>Sean Dague:
>   There aren't any plans that this point, we'll have our own git tree 
> hosted locally.

I suppose once we turn to git, a branch would go on github/gitorious and one of 
you should have to pull from this branch...

I agree with Mevlin gitorious have less limitation, and if you want to host it 
you can (but it will not increase the community power as much as go on 
gitorious or github)

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

Re: [Opensim-dev] Very Good Git Book

[Frisby, Adam]

Commits are still going to SVN this week however, correct?

(Got a bunch of stuff which I'm about to check-in)

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Sean Dague
> Sent: Tuesday, 28 July 2009 4:12 AM
> To: opensim-dev@lists.berlios.de
> Subject: [Opensim-dev] Very Good Git Book
> 
> There is a very good git book here under CC license, which you can read
> online: http://progit.org/.  This may very well be of interest to
> folks.
> 
> This week will be a go / no go decision for the git conversion, so
> please make sure you've poked at the new opensim-test3 tree when you
> get a chance.
> 
>   -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] Inventory loss

[Frisby, Adam]

It's worth also noting the clientside inventory skeleton can get corrupted - 
clearing cache will often restore supposedly missing inventory.

Adam

From: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Nebadon Izumi
Sent: Monday, 27 July 2009 10:39 PM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Inventory loss

I don't recall OSgrid really getting many complaints about it either, infact i 
do not recall any, I am not saying its never occured, but its so minimal its 
not something i ever remember occuring, even when our whole asset table 
corrupted, we were able to get 100% recovery, i think we lost 1 asset. We run 
on MySQL, but run fragstore for blob storage, any grids still storing blobs 
inside the database is going to be in major trouble if they don't switch, 
storing blobs inside of any of the currently available database systems 
OpenSim's core is really a terrible idea and should not be done for anything 
that is considered a production level type grid.

Neb
On Mon, Jul 27, 2009 at 6:39 AM, Chris Hart 
mailto:ch...@codetorque.co.uk>> wrote:
>From MSSQL side of the grid fence, I haven't had anyone complain of lost 
>inventory to me - we did until recently have some lost assets after SI 
>sessions due to asset server crashing - previously the code would attempt to 
>store assets with descriptions bigger than database field length. This seemed 
>to happen mostly with SI uploaded items but also was 100% reproducible if you 
>had a sim with a long name and a parcel with a long name and attempted to 
>create a landmark - there are checks now to stop this from happening that 
>Justin kindly committed (and he was good enough to add similar checks for 
>MySQL) and we've not had a crash since applying that patch over a week and a 
>half ago. In terms of actual inventory, no-one has reported loss of specific 
>items. Sometimes slow to load, but not loss.

Is this something that has happened since 0.6.6 tag?

Chris

-Original Message-
From: 
opensim-dev-boun...@lists.berlios.de
 
[mailto:opensim-dev-boun...@lists.berlios.de]
 On Behalf Of Melanie
Sent: 27 July 2009 14:32
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Inventory loss

Those MySQL issues listed below and others like it are corner cases
that OpenSim would never trigger. OpenSim is a very simplistic
database user, it doesn't even really use any relational features of
the database.
So, I don't think that MySQL errors are something we need to concern
ourselves with at this point. Especially, your suggestion would not
help in those cases, as they are all about complete loss of rows.
That is unaffected by a "deleted" type flag.

That is neither here nor there anyway, since such a "deleted" flag
would have to live under OpenSim.Data..

It has no business being in core at all.

Melanie


Colin B. Withers wrote:
> Reason I wondered is simply the number of websites dedicated to recovering 
> from MYSQL database corruption, and offering tools for the same. Google 
> returns over 250,000 sites for 'mysql database corruption'.
>
> MYSQL has had numerous bug fixes to fix database corruption, introduced by 
> differing versions of MYSQL, eg
>
> Fixed in 4.0.18
> INSERT DELAYED ... SELECT ... could cause table corruption because tables 
> were not locked properly. This is now fixed by ignoring DELAYED in this 
> context. (Bug #1983)
>
> Fixed in 4.0.16
> Fixed bug in overrun check for BLOB values with compressed tables. This was a 
> bug introduced in 4.0.14. It caused MySQL to regard some correct tables 
> containing BLOB values as corrupted. (Bug #770, Bug #1304, and maybe Bug 
> #1295)
>
> Fixed in 4.0.15
> Fixed rare bug in MYISAM introduced in 4.0.3 where the index file header was 
> not updated directly after an UPDATE of split dynamic rows. The symptom was 
> that the table had a corrupted delete-link if mysqld was shut down or the 
> table was checked directly after the update.
>
> Fixed in 4.0.14
> Comparison/sorting for latin1_de character set was rewritten. The old 
> algorithm could not handle cases like "sä" < "ßa". See section 5.6.1.1 German 
> character set. In rare cases, it resulted in table corruption.
>
> and so on..
>
> My own experience with Opensim is that in the last 12 months there has been 
> three occasions where residents complained of stuff 'missing' (not a single 
> resident, but several at once) and a roll-back to the last database backup 
> cured the problems.
>
> Rock
>
> -Original Message-
> From: 
> opensim-dev-boun...@lists.berlios.de
>  
> [mailto:opensim-dev-boun...@lists.berlios.de]
>  On Behalf Of Melanie
> Sent: Monday, July 27, 2009 2:07 PM
> To: opensim-dev@lists.berlios.de
> 

Re: [Opensim-dev] Inventory loss

[Frisby, Adam]

Sounds fine to me - however I would give pause before encouraging anyone to use 
'no-copy' -- while this particular solution should work for routine issues; 
no-copy is fundamentally incompatible with the ideas of doing region backups 
(rollbacks, etc) and other similar issues.

To solve that issue more effectively; I think some kind of 'serial number' 
system is probably preferred - so every legitimate copy produces a new serial 
number; and duplication efforts result in a serial number collision.

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Thomas Grimshaw
> Sent: Sunday, 26 July 2009 6:55 PM
> To: opensim-dev@lists.berlios.de
> Subject: [Opensim-dev] Inventory loss
> 
> Hey folks.
> 
> Been thinking a lot about inventory loss in OpenSim, something that I
> think we should really do as much as possible to avoid. We've been
> experiencing numerous cases of lost inventory in K-Grid recently.
> 
> What i'd like to implement, is..
> 
> When an item is removed from inventory (deleted, or rezzed if it's
> no-copy), it is not actually deleted by instead an "available" flag is
> set in the inventory database.
> All inventory queries will check for the flag and thus it will appear
> as
> deleted to the user, but it can be restored easily by an admin if
> needed.  A timestamp should also be set which indicates when the item
> was made unavailable, so that routine cleanup can be performed on items
> which were made unavailable a long time ago.
> 
> I wanted to get people's opinons of this before I implemented it in
> code. Can anyone think of any drawbacks or possible issues? Any further
> room for improvement?
> 
> Cheers
> 
> Thomas Grimshaw
> (RemedyTomm)
> ___
> 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] Bump GridComms Version Notice

[Frisby, Adam]

I think ultimately; we shouldn't be using LLSD in anywhere that isn't 
explicitly dealing with CAPS and it's required.

Frankly it's not an ideal serialisation format for anything but LL 
compatibility.

Adam

From: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Dahlia Trimble
Sent: Saturday, 25 July 2009 4:18 PM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Bump GridComms Version Notice

I've noticed one issue already with the "core" split after 0.7, references that 
were originally resolved to OpenMetaverse.dll now are in the new Core dll. This 
broke binary level compatibility with third party dlls, and source projects now 
need to be distributed assuming either configuration.

On Sat, Jul 25, 2009 at 4:06 PM, Jim Radford 
mailto:jradf...@npl.com>> wrote:
OSD (StructuredData) != Types, Full release notes:
http://jira.openmetaverse.org/secure/ReleaseNote.jspa?version=10071&styleName=Html&projectId=1&Create=Create


Although I notice there is nothing in those release notes that indicates
the breaking changes since 0.6.x, We (libomv) need to be better about
flagging changes as such. They are generally flagged as breaking in the
commit message, the problem is we don't always create jira issues for such
changes (bad behavior on our part). We'll get this process fixed so
breaking changes in 0.8 will be more obvious. Its probably worthwhile to do
a svn log (or browse through the -commits mailing list) which might help
indicate other possible issues in updating to 0.7.0.

Additionally the specifics of the change Teravus talks about  were done due
to a change in the OGP draft specs which the commit message indicates If
memory serves me correctly.

And lastly, one of the major projects for 0.8 will be to split the "core"
functionality (messages, packets, etc) into its own assembly separate from
client related items. This will for opensim of course mean a leaner
assembly without a bunch of the stuff you don't currently need. This change
will not be much in the way of API/Namespace changes. The desire is to
continue to support the many use cases for the library but in a more
organized fashion that makes better sense in those use cases.

Teravus: thanks for pointing these things out so we can improve the
process.

Regards,
Jim

On Sat, 25 Jul 2009 18:41:22 -0400, "Frisby, Adam" 
mailto:a...@deepthink.com.au>>
wrote:
> D'oh.
>
> Wasn't moving to OMVTypes supposed to avoid breaks like this?
>
> Adam
>
>> -Original Message-
>> From: 
>> opensim-dev-boun...@lists.berlios.de<mailto:opensim-dev-boun...@lists.berlios.de>
>>  [mailto:opensim-dev-<mailto:opensim-dev->
>> boun...@lists.berlios.de<mailto:boun...@lists.berlios.de>] On Behalf Of 
>> Teravus Ovares
>> Sent: Saturday, 25 July 2009 2:05 PM
>> To: opensim-dev
>> Subject: [Opensim-dev] Bump GridComms Version Notice
>>
>> Hey everyone
>>
>> After fighting with things for a bit, I'm going to recommend bumping
>> the version of the gridcomms.
>>
>> It turns out that the json serialization of the UUID type was changed
>> in libOMV revision r2588 to a plain string.
>> This leaves older regions expecting a 'uuid::' prefix (as was the
>> previous format) unable to decode UUIDs and return a UUID.Zero.
>>
>> This will break Hypergrid and some types of region to region comms
>> between OpenSim revisions 10081 and 10082. Regions in versions 10082
>> cannot talk properly to regions 10081 and below.   If you try, some
>> regions will show, some won't, you'll have border crossing issues
>> sometimes and you'll get weird console messages.   For grids who want
>> a consistent experience, you will need to upgrade regions together so
>> organize the effort appropriately.
>>
>> Unfortunately, there isn't really anything that we can do besides this
>> except roll back the LibOMV 0.7.0 commit and stay on an older version
>> of libOMV.  There isn't any way to programmatically change, without
>> forking OpenMetaverse.StructureData, what should go over the wire
>> serialization.   Additionally, on the receiving side, there's no way
>> to know what was a UUID and what was a string with UUID text in it's
>> contents so converting it there is also out of the question.
>>
>> Additionally, any services that make use of the json serialization are
>> affected (json stats come to mind).
>>
>> Be aware of these changes
>>
>> Regards
>>
>> Teravus
-- Jim

!DSPAM:370,4a6b8ffa312361761917752!


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

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

Re: [Opensim-dev] Bump GridComms Version Notice

[Frisby, Adam]

D'oh.

Wasn't moving to OMVTypes supposed to avoid breaks like this?

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Teravus Ovares
> Sent: Saturday, 25 July 2009 2:05 PM
> To: opensim-dev
> Subject: [Opensim-dev] Bump GridComms Version Notice
> 
> Hey everyone
> 
> After fighting with things for a bit, I'm going to recommend bumping
> the version of the gridcomms.
> 
> It turns out that the json serialization of the UUID type was changed
> in libOMV revision r2588 to a plain string.
> This leaves older regions expecting a 'uuid::' prefix (as was the
> previous format) unable to decode UUIDs and return a UUID.Zero.
> 
> This will break Hypergrid and some types of region to region comms
> between OpenSim revisions 10081 and 10082. Regions in versions 10082
> cannot talk properly to regions 10081 and below.   If you try, some
> regions will show, some won't, you'll have border crossing issues
> sometimes and you'll get weird console messages.   For grids who want
> a consistent experience, you will need to upgrade regions together so
> organize the effort appropriately.
> 
> Unfortunately, there isn't really anything that we can do besides this
> except roll back the LibOMV 0.7.0 commit and stay on an older version
> of libOMV.  There isn't any way to programmatically change, without
> forking OpenMetaverse.StructureData, what should go over the wire
> serialization.   Additionally, on the receiving side, there's no way
> to know what was a UUID and what was a string with UUID text in it's
> contents so converting it there is also out of the question.
> 
> Additionally, any services that make use of the json serialization are
> affected (json stats come to mind).
> 
> Be aware of these changes
> 
> Regards
> 
> Teravus
> ___
> 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] World map - map doesnt load on large grids

[Frisby, Adam]

No, I was suggesting that -- make it so we alter world map related packets/caps 
to reflect a lower coordinate range. The median of the grid, could be used to 
determine the 'center of mass' for the world map.

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Teravus Ovares
> Sent: Monday, 20 July 2009 10:27 AM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] World map - map doesnt load on large grids
> 
> Normally the client sends a post to one of the map CAPs, and then
> sends a bunch of UDP requests.On OSGrid, in the 10,000 range, the
> client just posts to the map CAP unless you click in an empty maptile
> space.Since no requests are made, no maptiles show. The hack
> is that when the client posts to the map cap, immediately send the map
> data for 10 spaces above and below the region the avatar is currently
> in.
> 
> Regards
> 
> Teravus
> 
> On Mon, Jul 20, 2009 at 12:54 PM, Frisby, Adam
> wrote:
> > Subtract 8,000 from all coordinates for the world map?
> > (derive 8,000 from the median position on the grid)
> >
> > Adam
> >
> >> -Original Message-
> >> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> >> boun...@lists.berlios.de] On Behalf Of Frisby, Adam
> >> Sent: Monday, 20 July 2009 9:34 AM
> >> To: opensim-dev@lists.berlios.de
> >> Subject: Re: [Opensim-dev] World map - map doesnt load on large
> grids
> >>
> >> Lame SL is lame.
> >>
> >> Is anyone able to patch Hippo to fix this issue? (tx?)
> >>
> >> Adam
> >>
> >> > -Original Message-
> >> > From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> >> > boun...@lists.berlios.de] On Behalf Of Teravus Ovares
> >> > Sent: Monday, 20 July 2009 9:27 AM
> >> > To: opensim-dev@lists.berlios.de
> >> > Subject: Re: [Opensim-dev] World map - map doesnt load on large
> grids
> >> >
> >> > Normally, the client requests things as they are scrolled on to,
> >> > however, in OSGrid's case, the regions are way outside the normal
> >> > space that the client is used to.     Remember that 4096m bug that
> >> > causes regions to be a void space when you teleport?   That also
> >> > applies to the map.     In fact, on OSGrid, without a hack I
> created
> >> > for exactly that situation, the map doesn't display at all until
> you
> >> > click on a region space.
> >> >
> >> > A couple of potential solutions:
> >> >
> >> > 1.  Move all regions within 4096 region block spaces.
> >> > 2.  Expand the hack that I created so that it forces sending a
> >> > significantly larger amount of regions.
> >> >
> >> >
> >> > Regards
> >> >
> >> > Teravus
> >> >
> >> >
> >> >
> >> > On Mon, Jul 20, 2009 at 11:31 AM, Frisby,
> Adam
> >> > wrote:
> >> > > Does anyone know what packets/messages the client requests as
> the
> >> map
> >> > is
> >> > > scrolled & zoomed - right now, only the initial area is shown
> when
> >> > you load
> >> > > the map. On OSGrid this represents like 10% of the total world
> map
> >> > being
> >> > > visible.
> >> > >
> >> > >
> >> > >
> >> > > 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] World map - map doesnt load on large grids

[Frisby, Adam]

Subtract 8,000 from all coordinates for the world map?
(derive 8,000 from the median position on the grid)

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Frisby, Adam
> Sent: Monday, 20 July 2009 9:34 AM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] World map - map doesnt load on large grids
> 
> Lame SL is lame.
> 
> Is anyone able to patch Hippo to fix this issue? (tx?)
> 
> Adam
> 
> > -Original Message-
> > From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> > boun...@lists.berlios.de] On Behalf Of Teravus Ovares
> > Sent: Monday, 20 July 2009 9:27 AM
> > To: opensim-dev@lists.berlios.de
> > Subject: Re: [Opensim-dev] World map - map doesnt load on large grids
> >
> > Normally, the client requests things as they are scrolled on to,
> > however, in OSGrid's case, the regions are way outside the normal
> > space that the client is used to. Remember that 4096m bug that
> > causes regions to be a void space when you teleport?   That also
> > applies to the map. In fact, on OSGrid, without a hack I created
> > for exactly that situation, the map doesn't display at all until you
> > click on a region space.
> >
> > A couple of potential solutions:
> >
> > 1.  Move all regions within 4096 region block spaces.
> > 2.  Expand the hack that I created so that it forces sending a
> > significantly larger amount of regions.
> >
> >
> > Regards
> >
> > Teravus
> >
> >
> >
> > On Mon, Jul 20, 2009 at 11:31 AM, Frisby, Adam
> > wrote:
> > > Does anyone know what packets/messages the client requests as the
> map
> > is
> > > scrolled & zoomed - right now, only the initial area is shown when
> > you load
> > > the map. On OSGrid this represents like 10% of the total world map
> > being
> > > visible.
> > >
> > >
> > >
> > > 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] World map - map doesnt load on large grids

[Frisby, Adam]

Lame SL is lame.

Is anyone able to patch Hippo to fix this issue? (tx?)

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Teravus Ovares
> Sent: Monday, 20 July 2009 9:27 AM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] World map - map doesnt load on large grids
> 
> Normally, the client requests things as they are scrolled on to,
> however, in OSGrid's case, the regions are way outside the normal
> space that the client is used to. Remember that 4096m bug that
> causes regions to be a void space when you teleport?   That also
> applies to the map. In fact, on OSGrid, without a hack I created
> for exactly that situation, the map doesn't display at all until you
> click on a region space.
> 
> A couple of potential solutions:
> 
> 1.  Move all regions within 4096 region block spaces.
> 2.  Expand the hack that I created so that it forces sending a
> significantly larger amount of regions.
> 
> 
> Regards
> 
> Teravus
> 
> 
> 
> On Mon, Jul 20, 2009 at 11:31 AM, Frisby, Adam
> wrote:
> > Does anyone know what packets/messages the client requests as the map
> is
> > scrolled & zoomed - right now, only the initial area is shown when
> you load
> > the map. On OSGrid this represents like 10% of the total world map
> being
> > visible.
> >
> >
> >
> > 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] World map - map doesnt load on large grids

[Frisby, Adam]

Does anyone know what packets/messages the client requests as the map is 
scrolled & zoomed - right now, only the initial area is shown when you load the 
map. On OSGrid this represents like 10% of the total world map being visible.

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

Re: [Opensim-dev] Looking for people with CLI/MSIL experience!

[Frisby, Adam]

Is this a project to implement CAS?

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Imaze Rhiano
> Sent: Monday, 20 July 2009 12:48 AM
> To: opensim-dev@lists.berlios.de
> Subject: [Opensim-dev] Looking for people with CLI/MSIL experience!
> 
> Hi!
> 
> Sorry, this is bit off topic, because this message doesn't just concern
> Open SIM development, it hopefully have also impact to Mono Project and
> SL.
> 
> We are looking for people with CLI/MSIL experience - or people who are
> motivated and quick learners - to join the project which goal is to
> write test suite for Mono project's metadata verifier. Also persons
> with
> less programming experience would be most helpful to join the project -
> there are lot's of things to do that don't require any programming
> skills!
> 
> Metadata verifier is critical component of Mono's sandbox
> (http://mono-project.com/MonoSandbox).When sandbox is completed it
> should allow "execute arbitrary untrusted code and ensure that the
> untrusted code does not compromise the security of the system". It
> enables  to run safely scripts that are written by C#, VB.NET or other
> CLI compatible language in SL or Open SIM servers. For Mono, sandbox is
> one big requirement under their Moonlight project (Open source version
> of M$ Silverlight) (http://mono-project.com/MoonlightNotes).
> 
> Currently we are doing very boring task called "reading specifications"
> - and same time we are collecting rules that are related to metadata
> verifier to very-big-ebil-list that we can use to generate test cases.
> When this is done, we hopefully can start writing test cases for
> metadata verifier. There is already working Mono metadata verifier that
> can analyze lower level logical format of metadata, but mostly due to
> lack of tests development has stopped to those tracks. Writing of test
> cases needs some lower level understanding of the runtime environment -
> that is where CLI/MSIL experience comes very handy.
> 
> To get more information about project:
> - VISIT in our Wiki:
> http://www.xugumadison.org/csharp-sl/index.php?title=Main_Page
> (includes
> meeting minutes, project plan, etc)
> - CONTACT to me in SL (Imaze Rhiano) or send mail for me
> - JOIN our SL group "C# Scripters".
> - JOIN to our next meeting: 10:00 SLT (PDT)/ 17:00 GMT (NO DST!) /
> 19:00
> CET- 21th July 2009 - IRC #monodev - http://mono-project.com/IRC
> 
> If you want know about more Metadata verifier
> - READ http://mono-project.com/MonoSandbox
> - CHECK out mono's source code
> - TALK with Kumpera in #monodev channel - http://mono-project.com/IRC
> 
> If you are not familiar with CLI/MSIL then you here are some good
> sources to start with:
> - Kenny Kerr: Introduction to MSIL
> (http://weblogs.asp.net/kennykerr/archive/2004/09/07/introduction-to-
> msil-part-1-hello-world.aspx)
> - Standard ECMA-335 Common Language Infrastructure (CLI)
> (http://www.ecma-international.org/publications/standards/Ecma-335.htm)
> - NET Common Language Runtime Unleashed (book preview)
> (http://books.google.fi/books?id=3059QRxPNQcC&printsec=frontcover&dq=.n
> et+common+language+runtime&ei=vhxjSvbBKqK2yATsxIDaDw)
> 
> Thank you!
> 
> 
> (Also sorry about my bd engrish :P)
> 
> ___
> 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] Separate SceneObjectGroup/Part into separate classes/interfaces

[Frisby, Adam]

Look at MRM.IObject - seriously.

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Melanie
> Sent: Saturday, 18 July 2009 11:27 AM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] [Proposal] Separate SceneObjectGroup/Part
> into separate classes/interfaces
> 
> A clear and loud +1 on getting started on removing this SOG/SOP
> hierarchy thing.
> The basic "node" could be stripped down to position, rotation,
> scale, parent, children and a few more things, with the prim stuff
> being in it's own class like Inventory was already moved out.
> 
> Accessors for the common, and frequently used, things like inventory
> would keep things moving at a manageable speed, so I'm also all for
> that.
> 
> I don't now about the interface registry, I'd rather see this
> "minimal" class be a base class from which more specific classes
> inherit and that handles the connections to Scene and the linking
> stuff. Seems more sensible to make this most used entity be fast,
> specific subclasses rather than registered interfaces. But... a
> subclass could offer that registration method if it needs to be that
> extensible..
> 
> Melanie
> 
> MW wrote:
> > Both SceneObjectGroup and Part are growing beyond manageable sizes
> (with both of them over 3000 lines long), and are not very easy to
> change when trying to make custom classes bassed on them (as I think
> Sean found out recently during his attempts).
> >
> > Ideally I think we would all like to see the separate Group and Part
> architecture replaced with a architecture that was more like a Node
> based scenegraph , and had a hierarchy of SceneObjects. But I think we
> all know of the problems in doing that, and how much work is involved.
> >
> > So as a small step in (hopefully) that direction, I propose to start
> splitting those two classes up, and having something similar to the
> interface registry we use in various of parts of the architecture.
> (RegisterInterface , RequestInterface() ).
> >
> > So things like the methods for editing prims would move out into a
> separate class; for example ISceneObjectGroupEditing. And then when the
> scenegraph wants to call a editing method on a Group, it can call :
> >
> > Group.RequestInterface();
> >
> >
> > I believe that this will at least make the code more manageable and
> make those classes easier to customise. I also hope that it will make
> it easier to head towards a new combined architecture for prim
> handling.
> >
> > The draw back could be performance, as we will have the overhead of
> calling those methods to request the correct interfaces. Although we
> could do the same as we do in scene and have properties that can access
> the common interfaces. (eg. SceneObjectGroup.Editor)
> >
> >
> >
> >
> >
> >
> >
> > -
> ---
> >
> > ___
> > 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 documentation - InventoryItems.InvType

[Frisby, Adam]

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

Re: [Opensim-dev] ipv6? (was: STUN for OpenSim?)

[Frisby, Adam]

IPv6 will work on non-UDP protocols. Eg; the IRCd clientstack supports IPv6. 
LLUDP will be IPv6 incompatible as long as it relies on circuits which depend 
on 32bit addresses.

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Kyle Hamilton
> Sent: Tuesday, 14 July 2009 3:44 PM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] ipv6? (was: STUN for OpenSim?)
> 
> Speaking of... is there any IPv6 work going on at this point?
> 
> -Kyle H
> 
> 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

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

[Frisby, Adam]

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
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] STUN for OpenSim?

[Frisby, Adam]

The big catch here is that SL's LLUDP relies on 'Circuits', also known as a 
'poor reinvention of TCP/IP sessions'; Circuits are sent by things like 
neighbouring sims to establish a neighbouring connection (important for seeing 
the other sim) -- but the other sim can't really know if your session is in 
front of, or behind a NAT'd firewall; and if it's behind - what your local 
addressable address should be.

This means, your still going to need a router supporting NAT Loopback - which 
is unfortunately all too rare.

That being said, if you want automatic port forwarding - UPnP is your best 
friend ever.

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Infinity Linden
> Sent: Tuesday, 14 July 2009 3:49 PM
> 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] Currency

[Frisby, Adam]

I will, if you can prove you know enough about computer security and writing 
secure code.

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Melanie
> Sent: Saturday, 11 July 2009 6:48 AM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] Currency
>
> As far as I now, the "currency" project (DTL currency) is maintained
> by DTL and may not accept outside developers.
>
> Melanie
>
> Aldon Hynes wrote:
> > Melanie, et al.,
> >
> >Thanks for the update.  I've joined the opencurrency project and
> have put
> > in a request to join the currency project as well.  Is there any
> > documentation on how to install this?
> >
> >I've added links to both projects to the bottom of the Money page
> in the
> > OpenSim wiki.  Is the OpenSim Wiki sufficient for handling this
> project, or
> > is there need and interest in a parallel Wiki specific to currency
> > implementations for OpenSim?
> >
> > Aldon
> >
> > -Original Message-
> > From: opensim-dev-boun...@lists.berlios.de
> > [mailto:opensim-dev-boun...@lists.berlios.de]on Behalf Of Melanie
> > Sent: Saturday, July 11, 2009 9:17 AM
> > To: opensim-dev@lists.berlios.de
> > Subject: Re: [Opensim-dev] Currency
> >
> >
> > The project is "opencurrency" on OpenSim forge. It uses a LAMP
> > server. The ASP.NET is a different implementation.
> >
> > Melanie
> >
> > Aldon Hynes wrote:
> >> Melanie, Fly Man, et al.,
> >>
> >>It is good to hear that a sample currency module is available on
> forge
> >> and that there are people interested in working on developing it.
> On
> >> Wednesday, I sent an email, offering to help with a currency project
> and
> >> asked if anyone knew where the sample currency module was.  No one
> stepped
> >> forward to help, or to tell me where I could find any exisiting
> >> implementation.
> >>
> >>I searched around and couldn't find anything.  On the OpenSim
> Wiki
> > there
> >> is the
> >> http://opensimulator.org/wiki/Money which "is intended as an open
> > discussion
> >> board for ideas regarding an in-world financial system".
> Unfortunately,
> > it
> >> does not provide any links to sample implementations.
> >>
> >>It does seem like this may primarily be a documentation problem.
> After
> >> reading your emails today and doing a bit of searching, I did find
> >> http://forge.opensimulator.org/gf/project/currency/ In searching
> through
> > the
> >> repository, I did find Currency_DesignDocument.doc which provides
> >> information about doing an installation of the module.
> (Installation
> >> information can currently be found in section 2.2.1.1.2 )
> >>
> >>It does appear as if it depends on having a ASP.NET enabled
> webserver,
> >> which rules me out from being able to do testing at this time.  It
> would
> > be
> >> interesting to see if a LAMP based server could be developed, or
> perhaps a
> >> lighter weight service that simply uses the existing databases in a
> > standard
> >> OpenSim installation.
> >>
> >>With that, I am willing to set up an OpenSimCurrency Wiki and
> help
> >> document this project.  I can help with a LAMP money server that
> could
> >> potentially be integrated with other interfaces. (For example,
> Jeroen was
> >> asking about a WiXTD interface).
> >>
> >>All of that said, I am heading off on vacation for the next two
> weeks.
> > I
> >> will have spotty access here and there and can't really focus on
> this
> >> substantially until August.  However, I would love to get some
> responses
> > now
> >> and see what we can do to get currency much more usable for anyone
> that
> >> wants it.
> >>
> >> Aldon
> >>
> >> -Original Message-
> >> From: opensim-dev-boun...@lists.berlios.de
> >> [mailto:opensim-dev-boun...@lists.berlios.de]on Behalf Of Melanie
> >> Sent: Saturday, July 11, 2009 7:12 AM
> >> To: opensim-dev@lists.berlios.de
> >> Subject: Re: [Opensim-dev] Currency
> >>
> >>
> >> Well, I am maintaining the sample currency module on forge now and
> >> keeping it available.
> >>
> >> I believe you are aware that I have a commercial RMT module, and had
> >> it for more than a year.
> >>
> >> We have simply decided it can't be in core, but we are still making
> >> it as easy to access and integrate it as we can.
> >> We're not against people having money. If we were, we would have
> >> remove the interfaces.
> >> We just can't risk it in core.
> >>
> >> Melanie
> >>
> >> Fly Man wrote:
> >>> Well, what a long discussion about something that was already
> decided
> >>> long ago 
> >>>
> >>> There is the OpenCurrency module for those that want to play around
> >>> with it and there are some other ppl working on Money related
> things.
> >>>
> >>> The removal of the SampleMoney module was 1 of the things that I
> left
> >>> the OpenSim development scene, as the name of the module said:
> "It's
> >>> SAMPLE money"
> >>>
> >>> I know there 3 people working on a r

Re: [Opensim-dev] mono *.exe crashes if screen is smaller than created...

[Frisby, Adam]

This sounds like a NLog bug actually -- all our console output is formatted by 
nlog (since it also does our logging, etc)

Adam

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Torrid Luna
> Sent: Friday, 10 July 2009 6:50 PM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] mono *.exe crashes if screen is smaller than
> created...
> 
> Also sprach Mojito Sorbet (mojitot...@gmail.com):
> 
> > Why can't the consoles just use ReadLine and WriteLine?  That would
> make it
> > easier to interface with in a variety of ways?
> 
> +1
> Coming from Unix, I had these kind of problems only with Cisco
> Terminals, Windows Telnet emulations and Opensim so far. stdin/stdout
> is
> so much more convenient, and it would save a lot of screen sessions.
> 
> 
> Cheers,
> Torrid
> --
> Excerpts of "1 Shell Scripts" -- today: monkeytypewriter
> $ cat /dev/random | strings | fmt | less
> 
> ___
> 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