from:"Justin Clark\-Casey"

Re: [Opensim-dev] Legacy region XML support - Remove?

2014-04-11 Thread Justin Clark-Casey


I don't see any problem with removing this - it's an extremely old format that 
I'd be surprised if anybody still uses.

On 11/04/14 02:03, Melanie wrote:

Hi,

the RegionInfo class supports an ancient form of XML, one that is
based on attributes rather than tags.

At this point, we believe no one uses this format anymore. Further,
NINI offers another form of XML that is much more up to date and a
better replacement for the ancient XML in any case.

The affected installations would be those that use pre-0.6
configuration files (regions.xml) or use web loading.

The old config files would need to be redone by hand in .ini format,
and people who web-load would need to change the server scripts to
provide the same data in the new format, which is not too hard a task.

I propose to remove the support for the legacy format, which has
last been updated in 2007 and has been unused for two major revisions.

Thoughts are welcome.

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




--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Parcel Access Enforcement

2014-04-10 Thread Justin Clark-Casey

   ___
   Opensim-dev mailing list
   Opensim-dev@lists.berlios.de mailto:Opensim-dev@lists.berlios.de
   https://lists.berlios.de/mailman/listinfo/opensim-dev
  
  
  
  
   --
   ===
   http://osgrid.org/
   http://simhost.com
   http://twitter.com/jstallings2
  
  
  
  
  
  
   ___
   Opensim-dev mailing list
   Opensim-dev@lists.berlios.de mailto:Opensim-dev@lists.berlios.de
   https://lists.berlios.de/mailman/listinfo/opensim-dev
  ___
  Opensim-dev mailing list
  Opensim-dev@lists.berlios.de mailto:Opensim-dev@lists.berlios.de
  https://lists.berlios.de/mailman/listinfo/opensim-dev
 
 
 
 
  --
  ===
  http://osgrid.org/
  http://simhost.com
  http://twitter.com/jstallings2
 
 
 
 
 
 
  ___
  Opensim-dev mailing list
  Opensim-dev@lists.berlios.de mailto:Opensim-dev@lists.berlios.de
  https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de mailto:Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev




--
===
http://osgrid.org/
http://simhost.com
http://twitter.com/jstallings2



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




--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Preparing for OpenSimulator 0.8

2014-04-02 Thread Justin Clark-Casey

Yes, that would be one alternative. But to emphasise, I'm only asking for a common-sense approach to avoid
destabilising master right now, not a blanket ban on commits or anything like that.

On 02/04/14 02:45, Michael Emory Cerquoni wrote:

+1 no disagreement here! anyone who wants to get crazy can do so in a new
branch for now?

On Apr 1, 2014 9:42 PM, Justin Clark-Casey jjusti...@googlemail.com
mailto:jjusti...@googlemail.com wrote:

Hi folks. For the past 3 years, we've had a significant OpenSimulator
release at about 4 to 8 month intervals.

As the last major release (0.7.6) was in September 2013, we are due for
another, and this seems like a reasonable
point. From my perspective, releases drive a very significant level of
OpenSimulator adoption. It's also the case
that I may have a limited window of time to act as release manager, after
which things may get very busy for me for
an extended period.

There was some disagreement over how the last release was handled,
particularly over the period when I asked that
developers take care to leave master stable. However, it's quite hard for
me to see how this could be done in
another way without significantly more manpower. Even when the release is
branched, if the release branch and
master diverge significantly (or master is broken) then a lot of the
testing done by users is lost - very few people
actually pick up and test release candidates.

So unless there is disagreement, I'm going to ask that people take care to
keep master stable until the end of April
or release, whichever occurs first. This certainly does not mean a halt to
development on master, it's just a
request that people take a common sense approach to holding off from
putting in destabilising or very complicated
changes for a while, unless these are to fix significant bugs or
regressions.

I'm very happy to hear alternatives, though I would also need people to
help if they involve more work. In any
case, Robert has very kindly volunteered to look at some of the current
regressions but more help is always very
welcome.

The current regressions or very major bugs have a 0.8 target in Mantis. As
with every release so far, only major
regressions are guaranteed to receive some sort of attention, where the
answer may still be WONTFIX for this release.

Regards,

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

Re: [Opensim-dev] REST handlers use partial string matching

2014-04-02 Thread Justin Clark-Casey

Yeah, it's an interesting problem. A quick google doesn't reveal any obvious solutions, though one StackOverflow thread
[1] has an interesting approach of wrapping multiple requests in a 'batch' request.

So I don't object to this, but I don't think that we should kid ourselves that we're writing pure REST interfaces.
get_asset_exists is effectively an RPC call which POSTs a bunch of UUIDs and gets data back - it is not an HTTP verb
operating on a resource.

Also, it would be great if you could add this new call to [2]. I'm very slowly trying to document all the various
interfaces, protocols and calls, so that it's possible for other projects to implement them, to get a better overview of
interfaces in OpenSimulator, etc.

[1]
http://stackoverflow.com/questions/14636332/convention-for-combining-rest-requests-and-replies
[2] http://opensimulator.org/wiki/AssetService

On 01/04/14 20:49, Oren Hurvitz wrote:

Re: why use POST instead of HEAD: because this lets me check the existence of
many assets at once with a single HTTP request. The main use of the
AssetsExist call is with HGAssetGatherer, which knows the full list of
assets that it wants to send, so it's able to check all of them at once.

--
View this message in context:
http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119p7579127.html
Sent from the opensim-dev mailing list archive at Nabble.com.
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
.

Re: [Opensim-dev] Viewer doesn't render attachments after teleport

2014-04-02 Thread Justin Clark-Casey

I also used to see this issue a lot when testing attachments. At the time, I remember looking into it and adjusting a
few things to make OpenSimulator's output packet order match LL much more closely but with no effect. I haven't seen it
for a while so I was hoping it had gone away, though that may also just be because I don't get the chance to go in-world
very often.

One possible thing to investigate is whether SOG updates with a position of 0,0,0 are somehow getting out to the
region before attachments are properly set up. This might account for audio issues, etc. It might also be a shot in
the dark, though I think this used to happen under some circumstances (along with other effects such as HUD attachments
wrongly appearing on other viewer's screens).

On 02/04/14 12:20, Melanie wrote:

I don't know if this may be related, but for some reason OpenSim
fails to update the viewer's notion of position properly.

The most noticeable effect is that sometimes after changing regions
or even parcels, sound is no longer heard. The audibility check
happens viewerside, just as the object visibility check.

If the viewer gets a wrong location, it may consider the attachments
as too far away and not render them - that is probably related to
why zooming can make them appear.

Therefore I don't believe we need to send any extra packets related
to these objects, but rather we are missing some packet or sending
wrong data related to the avatar's location.

This appears to be the case on moving in world as well as teleports,
but I have so far never observed it at login.

Melanie

On 02/04/2014 13:16, Oren Hurvitz wrote:

I got some great advice off-list from Nicky Perian. When there's a problem of
missing prims, go to the Graphics Preferences and toggle the option Basic
shaders. I tried this, and toggling this option (on or off, both work)
makes the missing prims appear immediately.

This proves that the viewer has the correct data, and it's just not showing
it. But I still want to find some combination of packets that will make the
viewers show the prims, since obviously most users will not know to use this
trick, and it's a hassle.

--
View this message in context:
http://opensim-dev.2196679.n2.nabble.com/Viewer-doesn-t-render-attachments-after-teleport-tp7579143p7579146.html
Sent from the opensim-dev mailing list archive at Nabble.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] REST handlers use partial string matching

2014-04-01 Thread Justin Clark-Casey

Hi Oren.  I believe the expected way to retrieve metadata (and effectively an existence check) for a resource in REST 
would be to send a HEAD request [1] to the url, rather than to have a separate endpoint.


I think changing the handling to exact matching is fine - I can't think why partial matching is done currently and I 
can't see how it makes sense in an HTTP context.  As far as I know nothing makes use of partial matching.


[1] 
http://books.google.co.uk/books?id=XUaErakHsoACpg=PA98lpg=PA98dq=restful+web+services+%22OPTIONS+method+lets%22source=blots=5jkmCnpNmysig=mXt_bcmXcZhoU6hFFm0L5j14IvEhl=ensa=Xei=Hf06U--1E7GM7Aad2YHwAwved=0CDMQ6AEwAA#v=onepageq=restful%20web%20services%20%22OPTIONS%20method%20lets%22f=false


On 01/04/14 14:00, Oren Hurvitz wrote:

I tried to add a REST handler at the endpoint /assets_exist. It turns out
that I can't do that, because REST handlers are searched using partial
string matches, so servers that don't implement the new handler will
mistakenly choose the /assets endpoint instead.

For now, I solved the problem by using a different endpoint:
/get_assets_exist.

For the future, I think that this should be changed so that only full string
matches work. Otherwise each time a new handler is added it will have to
find an endpoint name that isn't a prefix of any current endpoint -- a
difficult and error-prone task. Before I do that, does anyone know of
endpoints that rely on the current behavior (partial string matches)?



--
View this message in context: 
http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119.html
Sent from the opensim-dev mailing list archive at Nabble.com.
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev




--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] REST handlers use partial string matching

2014-04-01 Thread Justin Clark-Casey

In what context is such partial matching required? It is not a requirement of
REST, as far as I know.

On 01/04/14 18:55, Melanie wrote:

The REST URLs need to use partial matching, however, current
semantics are broken.

Without partial matching, URLS like /assets/782911. would not
work. the issue here is that it should match whole URL parts, not
partial URL parts. Matching partial words as it does now seems like
someone was cutting corners, it's not by design.

/assets/ should match /assets/9887234.. but not /assets_exist.
The slash is the differentiator and partial compares of URL string
prefixes should be done by full-string matches of slash/delimited
parts, not prefix matching of the entire URL.

Melanie

On 01/04/2014 15:00, Oren Hurvitz wrote:

I tried to add a REST handler at the endpoint /assets_exist. It turns out
that I can't do that, because REST handlers are searched using partial
string matches, so servers that don't implement the new handler will
mistakenly choose the /assets endpoint instead.

For now, I solved the problem by using a different endpoint:
/get_assets_exist.

For the future, I think that this should be changed so that only full string
matches work. Otherwise each time a new handler is added it will have to
find an endpoint name that isn't a prefix of any current endpoint -- a
difficult and error-prone task. Before I do that, does anyone know of
endpoints that rely on the current behavior (partial string matches)?

--
View this message in context:
http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119.html
Sent from the opensim-dev mailing list archive at Nabble.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] REST handlers use partial string matching

2014-04-01 Thread Justin Clark-Casey

Ah okay, I see what you mean. Yes, the asset/ part matches the asset handler and then it is in charge of interpreting
the subsequent 456392f6-c0b3-a346-6465-8218cbe7abe84592 section of the path.

When you said 782911... below I thought that you were talking about UUID fragments as used by git to identify commits,
where 782911 would normally be enough to identify an asset like 782911f6-c0b3-a346-6465-8218cbe7abe84592 so you
could say something like GET http://myserver.com/asset/782911. But that was a misinterpretation.

On 01/04/14 20:00, Melanie wrote:

It is required because it's the basis of extra path info. It's not
part of REST, but rather part of HTTP.

Requesting

/asset/456392f6-c0b3-a346-6465-8218cbe7abe84592

which is not a registered URL, will invoke

/asset/

which is. The ID passed as part of the URL is then given to that
handler as the extra path info. You have the same thing in apache.

Basically, any URL longer than and starting with a registered URL
will invoke that registered URL with extra path info.
The fallacy in our server is that the matching isn't by path parts,
but character-wise.

Melanie

On 01/04/2014 20:03, Justin Clark-Casey wrote:

In what context is such partial matching required? It is not a requirement of
REST, as far as I know.

On 01/04/14 18:55, Melanie wrote:

The REST URLs need to use partial matching, however, current
semantics are broken.

Melanie

On 01/04/2014 15:00, Oren Hurvitz wrote:

For now, I solved the problem by using a different endpoint:
/get_assets_exist.

___
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] Preparing for OpenSimulator 0.8

2014-04-01 Thread Justin Clark-Casey

Hi folks. For the past 3 years, we've had a significant OpenSimulator release
at about 4 to 8 month intervals.

As the last major release (0.7.6) was in September 2013, we are due for another, and this seems like a reasonable point.
From my perspective, releases drive a very significant level of OpenSimulator adoption. It's also the case that I may
have a limited window of time to act as release manager, after which things may get very busy for me for an extended period.

There was some disagreement over how the last release was handled, particularly over the period when I asked that
developers take care to leave master stable. However, it's quite hard for me to see how this could be done in another
way without significantly more manpower. Even when the release is branched, if the release branch and master diverge
significantly (or master is broken) then a lot of the testing done by users is lost - very few people actually pick up
and test release candidates.

So unless there is disagreement, I'm going to ask that people take care to keep master stable until the end of April or
release, whichever occurs first. This certainly does not mean a halt to development on master, it's just a request that
people take a common sense approach to holding off from putting in destabilising or very complicated changes for a
while, unless these are to fix significant bugs or regressions.

I'm very happy to hear alternatives, though I would also need people to help if they involve more work. In any case,
Robert has very kindly volunteered to look at some of the current regressions but more help is always very welcome.

The current regressions or very major bugs have a 0.8 target in Mantis. As with every release so far, only major
regressions are guaranteed to receive some sort of attention, where the answer may still be WONTFIX for this release.

Regards,

Re: [Opensim-dev] Optimize pushing assets to other grids

2014-03-31 Thread Justin Clark-Casey

I originally put in the MajorInterfaceVersion back in 2008 but I now think that's a very bad way to handle updates in a
distributed system with no central control.

Instead, just like the web, the protocol should be designed with extensbility in mind so that the system can evolve
without massive disruption [1], allowing old and new components to co-exist.

I think that one more planned bump of MajorInterfaceVersion would be acceptable to introduce extensibility but continual
bumps are going to do damage to the system and people's confidence in the system. Not only does it affect the Hypergrid
idea, but also in a large grid it makes it very difficult, if not impossible, to experiment with newer updates if they
are not protocol compatible.

I'll also note that the version number has not been bumped since October 2010. Unsurprisingly, nobody has wanted to
inflict (or be blamed) for that pain so everybody has been at pains not to introduce incompatible updates (or only
incompatible in minor ways). But really this compatibility should be achieved with a planned mechanism rather than the
ad hoc measures that have always been used, and where one day luck runs out.

[1] https://www.ics.uci.edu/~fielding/pubs/dissertation/net_app_arch.htm#sec_2_2

On 31/03/14 17:51, Melanie wrote:

There is no implicit versioning in the actual request protocol. That
would have been impossible to maintain in the long run. Instead,
there is a protocol version. We can bump it when there are
incompatible changes on any protocol and it invalidates all of them.
So a sim version 7 will refuse to connect to a server version 6 and
vice versa. This gives us both control and simplicity.

Melanie

On 31/03/2014 18:45, Jim Williams wrote:

Seems reasonable to me...A design approach I would have taken.

One question. Is there some sort of versioning built into the protocol?
One verb yes, but the dictionary numbers the definitions.

On Mon, Mar 31, 2014 at 12:35 PM, Melanie mela...@t-data.com wrote:

This isn't designed as RPC, it's designed as REST. One URL/VERB
combination for each function.
We wanted to get away from the RPC concept. Let's not take backwards
steps here.

Melanie

On 31/03/2014 15:15, Oren Hurvitz wrote:

This isn't overloading: it's an RPC endpoint that accepts many methods.

You

wouldn't create a separate endpoint for each method, would you?

--
View this message in context:

http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579104.html

Sent from the opensim-dev mailing list archive at Nabble.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] Prebuild versioning

2014-03-26 Thread Justin Clark-Casey


On 26/03/14 18:09, James Hughes wrote:

On 03/26/2014 01:24 PM, Oren Hurvitz wrote:

I'm a bit confused by your question because my patches are *already* in the
OpenSim Git, so I don't know what you mean by Would it make sense to merge
these [changes]. Merge them with what?

Anyhoo, if you're up to resurrecting Prebuild in Github then more power to
you! My patches to Prebuild are, of course, open-source and free to use.




Ahhhahhh, I see. I spoke before looking. We're all set then.


I'm quite surprised Prebuild is so dead - perhaps that shows how little 
cross-platform .NET stuff there is.

I was going to suggest putting it up on Github though that would suggest somebody is maintaining it for general use, 
which I'm not sure any of us have the time/inclination to do (I don't).


Having said, that a quick search of github reveals that lkalif has put up a fork [1].  Maybe it would be worth porting 
patches to that, though I know our Prebuild also has some nasty very OpenSimulator specific hacks in it which would need 
to be generalized first.


btw, I don't remember actually pushing any patches to the Prebuild project myself though it's quite possible I did some 
minor stuff and have forgotten about it.


[1] https://github.com/radegastdev/prebuild

--
Justin Clark-Casey (justincc)
OSVW Consulting
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] Prebuild versioning

2014-03-25 Thread Justin Clark-Casey

Hi Oren.  In commit f5ae36d7e25a20199d676e53a066be79f76b580d, I see you bumped update prebuild for .net 4.5 and bumped 
the version number (and some internal numbers) up to 2.0.6.


Whilst I know this has happened before, do you see any issue with tagging these versions as having OpenSimulator project 
patches applied?  For instance, 2.0.3-opensim3 as the last actual prebuild release 2.0.3.  This can save a lot of 
confusion in the future, particularly if prebuild ever does do another release (unlikely, I know).


--
Justin Clark-Casey (justincc)
OSVW Consulting
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] Unexplained disappearance of 2 commits from OpenSim/Services/Connectors/Hypergrid/UserAgentServiceConnector.cs

2014-03-25 Thread Justin Clark-Casey

It came to light today that two code changes have somehow gone completely missing from the git history of 
UserAgentServiceConnector.cs


These were commits afb2e07 (Fri Jan 24 2014, Robert Adams) and cf61cdf (Wed Feb 5 2014, Roger Kirkman/Zadark).  These 
were part of variable region support for home teleports.  I reinserted these as commit 2fbb906.


Right now, it looks like these may have disappeared on my bc7fda3 merge (Wed Feb 12 2014).  This is quite concerning 
since I didn't think it was possible for a merge to remove commits from git log history for a specific file.  I wasn't 
doing anything exotic, it was just a normal merge.


I will be investigating further very soon and making sure nothing else was affected by this.  But if code seems to have 
gone missing and the commit can be found in general git log but missing from the git log of specific files which 
git show shows it should be present then please let me know.


--
Justin Clark-Casey (justincc)
OSVW Consulting
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] Welcoming orenh and kcozens to the core OpenSimulator development team

2014-03-21 Thread Justin Clark-Casey


Hi folks,

I'm very pleased to announce that as of today, orenh and kcozens have joined 
the OpenSimulator core development team.

You may know Oren Hurvitz (orenh) as the co-founder and VP of RD at Kitely.  He has contributed many great patches to 
OpenSimulator over the years and various new functionality (e.g. multi-region OARs).


kcozens (Plugh in IRC) has helped out with the project for many, many years, both with patches and helping other people 
in OpenSimulator's IRC channels and elsewhere.


Please join me in welcoming them to the team!

--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Proposal: notify clients when Robust changes a user's inventory

2014-03-17 Thread Justin Clark-Casey

Yeah, I think for any really large scale installation you would want to leverage existing pub/sub tech (I used to work
on bits of IBM Websphere MQ in another life).

But I also think you should always be able to set up a 'reasonably' sized installation just with core OpenSimulator,
which means striking an appropriate balance between simplicity and functionality (e.g. creating components which work
well but are still in C# and don't have every conceivable complexity magnifying bell and whistle).

The problem I have with extending the use of IM structures in this case is that whilst it is relatively easy, I also
feel it might push more Second Life-isms into places where they don't need to be present and really don't make sense.
The result could be a very ad hoc and unintuitive interface with fields which are often inapplicable (e.g. 'fromGroup'
and 'imSessionID') and a temptation to abuse the format by serializing parameters into the binaryBucket.

Maybe it can be made to look very generic and I'm unnecessarily concerned. It would make me very happy if this was done
in a separate branch first (if you do decide to continue with this at this time and not implement the other short-term
solution for your particular task) so that we could review the effects. Changes like this tend to calcify very quickly
even when present just in master.

On 14/03/14 03:52, Mister Blue wrote:

The modern code pattern for this sort of thing is for there to be an underlying
notification service (like MQTT,
AWS/SNS, ...) and to build IM and server-to-server comms on top of that. A
serious refactoring would be to rip out the
existing push directed IM system and replace it with a pub/sub notification
system that inventory change notifications,
HGIMs, etc can be built on.
-- mb

On Thu, Mar 13, 2014 at 8:35 PM, Diva Canto d...@metaverseink.com
mailto:d...@metaverseink.com wrote:

I can see the justification for using IM server-side when what needs to be
communicated is intended to reach
specific users who may be online.For generic communications, we should not
use IM. But for those specific cases,
locating the user is the hardest task of the process; IM already does that.
So I'm ok with doing it. As Oren says,
refactoring this at some point would be nice...

On 3/13/2014 8:30 PM, Oren Hurvitz wrote:

Yes, this would be stateless. If the user's client can't be found then
the
message would be dropped.

The logic to find the user's client, especially in the presence of HG,
is
very complicated. I wouldn't want to replicate it, and of course we
wouldn't
want duplicate code. There are only two choices that don't involve code
duplication: use IM as the transport for this message, or a big rewrite
that
would create a generic locate+transport communications system, and then
run
both IM and the new API over that communications system. Option #2 is an
order of magnitude more complex than Option #1, and tbh I don't have the
time to implement it. I can do Option #1 in such a way that it would be
almost like a generic mechanism; so this change would only need to be
done
once, not over and over for each future message we may want to pass.

--
View this message in context:

http://opensim-dev.2196679.n2.__nabble.com/Proposal-notify-__clients-when-Robust-changes-a-__user-s-inventory-__tp7579018p7579027.html

http://opensim-dev.2196679.n2.nabble.com/Proposal-notify-clients-when-Robust-changes-a-user-s-inventory-tp7579018p7579027.html
Sent from the opensim-dev mailing list archive at Nabble.com.
_
Opensim-dev mailing list
Opensim-dev@lists.berlios.de mailto:Opensim-dev@lists.berlios.de
https://lists.berlios.de/__mailman/listinfo/opensim-dev
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
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: notify clients when Robust changes a user's inventory

2014-03-13 Thread Justin Clark-Casey


I think IM is just viewer - simulator and simulator - simulator or am I 
wrong?

On 14/03/14 00:50, Diva Canto wrote:


On 3/13/2014 5:48 PM, Justin Clark-Casey wrote:

I think this would be the first case of service - simulator comms.


Except for IM itself...

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




--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Proposal: notify clients when Robust changes a user's inventory

2014-03-13 Thread Justin Clark-Casey

On first consideration, I can't say that I'm at all keen on overloading GridInstantMessage as am internal service -
simulator protocol above its existing overloading. It's going to have a bunch of irrelevant fields (which is already
the case for the existing LL overloading) and seems to me a bad format to extend to internal operations (I know this is
de-facto done already but at least that's just simulator - simulator).

What are the alternatives? Specific OSDMap messages sent from service - simulator where the simulator has a connector
to receive that message and trigger the bulk update?

Also, I assume this operation wouldn't involve maintaining any state. As you're doubtless aware, it's imperative that
services are kept stateless. Perhaps if there was a need for state this could be isolated as a complete independent
service.

I think this would be the first case of service - simulator comms.

On 13/03/14 19:55, Melanie wrote:

In the past we have studiously acoided abusing thr instant message protocol as
a message transport.
The Linden protocols use the InstantMessageDialog for similar purposes, but way
back when it was decided to not make the same mistake.
So while notifying the client of such inventory changes is a good idea, using
instant messages as the protocol may not be agreeable to all.
Personally, I'm not opposed to it.

Melanie

On 13 Mar 2014, at 18:16, Oren Hurvitz or...@kitely.com wrote:

Sometimes Robust makes changes to a user's inventory on its own initiative
(i.e., not as the result of a client request). E.g., this happens when it
creates the My Suitcase folder. When that happens we should notify the
client, so that the new item or folder will be visible in the inventory
window immediately. Otherwise the user won't be able to see the changes
until they restart the client, which is confusing and frustrating.

I want to use the existing IM service to do this, since it already has 95%
of the necessary code. It already has services in place for Robust to find
which region the user is in, and send a message to that simulator. It can
even do this if the user is in a different grid.

My proposal is to define a special format of GridInstantMessage, which tells
the simulator to send SendBulkUpdateInventory() to the client. The data
about which specific folder/item were added will be encoded in the field
'binaryBucket'. OpenSim will recognize this new type of message, and call
client.SendBulkUpdateInventory().

This mechanism will work cleanly with older simulators: I'll remove a key
field from GridInstantMessage, e.g. 'from_agent_id', and this will cause old
simulators to ignore the message. This can be seen in
MessageTransferModule.processXMLRPCGridInstantMessage(): the removal of a
required field causes the simulator to ignore the message. Only new
simulators will recognize and handle this new type of message.

Any comments or objections? Is there a simpler way to do this?

Oren

--
View this message in context:
http://opensim-dev.2196679.n2.nabble.com/Proposal-notify-clients-when-Robust-changes-a-user-s-inventory-tp7579018.html
Sent from the opensim-dev mailing list archive at Nabble.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] OpenSimulator 0.7.6.1 and 0.7.5.1 now available

