Re: [Opensim-dev] [kyoryoku] Announce: realXtend Naali 0.1 (alpha) client viewer

[Tommi Laukkanen]

Nice work rex team :). Congratulations are in order!

-tommi

On Tue, Feb 9, 2010 at 12:02 PM, Ryan McDougall  wrote:

> realXtend is proud to announce the first major alpha release of its
> groundbreaking multi-use virtual world client viewer, Naali. We are
> hoping this release will see widespread user testing, to help us
> refine and improve our work. Naali is alpha software and missing many
> features, but we hope, with your feedback, to make Naali the "Firefox"
> of virtual worlds.
>
> Demo video can be found here: http://www.youtube.com/watch?v=4iiE66hY-RU
>
> Both source code and binaries can be found on our project website:
> http://code.google.com/p/realxtend-naali/
>
> Naali is released under the Apache 2.0 software license, and available
> for the following platforms:
>
> * Windows: Binary installer
> * Linux: Full source and build instructions
> * Mac: In progress
>
> Naali is implemented in C++ (using Qt and Ogre3D) and Python. Bindings
> for JavaScript are also planned. It is designed using a modular and
> scalable architecture, with easy repurposing for a wide variety of
> applications by simply dropping in new components.
>
> Naali is intended to work with any virtual world protocol through its
> modular architecture, however currently only support for SLUDP-based
> protocols through OpenSim are implemented.
>
> Naali comes with a reference server implementation called Taiga,
> which adds mesh-based assets, Python server-side scripting, web login
> with OpenID, and inventory over WebDAV.
>
> Naali is it true open-source project, which means the community has a
> voice in guiding the direction of the project, and commit access is
> available to contributors with a proven track record of quality
> patches.
>
> Please join us on our mailing lists:
> http://groups.google.com/group/realxtend
> http://groups.google.com/group/realxtend-dev
>
> Or on IRC, on Freenode
> #realxtend
> #realxtend-dev
>
> More information can be found on our website:
> http://wiki.realxtend.org/index.php/Main_Page
>
> Ryan McDougall
> http://www.realxtend.org
>
> --
> http://groups.google.com/group/kyoryoku
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

[Opensim-dev] getting spam from forge

[Tommi Laukkanen]

Hi

I am getting this kind of spam. I do not have the password for the
project commits list so I can not do anything about it:

opensimoperator-commits-boun...@forge.opensimulator.org to opensimoperato.
show details 6:00 PM (1 hour ago)
The opensimoperator-comm...@forge.opensimulator.org mailing list has 3
request(s) waiting for your consideration at:

   http://forge.opensimulator.org/mailman/admindb/opensimoperator-commits


Please attend to this at your earliest convenience.  This notice of
pending requests, if any, will be sent out daily.


Pending posts:
From: opensimoperator-comm...@forge.opensimulator.org on Thu Jul 30
00:22:50 2009
Subject: Dear opensimoperator-comm...@forge.opensimulator.org 74% 0FF
on Pfizer !
Cause: Post by non-member to a members-only list

From: opensimoperator-comm...@forge.opensimulator.org on Tue Aug  4
04:37:26 2009
Subject: Dear opensimoperator-comm...@forge.opensimulator.org 74% 0FF
on Pfizer !
Cause: Post by non-member to a members-only list

From: opensimoperator-comm...@forge.opensimulator.org on Sun Aug  9
04:18:29 2009
Subject: Dear opensimoperator-comm...@forge.opensimulator.org 71% 0FF
on Pfizer !

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

Re: [Opensim-dev] Main Repository now in Git

[Tommi Laukkanen]

Thats really nice improvement I think.

-tommi

On Thu, Aug 6, 2009 at 6:01 PM, Sean Dague wrote:
> Tommi Laukkanen wrote:
>> Out of curiosity: does commit I make register under my name in
>> repository now that git is used? In other words can non core member
>> claim their commits in ohloh.net now?
>>
>> -tommi
>
> If you make your commits in a git tree, and it is pulled in by a core
> member that way (vs. exported patch + apply), then yes.
>
>        -Sean
>
> --
> __
>
> Sean Dague                                       Mid-Hudson Valley
> sda...@gmail.com                                 Linux Users Group
> http://dague.net                                 http://mhvlug.org
>
> There is no silver bullet.  Plus, werewolves make better neighbors
> than zombies, and they tend to keep the vampire population down.
> __
>
>
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Main Repository now in Git

[Tommi Laukkanen]

Out of curiosity: does commit I make register under my name in
repository now that git is used? In other words can non core member
claim their commits in ohloh.net now?

-tommi

On Thu, Aug 6, 2009 at 2:42 PM, Sean Dague wrote:
> Ursula MATOVA wrote:
>> Sure you're right ... let's go to "git" then :)
>>
>> But, is it possible to change the "OpenSim Commits" posts ?
>> Really, it's un-useful and unreadable ...
>
> Yes, I'm working at changing that to something more readable, we'll need
> a few more commits going through before I figure out if I've fixed that.
>
> Also, there is an rss feed off of http://opensimulator.org/viewgit.
> I've found that to be a very useful way to keep up on things as well.
>
>        -Sean
>
> --
> __
>
> Sean Dague                                       Mid-Hudson Valley
> sda...@gmail.com                                 Linux Users Group
> http://dague.net                                 http://mhvlug.org
>
> There is no silver bullet.  Plus, werewolves make better neighbors
> than zombies, and they tend to keep the vampire population down.
> __
>
>
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] voice meetings

[Tommi Laukkanen]

Voice meetings are especially useful for getting to know people and
building trust relationship.

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

[Opensim-dev] Collada as Model Format

[Tommi Laukkanen]

Hello

As custom viewers start to emerge I would like to point to Collada
specification as one format which could
be used to support freestyle models (meshes):

This document describes the COLLADA schema. COLLADA is a COLLAborative
Design Activity that
defines an XML-based schema to enable 3-D authoring applications to
freely exchange digital assets
without loss of information, enabling multiple software packages to be
combined into extremely powerful
tool chains.

The specification:

http://www.khronos.org/files/collada_spec_1_4.pdf

The schema:

http://www.khronos.org/files/collada_schema_1_4

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

Re: [Opensim-dev] source code doc

[Tommi Laukkanen]

Hello

As far as I am concerned all documentation is much welcome and core
team can probably review the comments for validity on submit.

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

Re: [Opensim-dev] Axis aligned bounding box search data structure

[Tommi Laukkanen]

To be more exact does anyone know open source implementation for C# octree?

-tommi

On Fri, May 1, 2009 at 10:15 AM, Tommi Laukkanen
 wrote:
> Hello
>
> Does anyone have existing bounding box collection class which supports
> efficient volume searches? I guess the way to go is octal tree
> approach but I would rather not implement one from scratch.
>
> -tommi
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

[Opensim-dev] Axis aligned bounding box search data structure

[Tommi Laukkanen]

Hello

Does anyone have existing bounding box collection class which supports
efficient volume searches? I guess the way to go is octal tree
approach but I would rather not implement one from scratch.

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

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

[Tommi Laukkanen]

If we do not consider SL restrictions for a second and look to the
future it would be nice to discuss the following which popped out from
dahlias idea of supporting loading textures from websites directly and
Stefans suggestion of using strings as ids in the standard format
thread:

It is good to consider supporting identification of assets by
traditional urls. Some public asset servers could be www servers or
svn http servers. As all 3d modeling programs are refering to
aggregate assets using file paths, it would be easy to upload the
model to SVN http server and then using viewer pull out the model and
aggregate assets for viewing. This could be alternative asset
distribution model. it could work through region asset cache or
directly from viewer to the http server. This could be much more
scalable than the current model. I realize this is a threat to the
data consistency as models and aggregate assets are not saved to
relational database which could safeguard relations. It is also viable
only for completely public content but I assume considerable portion
of the vw content is likely to be freely distributable.

This would be in practice support for "importing" content from web on the fly.

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

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

[Tommi Laukkanen]

Well said Michael and I have come to similar conclusions when working
with OpenSim code. There is no need to have separate code for grid and
standalone. You can run the systems using separate executables like
standalone and distributed services and still keep the code base same.
Separate executables are just a question how you deploy and fire up
your system.

I might go even further and make decoupled services discuss over
network even if they are hosted in the same sandbox process. It is not
perfect for sandbox performance but then you would be running the same
code in local testing setup and in production grid. I would say this
is a big quality boost. It would also make everyone more concentrated
on the remote API performance as those APIs would then be used in
sandbox mode as well which is the environment mostly used on
development time testing.

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

Re: [Opensim-dev] OAuth as authentication and authorisation (capability) specification

[Tommi Laukkanen]

I think what Christian proposes is a win win for opensim and existing
social networks. We can easily expand to their entire user base while
the social networks can offer OpenSim as extension to their services.
Making that one extra account can be a deal breaker for many normal
users. One click and SSO from their favorite network is preferable :).

We should note that use profile is not same thing as user identity.
While user identity (id, name, nickname...) can become from for
example existing social network site opensim profile can still be
stored in opensim service. Federated identity is about collecting all
these different bits and pieces from social networks, other sites and
opensim to one unified profile. In practice all applications will have
some legacy profile pieces while some parts of the data will hopefully
be exposed through standard profile services.

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

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

[Tommi Laukkanen]

Hello

This is good initiative. Less code is less bugs. Diva could you tie
hypergrid approach on the public design documents as well. In other
words mark on design which of those services are truly distributed and
can be from different grids based on the users logged in via.
hypergrid and maybe even objects placed by users from different grids.
One of the goals is that on the long run the grid concept becomes less
important and OpenSim become more service oriented?

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

Re: [Opensim-dev] OAuth as authentication and authorisation (capability) specification

[Tommi Laukkanen]

Ouch, any chance of standard extension to support rich clients :)
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] OAuth as authentication and authorisation (capability) specification

