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
>