Re: [Opensim-dev] oddities with asset storage

[Dirk Krause]

Sorry, this mail somehow escaped me by scrolling off too fast.

Now that I found it, I'd like to state that a reaping strategy is something 
that definitely will work, but to me is something like the last resort. 

I just imagine all these mails of type:
'Dear Mr. Grid Owner, I hate you because you deleted my Blue Bird Of Happiness 
and my Shiny Sword of Trademark. Yes, I didn't thouch them for over a year, but 
they remind me of the first useless things I ever collected. So be you and your 
first born child please cursed. Thanks for your attention.'

>From an IT standpoint I'd like to make sure that you have a reasonable 
>database growth, and a reaping strategy would enforce that, so that would be 
>ok.

If there'd be another strategy that would make reaping unnecessary, I'd welcome 
that. To me one solution involving different data responsibilities and quotas 
smells like such a solution.

-- Dirk/Bart

-Ursprüngliche Nachricht-
Von: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Melanie
Gesendet: Donnerstag, 19. Februar 2009 03:27
An: opensim-dev@lists.berlios.de
Betreff: Re: [Opensim-dev] oddities with asset storage

Hi,

i proposed a reaping strategy that is both type and time based. 
There was no direct response to it, but current development on new 
de-duping cable beach plugins may go a long way to curb asset 
proliferation and the reaper can be developed on that basis. 
Refcounting may be feasible as a positive indication, e.g. to 
indicate something is _definitely_ safe to delete, but a reaper will 
still be required.

Melanie

Buckaroo Mu wrote:
> Melanie wrote:
>> This is something i have though about. However, it would not work in 
>> OSGrid. Regions may go away, and they may go away permanently. 
>> Anything in a prim inventory at that time is refcounted and would 
>> not be released. Ever.
>>   
> In what what in particular would this be worse than the current 
> situation? Yes, some assets would end up staying around forever. 
> However, unlike the current scheme, some... would not.
>> So, you'd need a ref list, to purge invalid refs. That is where the 
>> inpracticability begins. A redf list for each and every asset, 
>> listing either avatar UUID or region UUID?
>>
>>   
> Eep, no - wasn't considering suggesting this.
>> If assets are 51 mio, how long will the reflist table be?
>>
>> Melanie
>>
>> Buckaroo Mu wrote:
>>   
>>> Here's my L$0.02, for what it's worth - why not maintain a 'reference 
>>> count' in the asset entry?
>>>
>>> Resident A creates a prim, takes it into inventory. Asset is created, 
>>> inventory item pointing to asset is created, asset->useagecount++. User 
>>> gives away 15 copies of item, asset->usagecount+=15. Resident A deletes 
>>> original item, inventory item goes away, asset->usagecount--.
>>>
>>> Resident B rezzes item on sim. If item is no-copy, asset->usagecount--. 
>>> If it's copy, and Resident B (or Resident C) takes it back into 
>>> inventory, asset->usagecount++ (they would have two copies of it). 
>>> Resident B deletes both copies from inventory, asset->usagecount -=2.
>>>
>>> If asset->usagecount == 0, asset gets deleted.
>>>
>>> Tell me why this wouldn't work. I'm sure there's a simple reason, but I 
>>> can't think of it. All of this is assuming that the asset is no-mod - 
>>> any change to the asset creates a new UUID, correct? But if the asset is 
>>> rezzed, then taken back into inventory, it should have the same UUID, 
>>> thus adding one to the usage count.
>>>
>>> -Buckaroo
>>>
>>> Melanie wrote:
>>> 
 All you described is design behavior.


 Prim items in world are not assets. They are stored exclusively in
 the prims tables of the region.

 Once taken, they become an asset. The name is totally meaningless,
 it reflects whatever was the name at creation. Nothing else. It
 never changes from there on.

 On deleting the inventory item, assets remain. There is no easy or
 practicable way to conclusively say that an asset is trash, because
 we don't know.

 In your test case, your (human) mind could know this for a fact,
 however, the silicon mind of the asset server can't.

 This is because you may have given the object to another user, or
 put a copy into a prim.

 These copies would refer to the same asset, that is what "implictily
 shared" means.

 So, any asset may, at any time, have any number of links to it, even
 zero.

 Like a website, you don't know who linked to it. If you remove it,
 you leave dead links. Assets are the same. Except, you get "Asset
 missing from database".

 So, assetas are NOT 1-to-1 with inventory items, and they _never_
 get deleted.

 They have to be reaped, and there is a big discussion over how to
 best do that, running right now.

 Melanie


 Dirk Krause wrote:
   
   
>

Re: [Opensim-dev] User Authentication

[Dirk Krause]

I indeed didn't know that, thanks a bunch for pointing it out. Like Mark
I also would be interested on how this was achieved?

 

-- Dirk/Bart

 

PS: Since it seems that the whole proposed OpenID strategy will only
work for Charles, I better order a t-shirt with 'I AM CHARLES KRINKE'
printed on it.

 

Von: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Diva Canto
Gesendet: Dienstag, 24. Februar 2009 02:06
An: opensim-dev@lists.berlios.de
Betreff: Re: [Opensim-dev] User Authentication

 

Mark Malewski wrote: 

Just to clarify...

 

> Grids could provide openIDs in the form of
"openid.osgrid.org/users/screenname
 "

 

With all grids being independent of one another, or in the example given
by John, maybe use an "openid.osgrid.org/users/screenname"

 

http://openid.osgrid.org/users/Charles_Krinke

 

For those of you who don't know, this already exists. Click this:
http://osgrid.org:8002/users/charles_krinke
or this:
http://ucigrid00.nacs.uci.edu:8002/users/crista_lopes




Again, in this example Charles happens to have his identity at OSGrid,
but that's not a requirement of the exchange. It could just as easily
been an identity from another grid.

 

This way various grids could all run "openID" servers, and trust
agreements would need to be established between the various grids.

I'm not going to act on anything that suggests "trust agreements between
various grids." That's an AWG concept that I very much disagree with,
and want no part in. I have no problem with companies cutting corners on
security in order to be able to exchange agents on a lawyer-backed up
trust basis. But that's not what I'm doing here, and that's not what a
lot of people want OpenSim to be.

The goal is to be able to go from my home standalone to *any* sim out
there that I know nothing about, and still be sure that nothing bad will
happen to my belongings. Anything less than this is not acceptable as a
goal, for me.

Crista

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

[Opensim-dev] The Business Case for OpenSim

[Colin B. Withers]

Hi,

I have been thinking about writing a Business Case for OpenSim. A Business Case 
is the feasibility study performed before a full Business Plan is written, and 
is equally applicable to opensource 'products'.

If such a Case has not been written before, then I would be prepared to write 
one, if the core developers would like one. But beware, it could be quite tough.

As for credentials, I used to write business cases and business plans for News 
Corporation.

Let me know,

Rock
MSc, MBA


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