[Tommi Laukkanen]

I think Diva's point was that when using rich client we can collect
the credentials with a dialog and post them to openid. On http level
we can do the same tricks but we don't need necessarily switch to web
browser but we can stay inside the viewer.

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

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

[Tommi Laukkanen]

This patch only affects region asset service as I made separate class
namely CachedGetAssetStreamHandler instead of modifying
GetAssetStreamHandler directly. I could tweak it to be enabled only
when MXP is enabled and in grid mode. That should further limit any
possible risks.

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

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

[Tommi Laukkanen]

Hello

I just added CachedGetAssetStreamHandler to be able to use asset cache
and submitted the code as patch for review:

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

Maybe I should add further logic to enable CachedGetAssetStreamHandler
only in the special case of using MXP enabled grid mode?

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

[Opensim-dev] GetAssetStreamHandler, grid mode and caching

[Tommi Laukkanen]

Hello

Does someone know why GetAssetStreamHandler is not using cache but
fetching data directly from database with asset data plugin? This can
cause pretty heavy load on database when a lot of assets is loaded via
HTTP.

I noticed this when debugging why RegionAssetService does not work in
grid mode. It fails as GetAssetStreamHandler tries to load the assets
via data plugin which is not present in region instead of using
assetcache which is used by ll clients.

I would like to propose changing GetAssetStreamHandler to use
AssetCache to enable MXP enabled client to load assets via region in
grid mode (ll viewers load assets via region in grid mode but use
UDP).

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

Re: [Opensim-dev] OAuth as authentication and authorisation (capability) specification

[Tommi Laukkanen]

Hello

>
> Oauth is not an authentication system, it is delegated credentials
> system via a third party.
>

Authentication and authorisation with delegated credentials is what we
need as identities will be provided by identity providers and assets
from asset providers in distributed model. We need the client to be
able to authenticate against indentity provider acquire tokens and
provide them to region for authentication on region level, access to
profile information and assets etc. It is not good idea to pass
credentials to the region server directly.

> FOAF+SSL (aka Secure Web ID), is a much newer 3.0 techonology which
> has less complex interactions (no third party authentication or
> passwords required, it is a client server).  In a nutshell it uses the
> well established SSL protocol for authentication, and FOAF to makup a
> public key in your profile.

You can use OAuth for 2 legged authentication but your suggestion
sounds interesting as well. One would like to be able to use existing
networks hosting user identities but time will rectify that for any
new technologies as they gain popularity.

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

Re: [Opensim-dev] OAuth as authentication and authorisation (capability) specification

[Tommi Laukkanen]

Hello

Yeah I noticed it before posting and I see it as a living evidence
that the community is credible and they take security holes seriously.
As far as I understood it seemed to be related to usage of oauth from
web browser and some careless accepting of rights by the user. Similar
to some openid vulnerabilities.

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

[Opensim-dev] OAuth as authentication and authorisation (capability) specification

[Tommi Laukkanen]

Hello

OAuth seems to provide OpenSimulator server side authentication and
authorisation needs. If you are interested in this area please read
this page and especially the "What is it for"-chapter:

http://oauth.net/about/

"Is OAuth a New Concept?"-chapter is a good read as well.

Essentially it looks like a way to pass capabilities to servers. For
example you might give opensim region limited access to your
inventory.

More details can be found from their community wiki:

http://wiki.oauth.net/

Does anyone know other specifications for service level authentication
and authorisation (as opposed to browser and user level authentication
like OpenID and SAML)?

As you can see from the wiki front page for example google offers
standard oauth api. I would like to use my google identity in OpenSim
as soon as possible :). Someone might want to use AOL, Flickr, Amazon,
yahoo or facebook which are already supported. The big difference is
here that you need not pass your secrect password to opensim server or
go to openid login page at the provider. Idealistviewer could handle
authentication with google and pass the capability tokens to region
when connecting to it.

If you want to help Metaverse be realised in shortest possible time
please study OAuth and alternative approaches if such exist. I believe
this area needs some OpenSim community focus to get it properly sorted
for next technology leap. I hear a new version of CableBeach is coming
out and it would be great to have standards compliant solution in
capabilities area. By standards compliant I mean a solution which can
hook to major identity provider players as of now. The claim of this
post is that it is already possible with OAuth specification which has
been written by experts of the area.

If all those major players are supporting OAuth I think it is a strong
signal that the technology is good and mature. My understanding is
that it is very well compliant with OpenSim needs as well.

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

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

[Tommi Laukkanen]

Great summary and a really useful addition to build. ++

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

Re: [Opensim-dev] Withdrawing preview config changes for now

[Tommi Laukkanen]

Creating a "conf"-directory is a definitive ++. One could also condier
resource and temp directories or something like that and leave only
binaries to bin directory. Having runtime data under bin is not what
one would expect. Take any application which has bin-directory and
they store runtime data to some other dedicated directory and have
only binaries under bin.

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

Re: [Opensim-dev] Accessing textures via HTTP [bayes]

[Tommi Laukkanen]

My professional opinion is that it is a wild goose chase to try to
protect assets. The unfortunate reality is that when opensimulator
becomes widely adopted there will be open clients and anyone can go
and use them to get someone elses assets. There is just no way to
protect yourself against it. World wide web recognizes this and works
well.

We can put our heads in the bush but it does not change the reality.
Sorry to be so blunt about it but someone has to say it.

We should not put all things in the same security category either.
Some security things can be handled both in theory and reality and
some can not be. This is a situation where you have given the user
assets inside a container which he has all the keys for. I would not
say that we should lock the container because the user is too lazy to
unlock it.

Security through obscurity is not a good solution either (using j2k).

Any asset protection measures can be countered simple action:

A) Download a hacked client and use it.

** This applies to water marked and signed content as well. Once
client can view it, it can also store it and manipulate it.

As it is so easy there will be clients which do this. Why would anyone
choose restricted client if you can have one which works in open
fashion and provides you access to every asset? This just is a thing
we can not control. It is outside our sphere of influence.

Asset protection measures will just make our lives harder and not of
those who want to steal assets. These measures will make development
harder, adoption slower, cause bugs and above all waste our design
focus.

Only solution I can think of is to have some kind of network of
content registeries which will keep track of authorized content and
who has right to use it like Kyle suggested. Then majority of clients
should respect the registeries. There are two problems though. Can we
make such system work in global scale? Wont someone just branch and
make open OpenSim and clients?

Go for simple solution if complex ones do not give you real benefit.

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

Re: [Opensim-dev] Withdrawing preview config changes for now

[Tommi Laukkanen]

I apologise that I linked the latter chapter to this specific thread.
I should have posted it as a separate message as it was a more general
comment on our decission making process.

I guess it sprung from my wonderment about how the decission turned
out to be not to fix the overtly long config file in the way justincc
suggested. I think that the decission did not take into account people
like administrators and developers who use the system. Yes the
framework code can be more complex but it can produce benefits for
administrators and developers who need to deal with the long ini file.
I would even say that almost anything which splits the file is an
improvement to the current system.

Putting down an effort which tries to fix a problem at least can be
said to be counter productive.  I should reformulate my message: We
should in general suggest alternatives rather than just say "ouch I
dont like this". Our vote has consequences and if we use it we should
spend a little time to look into the issue and help the team to find a
better solution.

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

Re: [Opensim-dev] Withdrawing preview config changes for now

[Tommi Laukkanen]

It is a bit sad that this effort goes to waste. The opensim.ini is too
big to be efficient and everyone is wasting a lot of time browsing it
back and forth. I think something like splitting it up or moving
defaults to other file is really needed.

What is complex now is finding the properties you need from the
opensim property file. I think justincc:s proposal was elegant and
people should look deeper into it. It would definetly make everyones
life easier.

Honestly I also think that it is counter productive to give + or -
based on someone elses opinion (your favorite architect or the sorts).
One should only vote if one has himself looked into the matter. We are
not building political machine to steer opensim architecture are we?
Rather a board of specialists who look into the subject and give their
opinion if they are interested enough to dig into it. Otherwise we can
end up with a system where someone off handedly gives a - and as chain
reaction we get huge opposition for perfectly good suggestion or the
other way around.

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

Re: [Opensim-dev] Accessing textures via HTTP [bayes]

[Tommi Laukkanen]

I would not go so far that I would suggest we should go and try to
protect our assets by using semi supported image format instead of
well supported format...

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

Re: [Opensim-dev] Memory Leak and stats

[Tommi Laukkanen]

Ouch I forgot that evil madness. It would be good to put in proper
caches which drop items based on time. Eternal caches are well..
antipattern. Namely intentionally build memory leak. Anti patterns are
well known arch demons of software design and we should try to purge
them off the code base ,)

-Tommi

On Wed, Mar 18, 2009 at 7:48 PM, Melanie  wrote:
> It's really the proliferation of eternal caches that causes issues,
> IMHO.
>
> Melanie
>
>
> Tommi Laukkanen wrote:
>> One could catch the objects which are causing the leak by using a
>> profiler. If someone has .NET profiler and skills he could try to
>> trace the source of the problem so it can be fixed...
>>
>> -Tommi
>> ___
>> Opensim-dev mailing list
>> Opensim-dev@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Memory Leak and stats

[Tommi Laukkanen]

One could catch the objects which are causing the leak by using a
profiler. If someone has .NET profiler and skills he could try to
trace the source of the problem so it can be fixed...

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

Re: [Opensim-dev] Accessing textures via HTTP [bayes]

[Tommi Laukkanen]