2014-01-31 Thread Justin Clark-Casey

Hi folks. As previously discussed [1], OpenSimulator 0.7.6.1 is now available
with release notes at [2].

This is a minor point release which contains only a few bug fix changes. The chief of these (and the reason for making
this release) is one which fixes exceptions and appearance failures if an avatar teleports from a simulator running
current development code to one running OpenSimulator 0.7.6.

As such, you don't need to update unless you may receive users from such simulators via Hypergrid or if you are on an
open grid (such as OSGrid). For more details, please see [1]. That said, there is a fix for a memory leak on maptile
generation with the default generators which might be useful.

Because there are few changes, it will be possible to copy over existing config files from 0.7.6. But as always, please
backup your database before performing any updates.

The same appearance fix has also been applied to 0.7.5.1, which is a similar minor bug fix release on to of 0.7.5.
Release notes for that are at [3]. As yet, there are no plans to go back and patch older releases since it's better to
spend that time fixing current code.

[1] http://lists.berlios.de/pipermail/opensim-users/2014-January/013087.html
[2] http://opensimulator.org/wiki/0.7.6.1_Release
[3] http://opensimulator.org/wiki/0.7.5.1_Release

Best,

[Opensim-dev] OpenSimulator 0.7.6.1-rc1 and 0.7.5.1-rc1 now available for testing

2014-01-24 Thread Justin Clark-Casey

Hi folks,

OpenSimulator 0.7.6.1-rc1 and 0.7.5.1-rc1 are now available for testing [1].

These are minor point releases on top of 0.7.6 and 0.7.5 respectively - these are not branched from master development
code. As such, they only contain a few bug fix changes.

The chief motivation for this is to provide official releases that do not suffer from the appearance exception bug
described in [1]. To summarize, the addition of newer avatar visual parameters to master development code has revealed
a bug in the handling of visual parameters in existing releases. This triggers exceptions in the receiving simulator
and means the avatar will never de-cloud. Unfortunately, there's no way to work around this bug.

Because these parameters are only present in development code, you only need these releases if you might be receiving
avatars from such simulators. So uf you're operating a closed grid using only OpenSimulator 0.7.6 (or earlier), for
instance, then there's no need to update.

That said, I have taken the opportunity to include some minor bugs fixes in OpenSimulator 0.7.6.1-rc1 [3]. 0.7.5.1-rc1
[4], also has some additional changes, though nothing major afaik except for the appearance fix.

Because there are changes other than the appearance code fix, I have decided to issue release candidates first. So if
you see problems with the rc1 which were not present in 0.7.6 or 0.7.5 respectively, please report these in the Mantis.
However, I do not anticipate this to be a long RC phase.

Because these are minor releases, you should be able to safely copy over existing configuration files from 0.7.6 or
0.7.5 respectively. I also don't believe there are any database migrations, though, as always, you should backup your
database before updating.

I am doing a 0.7.5.1-rc1 release as well as 0.7.6.1-rc1 because I know some people did not/could not update from 0.7.5
(released in Feb 2013). However, I have no plans to update older releases.

[1] http://opensimulator.org/wiki/Download
[2] http://lists.berlios.de/pipermail/opensim-dev/2014-January/012135.html
[3] http://opensimulator.org/wiki/0.7.6.1_Release
[4] http://opensimulator.org/wiki/0.7.5.1_Release

Re: [Opensim-dev] New developer with an idea to fix IRCBridgeBot

2014-01-16 Thread Justin Clark-Casey

Hi Tamara.  I've never looked at the IRC module before (and I'm not familiar with the IRC protocol), but could it be as 
simple as calling m_reader.Read() in IRCConnector.Connect() and checking for the 004 and 005 responses?


Naturally, you would also need to set ReadTimeout [1] so that an unresponsive IRC server doesn't hang up the method 
permanently.


I agree, a Sleep would be an ugly hack and something we want to avoid.

I must admit, the IRC module gets very neglected as I doubt any core developer uses it, but very happy to accept patches 
on it.  Others who have worked on it in the past might also want to chime in.


[1] http://msdn.microsoft.com/en-us/library/bk6w7hs8%28v=vs.100%29.aspx

On 16/01/14 20:16, Nihlaeth wrote:

Hey All,
I've been meaning to delve into the opensim code for a while now, and
I finally found a starting point.

I think I have found the problem with the IRCBridgeBot module. It
sends the NICK, USER and JOIN commands at the same time, which causes
the JOIN to be ignored, because ircd's need some time to log you in.

This in turn causes the '[IRC-Connector-0]: cannot connect AvaBot29 to
127.0.0.1:5757: Write failure' error, because it doesn't get join
confirmation, at which bridgebot starts to reconnect, starting the
reconnect spam cycle.

It quite simple to solve, bridgebot should wait for the 004, or 005
(even better) response before sending the join command.

See this example of a telnet irc login (with input captured from
ircbridgebot, but timed differently):
:epona.nihlaeth.nl 001 AvaBot70 :Welcome to the AvaIrc Internet Relay
Chat Network AvaBot70
:epona.nihlaeth.nl 002 AvaBot70 :Your host is
epona.nihlaeth.nl[epona.nihlaeth.nl/6665], running version
charybdis-3.2.1
:epona.nihlaeth.nl 003 AvaBot70 :This server was created Thu Jan 16
2014 at 17:38:10 CET
:epona.nihlaeth.nl 004 AvaBot70 epona.nihlaeth.nl charybdis-3.2.1
DQRSZagiloswz CFILPQbcefgijklmnopqrstvz bkloveqjfI
:epona.nihlaeth.nl 005 AvaBot70 CHANTYPES=# EXCEPTS INVEX
CHANMODES=eIbq,k,flj,CFPcgimnpstz CHANLIMIT=#:15 PREFIX=(ov)@+
MAXLIST=bqeI:100 MODES=4 NETWORK=AvaIrc KNOCK STATUSMSG=@+ CALLERID=g
:are supported by this server

I'd really like to provide a fix for this myself, but I'm afraid I'm
going to need a bit of help with it. Anyone here who wants to help me
get started?

I don't quite understand how the different parts of the module fit
together and communicate. I've identified the spot where the login is
done, but other than building in a sleep (which would be a very ugly
hack), I'm a bit stuck.

I'd really appreciate it!

Kind regards,
Tamara van Haarlem
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev




--
Justin Clark-Casey (justincc)
OSVW Consulting
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] OpenSimulator wiki updated

2014-01-06 Thread Justin Clark-Casey


Hi folks.  I have just updated the OpenSimulator wiki to mediawiki 1.19.9 LTS.

Currently known issue is a custom cleanpage extension (which hides title and categories on some pages) is putting a 
wierd stamp at the bottom when used (e.g. UNIQ7c9bf44d72686d85-cleanpage-0001-QINU).  But please let us know about 
any other issues.  Thanks!


--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] GIt master is broken until further notice

2013-12-12 Thread Justin Clark-Casey

This needs to be done very soon or we need some imminent timeframe.  The rest of the code needs to be merged in so that 
master can be fixed and we can move forward.  Leaving it broken over Christmas would be a very poor show.


On 11/12/13 02:05, Dahlia Trimble wrote:

Melanie has begun merging her region crossing code into git master and expects 
that the changes will break the
repository for some indefinite period. The last usable commit was 
08750501617ca332ab196b2f25030e3c635c9dd6 made on
December 10th. Please do not use commits after this until master is fixed.

-dahlia


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



--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] UUID field at land table

2013-11-22 Thread Justin Clark-Casey


There's really no good reason, afaik.  I expect it's another inconsistency 
introduced by the First Men.

On 22/11/13 03:53, Fernando Francisco de Oliveira wrote:

Some fields at land table have varchar(255) as type/size.

Why isn't it varchar(36) to be used with UUID ?

   `UUID` varchar(255) NOT NULL,
   `RegionUUID` varchar(255) DEFAULT NULL,

because on PostgreSQL i would convert it to

   UUID uuid NOT NULL,
   RegionUUID uuid DEFAULT NULL,


Fernando Oliveira
http://oliveira.eti.br

http://twitter.com/oliveira_lands




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




--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] .NET 4 Teething Problems

2013-11-22 Thread Justin Clark-Casey


As of git master commit 60e049e, the various *.exe.config files not contain the 
required

loadFromRemoteSources enabled=true/

line.  If you subsitute your own config file changes on Windows then you will 
need to add the line manually [1].

[1] http://msdn.microsoft.com/en-us/library/dd409252%28v=vs.100%29.aspx

On 19/11/13 05:27, Zadark Portal wrote:

Included the following with Mantis 6853

Information relating to exception:
An attempt was made to load an assembly from a network location which
would have caused the assembly to be sandboxed in previous versions of
the .NET Framework.

Attachment Manager included in Microsoft Windows attaches security policies
to files downloaded from a network location. Normally this effects only files
contained in compressed zip format (.zip) though other file types can be 
affected depending on the local computer group
security policies (thinking machines registered to a domain though not 
exclusively)

The effect of the policy can be observed by opening the properties dialogue for 
a downloaded file, under the 'General'
tab (default) and towards the lower section of the dialogue an additional 
button is displayed 'Unblock'. Click this
button and exit the dialogue using the 'ok' button.

This procedure effectively changes all the files within the zip. If however the
unzipped contents are used prior to the procedure, the each file will require 
'Unblock' to be selected.

Changing this policy would be a significant security reduction, so best policy 
is, any file downloaded be inspected
using the procedure above.

Issue coming to light now is due to CAS policy changes within .NET 4

It would be useful if people evaluating this procedure reported their findings.



On 18 November 2013 16:15, Ai Austin ai.ai.aus...@gmail.com 
mailto:ai.ai.aus...@gmail.com wrote:

From: Zadark Portal zadarkpor...@gmail.com mailto:zadarkpor...@gmail.com

Further to my previous email, and to ensure the existing solution is 
clean
can you from within the opensim solution directory (same as compile.bat)
run:

C:\Windows\Microsoft.NET\__Framework64\v4.0.30319\msbuild OpenSim.sln 
/t:clean
C:\Windows\Microsoft.NET\__Framework64\v4.0.30319\msbuild OpenSim.sln 
/t:rebuild
C:\Windows\Microsoft.NET\__Framework64\v4.0.30319\msbuild OpenSim.sln

Amend the Microsoft.NET path accordingly.



Okay, got it. Zadark. Understood now.

On my Win 8.1 84 bit setup I did that to a fresh download of r/24051 
without adding the extra line to the
resources section of the Robust.exe.config file.

Then just amended the password for the database connection string in to 
make a Robust.ini file, and startup up
Robust.exe with that.

I get exactly the same error about the addin scan ... so for some reason 
the remote assembly load extra line in
Robust.exe.config (and openSim.exe.config) seem to be required in all my 
environments (Vista 34 bit, Win7 32 bit,
Win7 64 bit and Win8.1 64 bit)
_
Opensim-dev mailing list
Opensim-dev@lists.berlios.de mailto:Opensim-dev@lists.berlios.de
https://lists.berlios.de/__mailman/listinfo/opensim-dev 
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)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] .NET 4 Teething Problems

2013-11-20 Thread Justin Clark-Casey

After looking at references such as [1], I believe that the best course of action is to add loadFromRemoteSources 
enabled=true/ to all config files.


This is because the intention of the existing loads within OpenSimulator are not to sandbox the code.  If the user 
downloads a separate DLL add-on, then they have already made the decision to trust it.  Making them uncheck an extra box 
won't achieve much and will generate a lot of painful support issues which we are not in a position to handle.


Code Access Security appears never to have been completely implemented in Mono (and so presumably not enabled) so this 
does not apply there.


[1] 
http://blogs.msdn.com/b/shawnfa/archive/2009/05/22/sandboxing-in-net-4-0.aspx
[2] http://tirania.org/blog/archive/2007/Aug-08.html

On 19/11/13 05:27, Zadark Portal wrote:

Included the following with Mantis 6853

Information relating to exception:
An attempt was made to load an assembly from a network location which
would have caused the assembly to be sandboxed in previous versions of
the .NET Framework.

Attachment Manager included in Microsoft Windows attaches security policies
to files downloaded from a network location. Normally this effects only files
contained in compressed zip format (.zip) though other file types can be 
affected depending on the local computer group
security policies (thinking machines registered to a domain though not 
exclusively)

The effect of the policy can be observed by opening the properties dialogue for 
a downloaded file, under the 'General'
tab (default) and towards the lower section of the dialogue an additional 
button is displayed 'Unblock'. Click this
button and exit the dialogue using the 'ok' button.

This procedure effectively changes all the files within the zip. If however the
unzipped contents are used prior to the procedure, the each file will require 
'Unblock' to be selected.

Changing this policy would be a significant security reduction, so best policy 
is, any file downloaded be inspected
using the procedure above.

Issue coming to light now is due to CAS policy changes within .NET 4

It would be useful if people evaluating this procedure reported their findings.



On 18 November 2013 16:15, Ai Austin ai.ai.aus...@gmail.com 
mailto:ai.ai.aus...@gmail.com wrote:

From: Zadark Portal zadarkpor...@gmail.com mailto:zadarkpor...@gmail.com

Further to my previous email, and to ensure the existing solution is 
clean
can you from within the opensim solution directory (same as compile.bat)
run:

C:\Windows\Microsoft.NET\__Framework64\v4.0.30319\msbuild OpenSim.sln 
/t:clean
C:\Windows\Microsoft.NET\__Framework64\v4.0.30319\msbuild OpenSim.sln 
/t:rebuild
C:\Windows\Microsoft.NET\__Framework64\v4.0.30319\msbuild OpenSim.sln

Amend the Microsoft.NET path accordingly.



Okay, got it. Zadark. Understood now.

On my Win 8.1 84 bit setup I did that to a fresh download of r/24051 
without adding the extra line to the
resources section of the Robust.exe.config file.

Then just amended the password for the database connection string in to 
make a Robust.ini file, and startup up
Robust.exe with that.

I get exactly the same error about the addin scan ... so for some reason 
the remote assembly load extra line in
Robust.exe.config (and openSim.exe.config) seem to be required in all my 
environments (Vista 34 bit, Win7 32 bit,
Win7 64 bit and Win8.1 64 bit)
_
Opensim-dev mailing list
Opensim-dev@lists.berlios.de mailto:Opensim-dev@lists.berlios.de
https://lists.berlios.de/__mailman/listinfo/opensim-dev 
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)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Effect of entries in [Modules] in OpenSim.exe .ini files

2013-11-19 Thread Justin Clark-Casey

This is not ideal since classes are being added which will never be used.  However, if these classes are never 
instantiated, the effect on memory usage will be minimal.


I don't know exactly how the [Modules] config parameters are working, but it would make much more sense for 
OpenSimulator to decide which modules are enabled rather than relying on the modules to detect this for themselves.  The 
latter approach is potentially inconsistent and vulnerable to bugs in modules.


On 19/11/13 10:08, Ai Austin wrote:

In looking closely at the console logs for testing the .NET 4.0 setup I 
happened to notice the Physics and meshing
engines module load messages... on the openvue Grid since I have BulletSim and 
Meshmerizer enabled this gave...

[PHYSICS]: Added meshing engine: ZeroMesher
[PHYSICS]: Added physics engine: basicphysics
[PHYSICS]: Added physics engine: BulletSim
[PHYSICS]: Added meshing engine: Meshmerizer
[PHYSICS]: Added physics engine: OpenDynamicsEngine
[PHYSICS]: Added physics engine: POS
[PHYSICS]: creating meshing engine Meshmerizer
[PHYSICS]: creating BulletSim

What is the effect of Adding something that is not going to be used?  Does it 
actually do anything and make the
process image larger unnecessarily.

Seeing this reminded me that the Diva distribution has specific [Module] 
section module disable lines included.  Should
we all be doing this to improve our setups?  And is there somewhere that the 
Added module, Creating module and the
effect of Setup_Modulename = disabled is documented?

[Modules]

 ;; The following directives are to prevent these not-enabled modules
 ;; from being instantiated. If you change the default service connectors
 ;; of your D2 above, you should make sure the modules you use are not
 ;; disabled here.

 ...
 Setup_CenomeMemoryAssetCache = disabled
 Setup_CoreAssetCache = disabled
 Setup_GlynnTuckerAssetCache = disabled
 ...
 Setup_SimianProfiles = disabled
 Setup_SimianUserAccountServiceConnector = disabled

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




--
Justin Clark-Casey (justincc)
OSVW Consulting
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] OpenSimulator development code now builds using .NET 4.0

2013-11-08 Thread Justin Clark-Casey


Hello folks,

As discussed previously in the opensim-dev mailing list [1], the minimum .net framework version required by 
OpenSimulator is now .NET 4.0 in the development branch.


On Windows, this means that one must have the .NET 4 Framework installed to run OpenSimulator.  Previously, 
OpenSimulator ran with the .NET 3.5 framework.


Also on Windows, this also means that to build OpenSimulator, you must use Visual C# 2010 [Express], 2008 does not 
support .NET 4.0.  So runprebuild.bat now creates a 2010 solution.  I'm sure 2012 can also be used but I'll leave it to 
someone else to create a runprebuild2012.bat.


On Mono, this raises the official minimum Mono version to 2.10.8.1.  If you already have at least this version installed 
(which is the case for all the current major Linux distro versions) then you don't need to do anything.  At the moment, 
older versions of Mono will continue to work as well but this will change once someone uses some .NET 4.0 specific 
syntax or SDK functionality.


If you are building nant and using an old version (pre 0.91 or earlier, I think) then you may need to update this to 
0.91 or later.


[1] http://www.mail-archive.com/opensim-dev@lists.berlios.de/msg07214.html

--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Running Multiple Robust Instances errors and some questions about running in this configuration

2013-11-07 Thread Justin Clark-Casey

 = OpenSim.Services.AssetService.dll:AssetService   --- This is 
not loaded because my SRAS server is the
asset server
;[AssetService]
; LocalServiceModule = OpenSim.Services.AssetService.dll:AssetService
; DefaultAssetLoader = OpenSim.Framework.AssetLoader.Filesystem.dll
; AssetLoaderArgs = ./assets/AssetSets.xml

; * This configuration loads the inventory server modules. It duplicates
; * the function of the legacy inventory server
; *
;[InventoryService]
; LocalServiceModule = OpenSim.Services.InventoryService.dll:XInventoryService

Sorry about the length of this question just trying to get my head around the 
Robust connectors and Hypergrid
interaction is all. And I want to make sure I did not miss something setting up 
different Robust instances to improve
performance of my grid's Robust server.

Thanks
Todd





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




--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] database fields names

2013-10-25 Thread Justin Clark-Casey

I would say that those interfaces are not public - they are internal OpenSimulator interfaces that unfortunately are the
only way that region modules can currently interact with the simulator (in addition to all the other methods that aren't
on interfaces). None of these interfaces have been formalized or even documented as being available to region modules.

As soon as you start freezing these interfaces you lose the ability to evolve the codebase for the better without
incurring the cost of deprecation cycles. Projects like Linux take this position [1].

I would also argue that consistency is extremely important. It's okay once you know the codebase but anybody learning
things for the first time is greatly aided by consistency, whether that's in method/property naming, parameters,
interface design, code formatting, etc. If the code isn't consistent that acts as an extra barrier to adoption.

As for database column names, I would dearly love them to be consistent. Other code shouldn't really be operating on
OpenSimulator database tables directly but should go through Robust/OpenSimulator external interfaces, though I know the
right interfaces aren't always currently available. I'm also not convinced that column renaming would be an expensive
migration.

I believe that eventually column names have to be reasonably consistent if OpenSimulator is to be taken seriously by the
wider development community as a project. However, I also don't think that this is a point worth fighting over right now.

[1] https://www.kernel.org/doc/Documentation/stable_api_nonsense.txt

On 25/10/13 18:25, Adams, Robert wrote:

-1

As someone who has several external modules and knowing of several different
external projects that directly access the
database, the names should not change. I’d bad enough with Justin ‘cleaning up’
public interfaces of OpenSimulator classes.

While strange naming is irritating and would be cleaner if modified, don’t
change things just to make them prettier.

-- ra

*From:*opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] *On Behalf Of *ssm2017
*Sent:* Friday, October 25, 2013 6:23 AM
*To:* opensim-dev@lists.berlios.de
*Subject:* [Opensim-dev] database fields names

hello

what do you think about the idea to take the opportunity for 0.7.8 to unify the
database tables names ?

for example, the uuid of a user in UserAccounts is PrincipalID, in the Presence
table, this is UserID and in auth
(without capitalization) this is UUID...

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

Re: [Opensim-dev] Looking for paid simple viewer customization services

2013-10-24 Thread Justin Clark-Casey

Hi Oliver.  I do know somebody who was doing this work fairly recently but I don't know if he's available anymore since 
I haven't had contact with him for a while.  But if you'd like me to ask then please let me know.


On 24/10/13 19:30, Olivier BATTINI wrote:

Hi Word,

I contacted Siana Gearz at beginning of September, quite 2 months ago, and 
again recently and got a response but still
waiting for a quote.

This is why I came to the OpenSim list.

Thanks anyone for helping.

Best,
Olivier


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




--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Fwd: Issue 1096 in singularity-viewer: [AVFACTORY]: Missing baked texture spamming console

2013-10-22 Thread Justin Clark-Casey

Unfortunately, I'm somewhat at a loss.  Perhaps print out all the finally loaded config with the config save console 
command and attach it (redacting any info you consider sensitive?).  Unfortunately, all I can think of is to look for 
some config slip.


On 18/10/13 14:42, Mark Seibert wrote:

Thank you for helping. Here are answers to your questions:


Have you changed any other default settings such as setting 
PersistBakedTextures = true in the [Appearance] section of OpenSim.ini?


No. The only settings I have edited outside of the default are the new Groups 
V2 Module and Vivox.


Also, does this occur with every viewer or just a particular one?


I have tested it on the latest versions of Firestorm, Singularity, and 
Imprudence.