Re: [Opensim-dev] The Business Case for OpenSim

[Frisby, Adam]

You are going to have fun with this one. There's probably at least a hundred 
separate ones, depending on who you ask.

OpenSim has a lot of commercial contributions, a lot of which are biased 
towards particular features that their implementations need. Our goal has been 
to create a platform flexible enough that we can accommodate all these together 
while still sharing enough 'common ground'.

Adam

From: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Colin B. Withers
Sent: Tuesday, 24 February 2009 1:15 AM
To: opensim-dev@lists.berlios.de
Subject: [Opensim-dev] The Business Case for OpenSim

Hi,

I have been thinking about writing a Business Case for OpenSim. A Business Case 
is the feasibility study performed before a full Business Plan is written, and 
is equally applicable to opensource 'products'.

If such a Case has not been written before, then I would be prepared to write 
one, if the core developers would like one. But beware, it could be quite tough.

As for credentials, I used to write business cases and business plans for News 
Corporation.

Let me know,

Rock
MSc, MBA


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

Re: [Opensim-dev] User Authentication

[Stefan Andersson]

Dear colleagues;

 

for some time now, we at Tribal Media have employed an entirely different way 
of logging the viewer in, with tokens, that does not constitute changing the 
viewer.

 

What we do, is that we install a 'launcher' app on the users computer. It 
serves a number of purposes:

 

1) Installs rezzme, genesis and osurl url monikers, all of them taking tokens 
as auxiliary data - these monikers let people log onto web sites, and launch a 
viewer with a pre-authenticated token by a link. (see step 5)

 

2) Identifies installed viewers, and keep track of preferreed viewer.

 

3) Provides a pre-login login form to do non-web pre-launch authentication (in 
this case, this would probably be where the _form_ obtains the token to pass to 
step 5)

 

4) Launches pre-requisite software, as the TribalVoice.exe for when voice 
should be enabled, or a Proxy to divert certain packets.

 

5) Launched preferred user, with seamless login (using the login option of the 
ll viewer with dummy data to bypass the login screen) supplying the TOKEN in a 
tweaked LOGINURI - an example of this loginuri would be -loginuri 
http://{loginserver}/?token={token} - have a look at the login service, it has 
been providing overloads and aux data for some time now, just to be able to do 
this.

 

6) Provides for hypergrid cross-login by providing both loginuri and target 
region as endpoint.


While we might not want to provide all these options in OpenSim, I think our 
approach has worked well for us and our clients.


Most of the code for these options are actually already out there in various 
scattered projects.


Best regards,
Stefan Andersson
Tribal Media AB



 


Date: Mon, 23 Feb 2009 14:31:25 -0800
From: d...@metaverseink.com
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] User Authentication

Right. The constraint here, let's not forget, is that we want to continue to 
reuse the LL viewer for a while.
I'm going to read that doc about OpenID tokens, but if it requires 
participation from the viewer, forget it... We are and will continue to be in 
LL Viewer hacking mode in the foreseeable future, abnd I want to make things 
safe before a better viewer comes along.

The bottom line question in my email, phrased in OpenID terminology, is whether 
we can use the Viewer's IP address as the token.


Tommi Laukkanen wrote: 

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

Re: [Opensim-dev] script states

[Melanie]

We have never made an incompatible change to the script states 
format. I fully intend to not break it.That said, it doesn't belong 
in a database, IMO. Database storage makes it so much harder to 
autoclean and maintain them.
Script crossing is already implemented and has been for a while. 
They get transferred properly in that case.

Personally, I think they're fine just where they are.

Melanie

Frisby, Adam wrote:
> Sim states can't be reliable preserved between updates at the moment, because 
> if we make any form of API change in the script engine, the states are 
> invalidated.
> 
> Regards
> 
> Adam
> 
> From: opensim-dev-boun...@lists.berlios.de 
> [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Ralf Haifisch
> Sent: Monday, 23 February 2009 12:30 AM
> To: opensim-dev@lists.berlios.de
> Subject: [Opensim-dev] script states
> 
> Hi all,
> 
> right now script states are kept in a directory "ScriptEngines".
> 
> Loosing script states is getting a little bit pain in the neck.  Some script 
> don´t start without a manual reset for unknown reasons, other scripts don´t 
> get on their feet again by design.  So you have always some people running 
> around playing with scripts after an update that looses script state.
> 
> If I update I am always somewhat unsure wether I should take this into new 
> version or not- thinking about consistency and compatibility.
> 
> Furthermore I have no clue, wether that will be the best place in future when 
> sometimes region crossing for scripts or wearing scripted attachments and 
> logoff / logon will happen.
> 
> 
> Would it be possible to move the script states to central, or at least the 
> region db ?
> 
> 
> Cheers,
> Ralf
> 
> 
> 
> 
> 
> ___
> 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] script states

[Frisby, Adam]

Is there a description of the format available somewhere?

> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Melanie
> Sent: Tuesday, 24 February 2009 3:10 AM
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] script states
>
> We have never made an incompatible change to the script states
> format. I fully intend to not break it.That said, it doesn't belong
> in a database, IMO. Database storage makes it so much harder to
> autoclean and maintain them.
> Script crossing is already implemented and has been for a while.
> They get transferred properly in that case.
>
> Personally, I think they're fine just where they are.
>
> Melanie
>
> Frisby, Adam wrote:
> > Sim states can't be reliable preserved between updates at the moment,
> because if we make any form of API change in the script engine, the
> states are invalidated.
> >
> > Regards
> >
> > Adam
> >
> > From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Ralf Haifisch
> > Sent: Monday, 23 February 2009 12:30 AM
> > To: opensim-dev@lists.berlios.de
> > Subject: [Opensim-dev] script states
> >
> > Hi all,
> >
> > right now script states are kept in a directory "ScriptEngines".
> >
> > Loosing script states is getting a little bit pain in the neck.  Some
> script don´t start without a manual reset for unknown reasons, other
> scripts don´t get on their feet again by design.  So you have always
> some people running around playing with scripts after an update that
> looses script state.
> >
> > If I update I am always somewhat unsure wether I should take this
> into new version or not- thinking about consistency and compatibility.
> >
> > Furthermore I have no clue, wether that will be the best place in
> future when sometimes region crossing for scripts or wearing scripted
> attachments and logoff / logon will happen.
> >
> >
> > Would it be possible to move the script states to central, or at
> least the region db ?
> >
> >
> > Cheers,
> > Ralf
> >
> >
> >
> > -
> ---
> >
> > ___
> > 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] On solving Authentication and such

[Stefan Andersson]

By the way,

 

I've been talking to some people lately around various viewer and protocol 
issues, and I have come to realize that we are apparently locked into the 
mindset of having the viewer being the 'community application' - I would 
propose another frame of mind, separating whatever should be done in 3D as a 
separate experience from what should be done in 2D. Of course, they should 
interleave, but they should not have to be implemented in the same codebase.

 