I think j2k is not really supported by any main stream web browser
software nor SDK APIs of different languages. Requiring opejpeg native
lib to be included in all clients is not a good design decission. It
would be much cleaner if you can operate with the nativate image
manipulation API like System.Drawing in .NET. The converted JPEG's can
be easily cached for now. It is only the SL viewers which require it
because of some odd design decission from Linden Lab. I would not be
surprised if in the future textures will be stored as png and
converted to j2k for sl protocol. In high quality virtual world
lossless texture format could be preferable. Odd codecs should not be
forced on other protocols and clients based on ll behaviour.
Especially if we are experimenting with new brand of client / protocol
stacks like IdealistViewer and MXP.

I truly hope metaverse is not stuck with openjepg and j2k. Those
native libs tend to be more trouble than they are worth unless you
absoletuly need them.

Using the accept headers sounds like a good idea to me and if it is ok
with the team I could implement region asset service as Diva suggested
in the patch notes and Accept header support. I can put in cache as
well to avoid performance bottleneck. About image quality: we will end
up transforming from j2k anyway to some image format the client
rendering engine supports. I can also convert from j2k to png instead
of jpg to avoid any degradation as png is lossless format.

One could also consider naming the class as proxy as it will proxy the
call to local or remote asset server. Doing local caching on proxy is
a pattern used in http proxies and it could work for us as well.
Caching assets on region would lower the load on the grid asset
database.

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

Re: [Opensim-dev] Accessing textures via HTTP [bayes]

[Tommi Laukkanen]

Can everyone interested read the patch mantis and provide their
comments how we should proceed with this one:

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

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

Re: [Opensim-dev] Accessing textures via HTTP [bayes]

[Tommi Laukkanen]

I noticed that all our HTTP asset providers serve textures as j2k but
I need jpegs or other well supported image formats for MXP.

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

Re: [Opensim-dev] Accessing textures via HTTP [bayes]

[Tommi Laukkanen]

I can try and write a patch. I assume this is only usable in grid. Is
there any way to serve assets over http in sandbox mode?

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

Re: [Opensim-dev] Accessing textures via HTTP [bayes]

[Tommi Laukkanen]

Reading the source code from OpenSimAssetFrontEndPlugin. Looks like
there is no handling yet for the binary data request url in the
proposal:

http://assets.virtualworld.com/c228d1cf-4b5d-4ba8-84f4-899a0796aa97/data

Could we add here handing for handing out the raw binary data:

public override byte[] Handle(string path, Stream request,
OSHttpRequest httpRequest, OSHttpResponse httpResponse)
{
byte[] buffer = new byte[] {};
UUID assetID;
// Split the URL up to get the asset ID out
string[] rawUrl = httpRequest.Url.PathAndQuery.Split('/');

if (rawUrl.Length >= 3 && rawUrl[2].Length >= 36 &&
UUID.TryParse(rawUrl[2].Substring(0, 36), out assetID))
{
BackendResponse dataResponse;

AssetBase asset = new AssetBase();
if ((dataResponse =
m_server.StorageProvider.TryFetchDataMetadata(assetID, out asset)) ==
BackendResponse.Success)
{
XmlSerializer xs = new XmlSerializer(typeof
(AssetBase));
MemoryStream ms = new MemoryStream();
XmlTextWriter xw = new XmlTextWriter(ms, Encoding.UTF8);
xs.Serialize(xw, asset);
xw.Flush();

ms.Seek(0, SeekOrigin.Begin);
buffer = ms.GetBuffer();
Array.Resize(ref buffer, (int) ms.Length);
ms.Close();
httpResponse.StatusCode = (int) HttpStatusCode.OK;
}
else
{
m_log.WarnFormat("[OPENSIMASSETFRONTEND]:
Failed to fetch asset data or metadata for {0}: {1}", assetID,
dataResponse);
httpResponse.StatusCode = (int) HttpStatusCode.NotFound;
}
}
else
{
m_log.Warn("[OPENSIMASSETFRONTEND]: Unrecognized
OpenSim asset request: " + httpRequest.Url.PathAndQuery);
}

return buffer;
}
}

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

Re: [Opensim-dev] Accessing textures via HTTP [bayes]

[Tommi Laukkanen]

Hello

It looks like there is huge encoded data chunk in the Data element. Is
it possible to access it directly in binary format mike?


- http://www.w3.org/2001/XMLSchema-instance";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";>
  /0//UQAvAA...Data>
- 
  ----0005
  
  ----0005
  hardwood
  
  0
  false
  false
  

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

Re: [Opensim-dev] Accessing textures via HTTP

[Tommi Laukkanen]

Hi

I would like to receive the asset binary. I am not that interested in
the metadata currently. Is there a way to access that?

regards,
Tommi

On Mon, Mar 16, 2009 at 2:11 AM, Mike Mazur  wrote:
> Hi,
>
> On Sun, 15 Mar 2009 08:35:21 +0200
> Tommi Laukkanen  wrote:
>
>> I would need to fetch textures from assetserver using HTTP. Is it
>> enabled by default anf if so any pointers to find out url format? Do I
>> need enable some module?
>
> The asset server exposes an HTTP handler for assets at:
>
> http://address:port/assets/
>
> A GET request to that URL will receive an XML-serialized AssetBase
> class as defined in OpenSim/Framework/AssetBase.cs. A POST of an
> XML-serialized AssetBase class to the same URL will create an asset.
>
> If you'd like custom behavior, I encourage you to look at the
> AssetInventoryServer and some of the Frontend plugins it has. Look in
> OpenSim/Grid/AssetInventoryServer/Plugins.
>
> HTH,
> Mike
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

[Opensim-dev] Accessing textures via HTTP

[Tommi Laukkanen]

I would need to fetch textures from assetserver using HTTP. Is it
enabled by default anf if so any pointers to find out url format? Do I
need enable some module?

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

Re: [Opensim-dev] Unit tests should not be coupled (WAS: Re: [Opensim-commits] r8737 - trunk/OpenSim/Framework/Communications/Tests)

[Tommi Laukkanen]

Hello

In my experience the situation is that it is not feasible to write
unit test for things like repositories without relying in the test
order inside one test case. So that you can create add, update and
delete in that order. The same thing applies for any complex stateful
object/process where you want to test the states step by step and have
it fail in separate test phase so the first failure point is clearly
indicated in the test result.

My 2 cents: I know what the theory is but in practice to have useful
test set with reasonable amount of work ordered tests are a good
pattern.

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

Re: [Opensim-dev] Ini file(s) loading

[Tommi Laukkanen]

How about splitting to normal ini file and advanced ini file? In the
normal ini file you would have those parameters which 95% of the
people change and rest can be stuffed to advanced ini file.

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

[Opensim-dev] Identity Management, Inventory Management and Asset Management from MXP Perspective

[Tommi Laukkanen]

Hello

I have tried to collect a viewepoint from MXP perspective to the
OpenSimulator UGAIM architecture discussion. This text is based on the
discussion on this list and on formulation of an overall picture using
MXP terminology. I would like to hear your comments. Have I understood
things correctly and written it in understandable form? Is there
problems or mistakes on how I wrote the things down?

When we had the previous MXP version ready our conclusion was that we
needed some serious contribution from OpenSimulator to help fill in
the blank spots. I am happy to say that both technical details and
missing architecture areas have come to focus as a result of working
with OpenSimulator and reading this list.

Identity Management

Identity management, authenticaton and authorization are well
established areas. Identities are managed by open identity providers.
Participant identity consists of identity provider URI and participant
UUID. Participant may authenticate to identity provider by any means
available. Identity provider hands out one time tokens to participant.
These tokens are then used to to authenticate to bubbles and other
services. Bubbles and other services verify the tokens by invoking
verification requests to the identity provider. See OpenId and OAuth
for detailed description.

Inventory Management

Inventories are analogous to remote file systems with metadata
support. User has own directory where data can be stored. The
inventory service is not bound to identity provider or home bubble but
can be freely acquired from any compliant provider. Each user and user
group can have zero to many inventories. If no inventory is available
for user it is not possible to store data to inventory.

Asset Management

Asset management, storage and delivery are challenging from
ideological, theoretical and engineering view points. MXP is not an
asset delivery protocol. In ideological level it is enough to state
that any asset can easily be extracted with a specialized client.
Because of this there is no feasible technological way to absolutely
protect assets in an open system. MXP currently relies on the same
model as world wide web does. If a better model is introduced it will
be adopted. In practice this means that assets are delivered to all
connected participants by the asset cache of a bubble over HTTP.
Original assets are stored in an inventory of user or organization.
When user creates an object he assigns his own inventory or an
organization inventory to the object. The assigned inventory contains
assets of the object. This inventory is then used by bubble to load
the assets to local cache for further delivery to clients. In this
scheme the asset distribution is load balanced through bubbles and
inventory owners can control spread of their objects by limiting the
bubbles which may access the inventory in question. Asset ids are all
always assigned by inventories according to the proper UUID generation
algorithm which will effectively remove threat of id collisions
between assets from different inventories. See OpenSimulator
AssetServer Proposal for detailed description of protocol proposal.

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

Re: [Opensim-dev] OpenID

[Tommi Laukkanen]

As far as I understand with oAuth your viewer can post your credentials to
oAuth provider which will provide you with tokens. Tokens you hand to
consumers (remote services) which use those to get your identity and deduce
the access rights you have. What Diva explained is the core problem of
OpenID. The mechanism is not builtin to browsers but its takes web
forwarding to your openid browider for auth and back. If user is not careful
he can be get cheated. Normally open id should forward to your
open.idprovider according the url you gave and you should be able to
see in your
browser address bar if you were forwarded to correct place. Checking this
always takes superman qualities though.

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

Re: [Opensim-dev] Authentication and oAuth

[Tommi Laukkanen]

Hello again

This kind of argumentation really helps us to weed problems before we
implement them.

I think that if people have been on war over this issue for years then
either both or other party has not been entirely logical. After all in
engineering issues it should be possible to deduce how things are and arrive
to a conclusion which both parties agree is right and proper. This does not
apply to religional disputes like claiming earth is the center of universe.
I would not take advice from religious people on engineering.

