Re: [ogpx] Tourist use case
Morgaine <morgaine.dinova@googlemail.com> Fri, 30 October 2009 07:29 UTC
Return-Path: <morgaine.dinova@googlemail.com>
X-Original-To: ogpx@core3.amsl.com
Delivered-To: ogpx@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix)
with ESMTP id A790C3A694D for <ogpx@core3.amsl.com>;
Fri, 30 Oct 2009 00:29:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.624
X-Spam-Level:
X-Spam-Status: No, score=-1.624 tagged_above=-999 required=5 tests=[AWL=0.352,
BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com
[127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBPkskufw7QD for
<ogpx@core3.amsl.com>; Fri, 30 Oct 2009 00:29:31 -0700 (PDT)
Received: from mail-ew0-f209.google.com (mail-ew0-f209.google.com
[209.85.219.209]) by core3.amsl.com (Postfix) with ESMTP id A5A1F3A69D9 for
<ogpx@ietf.org>; Fri, 30 Oct 2009 00:29:30 -0700 (PDT)
Received: by ewy5 with SMTP id 5so755252ewy.37 for <ogpx@ietf.org>;
Fri, 30 Oct 2009 00:29:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma;
h=domainkey-signature:mime-version:received:in-reply-to:references
:date:message-id:subject:from:to:content-type;
bh=RSVqnnUDUH9CZDJfXQ1Jtz29QGbcRWeD6zC/YeBSb3c=;
b=Zdhn16IZuwZ+L5QkBAxGCp+5iGtuiN5HauY62TRaO5tbprGZruZULw7pAus7y40Arj
GIcunEeuUDR4m6cougkSynjIAh6iZO2WckK8Mc37MemujE6JeIBRPFZggq32V5nJSpbR
ay3KKih+h865g5Va89enhjidR9xZGMahyodWM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type;
b=jNT7ZlFhgraFqPUlXAe/s01zHgPg/PXbIQ7nWoand2HmMlvD+YY8iWgzCzoelsD/Gl
avXIAJ2NdlSEWIbaDuHJ+zIrx4sLsWcAwcUc2K9eKa25OZYh7sguKoZleF9QlX+QTLLe
ps4y00kmDPSII0qbaTuPtfWlPNIUUrQO8Vq0o=
MIME-Version: 1.0
Received: by 10.216.87.197 with SMTP id y47mr428884wee.202.1256887784336;
Fri, 30 Oct 2009 00:29:44 -0700 (PDT)
In-Reply-To: <20091029134353.GB2298@alinoe.com>
References: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com>
<3a880e2c0910160116g7a7e488fpe03b10d9b534aa35@mail.gmail.com>
<9b8a8de40910160635j268ef9c9mae55781221c94d7e@mail.gmail.com>
<20091029134353.GB2298@alinoe.com>
Date: Fri, 30 Oct 2009 07:29:44 +0000
Message-ID: <e0b04bba0910300029jd385ea7s1ab66a6d67b084d4@mail.gmail.com>
From: Morgaine <morgaine.dinova@googlemail.com>
To: ogpx@ietf.org
Content-Type: multipart/alternative; boundary=0016e6d63ffbe86d11047721fd77
Subject: Re: [ogpx] Tourist use case
X-BeenThere: ogpx@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual Worlds and the Open Grid Protocol <ogpx.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ogpx>,
<mailto:ogpx-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ogpx>
List-Post: <mailto:ogpx@ietf.org>
List-Help: <mailto:ogpx-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ogpx>,
<mailto:ogpx-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Oct 2009 07:29:32 -0000
On Thu, Oct 29, 2009 at 1:43 PM, Carlo Wood <carlo@alinoe.com> wrote: > > As a result, people will find the path of least resistance where apparently > two demands can be conflicting: > > 1) Being able to TP to that other destination > 2) Being able to access ones inventory > > Personally I feel not very confident that the combination of both is > going to work anywhere satisfactory given the intentions shown so far; > therefore I think it will be very important to have the possibility of > separate asset services. > Very true. This is of course why we headed down the path of giving RDs control over their own region policies, reinforced by David's observation that ADs could not impose non-local policies even if they wished. ADs won't exercise control over region policies anyway but stick to agent policies alone, according to previous discussions, so the assets present in a region are of no concern to the AD at all. This directly implies that asset services must be quite separate from ADs. Although we haven't spelled it out, clients must have access to an arbitrary list of asset services, because as agents travel around the VWRAP-compatible metaverse, the regions they visit will contain objects from an arbitrary number of asset service providers. *Without access to these asset services, the visited regions would not be visualizable at all. And denying visualization is no business of the AD's. * This makes it clear that access to asset services should not be mediated by the AD at all --- the AD's role should be limited to allowing or denying entrance to a region. Once inside a region, it is the region that offers capabilities for access to the asset services of assets within the region. > > Suddenly I see a glimpse of light: why can't it be possible to run > my OWN (personal!) inventory? Surely nobody is going to forbid me to > put FULL-PERM stuff in it? And even more surely nobody is going to > stop others from accessing my inventory when I use it (ie, to see > my attachments; or to see what I just rezzed). > > I'd be very happy with my own personal inventory, even if on some > worlds they only allow me to put 'full perm' stuff in it. At least > I'll know what I can use everywhere: if I can put it in my inventory, > I will have it at my disposal everywhere. > I think it's quite clear that SL's single-world / single asset service / single inventory model is not appropriate to the needs of VWRAP. As you suggest, an agent's inventory needs have very little to do with the asset service of the single world in which the agent is registered. It's very difficult to extrapolate from that monolithic model to a multi-world setting. > > Dream or not, this is definitely not going to happen if VWRAP > demands that the asset service is part of the agent service. > Indeed, but fortunately it hasn't been proposed that asset services be part of the agent service in VWRAP. The legacy SL model of assets and inventories clearly doesn't apply in our extended scenarios, and the OGP documents never covered asset services at all, so we're defining the asset services and inventory model of VWRAP as we speak. :-) Morgaine. ====================================== On Thu, Oct 29, 2009 at 1:43 PM, Carlo Wood <carlo@alinoe.com> wrote: > On Fri, Oct 16, 2009 at 03:35:57PM +0200, Vaughn Deluca wrote: > > Especially since there is nothing to prevent a configuration that works > exactly > > as the current SL use case. So nothing has to be sacrificed, yet a much > richer > > set of deployment patterns becomes possible. > > > > -Vaughn > > +1 > > > I think that as soon as a user runs into "sorry, can't do-- because we > don't > trust this or that service", they will be ANNOYED, and nothing else. > > As a result, people will find the path of least resistance where apparently > two demands can be conflicting: > > 1) Being able to TP to that other destination > 2) Being able to access ones inventory > > Personally I feel not very confident that the combination of both is > going to work anywhere satisfactory given the intentions shown so far; > therefore I think it will be very important to have the possibility of > separate asset services. > > Suddenly I see a glimpse of light: why can't it be possible to run > my OWN (personal!) inventory? Surely nobody is going to forbid me to > put FULL-PERM stuff in it? And even more surely nobody is going to > stop others from accessing my inventory when I use it (ie, to see > my attachments; or to see what I just rezzed). > > I'd be very happy with my own personal inventory, even if on some > worlds they only allow me to put 'full perm' stuff in it. At least > I'll know what I can use everywhere: if I can put it in my inventory, > I will have it at my disposal everywhere. > > Dream or not, this is definitely not going to happen if VWRAP > demands that the asset service is part of the agent service. > > -- > Carlo Wood <carlo@alinoe.com> > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx >
- [ogpx] Tourist use case Vaughn Deluca
- Re: [ogpx] Tourist use case Infinity Linden (Meadhbh Hamrick)
- Re: [ogpx] Tourist use case Infinity Linden (Meadhbh Hamrick)
- Re: [ogpx] Tourist use case Morgaine
- Re: [ogpx] Tourist use case Vaughn Deluca
- Re: [ogpx] Tourist use case Morgaine
- Re: [ogpx] Tourist use case Vaughn Deluca
- Re: [ogpx] Tourist use case Meadhbh Hamrick
- Re: [ogpx] Tourist use case Meadhbh Hamrick
- Re: [ogpx] Tourist use case Vaughn Deluca
- Re: [ogpx] Tourist use case Sean Hennessee
- Re: [ogpx] Tourist use case Joshua Bell
- Re: [ogpx] Tourist use case Meadhbh Hamrick
- Re: [ogpx] Tourist use case Meadhbh Hamrick
- Re: [ogpx] Tourist use case Charles Krinke
- Re: [ogpx] Tourist use case Charles Krinke
- Re: [ogpx] Tourist use case Vaughn Deluca
- Re: [ogpx] Tourist use case Infinity Linden (Meadhbh Hamrick)
- Re: [ogpx] Tourist use case Lawson English
- Re: [ogpx] Tourist use case Infinity Linden (Meadhbh Hamrick)
- Re: [ogpx] Tourist use case Vaughn Deluca
- [ogpx] Tourist use case Vaughn Deluca
- Re: [ogpx] Tourist use case Vaughn Deluca
- Re: [ogpx] Tourist use case Lawson English
- Re: [ogpx] Tourist use case Vaughn Deluca
- Re: [ogpx] Tourist use case David W Levine
- Re: [ogpx] Tourist use case Vaughn Deluca
- Re: [ogpx] Tourist use case Morgaine
- Re: [ogpx] Tourist use case Morgaine
- Re: [ogpx] Tourist use case Morgaine
- Re: [ogpx] Tourist use case Morgaine
- Re: [ogpx] Tourist use case Lawson English
- Re: [ogpx] Tourist use case Morgaine
- Re: [ogpx] Tourist use case Carlo Wood
- Re: [ogpx] Tourist use case Morgaine
- Re: [ogpx] Tourist use case Joshua Bell
- Re: [ogpx] Tourist use case Infinity Linden (Meadhbh Hamrick)
- Re: [ogpx] Tourist use case Morgaine
- Re: [ogpx] Tourist use case dyerbrookme@juno.com
- Re: [ogpx] Tourist use case Carlo Wood
- Re: [ogpx] Tourist use case Morgaine
- Re: [ogpx] Tourist use case Han Sontse
- Re: [ogpx] Tourist use case Han Sontse
- Re: [ogpx] Tourist use case Carlo Wood
- Re: [ogpx] Tourist use case Morgaine