Huh? I hear you say.

 

To put it otherwise; the ideal setup would be a 3D rendering surface optionally 
with 2D web surfaces superimposed on it. From there, the 3D rendering surface 
should talk some real-time protocol to a 3D scene streaming service (aka the 
region server) but the 2D web surfaces should communicate with Web 2.0 services.

 

This would allow us to break the issues apart, and having various competencies 
working on various domains, as well as letting the application coders slice the 
cookie anyway they want.

 

So, what I'm saying is, in short: Let's start breaking stuff out of the viewer 
context, and onto other user interfaces, like the web or third-party admin 
tools.

 

I should have my preferred IM client, not my viewer.

 

I should have my (web-based?) inventory tool, not my viewer.

 

I should log in thru my social network, not my viewer.

 

I should transfer and administrate content thru aux means (web, file, blog, 
e-mail, ftp, burn) not trhu the viewer.

 

et c.

 

Sure, we should always be able to do it thru clients that provide adequate 
tools, but hey, let's break free of the centralized monolith app thinking.

 

Ps, what's the difference with having windows on top of each others in the 3D 
surface, and having windows on top of each others on the desktop?


Best regards,
Stefan Andersson
Tribal Media AB



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

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

[Dirk Krause]

+1 (actually more then 1, but then people will get suspicious :-) ).

Absolutely in favor of this.

-- Dirk/Bart


-Ursprüngliche Nachricht-
Von: opensim-dev-boun...@lists.berlios.de im Auftrag von Stefan Andersson
Gesendet: Di 24.02.2009 12:07
An: opensim-dev@lists.berlios.de
Betreff: [Opensim-dev] On solving Authentication and such
 

By the way,

 

I've been talking to some people lately around various viewer and protocol 
issues, and I have come to realize that we are apparently locked into the 
mindset of having the viewer being the 'community application' - I would 
propose another frame of mind, separating whatever should be done in 3D as a 
separate experience from what should be done in 2D. Of course, they should 
interleave, but they should not have to be implemented in the same codebase.

 

Huh? I hear you say.

 

To put it otherwise; the ideal setup would be a 3D rendering surface optionally 
with 2D web surfaces superimposed on it. From there, the 3D rendering surface 
should talk some real-time protocol to a 3D scene streaming service (aka the 
region server) but the 2D web surfaces should communicate with Web 2.0 services.

 

This would allow us to break the issues apart, and having various competencies 
working on various domains, as well as letting the application coders slice the 
cookie anyway they want.

 

So, what I'm saying is, in short: Let's start breaking stuff out of the viewer 
context, and onto other user interfaces, like the web or third-party admin 
tools.

 

I should have my preferred IM client, not my viewer.

 

I should have my (web-based?) inventory tool, not my viewer.

 

I should log in thru my social network, not my viewer.

 

I should transfer and administrate content thru aux means (web, file, blog, 
e-mail, ftp, burn) not trhu the viewer.

 

et c.

 

Sure, we should always be able to do it thru clients that provide adequate 
tools, but hey, let's break free of the centralized monolith app thinking.

 

Ps, what's the difference with having windows on top of each others in the 3D 
surface, and having windows on top of each others on the desktop?


Best regards,
Stefan Andersson
Tribal Media AB




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

Re: [Opensim-dev] 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] The Business Case for OpenSim

[Mike Pitman]

Colin,

While there are several commercial contributors to opensim, and several
businesses that rely on the emergence of opensim as a mature platform for
enterprise, I personally feel it is timely to chart a course for a
sustained development effort at a larger scale.

Some on those this list work with or for companies which have identified
opensim as a platform for business operations, and some are employees of
multinational tech companies that would like to see opensim as a key
platform for business solutions. Some are involved in research with
opesnim, some are focused on development, and still others try to do both
at once.

We've reached a point where a great deal of progress could be made toward
reliability and hardening for enterprise with a focused and funded group of
developers brought together for the mission.  Attracting that level of
investment does require a formal process that has yet to be applied. If you
have the interest and capability, it would not be too early to apply that
process to opensim.

Success in that endeavor could help all of the businesses that rely on the
emergence opensim.

-Mike

Michael C. Pitman, PhD
IBM Thomas J. Watson Research Center
E: pit...@us.ibm.com
SL: Rez Tone


   
 "Colin B. 
 Withers"  
"opensim-dev@lists.berlios.de"  
 Sent by:
 opensim-dev-bounc  cc
 e...@lists.berlios. 
 deSubject
   [Opensim-dev] The Business Case for
   OpenSim 
 02/24/2009 04:15  
 AM
   
   
 Please respond to 
 opensim-...@lists 
.berlios.de
   
   




Hi,

I have been thinking about writing a Business Case for OpenSim. A Business
Case is the feasibility study performed before a full Business Plan is
written, and is equally applicable to opensource 'products'.

If such a Case has not been written before, then I would be prepared to
write one, if the core developers would like one. But beware, it could be
quite tough.

As for credentials, I used to write business cases and business plans for
News Corporation.

Let me know,

Rock
MSc, MBA

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

[Impalah]

I think I didn't understand the proposal... or maybe yes.

You are proposing to separate 3D rendering code from 2D (windows and so on)
on the viewer to allow them to choose what rendering engine to use? +1 from
my part



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

Re: [Opensim-dev] [Opensim-commits] r8467 - trunk/OpenSim/Data/MySQL/Resources

[Sean Dague]

Justin Clark-Casey wrote:
> Sean,
> 
> This commit saw the number of tests drop from 268 to 261.  From looking at
> 
> http://www.opensimulator.org:8085/browse/OPENSIM-TRUNK-3300/log
> 
> it appears that the MySQLGridTest was excepting CreateRegionsTable to exist.
> 
> 
> 17-Feb-2009 11:12:40 [nunit2] Exception System.Exception: 
> Resource 'CreateRegionsTable.sql' was not found
> 17-Feb-2009 11:12:40 [nunit2]   at 
> OpenSim.Data.MySQL.MySQLManager.getResourceString (System.String name) 
> [0x0]
> 17-Feb-2009 11:12:40 [nunit2]   at 
> OpenSim.Data.MySQL.MySQLManager.ExecuteResourceSql (System.String name) 
> [0x0]
> 17-Feb-2009 11:12:40 [nunit2]   at 
> OpenSim.Data.MySQL.MySQLGridData.UpgradeRegionsTable (System.String 
> oldVersion) 
> [0x0]
> 17-Feb-2009 11:12:40 [nunit2]   at 
> OpenSim.Data.MySQL.MySQLGridData.TestTables (OpenSim.Data.Migration m) 
> [0x0]
> 17-Feb-2009 11:12:40 [nunit2]   at 
> OpenSim.Data.MySQL.MySQLGridData.Initialise (System.String connect) [0x0]
> 17-Feb-2009 11:12:40 [nunit2]   at 
> OpenSim.Data.MySQL.Tests.MySQLGridTest.Init () [0x0]
> 
> 
> Any thoughts on this?