> 2) Server has to store the CAPS URL information to memory or database
> > which is extra overhead.
> Incorrect. Capability URLs can and are generated on the fly. Look, for
> example, at Caps.cs that handles about 1/2 of the Caps we pass to the
> client (the other half is spread in several modules that subscribe to
> OnRegisterCaps). They are also detracted on the fly. We already do this
> dynamic management for the CAPs we pass to the client. That is exactly
> the thing that I like the most. It's not just that the authorization is
> generated on the fly; the service handle itself is dynamic. So the
> service is only there during the appropriate context.


Do  you mean that the caps url is processed when client invokes it to deduce
what is encoded in the url to get capability out of it or do you mean that
the CAPS URLs are temporary and have short life time like that of a client
session?

 > It looks to me that oAuth might be used to authentication as well so
> it could replace OpenId entirely.
>
> I don't think so. The spec for OAuth clearly says that it doesn't
> concern the authentication steps, which can be done in a number of ways.
> They do suggest, however, that OpenID+OAuth is a good combination.
>

Their statement could be political as well. When I was reading their
detailed specification there were user authentication phase as well where
there were user token and secret passed which could be user name and
passwords. Of course these can be also OpenId generated tokens but it looked
a bit like the actual OpenId tokens proposal never got to the specification.
The oAuth specification needs closer study or we need an oAuth expert to go
deeper. (Or we need to spend some time reading the spec ourselves (Fear))

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

Re: [Opensim-dev] Authentication and oAuth

[Tommi Laukkanen]

Good morning

Here are some engineering concerns I see with CAPS URLs:

1) If client is given CAPS URL to access something we need to have access
list / ownership and user role information in the database to deduce if the
user has the right for capabilities he/she is requesting for. CAPS URLs do
not remove need to for ownership, roles and ACLs. ACL is theoretically just
a list of subjects who have ability to do given operations to an object. You
can not even theoretically eliminate this information. You can deduce it
from group memberhsip but groups are just another principal who can be added
to ACL.

2) Server has to store the CAPS URL information to memory or database which
is extra overhead.

3) CAPS URL does not work from server to client as HTTP requests can
reliably traverse only from client to server due to NATs and firewalls. So
they work only from client to server and server to server.

4) CAPS URLs are different from authentication tokens. CAPS URLs are
authrorization related mechanism which are handed out by the service process
like region itself. Region CAPS URLs not help to authenticate or authorize
against other service processes like asset providers but you need to first
authenticate and authorize against asset provider in which point the asset
provider can hand you CAPS URLs.

5) If the life time of the CAPS URL is that of a client session it can be
easily be abused by attackers who are sniffing the network traffic.

As conclusion CAPS URLs we talk here seem to be a kind of caching mechanism
where we do authentication and authorisation on client login and store the
authorisation information to CAPS URLs which client can access directly and
we do not need to authenticate&authorize anymore. As such CAPS URL is not a
competitor to either OpenId nor oAuth. OpenId is authentication mechanism
and oAuth is authorization mechanism for consuming services from remote
interfaces. It looks to me that oAuth might be used to authentication as
well so it could replace OpenId entirely.

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

Re: [Opensim-dev] Authentication and oAuth

[Tommi Laukkanen]

Hello

After reading a bit of that article and wikipedia about capabilities based
security it looks to me that the capability model requires quite severe
assumptions about environment they are used in. If I understand the system
correctly the capability framework has to be in control of the client
process capability list to stop it from forging capabilities or altering
them. This would work inside one operating system but not in the internet?
Even if there is somekind of encryption scheme to avoid forgery the
capabilities can be passed around by internet client programs if they are
not controlled somehow. Thus if you give capability A to Alice, she can pass
it to Bob. I guess you can still work around this by signing the capability
to Alice. In the end this becomes quite complex way of writing a certificate
for Alice to do thing 1,2,3 to object X. If you consider using this in any
real system you end up with huge amount of these capabilities (combination
of subject, abilities and resource) which you need to process.

Is there a document on SL capabilities so I could knock some knowledge in my
head?

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

Re: [Opensim-dev] Authentication and oAuth

[Tommi Laukkanen]

Thanks :) I stand corrected

On Sun, Mar 1, 2009 at 8:27 PM, Diva Canto  wrote:

> Just to keep the record straight, the Capabilities concept is about 50
> years old. It was devised at about the same time as ACLs. For a number of
> reasons, ACLs have dominated the field. See here for a nice historical
> perspective:
> http://www.nabble.com/On-the-Spread-of-the-Capability-Approach-to5608409.html
>
> Tommi Laukkanen wrote:
>
>   Hi Diva
>
> Thanks for the analysis. I have to admit I have only fastly scanned the
> oAuth spec. They advertise that it works for desktop applications so I
> assume it should not necessarily be too complex for the end user and not too
> hard to implement either. Someone would need to study / poc it or get a
> statement from the oAuth team. If the viewer acts as users and regions are
> consumers it could be that it can be nicely automated and hidden from the
> user. This would allow us to use all those identity providers who have
> adopted oAuth. Personally I think identity management, authentication and
> authorisation are so well known fields that it would be odd if we had to
> invent it from scratch. That said we should not try bend a standard to
> something which is not suitable for.
>
> In the end it is important to realise that this is not just about virtual
> worlds but all identity management in the net. No user wants to upkeep
> separate credentials just for virtual worlds. Besides web and vws will
> become more and more entangled in the long run. If we want to have a system
> which will fly in the near future we should stick our identity eggs to same
> basket with the rest of the internet crowd.
>
> regards,
> Tommi
>
> --
>
> ___
> Opensim-dev mailing 
> listopensim-...@lists.berlios.dehttps://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Authentication and oAuth

[Tommi Laukkanen]

Hi Diva

Thanks for the analysis. I have to admit I have only fastly scanned the
oAuth spec. They advertise that it works for desktop applications so I
assume it should not necessarily be too complex for the end user and not too
hard to implement either. Someone would need to study / poc it or get a
statement from the oAuth team. If the viewer acts as users and regions are
consumers it could be that it can be nicely automated and hidden from the
user. This would allow us to use all those identity providers who have
adopted oAuth. Personally I think identity management, authentication and
authorisation are so well known fields that it would be odd if we had to
invent it from scratch. That said we should not try bend a standard to
something which is not suitable for.

In the end it is important to realise that this is not just about virtual
worlds but all identity management in the net. No user wants to upkeep
separate credentials just for virtual worlds. Besides web and vws will
become more and more entangled in the long run. If we want to have a system
which will fly in the near future we should stick our identity eggs to same
basket with the rest of the internet crowd.

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

Re: [Opensim-dev] Authentication and oAuth

[Tommi Laukkanen]

It looks like OpenId Authentication 2.0 has similar functionality:

http://openid.net/specs/openid-authentication-2_0.html

regards,
Tommi

On Sun, Mar 1, 2009 at 4:42 PM, Tommi Laukkanen <
tommi.s.e.laukka...@gmail.com> wrote:

> Hello
>
> Everyone who is interested in authentication should check this out:
>
> http://oauth.net/core/1.0/
>
> Looks well established standard which does OpenId+Tokens and is getting
> adopted in web industry. What do you think?
>
> regards,
> Tommi
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

[Opensim-dev] Authentication and oAuth

[Tommi Laukkanen]

Hello

Everyone who is interested in authentication should check this out:

http://oauth.net/core/1.0/

Looks well established standard which does OpenId+Tokens and is getting
adopted in web industry. What do you think?

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

[Opensim-dev] MXP prim shape support

[Tommi Laukkanen]

Hello

I have added google protocol buffers extension (ObjectExtFragment) to MXP
dll and updated OpenSim MXP module to fill it in. Basicly clients should be
able to render prims correctly using data coming over MXP now.

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

Re: [Opensim-dev] MXP and Google Protocol Buffers

[Tommi Laukkanen]

Thank you John for the protocol buffers idea and encouragement. Lets keep
this train on the move. Hope you get your proposal published soon.

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

[Opensim-dev] MXP and Google Protocol Buffers

[Tommi Laukkanen]

After getting this great suggestion yesterday from Hurliman I added google
protocol buffers as the IDL mechanism for defining extension fragments to
MXP. Added also two dummy OpenMetaverse extensions
(ObjectStateExtensionFragment, ChatExtensionFragment) and unit tests.

Now it is possible to edit MXP.Extentions.OpenMetaverseFragments.proto IDL
file to define OpenMetaverse fragments, run runprotogen.bat and nant build
to get MXP.dll with OpenMetaverse specific extension fragments.This should
enable us to transmit PrimitiveBaseShape parameters to client so that client
can render proper shapes for primitives.

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

Re: [Opensim-dev] On solving Authentication and such

[Tommi Laukkanen]

+1 from me too. The 2d ui can start as sub set of html for example.
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] MXPClient?

[Tommi Laukkanen]

Decided to go for slightly simplified solution and drag that log4net
dependency with MXP for now but allow other alternatives:


using System;

using System.Collections.Generic;

using System.Text;

using log4net.Repository.Hierarchy;

using log4net;

using System.Reflection;

namespace MXP.Util