Every avatar or just a particular one?


All avatars that I have tested, 3 in all.


What happens if you change into different clothing and body parts?


While editing my appearance, everything is normal (no texture glitching). 
However, using entirely new shapes and
clothing still cause the issue to repeat as soon as I exit appearance editing.


What happens if you try this from a different machine (since baking does rely 
on viewer code which in turn has some reliance on graphics drivers).


I have tried it on an older machine (about 5 or 6 years) and 2 modern quad core 
machines, all of which this issue repeats.

I'm not really certain what the problem is, since the machine I am using has 
hosted .7.5 regions in the past. It uses
the latest version of Ubuntu Linux with the latest mono install as well. Other 
than this config file, any others that
may have new stuff with .7.6?

Thanks


On Thu, Oct 17, 2013 at 3:57 PM, Justin Clark-Casey jjusti...@googlemail.com 
mailto:jjusti...@googlemail.com wrote:

I'm not sure what the issue might be since I haven't heard any other 
reports of this with cache enabled.  Have you
changed any other default settings such as setting PersistBakedTextures = 
true in the [Appearance] section of
OpenSim.ini?  This defaults to false - true should work but is a much less 
tested option.

Also, does this occur with every viewer or just a particular one?  Every 
avatar or just a particular one?  What
happens if you change into different clothing and body parts?  What happens 
if you try this from a different machine
(since baking does rely on viewer code which in turn has some reliance on 
graphics drivers).


On 15/10/13 14:50, Mark Seibert wrote:

Thanks for the help.

I just finished the install and again I get the same error. Both with 
vanilla FlotsamCache.ini and with both
disk and
memory cache enabled. Below is a copy of my config file and example 
error messages:

FlotsamCache.ini:

[AssetCache]
  ;;
  ;; Options for FlotsamAssetCache
  ;;

  ; cache directory can be shared by multiple instances
  CacheDirectory = ./assetcache
  ; Other examples:
  ;CacheDirectory = /directory/writable/by/__OpenSim/instance

  ; Log level
  ; 0 - (Error) Errors only
  ; 1 - (Info)  Hit Rate Stats + Level 0
  ; 2 - (Debug) Cache Activity (Reads/Writes) + Level 1
  ;
  LogLevel = 0

  ; How often should hit rates be displayed (given in AssetRequests)
  ; 0 to disable
  HitRateDisplay = 100

  ; Set to false for no memory cache
  MemoryCacheEnabled = true

  ; Set to false for no file cache
  FileCacheEnabled = true

  ; How long {in hours} to keep assets cached in memory, .5 == 30 
minutes
  ; Optimization: for VPS or limited memory system installs set 
Timeout to .016 (1 minute)
  ; increases performance without large memory impact
  MemoryCacheTimeout = 2

  ; How long {in hours} to keep assets cached on disk, .5 == 30 
minutes
  ; Specify 0 if you do not want your disk cache to expire
  FileCacheTimeout = 48

  ; How often {in hours} should the disk be checked for expired 
filed
  ; Specify 0 to disable expiration checking
  FileCleanupTimer = 1.0  ;every hour

  ; If WAIT_ON_INPROGRESS_REQUESTS has been defined then this 
specifies how
  ; long (in miliseconds) to block a request thread while trying to 
complete
  ; an existing write to disk.
  ; NOTE: THIS PARAMETER IS NOT CURRENTLY USED BY THE CACHE
  ; WaitOnInprogressTimeout = 3000

Error Messages:


09:45:44 - [ASSET XFER UPLOADER]: Uploaded asset 
405eb5d5-11ef-56bf-05e0-__63887c4ce31e for transaction
263674c0-b5b9-7484-d5f2-__26b26aab69d2
09:45:44 - [ASSET XFER UPLOADER]: Uploaded asset 
c288982a-1eff-5bca-a6b3-__7732ba5dd35a for transaction
01500019-187b-49a1-d1f0

Re: [Opensim-dev] How to properly enable JsonStore

2013-10-21 Thread Justin Clark-Casey

As you're running on Windows, OpenSimulator 0.7.6 is constrained to using the classes/methods found in the .NET 3.5 
profile.  This means that practically all the Json script functions won't work yet.  I would assume that's the reason, 
though maybe there is some other issue too as the error message isn't the one Mic normally expects to see in this 
situation.  Mono doesn't constrain available classes/methods int he same way.


It just so happens that I have everything ready to update OpenSimulator .NET usage to 4.0 on git master dev code, as 
discussed in this list earlier this year (I'm waiting for Mono to be updated on opensimulator.org so that jenkins will 
continue to work).  However, this won't help much if you're sticking to the 0.7.6 release package.


On 21/10/13 19:25, fernando balmaceda wrote:

Hi Mic,

I just added a entry on mantis, with the description.

Thanks!


Date: Mon, 21 Oct 2013 10:56:23 -0700
From: cmick...@gmail.com
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] How to properly enable JsonStore

Could you open a mantis entry  add the compile error?

--mic



On Mon, Oct 21, 2013 at 8:21 AM, phantom phantom2...@hotmail.com 
mailto:phantom2...@hotmail.com wrote:

Hi!
Im doing some tests on opensim 0.7.6, running under windows 7 64 bits, with
the OpenSim.32BitLaunch.exe. I want to use JsonStore functions on my
scripts, like JsonGetValue, or JsonGetJson. I read how to enable json store
in this site: http://opensimulator.org/wiki/JsonStore_Module.
But i am only able to get working JsonCreateStore and JsonDestroyStore. When
i try to use JsonGetValue or JsonGetJson i get the following compile error:
The name 'JsonGetValue' does not exist in the current context.
The same goes for JsonGetJson.

The test script is:

key storeID;
default
{
 touch_start(integer n)
 {
 storeID = JsonCreateStore({ 'foo' : { 'bar' : 'one' } });
 llOwnerSay(JsonGetValue(storeID, foo.bar));
 JsonDestroyStore(storeID);
 }
}

I appreciate any help. Thanks!



--
View this message in context: 
http://opensim-dev.2196679.n2.nabble.com/How-to-properly-enable-JsonStore-tp7578850.html
Sent from the opensim-dev mailing list archive at Nabble.com.
___
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




--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] MinFrameTime = 0.089, whats the impact of changeing only that ?

2013-10-21 Thread Justin Clark-Casey

MinFrameTime is the minimum time for an iteration of the server-side scene loop in order to keep a constant frame rate. 
 If there is spare time after work done by an iteration then the main scene loop goes to sleep for the remaining time.


On ODE, changing this without also changing ODE parameters such as UpdatePhysicsEveryNFrames will cause massive avatar 
juddering.  Are you sure that you haven't changed these other parameters at some point?  I can't say what would happen 
with BulletSim.


On 20/10/13 20:20, R.Gunther wrote:

I figured out on my standalone that the not smooth moveing world i can fix by 
changeing
;MinFrameTime = 0.089  to   MinFrameTime = 0.025

with MinFrameTime = 0.025, flying is buttersmooth. really its super compared to 
shocking movement with ;MinFrameTime =
0.089
And then only changeing this number. But whats the impact ? Or is there 
soemthing else wrong that get hidden by lowering
this setting ?
Because with 0.7.5 it worked always smooth, since 0.7.6 its not smooth anymore. 
until ic hanged this parameter.
I made anyway mantis about my problem 
http://opensimulator.org/mantis/view.php?id=6814
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev




--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Rate Limit DOS Protection

2013-10-17 Thread Justin Clark-Casey

On 16/10/13 20:46, Toni Alatalo wrote:

On Oct 16, 2013, at 8:39 PM, Justin Clark-Casey jjusti...@googlemail.com
wrote:

I suppose that is certainly the case when you think of it as a distribution
also in itself, and not just a part of some larger distros (like Diva's etc).

If it would be strictly considered as a lib to be used in some system that
fills in the rest, then what makes sense can differ. Like say Bullet or Ogre
are.

But given that there are a lot of people out there who just use Opensim as is,
always new people just grabbing and launching it and starting to use, I figure
your statement must have truth in it.

I agree that there is a tension between making OpenSimulator usable out-of-the-box and doing different things in
downstream distributions.

My preference for out-of-the-box is to keep as many people using core OpenSimulator as possible. Multiple distributions
are valuable but I feel that they can fragment development resources. And then there is the temptation (which I would
have) to focus complex changes on one's own distribution rather than making the effort to negotiate them upstream.

Re: [Opensim-dev] Fwd: Issue 1096 in singularity-viewer: [AVFACTORY]: Missing baked texture spamming console

2013-10-17 Thread Justin Clark-Casey

-6d06802dd4e1 (11) for Mark Seibert, requesting rebake.
09:45:48 - [AVFACTORY]: Missing baked texture 
f145dba6-0f98-9fcc-07ce-72071a462afc (20) for Mark Seibert, requesting rebake.
This repeats over and over. In world, the avatar loses their textures (they 
turn white) and they come back on
eventually, repeating forever.

Mark Seibert


On Tue, Oct 15, 2013 at 9:25 AM, Fleep Tuque fleep...@gmail.com 
mailto:fleep...@gmail.com wrote:



-- Forwarded message --
From: *Justin Clark-Casey* jjusti...@googlemail.com 
mailto:jjusti...@googlemail.com
Date: Mon, Oct 14, 2013 at 7:16 PM
Subject: Re: [Opensim-dev] Fwd: Issue 1096 in singularity-viewer: 
[AVFACTORY]: Missing baked texture spamming console
To: opensim-dev@lists.berlios.de mailto:opensim-dev@lists.berlios.de


This is an issue if all caching is disabled.  However, it should have been 
fine with just disk caching enabled.
  This is the default that OpenSimulator ships with - one shouldn't need to 
do any copying of
FlotsamCache.ini.example, though it won't hurt.


On 14/10/13 16:12, Fleep Tuque wrote:

I'm not sure if there is already a mantis bug report on this and I 
don't have time right this second to look, but
thought I'd forward this message along as an FYI.  I recall having some 
discussions about this with Justin and
Neb prior
to OSCC but I don't recall what the resolution was if any.

- Chris/Fleep

-- Forwarded message --
From: ** singularity-viewer@__googlecode.com 
mailto:singularity-vie...@googlecode.com
mailto:singularity-viewer@__googlecode.com 
mailto:singularity-vie...@googlecode.com
Date: Mon, Oct 14, 2013 at 10:35 AM
Subject: Re: Issue 1096 in singularity-viewer: [AVFACTORY]: Missing 
baked texture spamming console
To: fleep...@gmail.com mailto:fleep...@gmail.com mailto:fleep...@gmail.com 
mailto:fleep...@gmail.com



Comment #1 on issue 1096 by jayden.b...@gmail.com 
mailto:jayden.b...@gmail.com mailto:jayden.b...@gmail.com
mailto:jayden.b...@gmail.com__: [AVFACTORY]: Missing baked texture
spamming console

http://code.google.com/p/singularity-viewer/issues/detail?id=1096
http://code.google.com/p/__singularity-viewer/issues/__detail?id=1096

http://code.google.com/p/__singularity-viewer/issues/__detail?id=1096
http://code.google.com/p/singularity-viewer/issues/detail?id=1096

As a very interested observer of this issue, but not a Singu team 
member just a user, I would like to make a
hopefully
helpful comment and also confirm this issue.

I noticed this issue about 2 weeks ago and have been testing 
extensively since then as I too suffered it.

I have mostly solved the byproduct; the error message in the log (not 
the root cause) by enabling the server
cache (copy
the FlotsamCache.ini.example to FlotsamCache.ini - OS setup documents 
mostly forget to constantly tell people this
rather important step .).

As a side effect loads are also much faster.

Googlefu found and confirmed that enabling *both* memory and disk 
caching in the FlotsamCache.ini file must be
done to
remove the error. (Devs: Remind me to add the cross reference to 
OpenSim's mantis later. hehe.)

With 2 weeks solid testing, it seems at least on my OS regions if you 
don't have both settings set to on then
the baked
textures are obtained by the server on TP in, but not applied and then 
lost by the OpenSim server as it deals with
everything else before finally rendering you. Before this workaround, 
on my regions at least, when it came time to
render the avatar I saw the warning in the logs. The previously sent 
but lost (due to insufficient server
caching) baked
textures are thus re-requested and applied and you finally turn from 
cloud to avatar.

(As a hint to the reporter, I also bumped up my cache retention quite a 
lot as my three regions are not so high
traffic.
I can afford the ram and disk to hold things for 3 days to a week even. 
YMMV depending on scenes and visitors.)

All that said:

There is STILL the root cause to this issue as I see it, in that the 
baked textures for a new person to the
region - to
my inexpert eyes looking at both server and client logs in depth - are 
done at the wrong interest level or lost
by the
server. As a hint to any developer who looks at this in the future; 
it's almost looks like the avatar needs to
be baked,
rendered and placed in world before the world is drawn around it... as 
an alternative, there could be a new step
included in the initial region processes... draw a known default 
texture as skin/eyes until the baked texture is
ready.

I suspect Cool does

Re: [Opensim-dev] Needing Mono.Security.dll on Windows at PostgreSQL module

2013-10-16 Thread Justin Clark-Casey

A small point - can this be in the directory bin/lib/.NET/ rather than Windows/? This makes it clear that it's a
library directory and only required under .NET (since you can theoretically run Mono in Windows, though admittedly
probably pretty much nobody does this).

On 16/10/13 12:49, Fernando Francisco de Oliveira wrote:

Yesterday I tested my code, and already patched it to load the
Mono.Security.dll from bin/windows folder only when the
program was running on windows.

It was put at first attempt to load it from PGSQL module. and it worked fine at
windows. I didn't tested on linux yet.
and still need to test also on Robust.

The implementation was exacly what Sean described, an event that is fired when
any assembly isnt found at default
directories, then I verify if it is running Mono environment and only use
Assembly.Load when it's not. The librarie is
stored at bin/windows folder, so the program don't load it unless for this code.

Fernando Oliveira
http://oliveira.eti.br

http://twitter.com/oliveira_lands

2013/10/16 Latif Khalifa lati...@streamgrid.net
mailto:lati...@streamgrid.net

We used to ship Mono.Security.dll with libopenmetaverse. It caused
all sorts of trouble for Linux users, because mono on startup will
load the one from cwd preferably. So shipping it in bin/windows that
mono will not know about is the only way to go.

I wish we thought of this approach back then ;)

On Wed, Oct 16, 2013 at 5:08 AM, Fernando Francisco de Oliveira
ferna...@oliveira.eti.br mailto:ferna...@oliveira.eti.br wrote:
Hello

I was investigating the bug
(http://opensimulator.org/mantis/view.php?id=6803) found that
Mono.Security.dll which is packaged with Npgsql.dll library is needed on
Windows, but can't be distributed on Linux, because mono already have it
and
gives conflicts error.

I would like to discuss about distributing the Mono.Security.dll on a
folder
above bin like bin/windows folder, which could contains the libraries
that
only is needed on windows.

I did a change on PGSQL project to load dynamicaly Mono.Security only if
it's running on Windows, and from that folder.
If it running on Mono, it load it from GAC (if available) and don't load
the
windows dll.

http://pastebin.com/WdzfmbSr

Let's talk about it ?

Fernando Oliveira
http://oliveira.eti.br

___
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] Needing Mono.Security.dll on Windows at PostgreSQL module

2013-10-16 Thread Justin Clark-Casey


Yes, this is also available as OpenSim.Framework.Util.IsPlatformMono().

On 16/10/13 18:28, Fernando Francisco de Oliveira wrote:

the test I put at code was testing Type.GetType(Mono.Runtime) if it return 
null that's not running on mono.


Fernando Oliveira
http://oliveira.eti.br

http://twitter.com/oliveira_lands




2013/10/16 Sean McNamara smc...@gmail.com mailto:smc...@gmail.com

On Wed, Oct 16, 2013 at 12:35 PM, Justin Clark-Casey
jjusti...@googlemail.com mailto:jjusti...@googlemail.com wrote:
  A small point - can this be in the directory bin/lib/.NET/ rather than
  Windows/?  This makes it clear that it's a library directory and only
  required under .NET (since you can theoretically run Mono in Windows, 
though
  admittedly probably pretty much nobody does this).

And now that you brought that up, the obvious follow-up question is,
can we reliably detect whether OpenSim is being run under Mono or the
.NET Framework? As you pointed out, Mono runs on Windows, and it is
possible that someone running OpenSim under Mono on Windows would
*pass* the Win32 platform check and get our shipped Mono.Security.dll
loaded, which would conflict with the Mono.Security.dll shipped with
the user's Mono version and perhaps cause exceptions.

So the condition for loading the bin/lib/.NET/*.dll would be: on Win32
AND running the Microsoft .NET Framework (or, by implication, NOT
Mono)

 
 
  On 16/10/13 12:49, Fernando Francisco de Oliveira wrote:
 
  Yesterday I tested my code, and already patched it to load the
  Mono.Security.dll from bin/windows folder only when the
  program was running on windows.
 
  It was put at first attempt to load it from PGSQL module. and it worked
  fine at windows. I didn't tested on linux yet.
  and still need to test also on Robust.
 
  The implementation was exacly what Sean described, an event that is 
fired
  when any assembly isnt found at default
  directories, then I verify if it is running Mono environment and only 
use
  Assembly.Load when it's not. The librarie is
  stored at bin/windows folder, so the program don't load it unless for 
this
  code.
 
 
 
 
  Fernando Oliveira
  http://oliveira.eti.br
 
  http://twitter.com/oliveira_lands
 
 
 
 
  2013/10/16 Latif Khalifa lati...@streamgrid.net 
mailto:lati...@streamgrid.net
  mailto:lati...@streamgrid.net mailto:lati...@streamgrid.net
 
 
  We used to ship  Mono.Security.dll with libopenmetaverse. It caused
  all sorts of trouble for Linux users, because mono on startup will
  load the one from cwd preferably. So shipping it in bin/windows that
  mono will not know about is the only way to go.
 
  I wish we thought of this approach back then ;)
 
  On Wed, Oct 16, 2013 at 5:08 AM, Fernando Francisco de Oliveira
  ferna...@oliveira.eti.br mailto:ferna...@oliveira.eti.br 
mailto:ferna...@oliveira.eti.br
mailto:ferna...@oliveira.eti.br wrote:
Hello
   
I was investigating the bug
(http://opensimulator.org/mantis/view.php?id=6803) found that
Mono.Security.dll which is packaged with Npgsql.dll library is
  needed on
Windows, but can't be distributed on Linux, because mono already
  have it and
gives conflicts error.
   
I would like to discuss about distributing the Mono.Security.dll 
on
  a folder
above bin like bin/windows folder, which could contains the
  libraries that
only is needed on windows.
   
I did a change on PGSQL project to load dynamicaly Mono.Security
  only if
it's running on Windows, and from that folder.
If it running on Mono, it load it from GAC (if available) and 
don't
  load the
windows dll.
   
http://pastebin.com/WdzfmbSr
   
Let's talk about it ?
   
Fernando Oliveira
http://oliveira.eti.br
   
   
   
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de mailto:Opensim-dev@lists.berlios.de 
mailto: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 
mailto: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

Re: [Opensim-dev] Rate Limit DOS Protection

2013-10-16 Thread Justin Clark-Casey

In my opinion, anybody who is sophisticated enough to be using a proxy is sophisticated enough to be aware of what's
happening in OpenSimulator and sophisticated enough to to disable these changes if required. Anybody operating a grid
must take responsibility for managing their configuration when upgrading.

I disagree that no change in behaviour is a standard operating procedure in OpenSimulator. The project changes in
behaviour all the time, usually to better match the de-facto standard and features set by Linden Lab or to give a better
user/admin experience.

In fact, I would say that making OpenSimulator as functional as possible out of the box (within certain bounds such as
not bundling a web interface) is a standard OpenSimulator operating procedure. That's why we have SQLite as the default
database, for example. Under this principle, one should enable things like core groups support by default when it's
ready instead of leaving them forever disabled because some existing users may have configured their system differently.

Not following this principle puts the burden of configuration change on the large number of new users who are least able
to manage it rather than the smaller number of existing users who are not using an out-of-the-box configuration.
Indeed, new users may never know that certain OpenSimulator features exist at all and that the system is less functional
than it really is. All this makes it harder to grow the project.

On 08/10/13 22:20, Melanie wrote:

People like us have the protection in the proxy and need to turn the
feature off. Not a problem for me, I'm aware of it, but my concern
was for those who didn't listen to me tell them Dont' blindly reuse
configs

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

Re: [Opensim-dev] Fwd: Issue 1096 in singularity-viewer: [AVFACTORY]: Missing baked texture spamming console

2013-10-14 Thread Justin Clark-Casey

://lists.berlios.de/mailman/listinfo/opensim-dev




--
Justin Clark-Casey (justincc)
OSVW Consulting
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] OpenSimulator 0.7.6 now available

2013-10-04 Thread Justin Clark-Casey


Hi folks.  OpenSimulator 0.7.6 is now officially released [1] with release 
notes at [2].

As usual, huge thanks to everybody who contributed code, tested and identified errors, wrote documentation, helped 
newbies and all the other things that are necessary for an open-source project to function.


Constraints on commits to git master are now lifted.

[1] http://opensimulator.org/wiki/Download
[2] http://opensimulator.org/wiki/0.7.6_Release

Regards,

--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Fixing Unknown User problems using the database

2013-09-24 Thread Justin Clark-Casey

I'm very surprised to see GUN9 since I thought changes should prevent it ever occurring in current code. I'll have to
revisit this.

Sharing bindings is an interesting idea. The existing GridUser cache kind of does this, I think, but only with users
that have ever been on the simulator afaik. Possibly this could even be used for this purpose. Naturally, one would
have to be careful of the performance considerations.

I would be very wary of having ROBUST instances start to talk to each other, as this would start to significantly
increase their complexity.

However, for the forthcoming release, I just want to resolve existing Unknown User issues [1] within the current code
structure as much as possible. It might be that this is not possible. There seem to be a lot more issues than
previously, probably connected with the extension of Hypergrid functionality.

[1] http://opensimulator.org/mantis/view.php?id=6625

On 24/09/13 12:51, Oren Hurvitz wrote:

I started using Hypergrid recently, and came across the Unknown User
problem. So far I've seen UserUMMAU4 and UserUMMTGUN9. I poked around to see
if I can do anything about this, and it seems that the mapping of UUID -
Name is stored in memory only (UserManagementModule.m_UserCache). This has
the following consequences:

1. Simulators don't share what they know.
2. When a simulator is restarted, it forgets even those bindings that it did
know before.

The simulators do attempt to rebuild their cache on startup, by examining
all the prims in the scene. But this is insufficient. E.g., inventory items
also have creators.

I think we should create a table in Robust, similar to UserAccounts (or
perhaps in UserAccounts itself), which stores these name mappings.
Simulators would use this table as a fallback if they don't find a mapping
in their own cache. This will solve all (or at least most) of the Unknown
User problems.

What do you think? Am I missing something?

Oren

--
View this message in context:
http://opensim-dev.2196679.n2.nabble.com/Fixing-Unknown-User-problems-using-the-database-tp7578750.html
Sent from the opensim-dev mailing list archive at Nabble.com.
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
.

[Opensim-dev] Please don't push any big changes to the OpenSimulator master branch for now

2013-09-24 Thread Justin Clark-Casey

Hi folks. This has been an informal thing up till now but after discussion on the IRC channel, I'm going to formally
ask all core developers to hold off on making any major changes to git master code until 0.7.6 is released.

This is so that some nasty and difficult regressions can be hammered out without the situation being complicated by
other major alterations.

The particularly sensitive area is anything connected with teleport or region cross (e.g. teleport or region cross code
itself, attachments, capabilities, LLUDP clientstack, network code, etc.). This is due to teleport regressions [1] that
are highly sensitive to a large number of factors, and the fact that changing one thing in OpenSimulator can lead to
unexpected effects elsewhere.

I'm not saying that all change should stop - please just use common sense.

I know this is not ideal but I think we're all agreed that it would be really nice to produce a good, stable
OpenSimulator release incorporating all the performance and other improvements generated by the recent conference as
well as other changes since February.

There is a 0.7.6-post-fixes branch, but I also want a low rate of change on master in order to get the widest possible
testing base for fixes, as many people follow master code rather than release branches. Of course, major changes can
also be done in other branches for now.

Once these complicated regressions are squashed (e.g. possibly including [2] as well) I will produce a release candidate
or two and then a release, as usual. This process may last 2 or 3 weeks. I would very much appreciate it if major
changes could be held off until I give the all clear or the final release (not release candidate) is produced. Believe
me, I want to get a release out the door as soon as possible but it has to be of good quality. Of course, any help with
these regression issues is also very welcome.

[1] http://opensimulator.org/mantis/view.php?id=6755
[2] http://opensimulator.org/mantis/view.php?id=6625

Re: [Opensim-dev] Fixing Unknown User problems using the database

2013-09-24 Thread Justin Clark-Casey

I hadn't appreciated this issue before. It will need to be addressed, though quite possibly not this release as it's
not a regression.

On 24/09/13 13:31, Allen Partridge wrote:

That would be a huge help for unidentified npc's created / recreated on restart.

Im not sure what the best org approach to the database might be, but it seems
like isolating npcs from users in db might
prove esp. Useful down the line.

-allen

On Sep 24, 2013 8:01 AM, Oren Hurvitz or...@kitely.com
mailto:or...@kitely.com wrote:

1. Simulators don't share what they know.
2. When a simulator is restarted, it forgets even those bindings that it did
know before.

The simulators do attempt to rebuild their cache on startup, by examining
all the prims in the scene. But this is insufficient. E.g., inventory items
also have creators.

What do you think? Am I missing something?

Oren

--
View this message in context:

http://opensim-dev.2196679.n2.nabble.com/Fixing-Unknown-User-problems-using-the-database-tp7578750.html
Sent from the opensim-dev mailing list archive at Nabble.com.
___
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] Command lines - use of hyphens and verb subject flipping

2013-09-02 Thread Justin Clark-Casey

No, the dispatch is based on the entire command that the module registers (e.g. show object name will only receive
commands starting with the tokens show, object and name).

On 30/08/13 19:08, Dahlia Trimble wrote:

I think the problem with verb-object is that the command handling code is
designed such that multiple modules can add
additional commands when they are instantiated, and Opensimulator uses the
first word in the command to dispatch the
command to whatever module owns it. If it were verb-object then it
(currently) would not know how to dispatch the
command as many modules could share the verb. It might be possible to rewrite
the command dispatching code to handle the
verb-object form but then existing modules that are not in core would need to
be updated or their registered commands
would not work.

On Fri, Aug 30, 2013 at 6:57 AM, R.Gunther ri...@rigutech.nl
mailto:ri...@rigutech.nl wrote:

i agree verb-object is a bit confuseing with typeing compared to verb
object.
delete-region is for me not really logic, delete region is more clear.

On 2013-08-30 15:32, Ai Austin wrote:

At 11:00 30/08/2013, opensim-dev-request@lists.__berlios.de
mailto:opensim-dev-requ...@lists.berlios.de wrote:

I'm still not sure whether verb-object is better (e.g. send
appearance) or object-verb (e.g. appearance send).

I strongly vote for verb object in such computer script languages.

This works well also where there are more than one main parameter too,
as that can get confusing otherwise. Its
also the way most commands already are.

There are just a few hyphenated commands as you say. I spotted
delete-region and remove-region

command-script is an odd on as really its just run script script script
or command script ? But its one I
always seem to get wrong. Leaving in a few problematic ones with
hyphen and non-hyphen versions, but making the
help text and documentation give the definitive one to move forward
with might be an approach?

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

Re: [Opensim-dev] Command lines - use of hyphens and verb subject flipping

2013-08-29 Thread Justin Clark-Casey

There is indeed a lot of inconsistency. Some of this is my fault. I'm still not sure whether verb-object is better
(e.g. send appearance) or object-verb (e.g. appearance send).

verb-object has the advantage of being more 'natural' in terms of English were order. It also enables similar commands
to be group (e.g. all show commands).

object-verb has the advantage of grouping all commands together by function (e.g. all appearance commands are in the
same place when you look at a command list instead of scattered).

Hyphenated commands, on the other hand, I would say should definitely become two words (e.g. delete region rather than
delete-region). This was agreed some time ago but not all commands were changed.

However, this may not be changed before release time. It takes more work than one might expect (e.g. deciding what to
do, changing docs, etc.) and I, for one, would rather concentrate on functionality bugs at this stage.

On 24/08/13 09:58, Ai Austin wrote:

I note several inconsistencies in the use of - in OpenSim.exe command console
command lines. I always seem to get
this wrong. and

create region [region name] region_file.ini - Create a new region.

delete-region name - Delete a region from disk

remove-region name - Remove a region from this simulator

Can this have a tidy up ahead of any major release to help people? Perhaps the
hyphen could even be optional where it
makes sense so both formats work?

And we have verb subject in most cases... and it is what one might expect in
general...

load iar
save iar

and yet we sometimes have the subject ahead of the verb as in

terrain load
terrain save

so its the opposite way round to what one might expect.

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

Re: [Opensim-dev] OpenSim.exe console - progress messages with mesh uploads

2013-08-29 Thread Justin Clark-Casey

I'm not sure this will be possible as I believe mesh is uploaded via a single HTTP post, which isn't easy to monitor
server-side. It's also possible that the mesh you're trying to upload is unfortunately simply too large and that we
should have (optional) server-side enforced limits. But this is speculation on my part.

Is this a purely local upload or one to a server not on the same system? If the server is on a different system,
possibly you could install a monitoring tool to check your rate of data upload. Naturally, one would expect a server on
a local LAN to be very quick, but a remote one might be different and even on the local scenario, things like slow wifi
might come into play.

Perhaps you could install a monitoring tool on your system
On 24/08/13 17:22, Ai Austin wrote:

I wonder if its possible to get any debugging related to mesh uploads and their
progress (or otherwise).

I think I am timing out even when I set the AckTimeout = 600 as suggested
by Justin and want to try to figure out
the stage at which the problems occur.

I am uploading some Collada meshes that are 20MB up to 100MB in size.. and got
them in once.. but cannot reliably repeat
that especially f I try to vary the upload options to scale the incoming mesh,
or if I add any physics details.

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

Re: [Opensim-dev] Timeout on uploading large Collada Meshes

2013-08-15 Thread Justin Clark-Casey

Austin, that means that during the mesh upload either the viewer is sending no UDP packets or they're all being crowded 
out by the upload.


A very short term 'fix' would be to increase the connection timeout using the AckTimeout setting in 
[ClientStack.LindenUDP].  If the viewer is genuinely sending no UDP data during the upload then this is something that 
needs to be considered separately (though I would find that rather surprising).


Robert, all cost calculations are done on the viewer - there is no code for this in OpenSim and no viewer numbers are 
used by OpenSim (which would be dangerous anyway as one cannot trust the viewer).  The viewer would have to disable this 
calc if it detects that it's working with OpenSim.


On 15/08/13 12:26, Robert Martin wrote:

on a related note is there a way for the cost part to be disabled (i have 
seen it take like 7 minutes for the cost
calc to timeout)?
Also what is the recommended limits for 1 Avatar meshes 2 static meshes ?




On Wed, Aug 14, 2013 at 4:05 PM, Ai Austin ai.ai.aus...@gmail.com 
mailto:ai.ai.aus...@gmail.com wrote:

When I try uploading some large meshes I am seeing timeouts every now and 
then.. but I can see no errors in the mesh
upload...

Is there a hard wired limit somewhere on the time and the mesh upload might 
be blocking any acknowledgements that
the viewer is ant to give to the server?

21:02:41 - [LLUDPSERVER]: Ack timeout, disconnecting root agent for Simona 
Stick in simonastick 1

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




--
Robert L Martin


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




--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Sensors and At_Target

2013-07-11 Thread Justin Clark-Casey


On 08/07/13 07:55, R.Gunther wrote:

Are sensors and Sensors and At_Target running in its own thread now ?
It works fine when you move 1 train. But as soon  i add another train things 
stop
moveing after a while. possible because the sensor or traget dont get trigger 
at the right time.
Still not coimpleet sure whats all blocking events. but i think one of them is 
teleporting avatars and possible slow
requests.

Thats why i like to know if Sensors and At_Target are running on own thread 
now. (0.7.6dev)


Well, they've been running on their own thread for years (AsyncLSLCmdHandlerThread) so this will not be making any 
difference.  The internals of sensors and at_target are quite complicated.  I couldn't comment further at this time as I 
haven't explored script behaviour in these situations.


--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] compile of opensimulator r/22900 - only warings - test dll's: .NET conflict

2013-07-01 Thread Justin Clark-Casey


On 29/06/13 23:41, OpenSimFan wrote:

here compile log of opensimulator r/22900  it only has warings (some are
interesting)
but **ALL**  test dll's hav a  .NET conflict...

example: (search for text No way to resolve conflict between Ionic.Zip )


so they need to be checked


I don't know why you would get those Ionic.Zip conflicts - there is only one Ionic.Zip.dll in the bin directory.  I 
suggest cleaning and completely rebuilding.





links to log:
-  r22900 compile log.txt
https://docs.google.com/file/d/0B-wo1XpNQPmyZDBMV0dXRWpRR2M/edit?usp=sharing
-  r22900 compile log.rtf
https://docs.google.com/file/d/0B-wo1XpNQPmyTmw1NnR0N2NqZ2M/edit?usp=sharing
-  r22900 compile log.pdf
https://docs.google.com/file/d/0B-wo1XpNQPmyZ0Q3S3NRQUZ0ZFk/edit?usp=sharing




hope this helps
...



-
_
Keep up the good work.!!! - OpenSimFan
My Opensim/Second Life Blog
http://verwijs.wordpress.com
(Dutch, basic hardware/software help  windows, Mac, Linux)
http://verwijs-pc.nl
My Twitter Page:
http://twitter.com/OpenSimFan
My Facebook page (be my friend, please )
http://www.facebook.com/andre.verwijs
--
View this message in context: 
http://opensim-dev.2196679.n2.nabble.com/compile-of-opensimulator-r-22900-only-warings-test-dll-s-NET-conflict-tp7578677.html
Sent from the opensim-dev mailing list archive at Nabble.com.
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev




--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] ¡NECESITAMOS TU VOTO! Estamos participando en BBVA Open Talent 2013.

2013-05-14 Thread Justin Clark-Casey


Yes, please do not send this kind of thing to the mailing lists, Jhon.  This is 
for development discussion.

On 14/05/13 21:37, Mark Malewski wrote:

WTC??  Is this spam?  Are these Spanish Marketing Materials?

I don't see how this pertains to OpenSim development.

If you are a new user looking for help, I would love to try and help you, but 
can you try to *speak _English_* please...

Mark


2013/5/14 JHON FELIPE URREGO MEJIA i...@jhonfelipeurregomejia.com 
mailto:i...@jhonfelipeurregomejia.com


Proyectos

logo


  PLANTILLAS TICColombia | Innovación y tecnología

Se trata de mas de 1200 plantillas para ser usadas en el área de educación, 
marketing y social media

http://jhonfelipeurregomejia.com/nuevasplantillas2013

Compartir 
https://www.centrodeinnovacionbbva.com/opentalent/votaciones/904-plantillas-tic#
Debes registrarte para poder votar, puedes hacerlo si tienes cuenta en 
GOOGLE:
https://www.centrodeinnovacionbbva.com/auth/google; o en TWITTER
https://www.centrodeinnovacionbbva.com/auth/twitter; o en FACEBOOK 
https://www.centrodeinnovacionbbva.com/auth/facebook
Puedes hacerlo manualmente en https://www.centrodeinnovacionbbva.com/signup

Votar a este proyecto 
https://www.centrodeinnovacionbbva.com/opentalent/votaciones/904-plantillas-tic


___
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




--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Problems With Teleports in 7.5

2013-05-09 Thread Justin Clark-Casey

I suggest trying the setting

async_call_method = UnsafeQueueUserWorkItem

in [Startup] if you are running mono 2.10 or later. This setting uses the built in thread pool for non-script temporary
threads rather than the SmartThreadPool (STP) package that OpenSimulator included in 0.7.5 post-fixes. There appears to
be an association between STP and this issue. See Mantis 6557 [1] for more details, which sounds like the same issue.

It appears that the built-in threadpool worked badly on mono 2.4 and before, which was one of the reasons for STP.
However, I believe this was resolved in mono 2.10 (though more data is very welcome). I have also updated the version
of STP used in current OpenSimulator dev code which may or may not help - awaiting results on this.

[1] http://opensimulator.org/mantis/view.php?id=6557

On 15/04/13 17:31, David Saunders wrote:

Hey

I ran into a problem I having trouble tracing down to something to fix...

using OpenSim 0.7.5 Post_Fixes:

My problem is Avatars try to TP into a region and the region thinks
they have arived but they never get
teleported. Then it removes the agent, including loging them out. And they are
hanging in the sim before the teleport
and shown offline.

This happens after a set of time, and then all avatars trying to TP into
the sim are handle this way. The sim
needs to be restarted for this to be resolved.

The Avatar who has failed teleport will receive the alerts from the target
sim. receive local chat from the the sim
there in.

On reset the Avatar is booted from the grid.

I have installed this same code on about 13 different sims and not seen this
happening with any of them. These are
are sims that been updated from 7.2 with new cache directories and asset
directory so its unlikely a cross contamination
of dlls.

David

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

Re: [Opensim-dev] Opensim-dev Client-side NPC development update (youtube)

2013-04-19 Thread Justin Clark-Casey

Coarse location updates are used by the viewer to display the avatar green dots on the minimap.  Decreasing the 
frequency (by increasing n frames) simply means that human viewers will see the minimap updating less frequently.


This is completely unrelated to the position updates that actually change your 3D view of other avatars, so I'm 
surprised that increasing this value allows you to place more bots.


On 18/04/13 17:50, Dave Gubser wrote:

NPCs and General Number of AVs in a sim:

UpdateCoarseLocationsEveryNFrames in Opensimdefaults.ini (in the bin folder)
I found, what appears to be a bottleneck related to the # of users in a
simulator/servers ability to update each users position (to each other).
Experimenting with over 22 NPC on my sims, generated missing or corrupted AV
position information communications from the server. Adding the
UpdateCoarseLocationsEveryNFrames = 50 (experiment with values that work for
you) allowed me to place 50 plus bots (all actually going someplace and
performing functions) on sims with this added line, modification. It also
appears to have no effect on any other part of the simulator. The question
being, by modifying my Opensim.ini with the line, am I going to break
something else?... some bad effect?
For fun, I included a Youtube vid of the latest npc updates:
http://www.youtube.com/watch?v=HxrdbV9OFYw
-Dave


-Original Message-
From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of
opensim-dev-requ...@lists.berlios.de
Sent: Thursday, April 18, 2013 3:00 AM
To: opensim-dev@lists.berlios.de
Subject: Opensim-dev Digest, Vol 68, Issue 9

Send Opensim-dev mailing list submissions to
opensim-dev@lists.berlios.de

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.berlios.de/mailman/listinfo/opensim-dev
or, via email, send a message with subject or body 'help' to
opensim-dev-requ...@lists.berlios.de

You can reach the person managing the list at
opensim-dev-ow...@lists.berlios.de

When replying, please edit your Subject line so it is more specific than
Re: Contents of Opensim-dev digest...


Today's Topics:

1. Re: AddRegion() not triggered (FoTo50)


--

Message: 1
Date: Wed, 17 Apr 2013 15:30:19 +0200
From: FoTo50 i...@foto50.com
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] AddRegion() not triggered
Message-ID: 516ea3eb.5090...@foto50.com
Content-Type: text/plain; charset=iso-8859-1; Format=flowed

Hi Justin

My other 2 modules (search and profile) do not run into this issue,
allthough they are more or less structured the same way. The money module is
like all my others a shared module. When I add debug lines to the log, I can
see it running through Initialise(IConfigSource source)
and then never hear/read anything of it anymore. Not AddRegion() or
RegionLoaded() or anything else ... and it either receives AddRegion for all
regions or for none. When I check with show modules it tells me that it is
not even loaded (running here 0.7.5 stable btw), allthough some custom
console commands of the module are working.

Thanks for the hint with the log level of RegionModulesControllerPlugin.
Turning this to DEBUG I get sometimes a line (when it loads correctly)
like:

DEBUG -
OpenSim.ApplicationPlugins.RegionModulesController.RegionModulesControllerPl
ugin
[REGIONMODULE]: Deferred load of jOpenSimMoneyModule and a bit later then
DEBUG -
OpenSim.ApplicationPlugins.RegionModulesController.RegionModulesControllerPl
ugin
[REGIONMODULE]: Adding scene testregion to shared module jOpenSimMoneyModule
(deferred)

... but when it fails, it writes only the first one and then later it adds
the BetaGridLikeMoneyModule instead, allthough this should be disabled by
configuration in OpenSim.ini:

[Startup]
...
economymodule = jOpenSimMoneyModule
...

Also something interesting: once it failed to startup correct, it will
fail to startup correct most of time later at restart. Renaming the
containing folder helps sometimes ?!?!?

Greetz
Georg



Am 16.04.2013 22:37, schrieb Justin Clark-Casey:

I'm not sure what would cause this behaviour, since AddRegion() should
always be triggered on startup and if there was a general problem then
there would be many problems with core modules.

Do any other modules suffer this issue?  Is this a shared or
non-shared module?  Does the module receive AddRegion for other
regions?  Does the module receive other events?

You can see more information on module startup if you change the
RegionModulesControllerPlugin log level in OpenSim.exe.config.  In
fairly recent dev versions of OpenSimulator there is also a show
modules command which will show loaded modules.

On 16/04/13 16:01, FoTo50 wrote:

Hi

Developing a third party (currency) module I run into some strange
behaviour. Sometimes AddRegion() is triggered at startup, sometimes
it is not triggered. Does somebody know

Re: [Opensim-dev] Documentation for IClientNetworkServer

2013-04-19 Thread Justin Clark-Casey

A great place to do this would be on new wiki page(s) linked from [1]. Please feel free just to create a wiki account
and start editing! I haven't yet written up any general information the LL viewer-server protocol and it would be great
to have some.

Another place for protocol information might be the libomv wiki [2], though on a (very) casual glance I don't see any
protocol-level doc apart from the auto-extracted UDP message templates.

The other sources of protocol information would be the LL wiki.

[1] http://opensimulator.org/wiki/Communication_Protocols
[2] http://lib.openmetaverse.org/wiki/Developer_Portal

On 19/04/13 20:10, Sergiy Byelozyorov wrote:

Thank you. This mailing list is in principle some kind of documentation. :-)

Btw, I have done some study of the LL protocol and wrote a small summary for a
few messages (that were logged by the
server while a client has performed a few simple actions such as walking and
flying). I haven't found any documentation
on the protocol other than the one in the code, which is where I have got the
information from. Perhaps someone can use
my research - where can I post my study? Would be also great if I could update
it as I will continue to learn more about
the protocol with time.

Sergiy

On Tue, Apr 16, 2013 at 11:06 PM, Justin Clark-Casey jjusti...@googlemail.com
mailto:jjusti...@googlemail.com wrote:

This is very old code, some of which was originally present for load
balancing experiments which have long been
defunct and the original coders unavailable. Its purpose was also
completely undocumented. Therefore, I have
removed NetworkStop().

As for AddScene, you can assume it will only be called once. There is a
mechanism in OpenSimBase which looks like
it was intended as a bypass (presumably so that AddScene() could be called
multiple times on a single
INetworkClientServer). But I believe this was again present for the above
load balancing experiments and is
effectively defunct.

I'm afraid no general documentation really exists for the client stack
interfaces and mechanisms. The best we can
do is try and fill in the blanks on request.

On 15/04/13 15:27, Sergiy Byelozyorov wrote:

Also what's the difference between Stop and NetworkStop?

Sergiy

On Mon, Apr 15, 2013 at 4:21 PM, Sergiy Byelozyorov rryk...@gmail.com
mailto:rryk...@gmail.com
mailto:rryk...@gmail.com mailto:rryk...@gmail.com wrote:

Hi,

I am implementing a new client network server class. Is there any
documentation on IClientNetworkServer? In
particular I am interested whether AddScene may be called several
times or not.

Sergiy

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

Re: [Opensim-dev] AddRegion() not triggered

2013-04-19 Thread Justin Clark-Casey

On 17/04/13 14:30, FoTo50 wrote:

Hi Justin

My other 2 modules (search and profile) do not run into this issue, allthough
they are more or less structured the same
way. The money module is like all my others a shared module. When I add debug
lines to the log, I can see it running
through Initialise(IConfigSource source) and then never hear/read anything of
it anymore. Not AddRegion() or
RegionLoaded() or anything else ... and it either receives AddRegion for all
regions or for none. When I check with
show modules it tells me that it is not even loaded (running here 0.7.5
stable btw), allthough some custom console
commands of the module are working.

Perhaps you could pastebin the module code if it's not confidential so we can take a quick look (though personally I
probably won't get a chance until Monday).

Thanks for the hint with the log level of RegionModulesControllerPlugin. Turning this
to DEBUG I get sometimes a
line (when it loads correctly) like:

DEBUG -
OpenSim.ApplicationPlugins.RegionModulesController.RegionModulesControllerPlugin
[REGIONMODULE]: Deferred load
of jOpenSimMoneyModule
and a bit later then
DEBUG -
OpenSim.ApplicationPlugins.RegionModulesController.RegionModulesControllerPlugin
[REGIONMODULE]: Adding scene
testregion to shared module jOpenSimMoneyModule (deferred)

... but when it fails, it writes only the first one and then later it adds the
BetaGridLikeMoneyModule instead,
allthough this should be disabled by configuration in OpenSim.ini:

At the moment, by default OpenSimulator loads all modules even if they are disabled in their individual configurations
(e.g. by Enabled = false). This is wasteful and confusing. I believe there is a mechanism for preventing load
altogether but I haven't used it myself so I don't remember what it is (not very useful, I know). I will try and have a
look next week.

[Startup]
...
economymodule = jOpenSimMoneyModule
...

Also something interesting: once it failed to startup correct, it will fail
to startup correct most of time later at
restart. Renaming the containing folder helps sometimes ?!?!?

Perhaps the Mono addins cache is getting corrupted, even though we haven't seen this for a long time. You might want to
try deleting bin/addin-db-001 before restarting if this happens.

Greetz
Georg

Am 16.04.2013 22:37, schrieb Justin Clark-Casey:

I'm not sure what would cause this behaviour, since AddRegion() should always
be triggered on startup and if there was
a general problem then there would be many problems with core modules.

Do any other modules suffer this issue? Is this a shared or non-shared module?
Does the module receive AddRegion for
other regions? Does the module receive other events?

You can see more information on module startup if you change the
RegionModulesControllerPlugin log level in
OpenSim.exe.config. In fairly recent dev versions of OpenSimulator there is also a
show modules command which will
show loaded modules.

On 16/04/13 16:01, FoTo50 wrote:

Developing a third party (currency) module I run into some strange behaviour.
Sometimes AddRegion() is triggered at
startup, sometimes it is not triggered. Does somebody know what could cause
this behaviour? (running on several
plattforms, but mostly under linux/mono 2.10.8.1)

Greetz
FoTo50 alias Georg

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

Re: [Opensim-dev] Documentation for IClientNetworkServer

2013-04-16 Thread Justin Clark-Casey

This is very old code, some of which was originally present for load balancing experiments which have long been defunct
and the original coders unavailable. Its purpose was also completely undocumented. Therefore, I have removed
NetworkStop().

As for AddScene, you can assume it will only be called once. There is a mechanism in OpenSimBase which looks like it
was intended as a bypass (presumably so that AddScene() could be called multiple times on a single
INetworkClientServer). But I believe this was again present for the above load balancing experiments and is effectively
defunct.

I'm afraid no general documentation really exists for the client stack interfaces and mechanisms. The best we can do is
try and fill in the blanks on request.

On 15/04/13 15:27, Sergiy Byelozyorov wrote:

Also what's the difference between Stop and NetworkStop?

Sergiy

On Mon, Apr 15, 2013 at 4:21 PM, Sergiy Byelozyorov rryk...@gmail.com
mailto:rryk...@gmail.com wrote:

Hi,

I am implementing a new client network server class. Is there any
documentation on IClientNetworkServer? In
particular I am interested whether AddScene may be called several times or
not.

Sergiy

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

Re: [Opensim-dev] AddRegion() not triggered

2013-04-16 Thread Justin Clark-Casey

I'm not sure what would cause this behaviour, since AddRegion() should always be triggered on startup and if there was a 
general problem then there would be many problems with core modules.


Do any other modules suffer this issue?  Is this a shared or non-shared module?  Does the module receive AddRegion for 
other regions?  Does the module receive other events?


You can see more information on module startup if you change the RegionModulesControllerPlugin log level in 
OpenSim.exe.config.  In fairly recent dev versions of OpenSimulator there is also a show modules command which will 
show loaded modules.


On 16/04/13 16:01, FoTo50 wrote:

Hi

Developing a third party (currency) module I run into some strange behaviour. 
Sometimes AddRegion() is triggered at
startup, sometimes it is not triggered. Does somebody know what could cause 
this behaviour? (running on several
plattforms, but mostly under linux/mono 2.10.8.1)

Greetz
FoTo50 alias Georg


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




--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] asset type vs inventory type

2013-03-13 Thread Justin Clark-Casey


On 13/03/13 12:40, Jeff Kelley wrote:

At 8:57 PM -0700 3/12/13, Mic Bowman wrote:


maybe a better question... are inventory types used for anything other than to 
put
the right icon in the viewer (without the need to pull the asset) and put stuff 
in the
right default folder?



According to http://opensimulator.org/wiki/Custom_Libraries

« Inventory type is what tells the viewer which sort of icon to show next to 
the inventory item's name. »


It also controls the variable part of the contextual menu (Open, Wear, Attach, 
Play, Teleport) and which
editor to use.


Yes, it does seem a messy crossover with much of the inventory type covered by equivalent asset type enums.  But it's 
not a subset - inventory type has an attachment enum for instance.  Although whether that particular enum is actually 
used I couldn't say.


--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Cant compile opensim with mono 3

2013-03-11 Thread Justin Clark-Casey

I rather doubt that. I think it's much more likely you have some old stuff hanging about. If you're going to compile
and use your own mono you really need to uninstall the system's packaged version, otherwise there's a good chance of
encountering issues like this.

On 11/03/13 21:58, R.Gunther wrote:

Looks like i have the answhere, you need to compile mono 2.10.9 in my case
first in userspace.
after that you can compile mono 3.0.6 without problems. dont ask me why.. the
system did have mono 2.10.6 default
installed.

On 2013-03-11 20:15, R.Gunther wrote:

Well installed mono 3 in userspace like i do always, try to compile opensim
0.7.5 release but it fails and complaining
about gmcs.exe
gmcs.exe is in /the user director bin mono directory. also export lines are set
and mono -V tells me that i use mono -V

[csc] Cannot open assembly
'/home/./bin/mono-3.0.6/lib/mono/2.0/gmcs.exe': No such file or directory.

BUILD FAILED - 0 non-fatal error(s), 2 warning(s)

/home/./grid/Build/opensim-0.7.5-source/ThirdParty/SmartThreadPool/SmartThreadPool.dll.build(6,6):
External Program Failed:
/home/./bin/mono-3.0.6/lib/mono/2.0/gmcs.exe (return code was 2)

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

Re: [Opensim-dev] Change JSON constants to be able to act as independent flags?

2013-02-19 Thread Justin Clark-Casey


On 19/02/13 18:01, Mic Bowman wrote:

I'm generally not in favor of bit fields. they are too hard to extend. two 
alternatives that might work based on the
idea that there are really two pieces of information we want to convey... the 
type of the JSON node (null, object/hash,
array, value) and the type of value in a value node.


An LSL integer would give you 31 bits to play with - do you envisage needing more than 31 constants (ignoring the 
potential to use negative constants)?  I'm also curious as to what extendability you're thinking of - JSON is unlikely 
to change.




0) take the OSD approach and just return the type of the node/value (which is 
where I had planned to end up), null is 0,
hash/object is 1, array is 2, value is anything greater than 2, string is 3, 
integer 4, etc...


The caller then has to know that there is an order to the constants.  If I want to see if something is a value then I 
need to do  JSON_TYPE_VALUE whereas for any other type I would use ==, which doesn't feel particularly intuitive to me.


Using a flag approach also appears very common in LSL and would work more as scripters expect (using bit operators for 
comparison, etc.).  I know you're not a fan of LSL but I believe it's better to try and work with the grain where possible.




1) partition the return into a node type and value type. use the bottom three 
bits for node type and the rest for the
value type if the node is a value node; this at least provides some space for 
future extensibility


I think a mixed bits and values approach is the worst of both worlds - callers then need to know which constants can be 
tested with bit operators and which cannot!




2) split the operations into two.. JsonGetNodeType() and JsonGetValueType()


You could do that.  It would match the JsonGetValue(), JsonSetValue(), etc. functions.  I would argue they are still 
both better off using flag constants for the reasons above.




--mic


On Mon, Feb 18, 2013 at 5:02 PM, Justin Clark-Casey jjusti...@googlemail.com 
mailto:jjusti...@googlemail.com wrote:

Hi Mic.  One small thing in case I don't catch you on IRC - could we change 
the Json node types to be independently
flaggable values rather than 0, 1, 2, 3 as they are at the moment?  That 
way, one would be able to more easily flag
a node as both Value and String in the future, for example.

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

Re: [Opensim-dev] Diva Groups and Offline IM

2013-02-19 Thread Justin Clark-Casey

On 19/02/13 09:25, Toni Alatalo wrote:

So this is “a module in core”, while R.Gunther thinks there’s “too much in
core and not enough in modules”.
So R.Gunther is happy as this is indeed a module? Even though it is in ‘core’.
Or?
Is there a name/term for the non-module parts of that ‘core’ BTW -- the
Opensimulator Kernel or what?  Core-Core? (I
use that sometimes for Tundra core to differentiate from
also-modules-in-central-repo/default-distro, which some others
call ‘core’ similarily to opensim speech I think).

At this stage, many parts of OpenSimulator that are implemented modules as core to the project, such as inventory access
modules and archiving modules.

Many, many years ago, a split was done in OpenSimulator to put things in 'CoreModules' and 'OptionalModules' with the
intent of moving the optional modules out one distant day. However, I suspect some of those optional modules would now
be properly considered core. Whether anybody actually ever removes the 'OptionalModules' DLL I don't know.

The line for a 'core' module is somewhat arbitrary since I think it depends on a number of factors, such as how much a
particularly piece is infrastructure, how much use it would get, how many core developers are willing to maintain it,
etc. And this may well evolve over time.

~Toni
*From:* Justin Clark-Casey jjusti...@googlemail.com
mailto:jjusti...@googlemail.com
*Sent:* ‎February‎ ‎19‎, ‎2013 ‎3‎:‎16‎ ‎AM
*To:* opensim-dev@lists.berlios.de mailto:opensim-dev@lists.berlios.de
*Subject:* Re: [Opensim-dev] Diva Groups and Offline IM
Yes, I think this is a perfectly reasonable kind of thing to go in core, as I
would regard it as basic infrastructure.

It will be a module in core anyway, and the existing external groups solutions
(Flotsam and Simian, for example) will
continue to work. I would also like to thank Diva for contributing this
functionality - a core groups service is
something I've wanted to see for a very long time but never had the time to
implement.

On 17/02/13 01:54, John Sheridan wrote:

I'm just theorizing here, but I would think that common components required
for interoperability between grids would
need to go into the core. Just recently I finished writing my own offline
IM handler in c# only to realize it didn't
save messages that came in from over the hypergrid. I've yet to dig in to
see why, but after pouring over different
examples on how to get profiles working I'm quickly realizing that there is
a need for a common way for all of these
services to communicate.

Its one thing to have your own proprietary communications formats if you're
running a closed grid, but in the case where
your components need to talk to other people's - that seems to be a
different story. For example, with my profiles
module I wanted to create a set of data objects (psProfile, psProfilePick,
psProfileClassifieds, etc.), serialize them
on the sim end, then ship them off to the profiles server and vice versa.
After seeing how other projects out there
communicate with their server counterparts, it became blatantly apparent
that my way would work just fine if it were
used on a closed grid but not in a Hypergridded environment where it would
need to talk to countless other profile
servers that all likely communicate in different ways. I'm pretty sure the
same would hold true for offline messaging,
groups, and so on.

On 02/16/2013 07:32 PM, R.Gunther wrote:

Opensim core ?
I hope it's going to be a module, and not in the core of opensim. I
have the idea there's already to much in
core and
not enough in modules.

On 2013-02-16 21:07, Diva Canto wrote:

Heads up: after discussion within core devs, the Groups and Offline
IM addons I did for D2 are going to be
donated to
core opensim. This means that core opensim will have support for
these out of the box without having to
install any
further components (i.e. apache). They work both for standalones
and grids. Diva Groups has the optional HG
service
for supporting groups with foreign users. It also implements
notices with attachments, something that is
missing from
Flotsam groups. It does not implement the voting and accounting
features of the viewer (patches welcome).

For those using Flotsam or Simian Groups, they're all mutually
exclusive -- the config decides which one to use.

The code will be added within the next week. If there are any
issues or questions, let us know.

Cheers
Diva
_
Opensim-dev mailing list
Opensim-dev@lists.berlios.de mailto:Opensim-dev@lists.berlios.de
https://lists.berlios.de/__mailman/listinfo/opensim-dev
https://lists.berlios.de/mailman

Re: [Opensim-dev] Diva Groups and Offline IM

2013-02-18 Thread Justin Clark-Casey

Yes, I think this is a perfectly reasonable kind of thing to go in core, as I
would regard it as basic infrastructure.

It will be a module in core anyway, and the existing external groups solutions (Flotsam and Simian, for example) will
continue to work. I would also like to thank Diva for contributing this functionality - a core groups service is
something I've wanted to see for a very long time but never had the time to implement.

On 17/02/13 01:54, John Sheridan wrote:

I'm just theorizing here, but I would think that common components required for
interoperability between grids would
need to go into the core. Just recently I finished writing my own offline IM
handler in c# only to realize it didn't
save messages that came in from over the hypergrid. I've yet to dig in to see
why, but after pouring over different
examples on how to get profiles working I'm quickly realizing that there is a
need for a common way for all of these
services to communicate.

Its one thing to have your own proprietary communications formats if you're
running a closed grid, but in the case where
your components need to talk to other people's - that seems to be a different
story. For example, with my profiles
module I wanted to create a set of data objects (psProfile, psProfilePick,
psProfileClassifieds, etc.), serialize them
on the sim end, then ship them off to the profiles server and vice versa.
After seeing how other projects out there
communicate with their server counterparts, it became blatantly apparent that
my way would work just fine if it were
used on a closed grid but not in a Hypergridded environment where it would need
to talk to countless other profile
servers that all likely communicate in different ways. I'm pretty sure the
same would hold true for offline messaging,
groups, and so on.

On 02/16/2013 07:32 PM, R.Gunther wrote:

Opensim core ?
I hope it's going to be a module, and not in the core of opensim. I have the
idea there's already to much in core and
not enough in modules.

On 2013-02-16 21:07, Diva Canto wrote:

Heads up: after discussion within core devs, the Groups and Offline IM addons I
did for D2 are going to be donated to
core opensim. This means that core opensim will have support for these out of
the box without having to install any
further components (i.e. apache). They work both for standalones and grids.
Diva Groups has the optional HG service
for supporting groups with foreign users. It also implements notices with
attachments, something that is missing from
Flotsam groups. It does not implement the voting and accounting features of the
viewer (patches welcome).

For those using Flotsam or Simian Groups, they're all mutually exclusive -- the
config decides which one to use.

The code will be added within the next week. If there are any issues or
questions, let us know.

Cheers
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] OpenSimulator 0.7.5 released

2013-02-08 Thread Justin Clark-Casey

Hi folks.  OpenSimulator 0.7.5 is now officially released [1] with release 
notes at [2].

As usual, huge thanks to everybody who contributed code, tested and identified 
errors, wrote documentation, helped newbies and all
the other things that are necessary for an open-source project to function.

I couldn't resist including a number of low-risk fixes that had emerged since 
0.7.5-rc2.  The most significant of these are a 
fix for mesh import so that the rotation of the components matches that seen in 
the viewer preview and a fix for an issue where wearables
would not be found within inventory on relog if they were renamed whilst still 
worn after being edited.

The full summmary of the commits since 0.7.5-rc2 is below.

a2d327b Merge branch '0.7.5-post-fixes' of 
ssh://opensimulator.org/var/git/opensim into 0.7.5-post-fixes
3063831 Bump 0.7.5 flavour to Release
689da0f If a component of a coalesced object fails to deserialization, do not 
add a null where the object should be.
6d3b2d2 On IAR loading, if loading of a coaleseced item entirely fails, then 
continue with the IAR load rather than failing completely.
78debc9 * the root prim was being given an OffsetPosition in addition to 
setting the position when creating the root prim.   The offset position caused 
the positioning code to re-move the root prim
e3f01f2 Try to fix uploaded mesh rotations - code from Avination code base.
f28a592 Added option for UUID as command parameters. This lets the command 
handle the UUID parsing and type checking before the command is executed.
4c4cc91 minor: Tidy up disabled logging on AssetTransactionModule for future 
use.  Make it clear that transaction parameter to HandleUDPUploadRequest is an 
ID.
43a minor: remove some mono compile warnings in XEngine.cs
eab57cd Prevent items being destroyed by rename operations. Renaming of a 
wearable also sends an asset transaciton but it is empty. So we can't ignore 
name data when a transaction is present and ca
5b60f63 Fix issue where the set terrain texture console command did not tell 
the viewers that textures had updated (hence they did not display the changes).
d132099 Mantis 6343: Turn a prim to flexy to OFF don't work llSetPrimParams
319069d Assign the SmartThreadPool name in the constructor
82268d7 Explicitly stop PollServiceRequestManager() rather than relying on its 
destructor.
efcbae3 Mantis 6507 keys returned by llGetAgentList incorrect for llList2Key
6e5d352 Changed protection of CreateDefaultAppearanceEntries to protected, so 
extensions of the UserAccountService can reuse this.

[1] http://opensimulator.org/wiki/Download
[2] http://opensimulator.org/wiki/0.7.5_Release

-- 
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Dynamic attributes

2013-02-07 Thread Justin Clark-Casey

I think this is a good point - if script access to dynamic attributes is every considered to be 'secure' (which might be 
a debatable point), one can't allow them to store indefinite amounts of data there.  Even in an 'insecure' situation, it 
might be best to stop scripts being able to casually do this (which perhaps comes down to the debate I think that Mic 
and I were having about whether you assume the feature users are completely dumb or completely smart or try not to give 
them so much rope that they can easily accidentally hang themselves - I might be paraphrasing).


The same thing is really true of the vanilla JsonStore since this is not limited either right now and could suck up all 
the memory even if its not persisted.


On 07/02/13 02:11, Melanie wrote:

A word of caution:

Many people have scripts that would store copious amounts of data.
Some limits need to be placed on the overall storage given to a
script so it becomes unattractive to store lots of data in the
simulator. Scripts needing lots of storage should use a web server,
not sim resources.

Melanie

On 07/02/2013 02:59, Mic Bowman wrote:

for discussion purposes...

added the jsonstore connection to the dynamic attributes. here's an example
of an LSL script that sets the attributes (create a notecard called
JsonData with some json structure inside it)... you can interrogate the
store through channel 30... eg /30 jstoretest.test1.field

btw... i really think that hooking up the object store with a variant of
llrezobject() would be very good. it would make passing more complex
initialization parameters a LOT easier (better than the one integer you get
right now). i'm doing this with a modified version that uses a global
jsonstore...

--mic


integer iChannel = 30;
string sInitCard = JsonData;
key kStoreID;

InitializeObjectStore()
{
 llOwnerSay(initializing the object store);
 JsonSetValueJson(kStoreID,jstoretest,{'test1': {'field' : 22}});
 JsonReadNotecard(kStoreID,jstoretest, sInitCard);
}

default
{
 state_entry()
 {
 kStoreID = JsonAttachObjectStore();
 if (JsonTestPathJson(kStoreID,jstoretest) == 0)
 InitializeObjectStore();

 llOwnerSay(object store is  + JsonGetValueJson(kStoreID,.));

 llListen(iChannel,,llGetOwner(),);
 }

 listen(integer ch, string name, key id, string msg)
 {
 if (ch == iChannel)
 {
 list tokens = llParseString2List(msg,[ ],[]);
 string path = JsonList2Path(tokens);
 string value = JsonGetValueJson(kStoreID,path);
 llOwnerSay(path +  ==  + value);
 }
 }
}



On Wed, Feb 6, 2013 at 3:00 PM, Mic Bowman cmick...@gmail.com wrote:


one more thing... is there a strong reason for XML serialization as
opposed to json? (I assume the primary reason is for consistency with other
properties.) the OSDMap data structure corresponds fairly closely to JSON.
serializing works fine for either format though it is easy to provide an
xml document that will not deserialize into an OSDMap.

--mic


On Wed, Feb 6, 2013 at 1:58 PM, Mic Bowman cmick...@gmail.com wrote:


Justin,

I took a look at the DAMap data structure  have some questions. What's
the value of explicit methods for the top level of the structure? It is
still possible to have name space collisions since there is nothing that
prevents one module from writing into another module's name space. Also,
whats your expectation for locking? The top level accessor locks the
structure, but modules that share the rest of the structure will have to do
their own locking anyway. I guess one value of controlling the top level is
that *IF* modules are making exclusive access to the structure, the locking
is minimized. Hard to control that, though.

Did you get a chance to look at the JsonStore structure? The path-based
accessors are very different than providing immediate access to the OSDMap.
As we discussed, I made that decision to support the synchronization
operations (take  read) and it removes the exposed OSDMap so that the data
structure can be replaced. I think the path-based accessor is probably too
heavyweight for DAMap... well... maybe... given that we dont have any
examples yet its hard to tell. :-)

--mic


On Mon, Feb 4, 2013 at 5:09 PM, Justin Clark-Casey 
jjusti...@googlemail.com wrote:


Okay, I have now merged this branch (dynamic-attributes2) to master.
  Please report any problems (or fix them :)

As this is experimental functionality, if necessary it can be
changed/bug-fixed without any attempt to preserve existing data.  Any code
using it should handle the 'expected data not found' case anyway.

On 26/01/13 19:52, Adams, Robert wrote:


This implementation will work for physics. The physics engine cannot
reference Scene (circular reference madness) so, on creation of the scene's
physics instance, I will pass in the instance of DAMap (since it is defined
in OpenSim.Framework) much the same way the asset request

[Opensim-dev] JsonStore questions - return values of JsonDestroyStore(), JsonRemoveValue() and behaviour of JsonReadNotecard()

2013-02-07 Thread Justin Clark-Casey


Hi Mic.  A couple of JsonStore related questions

* Both JsonDestroyStore() and JsonRemoveValue() return TRUE if the store/values they are removing do not exist.  This is 
inconsistent with .NET methods such as ICollection.Remove() which return false if the value one tried to remove did not 
exist.


This is a pretty minor case and perhaps it's not worth changing if you (or others) already have scripts which rely on 
this behaviour.  What do you think?


* In my regression testing, I found some behaviour with JsonReadNotecard() that I did not expect surrounding loading to 
multi-component paths where some or all of the tail components did not exist and loading to the invalid location (/) 
I put this information in Mantis 6535 [1] if you could comment.  It could just be me making mistakes late at night.


[1] http://opensimulator.org/mantis/view.php?id=6535

--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Dynamic attributes

2013-02-06 Thread Justin Clark-Casey


On 06/02/13 21:58, Mic Bowman wrote:

Justin,

I took a look at the DAMap data structure  have some questions. What's the 
value of explicit methods for the top level
of the structure? It is still possible to have name space collisions since 
there is nothing that prevents one module
from writing into another module's name space. Also, whats your expectation 
for locking? The top level accessor locks
the structure, but modules that share the rest of the structure will have to do 
their own locking anyway. I guess one
value of controlling the top level is that *IF* modules are making exclusive 
access to the structure, the locking is
minimized. Hard to control that, though.


The idea was to separate out DAMap into 'namespaces' (over-reaching name I know) so that distributed users did not 
casually overwite each other's data by writing directly to a root OSDMap.  Thus, moduleA would always write to a map 
under the name modA and moduleB under the name modB and never the twain would meet.


This doesn't stop modules from deliberately overwriting or deleting each other's data.  But if you really wanted to do 
that you could always achieve it by directly fiddling with the XML serialization.  At least this way, somebody writing a 
module just by experimenting with methods rather than reading doc (which is how most people do it, myself included if 
I'm being honest) will not casually overwrite the properties of another storer.


You're right about the deficient locking story.  At the moment, any module changing its OSDMap directly needs to lock 
DAMap, and even DAExampleModule doesn't do this.


But really, it would be better to lock the individual 'namespace' maps for better granularity.  I may make this change 
if there is no further discussion on this point.


I also think that we need to know what will happen if a module forgets to lock and serialization occurs concurrently 
with a map change.  What we cannot do is write corrupt XML to the SOP serialization.




Did you get a chance to look at the JsonStore structure? The path-based 
accessors are very different than providing
immediate access to the OSDMap. As we discussed, I made that decision to support 
the synchronization operations (take 
read) and it removes the exposed OSDMap so that the data structure can be 
replaced. I think the path-based accessor is
probably too heavyweight for DAMap... well... maybe... given that we dont have 
any examples yet its hard to tell. :-)


Yeah, I really do need to take a closer look.  Will try and do that soon, 
hopefully Fri.



--mic


On Mon, Feb 4, 2013 at 5:09 PM, Justin Clark-Casey jjusti...@googlemail.com 
mailto:jjusti...@googlemail.com wrote:

Okay, I have now merged this branch (dynamic-attributes2) to master.  
Please report any problems (or fix them :)

As this is experimental functionality, if necessary it can be 
changed/bug-fixed without any attempt to preserve
existing data.  Any code using it should handle the 'expected data not 
found' case anyway.

On 26/01/13 19:52, Adams, Robert wrote:

This implementation will work for physics. The physics engine cannot 
reference Scene (circular reference
madness) so, on creation of the scene's physics instance, I will pass 
in the instance of DAMap (since it is
defined in OpenSim.Framework) much the same way the asset request 
method instance is passed in.

I am +2 on this branch's inclusion into master.

-- ra

-Original Message-
From: opensim-dev-bounces@lists.__berlios.de 
mailto:opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-bounces@__lists.berlios.de 
mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of
Justin Clark-Casey
Sent: Friday, January 25, 2013 5:14 PM
To: opensim-dev@lists.berlios.de mailto:opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Dynamic attributes

On 25/01/13 08:40, Oren Hurvitz wrote:

Ok, great. I hope all goes well and this will be added to master 
soon.

What do you mean by put the code in for MSSQL? The code already
supports MySQL, MSSQL and SQLite.


Apologies - my brain stored the assumption that only MySQL had been 
added since that's the only one I remembered
seeing in the commit summaries but I see that the MSSQL code is there.

--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
_
Opensim-dev mailing list
Opensim-dev@lists.berlios.de mailto:Opensim-dev@lists.berlios.de
https://lists.berlios.de/__mailman/listinfo/opensim-dev 
https://lists.berlios.de/mailman/listinfo/opensim-dev
_
Opensim-dev mailing list
Opensim-dev@lists.berlios.de mailto:Opensim-dev@lists.berlios.de
https

Re: [Opensim-dev] Dynamic attributes

2013-02-06 Thread Justin Clark-Casey


On 06/02/13 23:00, Mic Bowman wrote:

one more thing... is there a strong reason for XML serialization as opposed to 
json? (I assume the primary reason is for
consistency with other properties.) the OSDMap data structure corresponds 
fairly closely to JSON. serializing works fine
for either format though it is easy to provide an xml document that will not 
deserialize into an OSDMap.


Your assumption is exactly right.  Embedding dynamic attributes as JSON with the rest of the SOP serialization being XML 
was a new depth of OpenSimulator inconsistency that I couldn't quite stomach.




--mic


On Wed, Feb 6, 2013 at 1:58 PM, Mic Bowman cmick...@gmail.com 
mailto:cmick...@gmail.com wrote:

Justin,

I took a look at the DAMap data structure  have some questions. What's the 
value of explicit methods for the top
level of the structure? It is still possible to have name space collisions 
since there is nothing that prevents one
module from writing into another module's name space. Also, whats your 
expectation for locking? The top level
accessor locks the structure, but modules that share the rest of the 
structure will have to do their own locking
anyway. I guess one value of controlling the top level is that *IF* modules 
are making exclusive access to the
structure, the locking is minimized. Hard to control that, though.

Did you get a chance to look at the JsonStore structure? The path-based 
accessors are very different than providing
immediate access to the OSDMap. As we discussed, I made that decision to 
support the synchronization operations
(take  read) and it removes the exposed OSDMap so that the data structure 
can be replaced. I think the path-based
accessor is probably too heavyweight for DAMap... well... maybe... given 
that we dont have any examples yet its hard
to tell. :-)

--mic


On Mon, Feb 4, 2013 at 5:09 PM, Justin Clark-Casey jjusti...@googlemail.com 
mailto:jjusti...@googlemail.com wrote:

Okay, I have now merged this branch (dynamic-attributes2) to master.  
Please report any problems (or fix them :)

As this is experimental functionality, if necessary it can be 
changed/bug-fixed without any attempt to preserve
existing data.  Any code using it should handle the 'expected data not 
found' case anyway.

On 26/01/13 19:52, Adams, Robert wrote:

This implementation will work for physics. The physics engine 
cannot reference Scene (circular reference
madness) so, on creation of the scene's physics instance, I will 
pass in the instance of DAMap (since it is
defined in OpenSim.Framework) much the same way the asset request 
method instance is passed in.

I am +2 on this branch's inclusion into master.

-- ra

-Original Message-
From: opensim-dev-bounces@lists.__berlios.de 
mailto:opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-bounces@__lists.berlios.de 
mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of
Justin Clark-Casey
Sent: Friday, January 25, 2013 5:14 PM
To: opensim-dev@lists.berlios.de 
mailto:opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Dynamic attributes

On 25/01/13 08:40, Oren Hurvitz wrote:

Ok, great. I hope all goes well and this will be added to 
master soon.

What do you mean by put the code in for MSSQL? The code 
already
supports MySQL, MSSQL and SQLite.


Apologies - my brain stored the assumption that only MySQL had been 
added since that's the only one I
remembered seeing in the commit summaries but I see that the MSSQL 
code is there.

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



--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
_
Opensim-dev mailing list
Opensim-dev@lists.berlios.de mailto:Opensim-dev@lists.berlios.de
https://lists.berlios.de/__mailman/listinfo/opensim-dev 
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Dynamic attributes

2013-02-04 Thread Justin Clark-Casey


Okay, I have now merged this branch (dynamic-attributes2) to master.  Please 
report any problems (or fix them :)

As this is experimental functionality, if necessary it can be changed/bug-fixed without any attempt to preserve existing 
data.  Any code using it should handle the 'expected data not found' case anyway.


On 26/01/13 19:52, Adams, Robert wrote:

This implementation will work for physics. The physics engine cannot reference 
Scene (circular reference madness) so, on creation of the scene's physics 
instance, I will pass in the instance of DAMap (since it is defined in 
OpenSim.Framework) much the same way the asset request method instance is 
passed in.

I am +2 on this branch's inclusion into master.

-- ra

-Original Message-
From: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Justin Clark-Casey
Sent: Friday, January 25, 2013 5:14 PM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Dynamic attributes

On 25/01/13 08:40, Oren Hurvitz wrote:

Ok, great. I hope all goes well and this will be added to master soon.

What do you mean by put the code in for MSSQL? The code already
supports MySQL, MSSQL and SQLite.


Apologies - my brain stored the assumption that only MySQL had been added since 
that's the only one I remembered seeing in the commit summaries but I see that 
the MSSQL code is there.

--
Justin Clark-Casey (justincc)
OSVW Consulting
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




--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Add a JsonTestStore() for the JSON store module?

2013-01-30 Thread Justin Clark-Casey


Thanks Mic.  Sorry I wasn't around earlier - schedule has gone massively late 
again (and I'm probably offline thurs).

I'm not an LSL expert, but I think the classic 'LSL' way to do this would be to 
return a strided list [1].

Maybe something like

JsonGetValues(key storeID, string path):list
JsonGetValuesJson(key storeID, string path):list

So

list stridedVals = JsonGetValues(storeID, foo[*].bar);

to get something like

[foo[0].bar, hello, foo[1].bar, world, ... ]

Then one can use functions like llList2ListStrided to get just the values as 
desired, e.g.

list result_a = llList2ListStrided(stridedVals, 0, -1, 2);
// result_a == [ hello, world ]

In this way, maybe one could even return the deeper structure by listing the full key for each value rather than the 
return serialized approach of the *Json() functions.  Maybe this could be signalled as via an optional constant int 
flags field (in the same LSL way that things like osNpcCreate() take options).


Strided lists are pretty horrible but at least people are familiar with them and there are various functions to help 
with handling them.  I guess it's the only way to get any semblance of nested data structures in LSL.


Also, a couple of other questions, which might just be due to my ignorance of not having looked at the code deeply 
enough yet.


* I see there are many parallel *Json methods such as JsonGetValueJson().  I presume the natural way to parse serialized 
json returned from those (if one wanted) would be to temporarily create a store and then remove it?


* Is the 'JPath' implementation the one at [2] or perhaps the one at [3] or something else entirely?  How much of these 
'specifications' is currently implemented?


[1] http://wiki.secondlife.com/wiki/Category:LSL_List#Strided_lists
[2] http://goessner.net/articles/JsonPath/
[3] http://projects.plural.cc/projects/jsonij/wiki/JPath


On 30/01/13 22:48, Mic Bowman wrote:

Done.

On Wed, Jan 30, 2013 at 8:57 AM, Mic Bowman cmick...@gmail.com 
mailto:cmick...@gmail.com wrote:

I think that would be very useful. I can add it this afternoon, if you 
don't beat me to it.

When I wrote the interface to the Json store, I modeled the path expansion 
after JQuery interface. However, I'm
finding that really challenging to use for iterating through an array of 
values. Right now, I use osFormatString to
create the path dynamically. For example:

integer i = 0;
while (i  10)
{
 string p = osFormatString(foo[{0}].bar,[i]); // create path 
foo[0].bar
 string v = JsonGetValue(storeID,p);
}

If you have any suggestions for a construct that would make the iteration 
cleaner, I would be very interested. I've
bounced around (and written some test code) for taking a list (the 
components of the path) as an argument, but
constructing the list is no easier than constructing the string. I've also 
poked around with creating store handles
that point into an existing store (so you resolve the path foo into a 
store handle then iterate at the top level).
Again, the code to walk through the structure is still excessively complex.

--mic




On Tue, Jan 29, 2013 at 10:03 PM, Justin Clark-Casey jjusti...@googlemail.com 
mailto:jjusti...@googlemail.com wrote:

Hi Mic.  Whilst looking through these functions tonight, it struck me 
that there doesn't appear to be a way to
tell if a certain JSON store still exists, as identified by its key.

Do you think it would be appropriate to add a function for that?  
Perhaps JsonTestStore(), which is in keeping
with JsonTestPath()?

--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
_
Opensim-dev mailing list
Opensim-dev@lists.berlios.de mailto:Opensim-dev@lists.berlios.de
https://lists.berlios.de/__mailman/listinfo/opensim-dev 
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)
OSVW Consulting
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] Add a JsonTestStore() for the JSON store module?

2013-01-29 Thread Justin Clark-Casey

Hi Mic.  Whilst looking through these functions tonight, it struck me that there doesn't appear to be a way to tell if a 
certain JSON store still exists, as identified by its key.


Do you think it would be appropriate to add a function for that?  Perhaps JsonTestStore(), which is in keeping with 
JsonTestPath()?


--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Raise minimum mono version to 2.6

2013-01-28 Thread Justin Clark-Casey

 of OpenSimulator 
developers is
  wide
   adoption, then it makes sense to have it be usable on as many 
existing
   hardware/software configurations as possible.
  
  
  
   On Sat, Jan 26, 2013 at 11:51 AM, Ilan Tochner i...@kitely.com 
mailto:i...@kitely.com
  wrote:
  
   I second setting 2.10 as the base. If we'll be forcing people 
to
   upgrade I think we should upgrade to the latest stable 
release and
  not to
   one that is outdated.
  
   If OpenSim works fine with 3.0 then I'd vote for it to be the 
base.
  If
   we're still calling OpenSim alpha we should at least get the
  benefits of
   doing so. Supporting old versions of mono is a waste of 
developer
  resources.
  
   Cheers,
  
   Ilan Tochner
   Co-Founder and CEO
   Kitely Ltd.
  
  
  
   On Sat, Jan 26, 2013 at 9:20 PM, Trinity trinit...@gmail.com 
mailto:trinit...@gmail.com
  wrote:
  
   if we can get a way with it why not go to 2.10 else quickly 
be out
  of
   date agian
  
  
   On Sat, Jan 26, 2013 at 9:38 AM, James Hughes 
   jam...@bluewallgroup.com mailto:jam...@bluewallgroup.com 
wrote:
  
   +1
  
   On 01/24/2013 10:29 PM, Justin Clark-Casey wrote:
  
   Whilst writing JsonStore regression tests this evening, I 
hit the
   problem where modInvoke script methods of more than 4 
parameters
   cannot
   be registered on Mono 2.4.3 as it doesn't implement the 
required
   larger
   multi-parameter Func generic types.
  
   Therefore, I want to bump the minimum Mono version for
  OpenSimulator
   up
   to 2.6 which was released more than 3 years ago. This also
  involves
   bumping the minimum .net framework version up to 4.0, as 
also
   detailed
   at [1]
  
   [1] http://opensimulator.org/**mantis/view.php?id=5971
  http://opensimulator.org/mantis/view.php?id=5971
  
   Any comments?
  
  
   __**_
   Opensim-dev mailing list
   Opensim-dev@lists.berlios.de 
mailto:Opensim-dev@lists.berlios.de
   https://lists.berlios.de/**mailman/listinfo/opensim-dev
  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 
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 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

Re: [Opensim-dev] Dynamic attributes

2013-01-25 Thread Justin Clark-Casey


On 25/01/13 08:40, Oren Hurvitz wrote:

Ok, great. I hope all goes well and this will be added to master soon.

What do you mean by put the code in for MSSQL? The code already supports
MySQL, MSSQL and SQLite.


Apologies - my brain stored the assumption that only MySQL had been added since that's the only one I remembered seeing 
in the commit summaries but I see that the MSSQL code is there.


--
Justin Clark-Casey (justincc)
OSVW Consulting
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] OpenSimulator 0.7.5-rc2 now available

2013-01-25 Thread Justin Clark-Casey

Hi folks,

OpenSimulator 0.7.5-rc2 [1], the second release candidate for the next version 
of OpenSimulator, is now available [2].

Compared to rc1, the changes are pretty minor - many are tweaks to debug 
console commands and additional debug commands.

Probably the chief change is a fix for a recent functionality regression where 
client AOs, such as that implemented by Firestorm, stopped working as they 
previously had been with OpenSimulator (commit af5a3f2).

Unless there are any showstopping regressions, I expect that this release 
candidate will likely be very close, if not functionally identical, to what is 
ultimately released as OpenSimulator 0.7.5.

The one line git summary of each commit since 0.7.5-rc1 is shown below.

8f32e16 minor: Fix full scene part console report to show proper Light* names 
rather than all wrongly FlexiDrag
c42e2c6 minor: Call down to base OpenSimTestCase.SetUp() in NPCModuleTests to 
disable any enabled logging from previous tests
6bd57f2 Bump version up to 0.7.5-rc2
af5a3f2 Restore previous client AO behaviour by not allowing them to remove the 
default animation but continue to allow scripts to do so.
0ba01ce Check the existing ScenePresence.ParentPart to make sure we're not 
trying to sit on a prim we're already sat upon, rather than looking up the part 
from scratch.
70e1dd5 New constants for llGetObjectDetails
c42bff5 Fix use of scene debug commands when region is set to root or a 
specific region where there is more than one region on the simulator.
10b3c6b Add debug set set animations true|false region console command.
8ecf6ed Add utility function to clamp a vector to a maximum magnitude.
0945044 Changed a couple of debug messages at the request of osgrid.
e2823bf move resit fix to ScenePresence.cs and allow for requesting sit on 
objects other than the object currently sat on
795009c Print full stacktrace from plugin loading failure to help determine 
what went wrong, rather than a possibly unhelpful simple exception message.
cc8fbf7 Fix exception reporting in SceneObjectPart so it logs what the 
exception is rather than just saying it happened.
af27180 add some sanity checking to HandleAgentRequestSit handler
c182157 Fix a regression in the last few scene commands changes where setting 
these via the viewer estate dialog stopped working.
1cda887 Add debug scene get console command to list current scene options
0ba0ac4 Move scene debug commands into separate module.  Command changes from 
debug scene key value to debug scene set key value to accomodate 
future settings
ce8b30d minor: Capitalize GroupsModule command category
d4c4cb3 minor: add missing newline to debug scene console command
ac43006 Remove unimplemented debug teleport console command
069e2d6 Add debug scene pbackup true|false console command.  This enables or 
disable periodic scene backup.  For debug purposes.
30eded2 revert accidental change to MemoryWatchdog stat calculation in previous 
b1b4687
2563553 Add show script timers command to show script timers.  For debug 
purposes.
9de Add show sensors command to show script sensor information for debug 
purposes.
99a5ea9 minor: Remove unnecessary commented out code from last commit c28a2f05 
and fix up code comment
880b236 minor: make spacing consistent in console help output
f47f3dd minor: Fix command match of debug script command to debug scripts 
to match other scripts commands (and it's own short help text)
8ee078c minor: Allow script * console commands to take multiple script item 
ids
17d54a7 Add the new UpdateAgentInformation cap to make maturity on more recent 
viewers work.

[1] http://opensimulator.org/wiki/0.7.5_Release
[2] http://opensimulator.org/wiki/Download

-- 
Justin Clark-Casey (justincc)
OSVW Consulting
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] Fwd: OpenSim - Global-scale Virtual Worlds Standardization Meeting invitation

2013-01-25 Thread Justin Clark-Casey

Hi folks.  Below is an e-mail from Aaron Walsh, director of the Immersive Education Initiative (IEI) [1], a non-profit 
consortium that brings together people enaged in virtual worlds, learning games, simulations, etc. in education.  I've 
been talking with Aaron by e-mail on and off for a number of years now and the IEI has held a number of conferences on 
these topics.


The institute is holding a meeting concerned with open-standards in virtual worlds.  Personally, I think it's too early 
for this to be very productive - the various projects involved are simply too immature - but this is just my own point 
of view and I'm sure it would be interesting to hear what other people have to say on the topic.  And there may be room 
for some kind of standardization in specific areas.


If any developer engaged with OpenSimulator does want to go along then please contact Aaron at the addresses below.  I 
have to assume that Realxtend ppl are going since it's being held on Meshmoon.


[1] http://members.immersiveeducation.org/

 Original Message 
Subject:OpenSim - Global-scale Virtual Worlds Standardization Meeting 
invitation
Date:   Fri, 25 Jan 2013 13:55:51 -0500
From:   Aaron Walsh aaron.e.wa...@gmail.com
To: Justin Clark-Casey jjusti...@gmail.com, Justin Clark-Casey 
jjusti...@googlemail.com



Hi Justin, while in transit I sent you a voice note reply (but to a different 
email address of yours, I think; hopefully
it arrived?). Below is the invitation which includes details on how to 
participate. Please do feel free
to circulate this to your OpenSim community. Cheers, Aaron

... 



IMMERSIVE EDUCATION INITIATIVE : OPEN STANDARDS MEETING
... 




MEETING: Global-scale Virtual Worlds Standardization Meeting
DATE: January 30, 2013
TIME: 12:00PM USA Eastern Standard Time [Boston / New York]

Convert to your own time zone:
http://www.timezoneconverter.com/cgi-bin/tzc.tzc

LOCATION: This meeting will convene in a virtual world. Details
will be posted to the Immersive Education OFF.TWG (Open File Formats)
group. Visit http://ImmersiveEducation.org/groups to participate or contact
the Director at http://MediaGrid.org/people/aew


...

AGENDA:

1. Welcome, overview and introductions
2. Open Scene Description vs. Scene Graph
3. Open Avatar (file format, animation, storage)
4. Open Inventory
5. Open Scripting
6. Open Repository
7. Open iED WebGL viewer

BACKGROUND MATERIALS:

1. Create Once, Experience Everywhere 3D/VR Format Unveiled for iED
http://mediagrid.org/news/2010-11_iED_Create_Once_Experience_Everywhere.html

2. Open File Formats Technology Working Group (OFF.TWG) CHARTER:
http://mediagrid.org/groups/technology/OFF.TWG


LOCATION: This meeting will convene in a virtual world. Details
will be posted to the Immersive Education OFF.TWG (Open File Formats)
group. Visit http://ImmersiveEducation.org/groups to participate or contact
the Director at http://MediaGrid.org/people/aew
.. 





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

[Opensim-dev] Raise minimum mono version to 2.6

2013-01-24 Thread Justin Clark-Casey

Whilst writing JsonStore regression tests this evening, I hit the problem where modInvoke script methods of more than 4 
parameters cannot be registered on Mono 2.4.3 as it doesn't implement the required larger multi-parameter Func generic 
types.


Therefore, I want to bump the minimum Mono version for OpenSimulator up to 2.6 which was released more than 3 years ago. 
 This also involves bumping the minimum .net framework version up to 4.0, as also detailed at [1]


[1] http://opensimulator.org/mantis/view.php?id=5971

Any comments?

--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Dynamic attributes

2013-01-21 Thread Justin Clark-Casey


On 21/01/13 14:15, Oren Hurvitz wrote:

In the interest of clarity I'm starting a new thread for this topic. Previous
discussion can be found here:
http://opensim-dev.2196679.n2.nabble.com/IRegisterInterface-for-extending-scene-entities-td7578406.html

Justin, the dynamic attributes branch allows storing attributes both in
Prims and in PrimShapes. Is there a reason for this? It would be simpler to
store attributes only in the prim.


I probably did this because MOAP is on the PrimitiveBaseShape class (as the property Media) along with other aspects of 
shape appearance.


However, I think it would be simpler to have properties all in one map rather 
than the complexity of two maps.

--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] IRegisterInterface for extending scene entities

2013-01-18 Thread Justin Clark-Casey


Alright, I'm going to suggest

1.  That all attributes must be within their own OSDMap, which must be a minimum of 4 chars long (maybe this could be 
relaxed for 'core' stuff).


2.  Within this map, attribute names and further OSDMap or other structures are 
entirely up to the caller.

3.  At the initial development stage, everything may change such that existing data may no longer be retrieved (e.g. the 
way this is stored or the entire approach may change).  One must not rely on data being present.


4.  If at all possible, this must be backward and forward compatible with other versions of OpenSimulator no matter 
whether it remains or is altered radically.  This should be fine since deserialization will ignore any top-level xml 
nodes that it doesn't recognize.  But we must preserve a Postel's law - this was a painful lesson to learn.


On 18/01/13 22:09, Adams, Robert wrote:

I have a need to add more attributes to an SOP (use specified 
center-of-gravity, user specified mass, rolling friction, ...) and the 
implementation of Justin's dynamic attributes is just what I need. It does not 
fulfill my other wishes of adding functionality to SOPs, but it does allow the 
dynamic addition of new and serialized objects attributes.

Can we Just Do It(r)(tm)(sm)? Some comments in the code suggesting a top level naming 
convention (prepend attribute names with your module name or some such) and 
an admonition to not store large things might be sufficient to control the use of a 
simple OSDMap.

What do you say? I am +1. How about everyone else? It is a start.

-- ra

-Original Message-
From: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Justin Clark-Casey
Sent: Friday, January 04, 2013 5:18 PM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] IRegisterInterface for extending scene entities

No problem in making this e-mails, Robert - I think this is exactly the kind of 
discussion that we need.  These are the kind of decisions that we'll be stuck 
with for a long time so I think we need to think them through, both through 
discussion and review or proof-of-concept code.

I hadn't really properly considered that the JSONStore is close to this.  I 
suppose one other significant difference is that the current dynamic-attributes 
effectively stores data per part rather than through a single datastore for the 
whole region.

But even if it does use the blackboard pattern, there still has to be an 
underlying persistence store, which in this case would be a serialized JSON 
object that is functionally identical with the OSD Map (I've run out of time 
today to see if the JSON store enforces type safety in some way).  Really, the 
code could be very similar, though in terms of formats I would prefer if to 
avoid further schizophrenia over data storage in OpenSimulator.  If we stored 
as JSON, for instance, we end up transporting a JSON object in XML... :p

On 04/01/13 21:22, Adams, Robert wrote:

I think adding a module allowing scripts to attach dynamic variables to SOPs is 
the right level of functionality. Just adding a key/value store is way too low 
a level.

For instance, the JSONStore module 
(http://opensimulator.org/wiki/JsonStore_Module) creates a dynamic variable 
storage to share between scripts. Since it's made for sharing, a script can 
request events when values are updated. The module adds, as one piece, 
functionality for extension and communication between scripts.

Does this attribute store enable such? Would a script want to know when one of 
the key/value pairs changed? Is polling suitable? Does the usage case just need 
static variable addition?

As to the practical, implementation angle, yes, you are correct that adding an 
OSD store on a scene object is simpler. This is an open source project, after 
all, so this is just my opinion.

-- ra

-Original Message-
From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Oren
Hurvitz
Sent: Friday, January 04, 2013 11:22 AM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] IRegisterInterface for extending scene
entities

The typing problem is already solved since the dynamic attributes are 
implemented using OSD.

Your proposal is much more complicated than the currently proposed
attributes, and I don't want to suppress a good solution in favor of a
perfect solution that might never be implemented (I assume you're too
busy with BulletSim to do this...) Furthermore, it would prevent a
very exciting
use-case: the ability to use dynamic attributes from a script, using OSSL.
(Well, unless you add a module for that specific purpose, but in that
case you just added a layer of indirection around the key-value
store.)

Oren



--
View this message in context:
http://opensim-dev.2196679.n2.nabble.com/IRegisterInterface-for-extend
ing-scene-entities-tp7578406p7578425.html
Sent from the opensim-dev mailing list archive

Re: [Opensim-dev] IRegisterInterface for extending scene entities

2013-01-18 Thread Justin Clark-Casey

My thinking here is to stop unrelated modules using short identifiers (e.g. a) and colliding with each other or having 
to use 'second choice' names.  Perhaps something like a UUID or a fragment of a UUID for reasonable uniqueness would be 
even better (if less readable).


Yes, I was thinking of enforcement down the line.

On 19/01/13 00:10, Dahlia Trimble wrote:

I'm not seeing the rationale for rule #1. Could you explain it a bit? Anyway, 
if there is a good technical reason for
it, perhaps OSDMap could be subclassed and code added to enforce the rule?

On Fri, Jan 18, 2013 at 3:46 PM, Justin Clark-Casey jjusti...@googlemail.com 
mailto:jjusti...@googlemail.com wrote:

Alright, I'm going to suggest

1.  That all attributes must be within their own OSDMap, which must be a 
minimum of 4 chars long (maybe this could
be relaxed for 'core' stuff).

2.  Within this map, attribute names and further OSDMap or other structures 
are entirely up to the caller.

3.  At the initial development stage, everything may change such that 
existing data may no longer be retrieved (e.g.
the way this is stored or the entire approach may change).  One must not 
rely on data being present.

4.  If at all possible, this must be backward and forward compatible with 
other versions of OpenSimulator no matter
whether it remains or is altered radically.  This should be fine since 
deserialization will ignore any top-level xml
nodes that it doesn't recognize.  But we must preserve a Postel's law - 
this was a painful lesson to learn.


On 18/01/13 22:09, Adams, Robert wrote:

I have a need to add more attributes to an SOP (use specified 
center-of-gravity, user specified mass, rolling
friction, ...) and the implementation of Justin's dynamic attributes is 
just what I need. It does not fulfill my
other wishes of adding functionality to SOPs, but it does allow the 
dynamic addition of new and serialized
objects attributes.

Can we Just Do It(r)(tm)(sm)? Some comments in the code suggesting a top 
level naming convention (prepend
attribute names with your module name or some such) and an admonition 
to not store large things might be
sufficient to control the use of a simple OSDMap.

What do you say? I am +1. How about everyone else? It is a start.

-- ra

-Original Message-
From: opensim-dev-bounces@lists.__berlios.de 
mailto:opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-bounces@__lists.berlios.de 
mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of
Justin Clark-Casey
Sent: Friday, January 04, 2013 5:18 PM
To: opensim-dev@lists.berlios.de mailto:opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] IRegisterInterface for extending scene 
entities

No problem in making this e-mails, Robert - I think this is exactly the 
kind of discussion that we need.  These
are the kind of decisions that we'll be stuck with for a long time so I 
think we need to think them through,
both through discussion and review or proof-of-concept code.

I hadn't really properly considered that the JSONStore is close to 
this.  I suppose one other significant
difference is that the current dynamic-attributes effectively stores 
data per part rather than through a single
datastore for the whole region.

But even if it does use the blackboard pattern, there still has to be 
an underlying persistence store, which in
this case would be a serialized JSON object that is functionally 
identical with the OSD Map (I've run out of
time today to see if the JSON store enforces type safety in some way).  
Really, the code could be very similar,
though in terms of formats I would prefer if to avoid further 
schizophrenia over data storage in OpenSimulator.
  If we stored as JSON, for instance, we end up transporting a JSON 
object in XML... :p

On 04/01/13 21:22, Adams, Robert wrote:

I think adding a module allowing scripts to attach dynamic 
variables to SOPs is the right level of
functionality. Just adding a key/value store is way too low a level.

For instance, the JSONStore module 
(http://opensimulator.org/__wiki/JsonStore_Module
http://opensimulator.org/wiki/JsonStore_Module) creates a dynamic 
variable storage to share between
scripts. Since it's made for sharing, a script can request events 
when values are updated. The module adds,
as one piece, functionality for extension and communication between 
scripts.

Does this attribute store enable such? Would a script want to know 
when one of the key/value pairs changed?
Is polling suitable? Does the usage case just need static variable 
addition?

As to the practical, implementation angle, yes, you are correct 
that adding

Re: [Opensim-dev] multiple robust instances

2013-01-14 Thread Justin Clark-Casey

 plugin OpenSim.Services.Interfaces.IAssetService from 
OpenSim.Services.AssetService.dll. Exception:
Object reference not set to an in
stance of an object

any idea about what it could be ?

if there are any errors on the wiki page, is it possible please to update 
it ?

__ __

___
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




--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Opensim-dev Digest, Vol 65, Issue 7

2013-01-09 Thread Justin Clark-Casey

That is impressive movement - there are pros and cons to different NPC approaches.  I would have thought the Linden 
server-side pathfinding (assuming that's what you're talking about) would not be too heavy on resources, though, 
especially compared to client-side NPCs.


On 09/01/13 17:56, Dave Gubser wrote:

Re: This may not be the place to post this, howevermay be of interest to
all that follow this thread.

Opensimulator / Second Life non-server based NPC? (Dahlia Trimble stated at
the bottom of her second video -  Here's a demo of an auto-navigating
(SERVER-SIDE) NPC character, which implies the npc is driven by a engine
attached to the server. (ie server side engine and needed access to the
server to impliment navigation.) On the other hand, the navigation system I
built does not require a plug in be installed on the server. It does all the
mapping and navigating by itself (think of an external browser with
capabilities to map and navigate any Opensimulator or Second Life simulator,
allowing the NPC(s) to perform tasks and requires less bandwidth and server
power than a normal Avatar.) Both approaches to NPC navigation have merit
and the work involved is non-trivial. Functional NPCs (not the server power
hogging mess Second Life came out with.) will give Opensim Content
capabilites whereby NPCs, going about their business, will enrich the user
experience. Picture transporting to a simulation of a 13th century village
and finding nobody there. Now picture the same village with NPCs filling
rolls until their human owners come in and take control of the NPCs body, ie
standard virtual world human interaction. Have to run... My 5 yr. old is
screaming for help she's busy flinging arrows at the NPC dragon
attacking her village!! :)

Dave Gubser

-Original Message-
From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of
opensim-dev-requ...@lists.berlios.de
Sent: Tuesday, January 08, 2013 11:17 PM
To: opensim-dev@lists.berlios.de
Subject: Opensim-dev Digest, Vol 65, Issue 7

Send Opensim-dev mailing list submissions to
opensim-dev@lists.berlios.de

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.berlios.de/mailman/listinfo/opensim-dev
or, via email, send a message with subject or body 'help' to
opensim-dev-requ...@lists.berlios.de

You can reach the person managing the list at
opensim-dev-ow...@lists.berlios.de

When replying, please edit your Subject line so it is more specific than
Re: Contents of Opensim-dev digest...


Today's Topics:

1. Re: 0.7.5 rc1, missing support for the DTL/NSL module
   (What Virtual World - Guy Quicksand)
2. Thread.Abort() considered harmful (Justin Clark-Casey)
3. Opensimulator / Second Life non-server based NPC navigation
   (Dave Gubser)
4. Re: Opensimulator / Second Life non-server based NPC
   navigation (Dahlia Trimble)


--

Message: 1
Date: Tue, 8 Jan 2013 23:29:55 +0100
From: What Virtual World - Guy Quicksand g...@whatvirtualworld.com
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] 0.7.5 rc1, missing support for the DTL/NSL
module
Message-ID: 3A9F5DC3D0AB482BABCC0EAA16B24E71@MARGRIET
Content-Type: text/plain; format=flowed; charset=iso-8859-1;
reply-type=response

Thanks Justin,

I found it was the search/profile module not any other as i had recompiled
dtl allready.
I still have to see if it works now, but i had no errors after removing the
search and profile dll's.
These 2 dll's where automaticly copied to the folder for setting up the
simulator allong with all proper ini files.
Still the dtl module is not working but we got a step forward, they probably
need the profile module to work properly.
Will do some more testing will let you know how it goes.

Thanks for everything.

Best regards,

Martin Forster

- Original Message -
From: Justin Clark-Casey jjusti...@googlemail.com
To: opensim-dev@lists.berlios.de
Sent: Tuesday, January 08, 2013 12:02 AM
Subject: Re: [Opensim-dev] 0.7.5 rc1, missing support for the DTL/NSL module



I suspect the compiled DTL/NSL module is looking for Mono.Addins v0.5
whereas recent changes now mean that Mono.Addins v0.6 is shipped.

If this is so, you really either need to recompile the DTL/NSL module (or
ask the authors to do so in preparation for the final release of 0.7.5),
or redirect the DTL/NSL assembly [1] to load the 0.6 module even though
it's looking for 0.5 (or ask the authors).  I can't say for sure if this
will work though there's a good chance.

[1] http://msdn.microsoft.com/en-us/library/twy1dw1e%28v=vs.90%29.aspx

On 07/01/13 01:31, James Hughes wrote:

Yes, please paste a full error output on pastebin.com and the link here.
Be sure no passwords or other sensitive
information is included.

Thanks!
BlueWall

On 01/06/2013 05:32 PM, What Virtual World - Guy Quicksand wrote

[Opensim-dev] Thread.Abort() considered harmful

2013-01-08 Thread Justin Clark-Casey

Over the past couple of months, I have been struggling with an issue where mono 2.10.8 would sometimes crash badly on a 
heavily loaded simulator (2000+ scripts).  Symptoms are 100% cpu use, simulator locking up with all threads waiting on a 
lock which no other thread holds or crashing with native stack trace


From analysis, this seems to be due to the use of Thread.Abort() to terminate script threads whose events do not 
complete within a short (or sometimes no) timeout.  This is used in llDie() and llResetOtherScript(), amongst other things.


The use of Thread.Abort() is considered harmful, leading to the kind of system instability described above [1] [2] [3], 
etc.  This affects scripts running in both separate AppDomains and the same AppDomain, since script functions constantly 
reach into core OpenSimulator code.


One could extend the timeout, but there is a tradeoff with timely script stopping.  Also, even a large timeout would not 
guarantee that threads would not be aborted.


Therefore, I will probably soon investigate a mechanism for stopping scripts without calling Thread.Abort().  This will 
probably involve the use of Thread.Interrupt() for Sleeps and the insertion of 'should I stop' flag checks in generated 
code where that code may be long running (e.g. control structures for, goto, etc. and user defined functions).  This is 
the normal approach one would take to co-operatively stop threads and avoid the chance of leaving Mono/.NET in a bad state.


The existing Thread.Abort mechanisms will remain default until this approach is shown not to have significant 
bugs/problems.  However, I think in the long term we have to stop using Thread.Abort() by default since it is not a safe 
thing to do.


Comments welcome.

[1] http://stackoverflow.com/questions/1051838/killing-a-thread-c
[2] http://msdn.microsoft.com/en-us/library/7a2f3ay4%28v=vs.80%29.aspx
[3] 
http://stackoverflow.com/questions/2251964/c-sharp-thread-termination-and-thread-abort

--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] 0.7.5 rc1, missing support for the DTL/NSL module

2013-01-07 Thread Justin Clark-Casey

I suspect the compiled DTL/NSL module is looking for Mono.Addins v0.5 whereas recent changes now mean that Mono.Addins 
v0.6 is shipped.


If this is so, you really either need to recompile the DTL/NSL module (or ask the authors to do so in preparation for 
the final release of 0.7.5), or redirect the DTL/NSL assembly [1] to load the 0.6 module even though it's looking for 
0.5 (or ask the authors).  I can't say for sure if this will work though there's a good chance.


[1] http://msdn.microsoft.com/en-us/library/twy1dw1e%28v=vs.90%29.aspx

On 07/01/13 01:31, James Hughes wrote:

Yes, please paste a full error output on pastebin.com and the link here. Be 
sure no passwords or other sensitive
information is included.

Thanks!
BlueWall

On 01/06/2013 05:32 PM, What Virtual World - Guy Quicksand wrote:

Hello James,

I have been searching for additinal dll''s in system paths, none found.
I am using the Mono.addons from the opensimulator, and no the module
does not come with its own version.
Personaly i dont think the module is failing as i get the same error on
a fresh ( without anny aditional modules ) opensim 0.7.5 rc1.
My effort you point out below was that i replaced the effected files
from git changes on this subject to see if i get it running.
I am probably over 30 hours now trying to solve this isue, that is why i
called out for help as i cant pinpoint this isue.
I even tried to use the .config files from 0.7.3 as they where
different.. also no solution.

Strange thing is that the older git 13c4fd7 is running fine.
I cant find any other mono.addin* files in any path that could be
accesed, i dont know if the mono.addins search locations by them selfs?
The robust is running just fine, only the simulator is giving this error.
( i asume this error couses all external modules to not load, as i dont
have this error on the win7 box and modules are working there just fine )

If you need a full error output, please let me know.

Best regards,
Martin forster


- Original Message - From: James Hughes
jam...@bluewallgroup.com
To: opensim-dev@lists.berlios.de
Sent: Sunday, January 06, 2013 8:57 PM
Subject: Re: [Opensim-dev] 0.7.5 rc1, missing support for the DTL/NSL
module



On 01/06/2013 09:15 AM, What Virtual World - Guy Quicksand wrote:

Hello all.. hope to post this to the right section.
I have been trying to update our beta simulators to 0.7.5 rc1.
It seems it has a problem at the mono.addins.
Error log(part):
log4net:ERROR DefaultRepositorySelector: Unhandled exception in
GetInfoForAssembly
System.IO.FileLoadException: Could not load file or assembly
'Mono.Addins, Versi
on=0.5.0.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756' or one of
its depe
ndencies. The located assembly's manifest definition does not match the
assembly
reference. (Exception from HRESULT: 0x80131040)
File name: 'Mono.Addins, Version=0.5.0.0, Culture=neutral,
PublicKeyToken=0738eb..


Can you see any other copies of Mono.Addins in the path on that
system, or does the module distribute it's own version of them?


I have done next:
replaced :
bin/Mono.Addins.CecilReflector.dll
bin/Mono.Addins.Setup.dll
bin/Mono.Addins.dll




Mono Addins have been updated to support some new capabilities on the
Robust server.

The distributed versions are what should work. Changing them might
cause further issues. First, let's see if there are additional copies
around. Also, if you remove that module, does it report the error?

Thanks
BlueWall
___
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)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] IRegisterInterface for extending scene entities

2013-01-04 Thread Justin Clark-Casey


On 04/01/13 05:48, Oren Hurvitz wrote:

For namespacing we can take a pointer from MIME types:
1. Keys used by core OpenSim will have no prefix, e.g. media or
prop.attr.


I'm not very comfortable with this, I think it would better if such attributes 
started with core. or even c.

I also think it would be better to enforce storage in a completely separate map rather than making this part of the key 
name. Perhaps that's too fussy.



2. Keys created outside core OpenSim will use the vnd. prefix, followed by
the name of the creating entity. For example: vnd.acme.myprop.


What would vnd stand for?  My preference would be not have this but just 
something like acme.myprop instead.



We should stick to storing the data in a single field. Database access is
much slower than in-memory string manipulation, so for any reasonable amount
of data it would be faster to read and write it as part of the existing
prims table rather than adding additional SQL operations on another table
(primattr?). And of course, a separate table would be much more
complicated to handle and I do like the simple life :)


It might be worth putting a limit on the amount of data stored, to stop any 
region module massively filling up the space.

--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] IRegisterInterface for extending scene entities

2013-01-04 Thread Justin Clark-Casey

No problem in making this e-mails, Robert - I think this is exactly the kind of discussion that we need.  These are the 
kind of decisions that we'll be stuck with for a long time so I think we need to think them through, both through 
discussion and review or proof-of-concept code.


I hadn't really properly considered that the JSONStore is close to this.  I suppose one other significant difference is 
that the current dynamic-attributes effectively stores data per part rather than through a single datastore for the 
whole region.


But even if it does use the blackboard pattern, there still has to be an underlying persistence store, which in this 
case would be a serialized JSON object that is functionally identical with the OSD Map (I've run out of time today to 
see if the JSON store enforces type safety in some way).  Really, the code could be very similar, though in terms of 
formats I would prefer if to avoid further schizophrenia over data storage in OpenSimulator.  If we stored as JSON, for 
instance, we end up transporting a JSON object in XML... :p


On 04/01/13 21:22, Adams, Robert wrote:

I think adding a module allowing scripts to attach dynamic variables to SOPs is 
the right level of functionality. Just adding a key/value store is way too low 
a level.

For instance, the JSONStore module 
(http://opensimulator.org/wiki/JsonStore_Module) creates a dynamic variable 
storage to share between scripts. Since it's made for sharing, a script can 
request events when values are updated. The module adds, as one piece, 
functionality for extension and communication between scripts.

Does this attribute store enable such? Would a script want to know when one of 
the key/value pairs changed? Is polling suitable? Does the usage case just need 
static variable addition?

As to the practical, implementation angle, yes, you are correct that adding an 
OSD store on a scene object is simpler. This is an open source project, after 
all, so this is just my opinion.

-- ra

-Original Message-
From: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Oren Hurvitz
Sent: Friday, January 04, 2013 11:22 AM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] IRegisterInterface for extending scene entities

The typing problem is already solved since the dynamic attributes are 
implemented using OSD.

Your proposal is much more complicated than the currently proposed attributes, 
and I don't want to suppress a good solution in favor of a perfect solution 
that might never be implemented (I assume you're too busy with BulletSim to do 
this...) Furthermore, it would prevent a very exciting
use-case: the ability to use dynamic attributes from a script, using OSSL.
(Well, unless you add a module for that specific purpose, but in that case you 
just added a layer of indirection around the key-value store.)

Oren



--
View this message in context: 
http://opensim-dev.2196679.n2.nabble.com/IRegisterInterface-for-extending-scene-entities-tp7578406p7578425.html
Sent from the opensim-dev mailing list archive at Nabble.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




--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] OpenSimulator branched in preparation for 0.7.5.RC1 (release candidate 1)

2013-01-02 Thread Justin Clark-Casey

This depends on the level of changes needed. If llSetKeyFramedMotion() is a self-contained implementation then possibly
it could be in 0.7.5. But if it requires other significant changes, which I believe is the case, then it will have to
wait for the next release.

Melanie, when do you think that you will get time to extract this code?

On 02/01/13 18:46, GarminKawaguichi wrote:

In late december, Melanie wrote:
llSetKeyfranedMotion can most likely not be implemented that way. We
know,*because we have implemented it*. Also, there is no need to
reinvent the wheel - llSetKeyframedMotion has been slated for core
release for a while now, we just haven't found the dev time to
extract it. So there is really no need for a second, competing
implementation.

If this llSetKeyframedMotionis now usable, it would be wise to add it to the
0.7.5 release candidate, because the module
SignpostMarv gave us in the Mantis 6112 is far from satisfactory despite all
efforts of SignpostMarv.

MML

31/12/2012 22:05, Justin Clark-Casey:

Hi folks. I have just created a new 0.7.5-post-fixes branch in preparation for
the first 0.7.5 release candidate.
This will be produced later on this week. I spoke about this on the IRC
channel before xmas but forgot to announce it
here. If this is a serious surprise then apologies.

*Core developers, for experimental functionality (e.g. Bullet), please feel
free to port changes from master if you
desire. * Otherwise, I would appreciate it if 0.7.5-post-fixes changes are
restricted to fixes for serious regressions
or low-risk fixes (very unlikely to create new bugs).

Depending on what happens in master, I may merge changes directly into
0.7.5-post-fixes for a time.

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

Re: [Opensim-dev] IRegisterInterface for extending scene entities

2013-01-02 Thread Justin Clark-Casey

Updating is probably quite trivial. Serialization is probably also reasonably
easy.

I think the bigger issue is whether this approach is reasonable, particularly in the light of going in an
entity-component direction. For instance, in the database, it stores all dynamic attributes in a single serialized
OSDMap in a DynAttrs column, in the same format as would be later put into the object serialization. This is nice and
simple but may have tradeoffs in terms of performance and ability to update directly via db manipulation.

I feel the tradeoffs are worthwhile but I think that everybody needs to look at this, which is one reason that I didn't
just push it in originally [1]. We could do this via a feature proposal [2]. In any case, it has to be discussed.

OARs use the XML2 format whereas everything else uses the 'XML' format. This is actually a very long-standing screw-up
due to a misunderstanding as to what XML2 meant - there is practically no difference between the two formats.

[1] http://lists.berlios.de/pipermail/opensim-dev/2010-August/009166.html
[2] http://opensimulator.org/wiki/Feature_Proposals

On 02/01/13 16:58, Oren Hurvitz wrote:

I just looked at the dynamic-attributes branch and it looks extremely useful!
I was just now considering ways to attach data to scene objects, and this
would fit the bill exactly. So I'd like to bring the dynamic attributes code
over to the master branch (updating it as needed), plus add serialization
into the XML, XML2 and OAR formats. Since it's been 2 years since that code
was written, are there any caveats I should be aware of before I begin?

Oren

--
View this message in context:
http://opensim-dev.2196679.n2.nabble.com/IRegisterInterface-for-extending-scene-entities-tp7578406p7578417.html
Sent from the opensim-dev mailing list archive at Nabble.com.
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

[Opensim-dev] OpenSimulator branched in preparation for 0.7.5.RC1 (release candidate 1)

2012-12-31 Thread Justin Clark-Casey

Hi folks.  I have just created a new 0.7.5-post-fixes branch in preparation for the first 0.7.5 release candidate.  This 
will be produced later on this week.  I spoke about this on the IRC channel before xmas but forgot to announce it here. 
 If this is a serious surprise then apologies.


Core developers, for experimental functionality (e.g. Bullet), please feel free to port changes from master if you 
desire.  Otherwise, I would appreciate it if 0.7.5-post-fixes changes are restricted to fixes for serious regressions or 
low-risk fixes (very unlikely to create new bugs).


Depending on what happens in master, I may merge changes directly into 
0.7.5-post-fixes for a time.

--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] IRegisterInterface for extending scene entities

2012-12-31 Thread Justin Clark-Casey

the physical mesh for this SOG) or just adding limpet like 
code to a scene entity.

Not sure of the nuances of serialization. I believe that the 
registered interfaces would just be
serialized with the SOG (thus saving and restoring the values 
in the registered interface instances) but
I can't be totally sure of that.

Anyway, run your sword through this strawman.

-- ra

[1] This is similar to other interfaced proposed in the past 
(particularly one by Adam Frizby).




_
Opensim-dev mailing list
Opensim-dev@lists.berlios.de 
mailto:Opensim-dev@lists.berlios.de
https://lists.berlios.de/__mailman/listinfo/opensim-dev
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 
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 
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 
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 
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 
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)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] OpenSim's direction after Linden cutting support, and the possibility of an official OpenSim viewer

2012-12-13 Thread Justin Clark-Casey

 
opinion is that it's time OpenSim does
something similar.

If it was me, I'd say grab the latest SL viewer without the restrictive Havoc 
library and make OpenSim viewer from that.
If Linden adds a nice feature to theirs which we can copy over, sure thing, but 
otherwise it can go its own separate
way. On the other hand, it would be a good aim to allow previous SL viewers to 
still connect to OpenSim, though they
wouldn't recognize some of its specific features then. I know OS and SL and 
under two different licenses, but that
doesn't make it wrong to distribute both on the same website and as part of the 
same project.

What does the core team of OpenSim think about this? Are there any plans or 
will to go in this direction? Or does anyone
believe that instead we should continue providing support for SL's features and 
have OpenSim users find their own
clients like until now? I believe this is an important question, and would like 
to know what to expect in the future.
Personally I really hope something in this direction will be decided, but I'm 
not one to know best.


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




--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] (CreateUser) Http Post

2012-12-07 Thread Justin Clark-Casey

It looks like you're trying to use the RemoteAdmin XMLRPC createuser command.  This only works in standalone mode and 
I'm not 100% sure it's currently working anyway.


However, it so happens that in grid mode an equivalent command is available on the UserAccount ROBUST service which 
requires slightly different calling parameters and a config setting [1].


[1] http://opensimulator.org/wiki/UserAccountService#createuser

On 07/12/12 05:04, Diva Canto wrote:

And the password is not stored on the same table...

If you want to find out more about how to talk to the robust services, take a 
look at OpenSim.Services.Connectors. If
you're using .NET you should be able to just reference that dll and use the 
connector objects that already exist.

On 12/6/2012 8:40 PM, Kukuk Jacob wrote:

Hello everyone, so we are getting a grid setup and we are running into a slight 
problem with registration of users. We
created a ASP.net HTTP XMLRPC POST that uses the method createuser but for some 
odd reason it returns Requested method
[createuser] not found. We are running as a grid and using robust. Here is what 
we are working with.

protected void join_btn_Click(object sender, EventArgs e)
 {
 CreateUser(new Uri(http://localhost:8003/;), null, first_txt.Text, 
last_txt.Text, pass_txt.Text,
email_txt.Text, 1000, 1000);
 }

 public void CreateUser(Uri url, string adminPassword, string firstName, 
string lastName, string password, string
email, int regionX, int regionY)
 {
 var address = Dns.GetHostEntry(url.DnsSafeHost).AddressList[0];
 var ht = new Hashtable();
 ht[user_firstname] = firstName;
 ht[user_lastname] = lastName;
 ht[user_password] = password;
 ht[PrincipalID] = 3a1c8128-908f-4455-8157-66c96a46f75e;
 var parameters = new ListHashtable { ht };
 var rpc = new XmlRpcRequest(createuser, parameters);
 rpc.Invoke(url.ToString());
 }
___
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)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Update for group module flotsam

2012-11-22 Thread Justin Clark-Casey

In principle you could.  However, I vaguely remember reading in the code that the Online/Login/Logout information was 
deprecated, though I can't remember why and I can't immediately find the reference.


On 21/11/12 20:08, Michelle Argus wrote:

Instead of checking with the presence service we could also use the user 
service via getgriduserinfos. This returns
both  Online and Last login data that we could use...

Am 29.10.2012 07:26, schrieb Kevin Cozens:

On 12-10-28 06:54 PM, Melanie wrote:

The presence service already has a call to fetch the online status
for a list of users rather then for just one user, AFAIR. At least I
remember putting such a call into the design.


I just took a look at the code and you are correct. In the file
Services/Connectors/Presence/PresenceServicesConnector.cs there is a function 
GetAgent() which takes a string[] of
UUID's and returns an array of type PresenceInfo.



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




--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Update for group module flotsam

2012-11-22 Thread Justin Clark-Casey

Okay, so it sounds like either threads are being exhausted or the sheer cost of messaging a lot of people it eating up
CPU. It would be really nice to know which via some external monitoring package. You might also want to try bumping up
MONO_THREADS_PER_CPU just to see what happens if you haven't already.

If it's threads, then perhaps one could only spawn N message threads to work until done. But naturally this would slow
down message sending and isn't a solution anyway if CPU load is the problem.

So perhaps the best thing would be to experiment with fanning out messages via an external service [1].
GroupsMessagingModule.SendMessageToGroup() could be patched with an experimental setting to send the message request
through a new method on IGroupsServicesConnector (e.g. IGroupsServicesConnector.SendMessageToGroup()) rather than purely
via the simulator.

XmlRpcGroupsServiceConnectorModule could then implement this message as another XmlRpcCall (with just a stub out in
SimianGroupsServiceConnectorModule for now).

Extension to the existing PHP groups code could then distribute the messages. The service should remain stateless so
it's easy to spin up additional instances if load balancing is needed (one would really need some way to monitor load).

I, for one, would welcome any patches to allow this experimentation. Unfortunately, this isn't an issue in my current
work so I can't spend much time on it myself presently.

[1]
http://opensimulator.org/wiki/Feature_Proposals/Improve_Groups_Service#D.29_Groups_service_distributes_IM

On 18/11/12 18:50, Michelle Argus wrote:

Darn, why did your responce land in my junkmails...^^

The exact same behaviour can be seen in the original and new solution. In the
original solution the time period is just
much longer during which the lag is noticable. The viewer lags the moment the
IM is sent by the viewer and stops once
all IMs have been sent out by the simulator, the issue already starts prior to
the simulator actualy sending the IMs.

During this time the sim console responce is also slowed down when typing a new
command.

I could imagine that it is thread related. In that case tests within the same
datacenter or near by would most
probably not cause much noticable issues. In my Case the distance EU/USA could
increase the lag situation I experiance
in a similar way all other requests were we have increasing issues with slow
requests.

Short sidenote on the slow request. The sims are hosted in one of the top 5
datacenters in germany that we had tested
with with very good ping times to the osgrid servers, so slow requests are
unlikely to be caused by slow network on the
simulator side.

Am 10.11.2012 04:44, schrieb Justin Clark-Casey:

What is the nature of the lag in this case? Is is some freezing of the scene
(if inbound packets stop being
processed) or something else? On a naive reading of the code, scene freezing
should not happen since the IM packet is
handled on its own thread and not the inbound packet loop thread, though I
guess it's possible that for big groups,
sending a lot of messages may tie up all the available threads (not something I
have experienced or tested).

Do you see the same thing with the original solution of caching presence
information directly in the groups service?
I would have thought so since the sending step in that case is still performed
by the simulator.

On 08/11/12 22:28, Michelle Argus wrote:

NP Justin.

I tested the new MessageOnlineUsersOnly and it is a big improvment eventhough
some lag still was noticable. The lag is
noticable from the moment the IM is beeing sent from the viewer untill all IMs
were sent to the online group members.
With the new option we have 3 lag creating steps:
- Query the groupmembers from the group server ( time is not logged)
- Query the presence server for online members (time is not logged)
- Sending the IMs (ranged between 59 - 3200 ms for constant 13 online members
of 560 total)
Same test with false took about 20 seconds to send all IMs

As my server is in europe, the 2 queries to the OSGrid group server AND the
presence server can both be slow at times.
This could be improved if the group service queries the presence server (as in
most cases both will be within the same
network) instead of the simulator sending both queries. So instead of the
currently implemented proposal B, the
proposal C would be better for simulators further away or those with slow
internet connection.

In addition, proposal C does not require each groupmember to be checked for
online status if the group server uses a
presence cache. Example, if 2 people are sending IMs to diffrent groups with
common members, then 1 presence check would
be enough for the common members, the lists of agents sent to the presence
service would thus also be reduced. As in a
bigger grids many IMs are beeing sent gridwide, the presence querries should
be even more efficiant in C compared to B

Re: [Opensim-dev] phantom avatar

2012-11-21 Thread Justin Clark-Casey


You can do this by setting

[Startup]
collidable_prim = false

in OpenSim.ini.

On 21/11/12 18:08, CJ Davies wrote:

I'm modifying a client so that avatar movement can be controlled from real 
world GPS readings. The idea is that you can
explore a real world location whilst your avatar mimics your position in a sim. 
Think walking around the ruins of an old
building whilst your avatar walks around a sim-based reconstruction

The modifications pretty much work, but one major issue is that there will 
frequently be obstructions in the sim that
don't exist in the real world - like walls that have fallen down. Thus I want 
to make the avatar phantom so that it can
simply pass through things.

Is there any way of doing this without having to make every single prim in the sim 
phantom? There are thousands 
thousands of prims so this would take a long time, if there isn't some way to 
automate it.

Ideally I'd like it to be on a per-avatar basis, but getting it to work for all 
avatars would be a sufficient first step.

The modified viewer as it stands atm is here, in case anybody is interested in 
the dirty hacks.

https://bitbucket.org/cj_davies/viewer-release-serial-io

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




--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Webrequest to presence service or other robust services.

2012-11-19 Thread Justin Clark-Casey

I'm assuming you mean getagents, which takes user IDs. There is a separate getagent call which confusingly requires a
session ID instead, which I imagine is less useful for your purposes.

I quickly documented the getagents call at [1]. As with pretty much all such calls, they were originally 'designed' for
a particular simulator need and so can be inconsistent and a bit funky to call. However, they have the advantage of
being pretty much guaranteed to work, since a bug here is also likely a bug for the simulators.

There is also a generic services page at [2] with links to information on call methods on some other services. The
pages available at [2] also have some PHP/Python examples.

[1] http://opensimulator.org/wiki/PresenceService
[2] http://opensimulator.org/wiki/Services

On 18/11/12 19:01, Michelle Argus wrote:

I would like to do a getagent request to the presence service (or later to
other services) via a webapplication
using php. Has anyone got a working example in php?

I have tryed some scripts without any success. I have tryed using xmlrpc
similar to the test example in the groups
module (
https://github.com/mcortez/flotsam/tree/master/flotsam/Servers/XmlRpcGroupsServer/
) and I also tryed using the
php example used by RemoteAdmin. Any ideas?
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Update for group module flotsam

2012-11-09 Thread Justin Clark-Casey

What is the nature of the lag in this case? Is is some freezing of the scene (if inbound packets stop being processed)
or something else? On a naive reading of the code, scene freezing should not happen since the IM packet is handled on
its own thread and not the inbound packet loop thread, though I guess it's possible that for big groups, sending a lot
of messages may tie up all the available threads (not something I have experienced or tested).

Do you see the same thing with the original solution of caching presence information directly in the groups service? I
would have thought so since the sending step in that case is still performed by the simulator.

On 08/11/12 22:28, Michelle Argus wrote:

NP Justin.

Yes, E is a hybrid of B/C and D. It could use the exact same online presence
method as in B/C to get the list of online
members. The group service would thus not realy need any changes. This also
means, that a 3rd party dev could develope
the IM relay service which would then not need to be part of the core itself.
The only change required would be
simulator side, but even this would be a minor change. One would need to
implement a url/enable ini setting, and
depending on the setting the IM is sent simulator side or passed on to the IM
relay service. Its a small change
simulator side which should not be a problem for implementation in core.

As the IM relay server is an option, everyone can deside themselves if they
trust the hoster of the IM relay service or
if they want to have their own simulator send all IMs. Talking for the german
cummunity in OSGrid, I know that we
definatly will use a IM relay to improve the IM situation for the simulator
side nomatter if A, B or C get implemented,
especialy on our event regions.

My personal favorit would be E, were C is the core group service and the
optional IM+group notice Service can be run
by closed grid admins or 3rd party in open grids to improve worldwide groupchat
and notice sending usage.

Am 08.11.2012 04:39, schrieb Justin Clark-Casey:

Hi Michelle. Sorry that it's taken quite a long time for me to reply to this -
unfortunately been hit by other work
and divers alarums.

I somewhat edited [1] again, mainly for sense changes though I also left a few
comments in italics. To try and make
things clearer, I gave the alternatives names (e.g. alternative E I've called
Separate group IM relay service.
Please change if these are not accurate.

It would seem that E is mostly a hybrid solution of B (simulator queries
presence service on IM) and D (Groups service
distributes IM)? I would regard this as over-complicated for a core
OpenSimulator solution, especially when one
starts talking about trusted relay services.

I'm curious if you have tried the experimental MessageOnlineUsersOnly = true
setting I added a couple of weeks ago.

[1] http://opensimulator.org/wiki/Feature_Proposals/Improve_Groups_Service

On 29/10/12 00:13, Michelle Argus wrote:

I have updated the proposal page and listed the diffrent alternative from A
onwards sothat its easier for us.

My current favorite is the alternative E: The group server requests the online
status from the grid server itself and
caches this data instead of the grid server keeping the group server updated.

- Simulators request their data directly from the group server and sends IMs
itself OR
- Optionaly the Simulator communicates via a relay service with its own cache.
The relay service

Re: [Opensim-dev] Robust dynamic connector plugins...

2012-11-09 Thread Justin Clark-Casey

Hi James. Sorry it's taken so long for me to reply, various work pressures and
other stuff.

Yeah, personally I'm happy going with Mono.Addins. As you say, we're already using it and going with the MEF would mean
rolling a repository system. Also, I see some talk that Mono.Addins could just use the MEF as it's underlying basis in
the future anyway.

Now some other points.

* IRobustConnector appears to assume that all ROBUST plugins implement HTTP handlers. However, some plugins may just
provide extra debug console commands (some such region plugins exist already) or extend other plugins (and thus don't
implement their own handlers). How would these work? This would also be a problem with IRobustConnector.Configure()
passing back a number for the listening port.

* Why provide the option to pull down a bootstrap.ini? This seems overcomplicated to me but perhaps an example would
make it clearer. And writing this data to an existing ini file makes me a bit nervous, esp. on windows since, for
instance, the write could fail if the user also has the file open.

* I think IRobustConnector would be better named IRobustServerInConnector or similar to match XInventoryInConnector,
GridInfoServerInConnector, etc. in OpenSim.Server.Handlers. I like the *InConnnector because this better distinguishes
the inbound ROBUST handlers from the simulator outbound requests (which are also called connectors and are, as we know,
in OpenSim.Service.Connectors.

In fact, I would personally prefer to see the *InConnectors called something different to make the difference with the
outbound connectors much clearer in the code. However, nothing springs to mind - perhaps InConnector is good enough.

Of course, this isn't helped by the inconsistency in OpenSim.Server.Handlers naming (where most are just named
ServerConnector). Or the fact that these extend ServiceConnector (which implements IServiceConnector) but yet are in a
file named ServerConnector.cs.

* From your previous e-mail, I think it would be better to start off with the specific interface for dynamic plugins and
then look at modifying IServiceConnector once the code is in core and the implications are understood.

* I certainly think it would be good to extend such a system to region modules. But I think there are various issues
there which I'd prefer to discuss at a later point rather than extend this e-mail.

I also took the liberty of updating
http://opensimulator.org/wiki/Feature_Proposals/PluginManager with
instructions, etc.

Best,

Justin

On 27/10/12 04:11, James Hughes wrote:

Fortis used it and it didn't seem a lot different than the way we have been
using mono-addins in OpenSim.exe to this
point. MEF uses attributes to define, as does most of addins. Some things in
mono-addins still need to be defined in the
xml manafest files, but most things can be done by attributes. MEF supports
management of local assemblies and it
doesn't provide tools for repositories and assemblies like mono-addins. Using
MEF would require the additional
development of those tools. So, the feature set of mono-addins is more complete
for this type of work. We already use
mono-addins extensively in the region server and it has served us well. It
seems that some miss-steps were made in the
implementation and need some refactoring (possibly newer versions have resolved
issues that caused us to have these
workarounds?). But, all in all we have had good results and have a great deal
of the work toward managing remote
repositories and plugins in the region server done as well. Even if we were
just dealing with local assemblies I would
see no real technical advantage to using MEF over mono-addins.

The mono-addins project is part of the mono git-hub code and has been headed up
by Llouis Sanchez, one of the lead Mono
developers with Xamarin. And it is used in Monodevelop that is the IDE of their
commercial products. So, its heritage is
OK and it is actively developed.

Thanks
BlueWall

On 10/26/2012 07:32 PM, Justin Clark-Casey wrote:

My first question is, what do you think of the alternatives to
Mono.Addins, chiefly MEF (Managed Extensibility Framework)? How do they
compare?

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

Re: [Opensim-dev] PhysicalPrimMax numbers for BulletSim

2012-11-08 Thread Justin Clark-Casey


Very nice.  And various helpful bug reports I see - ra is going to be busy :)

On 08/11/12 20:41, Teravus Ovares wrote:

Not sure if you saw, however this is some good stuff.
http://opensimulator.org/mantis/view.php?id=6409
:)
Regards
Teravus

On Wed, Nov 7, 2012 at 4:35 PM, Adams, Robert robert.ad...@intel.com 
mailto:robert.ad...@intel.com wrote:

There has been an ongoing discussion on physical prim maximum size. Lani 
Global did some testing and published a
graph of her results at 
http://opensimulator.org/wiki/User:LaniGlobal#PhysicalPrimMax_Size_Testing . 
Her testing
showed that, for ODE, a max size of 32m resulted in a livable frame rate 
degradation.

__ __

I performed the same tests with BulletSim and discovered that a single 
sphere (native physical shape) or a single
torus (mesh/hull shape) did not reduce simulator frame rate no matter the 
size of the object.

__ __

So, I created a single, standalone region with lumpy terrain and dropped 
different quantities of large shapes. The
resulting frame rates were:

__ __

  NumberNumber

SPHERE1   4   8  16  32TORUS[2] 1   4   8  32  64

+ +

 10 | 55  55  55  55  55   10 | 55  55  55  55  55

S  20 | 55  55  55  55  55 S 20 | 55  55  55  26  13

i  32 | 55  55  55  55  55 i 32 | 55  55  40  16

z  64 | 55  55  55  49  49 z 64 | 55  50  20

e  100| 55  54  49  47  [1]e 100| 40  15

__ __

   [1] My setup wasn’t large enough to hold 32 100m spheres.

   [2] The torus height is about one third of the width because I preferred 
the doughnut shape.

__ __

A few pictures of the experiments (one region with walls):

https://dl.dropbox.com/u/86260377/20121107_009.png 

https://dl.dropbox.com/u/86260377/20121107_012.png 

https://dl.dropbox.com/u/86260377/20121107_017.png 

https://dl.dropbox.com/u/86260377/20121107_019.png 

https://dl.dropbox.com/u/86260377/20121107_022.png 

https://dl.dropbox.com/u/86260377/20121107_026.png 

__ __

It looks like, for BulletSim, a physical object max size of 32m is 
acceptable and 64m would probably be OK. 

The physics frame rate is a function of the number and size of large, 
physical prims.  The above numbers are for
multiple of the same object. The next tests should be on large sized 
linksets (for instance, two 5m cubes that are
32m apart and linked and physical).

__ __

-- ra

__ __


___
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




--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Update for group module flotsam

2012-11-07 Thread Justin Clark-Casey

Hi Michelle. Sorry that it's taken quite a long time for me to reply to this - unfortunately been hit by other work and
divers alarums.

I somewhat edited [1] again, mainly for sense changes though I also left a few comments in italics. To try and make
things clearer, I gave the alternatives names (e.g. alternative E I've called Separate group IM relay service. Please
change if these are not accurate.

It would seem that E is mostly a hybrid solution of B (simulator queries presence service on IM) and D (Groups service
distributes IM)? I would regard this as over-complicated for a core OpenSimulator solution, especially when one starts
talking about trusted relay services.

I'm curious if you have tried the experimental MessageOnlineUsersOnly = true
setting I added a couple of weeks ago.

[1] http://opensimulator.org/wiki/Feature_Proposals/Improve_Groups_Service

On 29/10/12 00:13, Michelle Argus wrote:

I have updated the proposal page and listed the diffrent alternative from A
onwards sothat its easier for us.

My current favorite is the alternative E: The group server requests the online
status from the grid server itself and
caches this data instead of the grid server keeping the group server updated.

- Simulators request their data directly from the group server and sends IMs
itself OR
- Optionaly the Simulator communicates via a relay service with its own cache.
The relay service requests its data from
the same central group server. The relay service can additionaly send IMs if
wanted to reduce resource usage simulator
side. The relay service can be hosted by anyone for a worldwide network.

The same concept could be used for other services such as assets, presence,
inventory, friendslist etc which are
meanwhile causing many issues due to slow requests in bigger grids such as
OSGrid.

Am 23.10.2012 04:40, schrieb Justin Clark-Casey:

Apologies, it's [1]. Please feel free to edit it as you see fit - I've put
you as one of the proposers. This page
is to keep track of the issue rather than a formal proposal mechanism.

No rush on this - please feel free to take your time in responding. In truth, I
only have a certain amount of time for
these issues currently myself.

Having messages route through a service rather than be largely handled by
simulators themselves is an interesting
approach. It's the argument of a distributed versus a more centralized
architecture. Although I can't see
OpenSimulator going down this route in the near future, if anybody wants to
experiment and needs additional config
settings then patches are very welcome.

[1] http://opensimulator.org/wiki/Feature_Proposals/Improve_Groups_Service

On 20/10/12 11:06, Michelle Argus wrote:

Justin, could you post the url to the suggestion page, I think you forgot to
add it ;)

One issue that having the sim updating online status is, that if someone has
the group module diabled or uses a
diffrent setting then the status is not updated. As other modules hosted by the
grids also might this information, one
should consider adding something to the gridserver for this.

I also like the idea from Akira to have the groupserver to receive the full IM
and then sending it to everyone instead
of having the sim send the message. One then could have a specialized server
installed for the group module which cannot
create any lagissues simside. This could then also be used for a gridwide
spamfilter or filtering illigal activities
within the grid.

Havnt had much time though as I have a longer event running which ends on
sunday...

Am 20.10.2012 04:32, schrieb Justin Clark-Casey:

Regarding the groups work, I have now implemented an OpenSimulator experimental
option, MessageOnlineUsersOnly in
[Groups] as of git master 1937e5f. When set to true this will only send group
IMs to online users. This does not
require a groups service update. I believe OSGrid is going to test this more
extensively soon though it appears to
work fine on Wright Plaza.

It's temporarily a little spammy on the console right now (what isn't!) with a
debug message that says how many online
users it is sending to and how long a send takes.

Unlike Michelle's solution, this works by querying the Presence service for
online users, though it also caches this
data to avoid hitting the presence service too hard.

Even though I implemented this, I'm not convinced that it's the best way to go
- I think Michelle's approach of
sending login/logoff status directly from simulator to groups service could
still be better. My chief concern with
the groups approach is the potential inconsistency between online status stored
there and in the Presence service.
However, this could be a non-issue. Need to give it more thought.

On 14/10/12 22:53, Akira Sonoda wrote:

IMHO finding out which group members are online and sending group IM/Notice
etc. to them actually should not be
done by
the region server from which the group IM/notice etc. is sent

Re: [Opensim-dev] Update for group module flotsam

2012-11-07 Thread Justin Clark-Casey


On 29/10/12 06:26, Kevin Cozens wrote:

On 12-10-28 06:54 PM, Melanie wrote:

The presence service already has a call to fetch the online status
for a list of users rather then for just one user, AFAIR. At least I
remember putting such a call into the design.


I just took a look at the code and you are correct. In the file
Services/Connectors/Presence/PresenceServicesConnector.cs there is a function 
GetAgent() which takes a string[] of
UUID's and returns an array of type PresenceInfo.



Yes, when I implemented the MessageOnlineUsersOnly setting I realized that this existed and used it to fetch all 
presence information in one network call rather than one network call for each presence.


--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Collisions and Sensors.

2012-11-01 Thread Justin Clark-Casey


On 01/11/12 21:05, R.Gunther wrote:

Are the Collisions and Sensors running now in own thread ?


No.


It seems to work fine. until i use it on 2 ODE verhicles (bullet still fail 
here)

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




--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Robust dynamic connector plugins...

2012-10-26 Thread Justin Clark-Casey

 region modules too in
our next release.

Thanks!
-BlueWall



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




--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

1 2 3 4 5 6 >

1 - 100 of 587 matches

Mail list logo