Yeh, there was an oops, I fixed it the next day (and for some reason
only got this email today).

-Sean

-- 
Sean Dague / Neas Bade
sda...@gmail.com
http://dague.net




signature.asc
Description: OpenPGP digital signature
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] User Authentication

[Diva Canto]

You sneaky hacking devils! That's a great idea! I hadn't thought of that :-)

But does this solve the problem of malicious hosts taking over the 
user's identity? Unless you involve that meta-tool in agent transfers, 
I'm not seeing how.

Can you explain more?

Maybe it doesn't matter in your case, because the LL viewer can be 
stripped out of all power involving inventory and such? But how about 
actions involving objects already inworld that belong to the person?

Please say more...

Crista

Stefan Andersson wrote:

Dear colleagues;
 
for some time now, we at Tribal Media have employed an entirely 
different way of logging the viewer in, with tokens, that does not 
constitute changing the viewer.
 
What we do, is that we install a 'launcher' app on the users computer. 
It serves a number of purposes:
 
1) Installs rezzme, genesis and osurl url monikers, all of them taking 
tokens as auxiliary data - these monikers let people log onto web 
sites, and launch a viewer with a pre-authenticated token by a link. 
(see step 5)
 
2) Identifies installed viewers, and keep track of preferreed viewer.
 
3) Provides a pre-login login form to do non-web pre-launch 
authentication (in this case, this would probably be where the _form_ 
obtains the token to pass to step 5)
 
4) Launches pre-requisite software, as the TribalVoice.exe for when 
voice should be enabled, or a Proxy to divert certain packets.
 
5) Launched preferred user, with seamless login (using the login 
option of the ll viewer with dummy data to bypass the login screen) 
supplying the TOKEN in a tweaked LOGINURI - an example of this 
loginuri would be -loginuri http://{loginserver}/?token={token 
} - have a look at the login 
service, it has been providing overloads and aux data for some time 
now, just to be able to do this.
 
6) Provides for hypergrid cross-login by providing both loginuri and 
target region as endpoint.


While we might not want to provide all these options in OpenSim, I 
think our approach has worked well for us and our clients.


Most of the code for these options are actually already out there in 
various scattered projects.


Best regards,
Stefan Andersson
Tribal Media AB



 


Date: Mon, 23 Feb 2009 14:31:25 -0800
From: d...@metaverseink.com
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] User Authentication

Right. The constraint here, let's not forget, is that we want to 
continue to reuse the LL viewer for a while.
I'm going to read that doc about OpenID tokens, but if it requires 
participation from the viewer, forget it... We are and will continue 
to be in LL Viewer hacking mode in the foreseeable future, abnd I want 
to make things safe before a better viewer comes along.


The bottom line question in my email, phrased in OpenID terminology, 
is whether we can use the Viewer's IP address as the token.



Tommi Laukkanen wrote:

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
  





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


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

Re: [Opensim-dev] Opensim-dev Digest, Vol 18, Issue 127

[Ralf Haifisch]

Hi there,


At least usecases will be pretty important to show how to use opensim for
other stuff than gaming, while gaming and using it for a creative and
relaxing time are own usecases.

Some of them will develop to business cases.


To show, that opensim is mature enough and how to develop a solution to a
demand, based on opensim as a technology we started with a first Usecase on
http://www.rexdeveloper.org/wiki/index.php?title=UC-classroom-tactical-train
ing .

I expect to get 1 per 3 month period.

All this (from my side) will only be things, where real life companys are
interested to use this - and maybe even fund the needed development.

At least the usecases should deliver knowledge back to the community, and
where the commercial arrangement with the "customer" does allow - code
should be opend, as well.

I will have my first project meeting at the 6th of march and I am very happy
about the possibility to show opensim to an organization that is not just
100 people in size.


Cheers,
Ralf
--

Message: 2
Date: Tue, 24 Feb 2009 04:23:03 -0500
From: "Frisby, Adam" 
Subject: Re: [Opensim-dev] The Business Case for OpenSim
To: "opensim-dev@lists.berlios.de" 
Message-ID:
<63fad4f30a4ea79de9e8be664735056d2...@winxbeus19.exchange.xchg>
Content-Type: text/plain; charset="us-ascii"

You are going to have fun with this one. There's probably at least a hundred
separate ones, depending on who you ask.

OpenSim has a lot of commercial contributions, a lot of which are biased
towards particular features that their implementations need. Our goal has
been to create a platform flexible enough that we can accommodate all these
together while still sharing enough 'common ground'.

Adam

From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Colin B. Withers
Sent: Tuesday, 24 February 2009 1:15 AM
To: opensim-dev@lists.berlios.de
Subject: [Opensim-dev] The Business Case for OpenSim

Hi,

I have been thinking about writing a Business Case for OpenSim. A Business
Case is the feasibility study performed before a full Business Plan is
written, and is equally applicable to opensource 'products'.

If such a Case has not been written before, then I would be prepared to
write one, if the core developers would like one. But beware, it could be
quite tough.

As for credentials, I used to write business cases and business plans for
News Corporation.

Let me know,

Rock
MSc, MBA


-- next part --
An HTML attachment was scrubbed...
URL:
https://lists.berlios.de/pipermail/opensim-dev/attachments/20090224/876401e5
/attachment-0001.html 

--

Message: 3
Date: Tue, 24 Feb 2009 10:58:58 +0100
From: Stefan Andersson 
Subject: Re: [Opensim-dev] User Authentication
To: "opensim-dev@lists.berlios.de" 
Message-ID: 
Content-Type: text/plain; charset="iso-8859-1"


Dear colleagues;

 

for some time now, we at Tribal Media have employed an entirely different
way of logging the viewer in, with tokens, that does not constitute changing
the viewer.

 

What we do, is that we install a 'launcher' app on the users computer. It
serves a number of purposes:

 

1) Installs rezzme, genesis and osurl url monikers, all of them taking
tokens as auxiliary data - these monikers let people log onto web sites, and
launch a viewer with a pre-authenticated token by a link. (see step 5)

 

2) Identifies installed viewers, and keep track of preferreed viewer.

 

3) Provides a pre-login login form to do non-web pre-launch authentication
(in this case, this would probably be where the _form_ obtains the token to
pass to step 5)

 

4) Launches pre-requisite software, as the TribalVoice.exe for when voice
should be enabled, or a Proxy to divert certain packets.

 

5) Launched preferred user, with seamless login (using the login option of
the ll viewer with dummy data to bypass the login screen) supplying the
TOKEN in a tweaked LOGINURI - an example of this loginuri would be -loginuri
http://{loginserver}/?token={token} - have a look at the login service, it
has been providing overloads and aux data for some time now, just to be able
to do this.

 

6) Provides for hypergrid cross-login by providing both loginuri and target
region as endpoint.


While we might not want to provide all these options in OpenSim, I think our
approach has worked well for us and our clients.