{

public class LogUtil

{

private static readonly ILog logger = LogManager.GetLogger("MXP");

public static bool LogToTrace = true;

public static bool LogToLog4Net = true;

public static bool LogToConsole = false;

public static void Debug(string message)

{

if (LogToTrace)

System.Diagnostics.Debug.WriteLine(message);

if (LogToLog4Net)

logger.Debug(message);

if (LogToConsole)

Console.WriteLine("debug: " + message);

}

public static void Info(string message)

{

if (LogToTrace)

System.Diagnostics.Trace.TraceInformation(message);

if (LogToLog4Net)

logger.Info(message);

if (LogToConsole)

Console.WriteLine("info: " + message);

}

public static void Warn(string message)

{

if (LogToTrace)

System.Diagnostics.Trace.TraceWarning("Warning: " + message);

if (LogToLog4Net)

logger.Warn(message);

if (LogToConsole)

Console.WriteLine("warn: " + message);

}

public static void Error(string message)

{

if (LogToTrace)

System.Diagnostics.Trace.TraceError(message);

if (LogToLog4Net)

logger.Error(message);

if (LogToConsole)

Console.Error.WriteLine("error: " + message);

}

}

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

Re: [Opensim-dev] User Authentication

[Tommi Laukkanen]

I meant that in LLClientView login we could contact the open id token
provider for token. Each ugaim could basicly implement open id token
provider functionality as well in case all users are not interested to use
external token provider. This would enable us to use grid based user
directories as before but also allow for external open id providers. You
could also use your grid account as open identifier.

You could also hack the ll viewer so that first name would be the open id
provider url and last name the open identifier :). hacky hack!

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

Re: [Opensim-dev] User Authentication

[Tommi Laukkanen]

You could use the LLClientView to do it as well. So other protocols
(MXP) with their own client views could go directly to proper model.
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] User Authentication

[Tommi Laukkanen]

As we cannot change the viewer at the moment one could use the opensim login
code to create the token...

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

Re: [Opensim-dev] User Authentication

[Tommi Laukkanen]

Hello

I got promising link from yesterday from Ryan (sempuki):

http://dev.aol.com/OpenidTokenExchange

That seems to be developed to solve exactly this problem. First point of
authentication fetches tokens from token exchange, passes those temporary
tokens to other components which use them to validate login against token
exchange. This will provide nice decoupling from original login region as
only the tokens need to be passed around?

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

Re: [Opensim-dev] MXPClient?

[Tommi Laukkanen]

Thanks John, sounds perfect. Is the license such that I can copy their
implementation directly?

regards,
Tommi

On Mon, Feb 23, 2009 at 9:38 PM, Hurliman, John wrote:

> Take a look at how C# WebServer handles logging (ILogWriter.cs in
> http://www.codeplex.com/webserver/SourceControl/changeset/view/18488). A
> simple interface is defined for logging, and default console and null
> loggers are provided. Developers using the library in their own applications
> can implement the class and hook it up to log4net, .NET trace logging, etc.
> without MXP.dll having to drag any dependencies around. This is the best
> balance between ease of use and clean separation of dependencies that I've
> found for C# logging so far.
>
> John
>
> >-Original Message-
> >From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> >boun...@lists.berlios.de] On Behalf Of Tommi Laukkanen
> >Sent: Monday, February 23, 2009 11:21 AM
> >To: opensim-dev@lists.berlios.de
> >Subject: Re: [Opensim-dev] MXPClient?
> >
>  >I added prebuild support to MXP library so you can build MXP.dll with
> >mono and nant now. I also removed Action<> class dependency. I will take
> >a look at log4net support next.
> >
> >
>  ___
> 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] MXPClient?

[Tommi Laukkanen]

I added prebuild support to MXP library so you can build MXP.dll with mono
and nant now. I also removed Action<> class dependency. I will take a look
at log4net support next.
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] oddities with asset storage

[Tommi Laukkanen]

How does the situation change if you clone the asset to your chosen storage
provider? Does it not still require use of hacked storage provider to get
access rights to the asset outside the defined rights?

Tommi

On Thu, Feb 19, 2009 at 9:02 PM, Melanie  wrote:

> No one would sue over a $0.05 shirt. The point of technical copy
> protection is not to block copying. It is to make it require
> criminal energy.
> You can't do it accidentally, or because you don't know better, it
> prevents "casual copying". You need to invest criminal energy,
> either by downloading software that does it for you, or by writing
> it. That proves intent. Which is what you need, in several
> countries, of you _do_ want to get them slammed for more than just
> the price of the item.
> If you can prove intent, the $0.05 shirt can translate into $1000 in
> penalties - and that is what a creator wants.
>
> Melanie
>
>
> Tommi Laukkanen wrote:
> > I have to admit I did not consider this through before posting. Still
> after
> > reflecting on it a bit I am thinking that we might need to consider this
> > from practical view point. Usually all copy right enforcing software is
> > cracked in no time and open source is especially vulnerable. So I would
> > state that if you can copy something say to your inventory or wear it you
> > can copy all dependencies to your asset provider. If someone resells
> > your assets or breaks your license in some other way you need to sue them
> > which is in reality only real protection for any immaterial rights.
> >
> > Please note that if someone can even observe any asset in a viewer it is
> > trivial to write a version of that viewer which will make local copies of
> > anything you want. It might not be trivial for end user but cracked
> versions
> > would be soon available in internet. We can not even defend against that
> as
> > our software is open source and modifications are legit. Even those
> allowing
> > for local copies. I don't think legislation in any country forbits you
> from
> > saving a stream or image to your local disk even if it is copyrighted. It
> > becomes illegal if you break the license by for example redistributing
> > or selling. Instead of starting a fight we can not win we should make a
> > clean way to mark licensing and copyrights to all assets and leave it to
> the
> > morale of the users and legal systems.
> >
> > regards,
> > Tommi
> >
> >
> >
>  >
> 
> >
> > ___
> > Opensim-dev mailing list
> > Opensim-dev@lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] oddities with asset storage

[Tommi Laukkanen]

I have to admit I did not consider this through before posting. Still after
reflecting on it a bit I am thinking that we might need to consider this
from practical view point. Usually all copy right enforcing software is
cracked in no time and open source is especially vulnerable. So I would
state that if you can copy something say to your inventory or wear it you
can copy all dependencies to your asset provider. If someone resells
your assets or breaks your license in some other way you need to sue them
which is in reality only real protection for any immaterial rights.

Please note that if someone can even observe any asset in a viewer it is
trivial to write a version of that viewer which will make local copies of
anything you want. It might not be trivial for end user but cracked versions
would be soon available in internet. We can not even defend against that as
our software is open source and modifications are legit. Even those allowing
for local copies. I don't think legislation in any country forbits you from
saving a stream or image to your local disk even if it is copyrighted. It
becomes illegal if you break the license by for example redistributing
or selling. Instead of starting a fight we can not win we should make a
clean way to mark licensing and copyrights to all assets and leave it to the
morale of the users and legal systems.

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

Re: [Opensim-dev] Heads Up: Updating Prebuild to Upstream

[Tommi Laukkanen]

*applauds*

On Thu, Feb 19, 2009 at 2:54 PM, Stefan Andersson wrote:

> First of all, sorry for the cross-post, just felt the 'users'
> (whatever that means) should be aware of this as well:
>
> I have now updated Prebuild from upstream. Please, try the latest rev out
> and report to me if I have caused any breakage or regressions. Thank you to
> Kunnis and JHurliman for back-porting the OpenSim fixes into Prebuild
> upstream.
>
> This is the commit log entry for the update:
>
> === PREBUILD UPSTREAMS UPDATE : POTENTIAL BREAKAGE ===
> * Applied upstreams changes to allow for auditing and debugging in our
> various environments.
> * This should, in theory, bring back 'multiple ref dirs'.
> * Temporarily Removed xmlns because prebuild-1.7 schema does not allow for
> multiple solutions per prebuild node (This will be a moot issue once the
> Prebuild node is moved out of prebuild.xml)
> * Autotools target: Various minor fixes
> * MonoDevelop Target : No changes.
> * Nant Target: Various minor fixes, support for net-3.5 and mono-2.0/3.5
> targets
> * Sharpdevelop targets: No changes.
> * VS Targets: Refactored into using VSGenericTarget, and supports 2.0-3.5
> * XCode Target: No changes.
>
> --- Regressions and outstanding issues ---
> * The Solution is assigned a random Guid - will lead to unnecessary reloads
> and loss of user settings. [in Visual Studio, that is]
>
> --- New features of Prebuild 2.0.4 ---
> * (Better) support for Web, WinForms and Database Projects and build
> actions
> * Conditional Framework Version compilation support (1.1, 2.0-3.5)
> * ArrayList -> List<>, ICollection -> IList
>   (this means Prebuild can generate 1.1 solutions, but can't itself be
> built under 1.1 - how very meta)
> * Added  preprocessor directive.
>
> Best regards,
> Stefan Andersson
> Tribal Media AB
>
>
>
>
> --
> From: ste...@tribalmedia.se
> To: opensim-dev@lists.berlios.de
> Subject: Heads Up: Updating Prebuild to Upstream
> Date: Wed, 18 Feb 2009 22:14:43 +0100
>
>
> Dear colleagues,
>
> Kunnis and JHurliman has been working to incorporate our Prebuild
> customizations into the upstream source, and we're now at the point where we
> can do an upstream update and subsequentially move the Prebuild source out
> of the trunk and into opensim-libs. (Or should it go on the forge?)
>
> Since the code hasn't changed that much, I believe we should simply go
> ahead and do the switch, and if any cross-environment breakage would happen,
> work together to solve it.
>
> So please help us troubleshoot Prebuild on your environment.
>
> Best regards,
> Stefan Andersson
> Tribal Media AB
>
>
>
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] oddities with asset storage

[Tommi Laukkanen]

I think somekind of hybrid of different strategies might work well. Maybe
each storage provider could keep the assets in database and use hash to
ensure there is no duplicates and a separate metadata entry which is ref
counted with the binary. Anyhow this would be up to the specific storage
provider implementation. When for one reason or another asset is referenced
by another storage provider then the other asset provider can clone it to
own storage. Rights for cloning can be deduced simply as follows: If you
have right to copy the asset you have right to clone it to your own service
provider. This would also leave distribution strategies etc. decissions for
the specific storage provider. All we need to do is figure out where and how
different storage providers are used. Can region have dedicated storage
provider? Can user have own storage provider? Can grid choose external
storage provider? How do these different storage providers play together in
all use cases?

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