Most of the code for these options are actually already out there in various
scattered projects.


Best regards,
Stefan Andersson
Tribal Media AB



 


Date: Mon, 23 Feb 2009 14:31:25 -0800
From: d...@metaverseink.com
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] User Authentication

Right. The constraint here, let's not forget, is that we want to continue to
reuse the LL viewer for a while.
I'm going to read that doc about OpenID tok

Re: [Opensim-dev] User Authentication

[Diva Canto]

The OpenID service was introduced back in early January if I'm not 
mistaken, a patch from JHurliman. It runs on all User Servers out there 
that are updated, not just osgrid and ucigrid. If you have a UGAIM, you 
have this. Try it.


Dirk Krause wrote:


I indeed didn't know that, thanks a bunch for pointing it out. Like 
Mark I also would be interested on how this was achieved?


 


-- Dirk/Bart

 

PS: Since it seems that the whole proposed OpenID strategy will only 
work for Charles, I better order a t-shirt with 'I AM CHARLES KRINKE' 
printed on it.


 

*Von:* opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] *Im Auftrag von *Diva Canto

*Gesendet:* Dienstag, 24. Februar 2009 02:06
*An:* opensim-dev@lists.berlios.de
*Betreff:* Re: [Opensim-dev] User Authentication

 


Mark Malewski wrote:

Just to clarify...

 

/*> Grids could provide openIDs in the form of 
"*//*openid.osgrid.org/users/screenname*/ 
/*"*/


 

With all grids being independent of one another, or in the example 
given by John, maybe use an "openid.osgrid.org/users/screenname 
"


 


http://openid.osgrid.org/users/Charles_Krinke

 


For those of you who don't know, this already exists. Click this:
http://osgrid.org:8002/users/charles_krinke
or this:
http://ucigrid00.nacs.uci.edu:8002/users/crista_lopes


Again, in this example Charles happens to have his identity at OSGrid, 
but that's not a requirement of the exchange. It could just as easily 
been an identity from another grid.


 

This way various grids could all run "openID" servers, and trust 
agreements would need to be established between the various grids.


I'm not going to act on anything that suggests "trust agreements 
between various grids." That's an AWG concept that I very much 
disagree with, and want no part in. I have no problem with companies 
cutting corners on security in order to be able to exchange agents on 
a lawyer-backed up trust basis. But that's not what I'm doing here, 
and that's not what a lot of people want OpenSim to be.


The goal is to be able to go from my home standalone to *any* sim out 
there that I know nothing about, and still be sure that nothing bad 
will happen to my belongings. Anything less than this is not 
acceptable as a goal, for me.


Crista



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


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

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

[Gustavo Alberto Navarro Bilbao]

If that is the proposal, +1 from me too. to can choose a rendering
engine like OGRE/COLLADA allow a significant improvement in the
client.

2009/2/24 Impalah :
> I think I didn't understand the proposal... or maybe yes.
>
> You are proposing to separate 3D rendering code from 2D (windows and so on)
> on the viewer to allow them to choose what rendering engine to use? +1 from
> my part
>
>
>
> 2009/2/24 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
>>
>
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

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

[Diva Canto]

I think the proposal is exactly the opposite, at least for the time 
being. That is, let's use whatever the LL viewer already has for 3D 
rendering, and let's move the non-3D features out onto Web applications.



Gustavo Alberto Navarro Bilbao wrote:

If that is the proposal, +1 from me too. to can choose a rendering
engine like OGRE/COLLADA allow a significant improvement in the
client.

2009/2/24 Impalah :
  

I think I didn't understand the proposal... or maybe yes.

You are proposing to separate 3D rendering code from 2D (windows and so on)
on the viewer to allow them to choose what rendering engine to use? +1 from
my part



2009/2/24 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

  

___
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] On solving Authentication and such

[Diva Canto]

There's a fine line to draw here, and if we go too far the immersion 
feeling will be affected. So the difficult thing in this approach will 
be to draw that line. It would be an interesting academic exercise to 
pull out ALL the features from the viewer except its 3D rendering 
engine-ness.


I started writing down an attempt at categorizing this, but I realized 
that we will never get consensus on the feeling of immersion. Our best 
option, on the OpenSim side, is to make it configurable at the services 
level and to leave it to the world builders to choose which features 
they want to serve via the 3D rendering engine viewer. The tradeoff 
being, the more features they allow the LL viewer to do, the less safely 
interoperable things will be because the LL viewer proxies things 
through the regions, therefore assuming the regions are to be trusted. 
In cases of worlds that don't want interoperability of any kind, or 
worlds that simply want the "trust domains" a-la Linden Lab, that is 
fine. For everything else (Hypergrid), regions are not to be trusted in 
general, and those extra 2D interfaces can be used instead.


The good thing is that if we do that separation, it shouldn't be hard 
for the Hippo devs, for example, to chop down the monolithic application 
and start integrating other more secure components.


In any case, here's a slightly more extended list of features to think 
about:


- Inventory
- Social network (groups, friends, etc)
- Admin tasks (estate/region/parcel permissions, bans, etc)
- Search
- IM
- Map
- Teleports
- Script editing
- Inter-user inworld interaction (inventory exchanges)
- ...

Stefan Andersson wrote:

By the way,
 
I've been talking to some people lately around various viewer and 
protocol issues, and I have come to realize that we are apparently 
locked into the mindset of having the viewer being the 'community 
application' - I would propose another frame of mind, separating 
whatever should be done in 3D as a separate experience from what 
should be done in 2D. Of course, they should interleave, but they 
should not have to be implemented in the same codebase.
 
Huh? I hear you say.
 
To put it otherwise; the ideal setup would be a 3D rendering 
surface optionally with 2D web surfaces superimposed on it. From 
there, the 3D rendering surface should talk some real-time protocol to 
a 3D scene streaming service (aka the region server) but the 2D web 
surfaces should communicate with Web 2.0 services.
 
This would allow us to break the issues apart, and having various 
competencies working on various domains, as well as letting the 
application coders slice the cookie anyway they want.
 
So, what I'm saying is, in short: Let's start breaking stuff out of 
the viewer context, and onto other user interfaces, like the web or 
third-party admin tools.
 
I should have my preferred IM client, not my viewer.
 
I should have my (web-based?) inventory tool, not my viewer.
 
I should log in thru my social network, not my viewer.
 
I should transfer and administrate content thru aux means (web, file, 
blog, e-mail, ftp, burn) not trhu the viewer.
 
et c.
 
Sure, we should always be able to do it thru clients that 
provide adequate tools, but hey, let's break free of the centralized 
monolith app thinking.
 
Ps, what's the difference with having windows on top of each others in 
the 3D surface, and having windows on top of each others on the desktop?


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] script states

[Ralf Haifisch]

Heho,

that means:

just update those "update howtos" to include the / ScriptEngines , as well -
right ?

I have to recheck, but my last memory was, that if I e.g. teleport - my
personal teleport device (worn as a attachment) needed to be resetet.

Would that be an error, in that case ?


Cheers,
Ralf
--

Message: 4
Date: Tue, 24 Feb 2009 11:10:18 +
From: Melanie 
Subject: Re: [Opensim-dev] script states
To: opensim-dev@lists.berlios.de
Message-ID: <49a3d59a.1080...@t-data.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

We have never made an incompatible change to the script states 
format. I fully intend to not break it.That said, it doesn't belong 
in a database, IMO. Database storage makes it so much harder to 
autoclean and maintain them.
Script crossing is already implemented and has been for a while. 
They get transferred properly in that case.

Personally, I think they're fine just where they are.

Melanie

Frisby, Adam wrote:
> Sim states can't be reliable preserved between updates at the moment,
because if we make any form of API change in the script engine, the states
are invalidated.
> 
> Regards
> 
> Adam
> 
> From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Ralf Haifisch
> Sent: Monday, 23 February 2009 12:30 AM
> To: opensim-dev@lists.berlios.de
> Subject: [Opensim-dev] script states
> 
> Hi all,
> 
> right now script states are kept in a directory "ScriptEngines".
> 
> Loosing script states is getting a little bit pain in the neck.  Some
script don?t start without a manual reset for unknown reasons, other scripts
don?t get on their feet again by design.  So you have always some people
running around playing with scripts after an update that looses script
state.
> 
> If I update I am always somewhat unsure wether I should take this into new
version or not- thinking about consistency and compatibility.
> 
> Furthermore I have no clue, wether that will be the best place in future
when sometimes region crossing for scripts or wearing scripted attachments
and logoff / logon will happen.
> 
> 
> Would it be possible to move the script states to central, or at least the
region db ?
> 
> 
> Cheers,
> Ralf
> 
> 
> 
> 
> 
> ___
> 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


End of Opensim-dev Digest, Vol 18, Issue 127


___
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

[Hurliman, John]

Definitely a +1.

(only slightly on-topic) Speaking of 2D and 3D worlds: 
http://www.youtube.com/watch?v=wT1UR6qEgdg

>-Original Message-
>From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
>boun...@lists.berlios.de] On Behalf Of Stefan Andersson
>Sent: Tuesday, February 24, 2009 3:07 AM
>To: opensim-dev@lists.berlios.de
>Subject: [Opensim-dev] On solving Authentication and such
>
>By the way,
>
>I've been talking to some people lately around various viewer and
>protocol issues, and I have come to realize that we are apparently
>locked into the mindset of having the viewer being the 'community
>application' - I would propose another frame of mind, separating
>whatever should be done in 3D as a separate experience from what should
>be done in 2D. Of course, they should interleave, but they should not
>have to be implemented in the same codebase.
>
>Huh? I hear you say.
>
>To put it otherwise; the ideal setup would be a 3D rendering surface
>optionally with 2D web surfaces superimposed on it. From there, the 3D
>rendering surface should talk some real-time protocol to a 3D scene
>streaming service (aka the region server) but the 2D web surfaces should
>communicate with Web 2.0 services.
>
>This would allow us to break the issues apart, and having various
>competencies working on various domains, as well as letting the
>application coders slice the cookie anyway they want.
>
>So, what I'm saying is, in short: Let's start breaking stuff out of the
>viewer context, and onto other user interfaces, like the web or third-
>party admin tools.
>
>I should have my preferred IM client, not my viewer.
>
>I should have my (web-based?) inventory tool, not my viewer.
>
>I should log in thru my social network, not my viewer.
>
>I should transfer and administrate content thru aux means (web, file,
>blog, e-mail, ftp, burn) not trhu the viewer.
>
>et c.
>
>Sure, we should always be able to do it thru clients that provide
>adequate tools, but hey, let's break free of the centralized monolith
>app thinking.
>
>Ps, what's the difference with having windows on top of each others in
>the 3D surface, and having windows on top of each others on the desktop?
>
>Best regards,
>Stefan Andersson
>Tribal Media AB
>
>
>

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

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

[Hurliman, John]

Tommi, you are a programming powerhouse! This is great stuff.

>-Original Message-
>From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
>boun...@lists.berlios.de] On Behalf Of Tommi Laukkanen
>Sent: Tuesday, February 24, 2009 5:13 AM
>To: opensim-dev@lists.berlios.de
>Subject: [Opensim-dev] MXP and Google Protocol Buffers
>
>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] 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

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

[Mike Mazur]

Hi,

On Tue, 24 Feb 2009 09:45:27 -0800
Diva Canto  wrote:

> I think the proposal is exactly the opposite, at least for the time 
> being. That is, let's use whatever the LL viewer already has for 3D 
> rendering, and let's move the non-3D features out onto Web
> applications.

The way I understood the proposal is to separate out the 3D and 2D
functionality at all(?) levels.

This means that the server will provide one client stack implementing
one protocol that deals only with 3D information. Avatar movement,
scene description, agent updates, prim updates, etc. The viewer speaks
this protocol in order to display to the user what is happening in the
3D world. This makes it possible to write a client that is only capable
of viewing the world and doesn't care about inventory. The protocol
could be, for example, the LLUDP protocol.

The inherently 2D features, such as chat or inventory, can use another
protocol. The server will provide a different client stack that deals
only with the 2D feature(s). The viewer also implements this protocol to
provide these additional services to the user. This 2D information can
then be overlaid over the 3D rendering of the world. This allows to
write clients that manipulate this data only, like inventory managers,
asset browsers, chat-only clients, etc. The protocol used here could be
HTTP.

This separation of protocols for all the different ways a user
interacts with the virtual world sounds like a Good Thing (tm) to me.

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

[Charles Krinke]

I would concur. I can certainly see this idea expediting PDA and cell phone 
group and IM communication into the Metaverse. This seems like an entirely 
reasonable additional use case as we evolve.

Charles



From: Mike Mazur 
To: opensim-dev@lists.berlios.de
Sent: Tuesday, February 24, 2009 4:06:04 PM
Subject: Re: [Opensim-dev] On solving Authentication and such

Hi,

On Tue, 24 Feb 2009 09:45:27 -0800
Diva Canto  wrote:

> I think the proposal is exactly the opposite, at least for the time 
> being. That is, let's use whatever the LL viewer already has for 3D 
> rendering, and let's move the non-3D features out onto Web
> applications.

The way I understood the proposal is to separate out the 3D and 2D
functionality at all(?) levels.

This means that the server will provide one client stack implementing
one protocol that deals only with 3D information. Avatar movement,
scene description, agent updates, prim updates, etc. The viewer speaks
this protocol in order to display to the user what is happening in the
3D world. This makes it possible to write a client that is only capable
of viewing the world and doesn't care about inventory. The protocol
could be, for example, the LLUDP protocol.