Re: [Opensim-dev] oddities with asset storage

[Tommi Laukkanen]

+1 asset storage providers again. Trying to avoid one unideality causes
usually another unideality to occur. In this case immutable assets cause
uncontrollable growth in asset storage systems. It would be better to do
something like Dirk suggests and accept that sometimes something what is
referenced gets deleted. If you want to avoid this use textures from
providers who quarantee to keep them available or host them in your own
service provider.

regards,
Tommi

On Wed, Feb 18, 2009 at 7:33 PM, Dirk Krause wrote:

> Glad you asked :-).
>
> I would do a mixture of the following (and admit that I didn't think it all
> through to the very end).
>
> - introduce grid wide, region wide and personal (user) asset domains
> - introduce quotas for these
> - allow clones ('byref') assets, and copies that go into one of the
> domains, resp.
>
> I then would expect to have grid wide assets that are 'always on', region
> wide assets that only are important when the region is connected, and
> personal assets that are only visible when the user is online (could even be
> an FTP server behind a cable beach server).
>
> It boils down to: if someone treasures something, she better keeps it in
> her treasure chest, in her responsibility (and maintenance cost).
>
>
> -Ursprüngliche Nachricht-
> Von: opensim-dev-boun...@lists.berlios.de [mailto:
> opensim-dev-boun...@lists.berlios.de] Im Auftrag von Dr Scofield
> Gesendet: Mittwoch, 18. Februar 2009 17:41
> An: opensim-dev@lists.berlios.de
> Betreff: Re: [Opensim-dev] oddities with asset storage
>
> Dirk Krause wrote:
> > ...
> [...]
> >
> > But isn't that ... horrible? (in lack of a better/worse word.)
> >
> > As I said yesterday, IMHO there is no real need to think about
> > optimizations when you have
> > a serious blocker like this. I would even go so far that this is a major
> > roadblock for grid based technologies per se. (grid as in Rosedale's
> > 'Happily now, Second Life has been proven to exist. If we disappeared
> > tomorrow, the grid would be rebuilt by you.')
> >
> > I take it the bad news is that any proposed solution to this breaks SL
> > compatibility?
> >
> > Maybe now would be a good time to take a step away from it.
>
> so, what do you supposed should be done? ride OpenSim on web route 404?
> lots of
> dangling references?
>
> i supposed on a standalone system you could do ref counting or
> bidirectional
> refs/links --- that however is not a very scalable solution for a grid with
> sporadically connected grid components.
>
> one avatar's garbage is another avatar's treasure...
>
>DrS/dirk
>
>
> --
> dr dirk husemann  virtual worlds research  ibm zurich research lab
> SL: dr scofield  drscofi...@xyzzyxyzzy.net  http://xyzzyxyzzy.net/
> RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
> ___
> Opensim-dev 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] Blockers for unit testing physics modules

[Tommi Laukkanen]

The thing with the ode tests is that instead of having them in separate test
dll as with all the rest of the tests the ode tests are placed in the same
dll as ode plugin. Because of this it does not need to reference the
ode plugin dll which would not work. I think we should really push for
improvements to prebuild as getting everything to same output directory is
not very clean solution considering for example deployment of different exe
files to different machines. There is also problem of not being able to
clean the bin directory as it permanently contains dll dependencies and even
runtime data. In practice I think it is a good pattern that the bin
directory is completely emptied on build clean. It would be also nice to be
able to build different exe files to their own distribution folders. These
last two as a long term goals to consider.

regards,
Tommi

On Tue, Feb 17, 2009 at 4:29 PM, Teravus Ovares  wrote:

> Stefan,
>
> No, this doesn't work. We've tried all sorts of ways to do that.  But,
> there is a solution that we're already using for this very problem
> with bamboo.   Simply copy the physics assembly to bin when running
> the tests.   As I said, bamboo already does this.   The test harness
> is currently in the odeplugin assembly and gets run successfully.
>
> Best Regards
>
> Teravus
>
> On Tue, Feb 17, 2009 at 6:24 AM, Stefan Andersson 
> wrote:
> > You should be able to specify a 'path' attribute on the prebuild
> reference
> > element.
> >
> >  path="../../Whatever/Dir/Test.dll"
> > />
> >
> > If that doesn't work, let me know and I'll have a look at a solution.
> >
> > (Sorry for the late reply)
> >
> > Best regards,
> > Stefan Andersson
> > Tribal Media AB
> >
> >
> >
> >
> > 
> > Date: Mon, 9 Feb 2009 20:54:33 +0200
> > From: tommi.s.e.laukka...@gmail.com
> > To: opensim-dev@lists.berlios.de
> > Subject: [Opensim-dev] Blockers for unit testing physics modules
> >
> > Hello
> >
> > I was writing some unit tests for physics modules and I collided with the
> > following problem with prebuild and nant:
> >
> > Currently physics modules are stored in bin/Physics and because of this
> you
> > can not reference them in further steps of the build as you can define
> only
> > one reference directory for a project. I have referenced ode plugin dll
> from
> > test dll but because of the reference problem the nant build fails. The
> test
> > itself builds and works well in visual studio.
> >
> > I dont see any way around this. We would need to move the physics plugin
> > dlls to bin directory like rest of the dlls or forget doing separate unit
> > test dlls which refer to these plugins.
> >
> > This limitation is good to know for all prebuild work we do. Do not place
> > the build output to any other directory than OpenSim/bin or you cannot
> > reference that in other projects of nant build.
> >
> > If someone knows how to fix this easily please let me know.
> >
> > regards,
> > Tommi
> >
> > ___
> > Opensim-dev mailing list
> > Opensim-dev@lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> >
> >
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Please do not revert fixes without careful comtemplation

[Tommi Laukkanen]

How are you going to do carbage collection of the shared binaries? Just by
last access date or somekind of reference counting mechanisms from metadatas
to the binaries?
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Please do not revert fixes without careful comtemplation

[Tommi Laukkanen]

Plus you could use those hashes to distribute the assets to several backed
databases in similar manner as hashmap works. If a database becomes too full
you can always split it to sub databases and move assets there in analogy
with hashmap internal datastructure. Basicly all hashmap performance math
and algorithms should apply. Do you think this could be workable way of
doing asset storage distribution?

regards,
Tommi

On Mon, Feb 16, 2009 at 3:21 PM, Frisby, Adam  wrote:

> Hence me suggesting stronger hashes - there's no known attacks on anything
> above or equal to 160bit, plus to calculate an attack you'd have to have the
> hash of the original to begin with, which shouldn't be something revealed to
> an end user.
>
> Adam
>
> > -Original Message-
> > From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> > boun...@lists.berlios.de] On Behalf Of Melanie
> > Sent: Monday, 16 February 2009 5:26 AM
> > To: opensim-dev@lists.berlios.de
> > Subject: Re: [Opensim-dev] Please do not revert fixes without careful
> > comtemplation
> >
> > I see the potential of targeted MD5 collisions as a way to obtain
> > script sources.
> > A saves a script.
> > B creates a targeted collision, which will result in creation of an
> > inventory item refering to A. The data B saves is ignored because of
> > hash equality
> > B then reopens the object and receives A's script source.
> >
> > Melanie
> >
> >
> > Frisby, Adam wrote:
> > > You do realise you could just not update the asset. If the hash is
> > the same, then you can just completely ignore the save/update request.
> > >
> > > That being said, even a targeted collision on MD5 is a 2^58 chance,
> > on SHA256 it's well over 2^128 which makes it pretty much impossible.
> > Frankly it's not something worth concerning oneself over.
> > >
> > > Adam
> > >
> > >> -Original Message-
> > >> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> > >> boun...@lists.berlios.de] On Behalf Of Melanie
> > >> Sent: Monday, 16 February 2009 4:45 AM
> > >> To: opensim-dev@lists.berlios.de
> > >> Subject: Re: [Opensim-dev] Please do not revert fixes without
> > careful
> > >> comtemplation
> > >>
> > >> Again, I'd like to stress that I believe this is too dangerous to do
> > >> for anything other than textures.
> > >> It is also not really needed for things other than textures, since
> > >> the other assets are comparatively small, textural data.
> > >>
> > >> I would not want to risk even the smallest chance of a hash
> > >> collision on script source.
> > >>
> > >> Melanie
> > >>
> > >> Stefan Andersson wrote:
> > >> > Coming in a bit from the side here,
> > >> >
> > >> >
> > >> >
> > >> > we have, for some time, discussed to separate out the binary blog
> > out
> > >> of the metadata for an entirely different reason, namely to be able
> > to
> > >> weed out binary duplicates.
> > >> >
> > >> >
> > >> > If there was a way for us to separate out the binary parts, into
> > >> something like 'binaryassetId, hashData[256], binarydata' and then
> > just
> > >> have the asset table referencing that row, I think it would help a
> > lot.
> > >> >
> > >> >
> > >> > I realize it's a separate discussion, just chipping in my two
> > cents.
> > >> >
> > >> >
> > >> > Best regards,
> > >> > Stefan Andersson
> > >> > Tribal Media AB
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > Date: Sat, 14 Feb 2009 17:49:22 +0200
> > >> > From: tommi.s.e.laukka...@gmail.com
> > >> > To: mma...@gmail.com
> > >> > CC: opensim-dev@lists.berlios.de
> > >> > Subject: Re: [Opensim-dev] Please do not revert fixes without
> > careful
> > >> comtemplation
> > >> >
> > >> >
> > >> > Hello,
> > >> >
> > >> > On second though we could keep the current structure and expose
> > all
> > >> fields also through AssetBase properties. Then we could save / load
> > the
> > >> AssetBas

Re: [Opensim-dev] Please do not revert fixes without careful comtemplation

[Tommi Laukkanen]

Hello

That works if we have property accessors directly exposed from AssetBase to
all metadata fields. Then we can write mapping with those accessors and
ignore the metadata aggregate.