The inherently 2D features, such as chat or inventory, can use another
protocol. The server will provide a different client stack that deals
only with the 2D feature(s). The viewer also implements this protocol to
provide these additional services to the user. This 2D information can
then be overlaid over the 3D rendering of the world. This allows to
write clients that manipulate this data only, like inventory managers,
asset browsers, chat-only clients, etc. The protocol used here could be
HTTP.

This separation of protocols for all the different ways a user
interacts with the virtual world sounds like a Good Thing (tm) to me.

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] On solving Authentication and such

[Dahlia Trimble]

+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1

On Tue, Feb 24, 2009 at 3:07 AM, Stefan Andersson wrote:

>  By the way,
>
> I've been talking to some people lately around various viewer and protocol
> issues, and I have come to realize that we are apparently locked into the
> mindset of having the viewer being the 'community application' - I would
> propose another frame of mind, separating whatever should be done in 3D as a
> separate experience from what should be done in 2D. Of course, they should
> interleave, but they should not have to be implemented in the same codebase.
>
> Huh? I hear you say.
>
> To put it otherwise; the ideal setup would be a 3D rendering
> surface optionally with 2D web surfaces superimposed on it. From there, the
> 3D rendering surface should talk some real-time protocol to a 3D scene
> streaming service (aka the region server) but the 2D web surfaces should
> communicate with Web 2.0 services.
>
> This would allow us to break the issues apart, and having various
> competencies working on various domains, as well as letting the application
> coders slice the cookie anyway they want.
>
> So, what I'm saying is, in short: Let's start breaking stuff out of the
> viewer context, and onto other user interfaces, like the web or third-party
> admin tools.
>
> I should have my preferred IM client, not my viewer.
>
> I should have my (web-based?) inventory tool, not my viewer.
>
> I should log in thru my social network, not my viewer.
>
> I should transfer and administrate content thru aux means (web, file, blog,
> e-mail, ftp, burn) not trhu the viewer.
>
> et c.
>
> Sure, we should always be able to do it thru clients that provide adequate
> tools, but hey, let's break free of the centralized monolith app thinking.
>
> Ps, what's the difference with having windows on top of each others in the
> 3D surface, and having windows on top of each others on the desktop?
>
> 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] User Authentication

[Diva Canto]

Thanks for all these ideas. As usual, talking throws everything up in 
the air, then it's up to whoever wants to act to pick up the interesting 
bits. Here's my summary and proposed action items.

User authentication / security is a critical thing in interoperability, 
and it requires a serious commitment from that cloudy component called 
"the viewer". Given the background of this project, we have 3 options:
a) reuse the LL Viewer as-is and hack the heck of out it;
b) write a new viewer designed for open VW systems from the onset;
c) use what we can from the LL Viewer and move the [security-critical] 
1D and 2D components out to more secure, possibly standard, clients 
which can then be accessed either through a regular Web browser or 
through the embedded browser;

As Stefan put it to me, we, as a community, need to do all of the above 
at the same time :-)
Option b), however, is the least actionable as a strategy, unless 
someone is willing to invest a lot of time/money. And even then... it's 
probably a better idea to do c) first.

So here's my plan, as user authentication and security goes:

* Within a few days: write a simple [optional] UserAuthenticationModule 
along the lines of option a) that does the following: upon a 
NewUserConnection, regions will check with the incoming user's User 
server that the declared user exists and is logged into the system. 
Furthermore, upon AddNewClient (which happens shortly after), regions 
will challenge the incoming client with 3 UDP Ping messages having 
random seq numbers, to which the incoming client must respond correctly 
(look at it as the Bridge of Death in Monty Python and the Holy Grail). 
This will prevent spoofing and other kinds of false impersonations to 
which OpenSim is vulnerable right now. This Authentication module will 
likely go away as we rethink the whole thing seriously around option c). 
But it will be a good exercise around the topic of authentication, while 
making things more secure right now.

* Within the next month: write wrapper modules around inventory and 
Scene.Inventory to implement the concept of the Suitcase. That is, at 
"home" (a concept which can be extended to many regions) the user can 
access inventory via the LL Viewer as normal; outside those regions, the 
user can only access a few folders. This is a simple idea whose 
implementation will require a serious incursion into option a), the art 
of hackery. But the good thing is that this general idea will also serve 
option c) well: once we have a web interface to the user's inventory, 
the user will be able to safely access the entirety of her inventory no 
matter where she is, via the embedded web browser. The Suitcase 
folder(s) can still be accessed via the LL Viewer, for convenience. So 
the user can do things like this: "Oh, shoot, I forgot to pack that 
object that I want to give you. Hold on.   There you have it."

So, not the grand vision yet; just small feasible steps towards it.

Comments?

Crista


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

Re: [Opensim-dev] User Authentication

[Mike Mazur]

Hi,

On Tue, 24 Feb 2009 19:54:16 -0800
Diva Canto  wrote:

> * Within a few days: write a simple [optional]
> UserAuthenticationModule along the lines of option a) that does the
> following: upon a NewUserConnection, regions will check with the
> incoming user's User server that the declared user exists and is
> logged into the system.

In a grid a region can be told (via a configuration option) which user
server to check. What about HG regions? How does an HG region know
which user server to ping? Is this information supplied by the
connecting client? If so, what's to prevent a malicious client from
supplying a user server that will always reply favorably?

> Furthermore, upon AddNewClient (which happens
> shortly after), regions will challenge the incoming client with 3 UDP
> Ping messages having random seq numbers, to which the incoming client
> must respond correctly

How does the client know the correct response?

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

Re: [Opensim-dev] User Authentication

[Diva Canto]

 Mike Mazur wrote:

Hi,

On Tue, 24 Feb 2009 19:54:16 -0800
Diva Canto  wrote:

  

* Within a few days: write a simple [optional]
UserAuthenticationModule along the lines of option a) that does the
following: upon a NewUserConnection, regions will check with the
incoming user's User server that the declared user exists and is
logged into the system.



In a grid a region can be told (via a configuration option) which user
server to check. What about HG regions? How does an HG region know
which user server to ping? Is this information supplied by the
connecting client? If so, what's to prevent a malicious client from
supplying a user server that will always reply favorably?
  
The HG region sends that information along when the user moves away from 
the home UGAIM. The user carries along the collection of URLs of all of 
the servers it uses. It's ok if the given User Server @ foobar.com 
always says yes -- that's not the problem. The problem we need to detect 
is the user claiming to be from Intel.com or OSGrid.org, when, in fact, 
isn't.



Furthermore, upon AddNewClient (which happens
shortly after), regions will challenge the incoming client with 3 UDP
Ping messages having random seq numbers, to which the incoming client
must respond correctly



How does the client know the correct response?
  
In fiddling with the client after talking to Teravus, I discovered a 
pair of response-reply packets that can be initiated from the server. 
They are StartPingCheck / CompletePingCheck. They take a byte as 
argument. The server sends StartPingCheck(33), the client responds with 
CompletePingCheck(33). Handy.