regards,
Tommi

On Mon, Feb 16, 2009 at 1:54 PM, Mike Mazur  wrote:

> Hi,
>
> On Mon, Feb 16, 2009 at 8:38 PM, Tommi Laukkanen
>  wrote:
> > It would be nice to have somekind of short term solution to fix the
> current
> > nhibernate asset store implementation so that it works and when cable
> beach
> > is finalized we can see if we need to do something extra to support that
> > fully.
>
> How would this work as a temporary measure:
>
> class AssetBase
> {
>  private byte [] m_data;
>  private AssetMetadata m_metadata;
>
>  public UUID FullID
>  {
>get { return m_metadata.FullID; }
>set { m_metadata.FullID = value; }
>  }
>  // etc for the rest of the properties
>
>  // we have a method to retrieve the AssetMetadata object
>  // so we don't also serialize it when sending assets over the wire
>  public AssetMetadata getMetadata()
>  {
>return m_metadata;
>  }
>  public void setMetadata(AssetMetadata metadata)
>  {
>m_metadata = metadata;
>  }
> }
>
> Is there a better way to stop the metadata (property) from being
> serialized instead of using the C++-style accessor and mutator?
>
> I can commit this in about 12 hours if it would work. Comments welcome.
>
> Thanks,
> Mike
>  ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Please do not revert fixes without careful comtemplation

[Tommi Laukkanen]

Hello

It would be nice to have somekind of short term solution to fix the current
nhibernate asset store implementation so that it works and when cable beach
is finalized we can see if we need to do something extra to support that
fully.

Antti: Can you elaborate with examples or link me to some nhibernate
documentation which explains bulk object concept in detail. I don't get the
exact implementation details from your mail.  By implementation I mean what
kind of mapping files you are proposing we would need and how they would be
used from code.

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

Re: [Opensim-dev] Let's post-tag 0.6.3 [Was: some instability ahead r8399+]

[Tommi Laukkanen]

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

Re: [Opensim-dev] Please do not revert fixes without careful comtemplation

[Tommi Laukkanen]

Hello,

On second though we could keep the current structure and expose all fields
also through AssetBase properties. Then we could save / load the AssetBase
with nhibernate as a single object and leave out the Metadata  property from
NHibernate mapping. Does this sound good?

regards,
Tommi

On Sat, Feb 14, 2009 at 5:06 PM, Mike Mazur  wrote:

> Hi,
>
> On Sat, Feb 14, 2009 at 4:05 PM, Tommi Laukkanen
>  wrote:
> > I was talking with mikkopa and he suggested we should create two tables
> to
> > cover AssetBase to solve this issue properly. Namely AssetMetadata for
> > metadata information and AssetData for blobs to avoid situation where we
> end
> > up accessing also the blob data just to read metadata.
>
> I was hoping not to have to do that.
>
> It should be straightforward to support the current
> AssetBase/AssetMetadata composition in the existing OpenSim data
> layers, but as sdague warned me earlier, by mapping multiple classes
> to one table I was entering a world of pain. Seems that's exactly
> what's happening with NHibernate.
>
> The reason I introduced the AssetMetadata class is to supply metadata
> information only for some requests that Cable Beach, the new asset
> server, supports. Now I realize that this was probably a premature
> optimization.
>
> Instead of modifying the DB schema, we could have AssetBase inherit
> from AssetMetadata, as I outlined before[1]. Alternatively, we could
> get rid of AssetMetadata altogether and store everything in AssetBase
> as before, splitting out the metadata sometime in the future when a
> use case warrants it.
>
> What do you think?
>
> Thanks,
> Mike
>
>
> [1]
> https://lists.berlios.de/pipermail/opensim-dev/2009-February/004918.html
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] EstateID from uint to UUID

[Tommi Laukkanen]

I think this is a valuable discussion to have. My view is that all object
identifiers ought to be UUIDs as UUID type is developed specifically for
that with bullet broof unique id generation algorithm where as all other id
generation algorithms are either database specific or fail if you have
distributed service or both. If we want to prepare for distributing all our
systems then aiming for purely UUID based identification is a good step
forward. In understand that in practice it might be a very long time before
we can reach a point where all identifiers are of UUID type but if we
consider this to be a design principle then the resolution is immediately
valid for any new implementations we do.

On Sat, Feb 14, 2009 at 1:23 PM, Melanie  wrote:

> Estate ID is a purely local concept that is likely to vanish in
> newer viewers and the Hypergrid. There is no point in creating a
> double-lookup scenario.
> There is nothing that says that all objects must be GUID and no
> point in refactoring for refactoring's sake.
>
> Melanie
>
>
> Tommi Laukkanen wrote:
> > Hello
> >
> > LL viewer quirks we must conform to but as with many other objects the
> > primary key could be uuid and uint based id is kept around for ll viewer
> > compatibility? Maybe it gets too messy in the end to be worth the
> trouble.
> > One can consider it once we get to have custom viewers which are not
> leashed
> > by SL protocol limitations.
> >
> > regards,
> > Tommi
> >
> > On Sat, Feb 14, 2009 at 1:14 PM, Melanie  wrote:
> >
> >> Hi,
> >>
> >> the estate id _is_ a uint. It is not a UUID and was never meant to
> >> be a UUID. The client sends and expects a UINT.
> >>
> >> Melanie
> >>
> >>
> >> Tommi Laukkanen wrote:
> >> > Hello
> >> >
> >> > I am working on Estate NHibernate storage and noticed that EstateID is
> >> still
> >> > of uint type where as most of other objects have been converted to
> UUID
> >> > identifiers. Is anyone interested in tackling this refactoring from
> uint
> >> to
> >> > UUID. Its not a small job but it would make the database much cleaner.
> >> >
> >> > regards,
> >> > Tommi
> >> >
> >> >
> >> >
> >> >
> 
> >> >
> >> > ___
> >> > Opensim-dev mailing list
> >> > Opensim-dev@lists.berlios.de
> >> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> >> ___
> >> Opensim-dev mailing list
> >> Opensim-dev@lists.berlios.de
> >> https://lists.berlios.de/mailman/listinfo/opensim-dev
> >>
> >
> >
> > 
> >
> > ___
> > Opensim-dev mailing list
> > Opensim-dev@lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> ___
> Opensim-dev 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] EstateID from uint to UUID

[Tommi Laukkanen]

Hello

LL viewer quirks we must conform to but as with many other objects the
primary key could be uuid and uint based id is kept around for ll viewer
compatibility? Maybe it gets too messy in the end to be worth the trouble.
One can consider it once we get to have custom viewers which are not leashed
by SL protocol limitations.

regards,
Tommi

On Sat, Feb 14, 2009 at 1:14 PM, Melanie  wrote:

> Hi,
>
> the estate id _is_ a uint. It is not a UUID and was never meant to
> be a UUID. The client sends and expects a UINT.
>
> Melanie
>
>
> Tommi Laukkanen wrote:
> > Hello
> >
> > I am working on Estate NHibernate storage and noticed that EstateID is
> still
> > of uint type where as most of other objects have been converted to UUID
> > identifiers. Is anyone interested in tackling this refactoring from uint
> to
> > UUID. Its not a small job but it would make the database much cleaner.
> >
> > regards,
> > Tommi
> >
> >
> >
> > 
> >
> > ___
> > Opensim-dev mailing list
> > Opensim-dev@lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

[Opensim-dev] EstateID from uint to UUID

[Tommi Laukkanen]

Hello

I am working on Estate NHibernate storage and noticed that EstateID is still
of uint type where as most of other objects have been converted to UUID
identifiers. Is anyone interested in tackling this refactoring from uint to
UUID. Its not a small job but it would make the database much cleaner.

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

Re: [Opensim-dev] Please do not revert fixes without careful comtemplation

[Tommi Laukkanen]

Hello Mike,

Thank you for your professional reply. I have tried to reach you in irc
immediately after you first commented the mantis but we seem to be in
different time zones.

The NHibernate unit tests are not in the build as the system is still in
experimental state. We have not tried to push them into build yet to avoid
hindering the OpenSim development before there is clear indication that
NHibernate storage is complete and mature enough to be used in production
systems. Currently we are intentionally playing catchup with rest of the
systems.

I was talking with mikkopa and he suggested we should create two tables to
cover AssetBase to solve this issue properly. Namely AssetMetadata for
metadata information and AssetData for blobs to avoid situation where we end
up accessing also the blob data just to read metadata.  He thought you had
something like this in mind when you moved metadata fields to aggregate
object. This approach would also fix the double id issue which is caused by
the fact that nhibernate to my best knowledge does not support reading
object primary id from aggregate object.

I apologize if I overreacted. It is hard for me to read people and
intentions in online environments.

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

Re: [Opensim-dev] Mesh to primitive converter

[Tommi Laukkanen]

How about adding prim type mesh? I understand we need custom viewer but how
long can we stay in SL leash?

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

Re: [Opensim-dev] Please do not revert fixes without careful comtemplation

[Tommi Laukkanen]

Here is the mantis in question:
http://opensimulator.org/mantis/view.php?id=3122

regards,
Tommi

On Fri, Feb 13, 2009 at 7:25 PM, Dahlia Trimble wrote:

> Is there a specific commit or mantis which this is addressing? I'm not
> aware of which events your message applies to, but I can say in general that
> I've only seen a code revert when the original changes  cripple
> functionality for other users or imposes a needless barrier on further
> development, and then the revert only happens after consultation with others
> had occurred.
> This is also a fast moving project with many modifications made to the
> source tree from many authors. Usually if a revert is required it needs to
> happen quickly otherwise it becomes increasingly difficult to restore the
> code back to a condition where it would be had the changes not been applied.
> If the author of the changes had not been available at the time of the
> decision to revert then notes are added to the mantis containing the patches
> explaining the situation to the author.
>
>   On Fri, Feb 13, 2009 at 8:12 AM, Tommi Laukkanen <
> tommi.s.e.laukka...@gmail.com> wrote:
>
>>   Dear all
>> If you decide to revert fixes the least you can do is to look into them in
>> detail and run the unit tests to make sure that the revert does not make
>> situation worse.
>>
>> This is also part of mutual respect between developers. Some of us are new
>> in the project. Some of us are inexperienced. But all of us have intellect
>> and feelings. Optimally if you find a problem which does not cause problems
>> in the production it is best that the person in blame is given advice and
>> gets to fix the issue himself.
>>
>> This is a large project and we should appreciate everyone who contributes.
>> Motivation is a fragile thing and we should give our peers all the courtesy
>> we can. Let us make the community more enjoyable to everyone.
>>
>> sincerely,
>> Tommi
>>
>> ___
>> Opensim-dev mailing list
>> Opensim-dev@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

[Opensim-dev] Please do not revert fixes without careful comtemplation

[Tommi Laukkanen]

Dear all
If you decide to revert fixes the least you can do is to look into them in
detail and run the unit tests to make sure that the revert does not make
situation worse.

This is also part of mutual respect between developers. Some of us are new
in the project. Some of us are inexperienced. But all of us have intellect
and feelings. Optimally if you find a problem which does not cause problems
in the production it is best that the person in blame is given advice and
gets to fix the issue himself.

This is a large project and we should appreciate everyone who contributes.
Motivation is a fragile thing and we should give our peers all the courtesy
we can. Let us make the community more enjoyable to everyone.

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

Re: [Opensim-dev] Need a debugging tip for Visual Studio C# 2008 Express

[Tommi Laukkanen]

Sounds like your program is running as 64 bits when running in debugger.
Trying changing processor architecture to 32 bits from project settings.

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

Re: [Opensim-dev] Avatar movement packet optimization

[Tommi Laukkanen]

Nice!

We need more work like this.

Tommi

On Wed, Feb 11, 2009 at 1:21 PM, Mikko Pallari  wrote:

>  Hi,
>
>
>
> I have made a patch to optimize number of packets to enable even more users
> in simulator. I have submitted this patch to mantis and you can review it
> here: http://opensimulator.org/mantis/view.php?id=3136
>
>
>
> And as described in mantis this packet should increase the max number of
> avatars the server can handle. It combines many terse update packets in to
> one packet.
>
>
>
> Our initial tests show that:
>
> - two avatars moving in a circle with optimization: 30-60 packets per
> second on client
>
> - two avatars moving in a circle without optimization: 40-70 packets per
> second on client
>
>
>
> Cheers,
>
> Mikko Pallari
>
> ___
> 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] Setting default locale for opensim processes

[Tommi Laukkanen]

Hello

Should we set default locale programmatically when we launch the exe
files as there are various functions which will get mixed results if system
locale has different decimal separator defined?

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

[Opensim-dev] Blockers for unit testing physics modules

[Tommi Laukkanen]

Hello

I was writing some unit tests for physics modules and I collided with the
following problem with prebuild and nant:

Currently physics modules are stored in bin/Physics and because of this you
can not reference them in further steps of the build as you can define only
one reference directory for a project. I have referenced ode plugin dll from
test dll but because of the reference problem the nant build fails. The test
itself builds and works well in visual studio.

I dont see any way around this. We would need to move the physics plugin
dlls to bin directory like rest of the dlls or forget doing separate unit
test dlls which refer to these plugins.

This limitation is good to know for all prebuild work we do. Do not place
the build output to any other directory than OpenSim/bin or you cannot
reference that in other projects of nant build.

If someone knows how to fix this easily please let me know.

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

Re: [Opensim-dev] AssetServer Observations and Suggestions

[Tommi Laukkanen]

I like the idea of grid independent storage providers (assets and
inventories). It is in analogy with open id providers which are application
independent identity providers. The challenge with both is that the UUID
should always be accompanied by the provider url unless we have a way to
resolve provider URL from asset UUID.  In other words if Frank will have
texture asset on his avatar with given UUID it does not get me anywhere
unless I have a way to find out from which URL I can actually download that
asset. You can hide this from the viewer program and implement it in region
services for example but ultimately you will still face the same problem. If
we want simple engineering solution which works in all situations we should
figure out how we will solve mapping from asset UUID to provider service
URL. Possible solutions:

1) Use keys which consists of UUID and asset provider URL instead of just
UUID's (not very practical when you store the key to database)
2) Have distributed registry with maps UUIDs and provider URLs. This might
be even theoretically impossible as they amount of keys in the distributed
registry would be same as all the assets in the internet. Could this be
resolved by allocating UUIDs to different nodes based on somekind of UUID
hash value?
3) Try to hard wire asset access to correct repository behind the scenes. In
other words in HG region all avatars would notify the region which is their
asset provider and region will broker the asset calls to correct asset
provider. Client in turn assumes that each region may have separate asset
server and queries assets separately from each region. This is not very
clean solution and can result in quite complex overall system.

Number 2 would be good for enforcing uniqueness of UUID's so that it is not
possible to manually copy an asset and steal the identity by using the same
UUID. So this registry could be used to also store ownerhship rights for
UUIDs.

Work name: Distributed Identity Ownerhship and Provider Registry

best regards,
Tommi Laukkanen
On Sun, Feb 8, 2009 at 11:21 PM, Paul Fishwick wrote:

> On the observation that most multi-player games have asset stored
> client-side,
> thus allowing huge and feature-rich worlds, it would be nice to have an
> option ("private assets", "fixed assets" perhaps indicated by land
> parcel ?) that required people who wanted to take advantage of
> interacting there to first download all assets prior to launching
> the viewer. Having both ends of the spectrum (at one end, all
> startup assets are private and non-dynamically shared and at the other
> end, all assets are dynamically loaded to each connecting client)
> would provide more flexibility and some detailed spaces.
>
> -p
>
> Frank Nichols wrote:
> > I like the idea of shifting responsibility for user storage costs closer
> > to the user. Region maybe a good place to do this.
> >
> > Frank
> >
> > Charles Krinke wrote:
> >
> >> We have been studying the assets table on OSGrid as it heads toward
> >> the "disk full" stage and I have a couple of observations and am
> >> heading towards a suggestion. Maybe this is already accounted for in
> >> the "Cable Beach" project, at which point, this will only indicate
> >> that I did not read all the exchanges carefully enough.
> >>
> >> It appears to me that we are storing on the MySQL data store at the
> >> assetServer on a grid every edit of every script, terrainImage and
> >> clothingItem amongst other things. So, my first observation is that we
> >> appear to be storing all the older, obsolete items that can no longer
> >> be accessed.
> >>
> >> Additionally, it appears to me that we are also storing things that
> >> could arguably be stored on the regions datastore, such as the
> >> terrainImage.
> >>
> >> Now, to the beginnings of a suggestion. It seems to me that each
> >> avatar will have a "home" region. And that perhaps that is the place
> >> to store the items in an avatars inventory. Things like scripts,
> >> notecards, textures and the like.
> >>
> >> At that point, the assetServer on a grid could be used to store only
> >> pointers (or URL's) to each avatars inventory on his or her home region.
> >>
> >> So, by doing that, we start shifting the ever increasing disk storage
> >> requirements of a grid back to the regions distributed around the
> >> internet.
> >>
> >> Again, perhaps Cable Beach is already doing this, and if so, this is
> >> great. If not, I put out these ideas and duck as the tomatoes start
> >> flying.
> >>
> >> Charle

Re: [Opensim-dev] RegionOnline status

[Tommi Laukkanen]

I would maybe add just offline/online states for region and make a separate
reservation table as fields required for reservation are different from that
of region.

regards,
Tommi

On Tue, Feb 3, 2009 at 7:00 AM, Dahlia Trimble wrote:

> Then again one could assume if a record existed for that region even if it
> were offline, that it's spot is reserved.
>
>
> On Mon, Feb 2, 2009 at 8:50 PM, Frank Nichols wrote:
>
>> To me the region does not need to know if or when the reserved status
>> would expire. Some process/module must have set it to reserved, and to
>> me would then assume the responsibility of knowing when/if to expire the
>> reservation.
>>
>> Dahlia Trimble wrote:
>> > I would think if a "RESERVED" state were added there would probably
>> > need to be an expiration date associated with it.
>> >
>> > On Sat, Jan 31, 2009 at 8:23 PM, Frank Nichols > > > wrote:
>> >
>> > There is a member in RegionProfileData (regionOnline) which is
>> > currently
>> > not used and does not exist in the region db table. I would like
>> > to add
>> > it to the region table as an enum and not a boolean. Currently the
>> > code
>> > assumes a region that has an entry in the region table is online
>> > (as far
>> > as I have figured out...) With this field in place we can
>> > impliment the
>> > requested feature of reserving regions as well as having regions
>> > online
>> > but not available for logins. I suggest the following enums:
>> >
>> > RESERVED
>> > OFFLINE
>> > ONLINE
>> >
>> > at least for starters.
>> >
>> > Before submitting a patch to support this, i wanted to get some
>> > direction and comments from the core developers and architects.
>> >
>> > Frank
>> > ___
>> > Opensim-dev mailing list
>> > Opensim-dev@lists.berlios.de 
>> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>> >
>> >
>> > 
>>  >
>> > ___
>> > Opensim-dev mailing list
>> > Opensim-dev@lists.berlios.de
>> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>> >
>>
>> ___
>> Opensim-dev mailing list
>> Opensim-dev@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Regions larger then 256x256

[Tommi Laukkanen]

How about allowing global scale change which would affect everything else
except terrain. If you would divide object scales by 10 you would have
regions of size 2560x2560. This of couse would be grid wide setting and
grids making hyper grid links should share the scale settings. Would this be
feasible?

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