___
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

[Mister Blue]

Definitely a +1.

If one is using a 3d system like Ogre, you could use webkit to display
on the 'overlay' surfaces (Ogre has this concept of transparent
overlays over the 3d view). Even the interface to the viewer proper
could be all web pages and AJAX goop. Then any web page -- any
interface to server, simulator, user service, status display, ... --
could be made part of the user interface by spinning up an overlay
containing that web page.

The immersion issue is a concern and any interface design should take
that into account. That doesn't mean that the existing chat client
chat window could not equivalently be implemented with HTTP/JS/CSS and
a connection to a different chat service.

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

[Toni Alatalo]

First, a big + the separation of concerns. Then some brief remarks and 
comments:

Mike Mazur kirjoitti:
> This means that the server will provide one client stack implementing
> one protocol that deals only with 3D information. Avatar movement,
> scene description, agent updates, prim updates, etc. The viewer speaks
> this protocol in order to display to the user what is happening in the
> 3D world. This makes it possible to write a client that is only capable
> of viewing the world and doesn't care about inventory. The protocol
> could be, for example, the LLUDP protocol.
>   

That is BTW exactly the plan in the RexNG viewer effort now: implement a 
minimal set of LLUDP for the client to get the world, and leave out all 
the IM, social networking, commerce etc. related parts of the SL 
protocol, as the idea is to use other existing things for those (xmpp 
etc). And possibly switch away from LLUDP later if it seems to make 
sense, the experiments with MXP now are interesting (i started testing 
adding support to that to openviewer btw to learn more, dunno if will 
have time to complete that soon but we'll see).

So I guess a part of the plan is to facilitate that on the server side 
too, AFAIK that part hasn't been examined more closely in Rex work yet 
(apart from doing modrex and hence getting experience with dealing with 
client views etc). But if the core etc. would be refactored as needed in 
Opensim in general to support using such a minimal set nicely I think 
it'd also benefit the Rex effort directly.

> The inherently 2D features, such as chat or inventory, can use another
> protocol. The server will provide a different client stack that deals
> only with the 2D feature(s). The viewer also implements this protocol to
>   

A remark on the concepts: There is nothing 'inherently 2d' about those. 
They are information that can be represented in many ways. Some GUI may 
use a 2d widget to show them, some other may feature 2,5d or 3d UIs to 
e.g. deal with inventory, and for e.g. blind people you can have chat 
and inventory as audio.

> provide these additional services to the user. This 2D information can
> then be overlaid over the 3D rendering of the world. This allows to
>   

Or some other client implementation may come up with interesting ways to 
integrate them to inworld. In fact the idea that the other GUIs would 
disappear, and the VW itself would be the interface for all services: 
e.g. google searches, making notes, planning an API,  .. but not via 
putting rendered html pages as images to planes, but having the 
structures of the world itself be the information, services and tools -- 
that's what sometimes intriques me most as a long-term thing (and this 
is just my private thinking based on good experiences from earlier 
research systems, can point to them elsewhere if someone's interested).

Back to short term concrete plans, with Rex the plan is exactly that - 
overlay traditional GUI things on top of the Ogre scene (like openviewer 
and idealist do too).

But yes, I'd also think that such separation would make sense - 
especially because there are many possible and I'd bet yet unknown ways 
to mix&match these different features. Like someone said, let's do 
components and let the world decide about the configurations. And indeed 
a specific client may be interested in a single feature, and doing that 
powerfully (e.g. inventory management).

> Mike

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

Re: [Opensim-dev] Thoughts on performance with a profiler

[Melanie]

Hi,

Frisby, Adam wrote:
> -  SceneGraph.Get* methods are generally very wasteful. Lots of them 
> use the /slow/ GetEntities method to build a list of entities before 
> searching them. This is particularly noticeable on the GetGroupByPrim(UUID) 
> method. EntityManager should be having indexes for these frequently accessed 
> items.

I thought some one (justin?) worked on that with the goal of adding 
indexes/making it a dict.

> -  Why, to send a primitive do we need to: - Mark it for updates. - 
> Crawl through the Entities list for updates - Send updates to ClientViews, 
> when we could just Send the update directly to viewers 
> (EventManager.TriggerOnPrimUpdated[?])?

Because it would happen in the wrong thread context, maybe?

> -  Why does Scene.Heartbeat/Update do more than just updating 
> frame-dependent things? Eg, why not keep Update to just: Update Physics, 
> Process Scripts[?], etc. Out of it we move: Backup (timer?), Land update 
> (when something happens+ timer?), Terrain backup (main backup thread?)

Scripts don't run in update, although movement events are generated 
there.

> -  Why build X copies of the same packet for fifteen separate 
> clients? Why not re-use the update packet and change the agent IDs? Maybe 
> some kind of 'PacketMaster' could be developed for each ClientView type which 
> allows us to do 'bulk' operations like this.

Because of the sequence numbers. They are different for each client.

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

Re: [Opensim-dev] script states

[Melanie]

+1 on the console command, That could be helpful and is pretty 
trivial to do.

Melanie

Sacha Magne wrote:
> i would suggest to recompile all the scripts after an update.
> There is an option in the ini for that, something like "compile on startup".
> Maybe we could implement a console based command like "recompile all" ?
> 
> 
> Sm
> 
> On Mon, Feb 23, 2009 at 9:54 AM, Frisby, Adam  wrote:
> 
>>  Sim states can't be reliable preserved between updates at the moment,
>> because if we make any form of API change in the script engine, the states
>> are invalidated.
>>
>>
>>
>> Regards
>>
>>
>>
>> Adam
>>
>>
>>
>> *From:* opensim-dev-boun...@lists.berlios.de [mailto:
>> opensim-dev-boun...@lists.berlios.de] *On Behalf Of *Ralf Haifisch
>> *Sent:* Monday, 23 February 2009 12:30 AM
>> *To:* opensim-dev@lists.berlios.de
>> *Subject:* [Opensim-dev] script states
>>
>>
>>
>> Hi all,
>>
>>
>>
>> right now script states are kept in a directory "ScriptEngines".
>>
>>
>>
>> Loosing script states is getting a little bit pain in the neck.  Some
>> script don´t start without a manual reset for unknown reasons, other scripts
>> don´t get on their feet again by design.  So you have always some people
>> running around playing with scripts after an update that looses script
>> state.
>>
>>
>>
>> If I update I am always somewhat unsure wether I should take this into new
>> version or not- thinking about consistency and compatibility.
>>
>>
>>
>> Furthermore I have no clue, wether that will be the best place in future
>> when sometimes region crossing for scripts or wearing scripted attachments
>> and logoff / logon will happen.
>>
>>
>>
>>
>>
>> Would it be possible to move the script states to central, or at least the
>> region db ?
>>
>>
>>
>>
>>
>> Cheers,
>>
>> Ralf
>>
>> ___
>> 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