Re: [vwrap] Conditioners and refineries

Dzonatas Sol <dzonatas@gmail.com> Thu, 31 March 2011 15:19 UTC

Return-Path: <dzonatas@gmail.com>
X-Original-To: vwrap@core3.amsl.com
Delivered-To: vwrap@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4226F3A6B24 for <vwrap@core3.amsl.com>; Thu, 31 Mar 2011 08:19:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.531
X-Spam-Level:
X-Spam-Status: No, score=-3.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 E3UlLp7874yW for <vwrap@core3.amsl.com>; Thu, 31 Mar 2011 08:19:47 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id C40A73A6AD7 for <vwrap@ietf.org>; Thu, 31 Mar 2011 08:19:47 -0700 (PDT)
Received: by iwn39 with SMTP id 39so2891520iwn.31 for <vwrap@ietf.org>; Thu, 31 Mar 2011 08:21:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=9jgLBDYGca6EqOIhb4/Wmz6cyh2ErEBJHQN9AcU0KYg=; b=BSSnyncCdfYA6ztHScCXgD5RUQXCGcWc1+C9Jx15xJxu2tGBnKcux249EoMvo4SuYW WNpw7Zrzb5KC0uyshfLPtRX45rbrz7IM9WCUz1xaCV+y4Zb4hjJ68sMWJ25ZhmcLSlxb WKkKaOQLfwGPEUiTtGS/Gmqhc+G+ViYYFbejM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=PTQGAcga+PSQivLkJzdqkN+MXeg5ELBLwNBxdUuoUP+RJVA0mQ8vhnGVAVzFEniyNA eRN012rvBiFg0Dc9sl8QH+x72n3IuiZAABrLGE0ptd+B3k7/5ui9X2BeJ5lQ6itihusS iAjSJSNBxExpvL0tgOPxMARZc2Br85iOdZaws=
Received: by 10.43.57.131 with SMTP id wg3mr2026299icb.299.1301584887252; Thu, 31 Mar 2011 08:21:27 -0700 (PDT)
Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id uf10sm684555icb.17.2011.03.31.08.21.23 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 31 Mar 2011 08:21:23 -0700 (PDT)
Message-ID: <4D949BFB.1010804@gmail.com>
Date: Thu, 31 Mar 2011 08:21:31 -0700
From: Dzonatas Sol <dzonatas@gmail.com>
User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329)
MIME-Version: 1.0
To: Morgaine <morgaine.dinova@googlemail.com>
References: <4D93E82C.7060503@gmail.com> <AANLkTinH2vz+HXTs2j60D2S4BsBH0uT=eG1kTnwBctfJ@mail.gmail.com>
In-Reply-To: <AANLkTinH2vz+HXTs2j60D2S4BsBH0uT=eG1kTnwBctfJ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: vwrap@ietf.org
Subject: Re: [vwrap] Conditioners and refineries
X-BeenThere: vwrap@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual World Region Agent Protocol - IETF working group <vwrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vwrap>, <mailto:vwrap-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vwrap>
List-Post: <mailto:vwrap@ietf.org>
List-Help: <mailto:vwrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vwrap>, <mailto:vwrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Mar 2011 15:19:49 -0000

Don't need to assume too much like that, Morgaine; however, we need 
something more of "trust domains" defined and the example(s) I wrote 
about fit in well as lead-in. I stated these use-cases specially to 
avoid the use of terminology that now exists, and this leans towards the 
need to center on "trust domains." I see the use of current 
client/server-* terminology continually to confuse us (even if some like 
it, not all do). If we have to think about such terminology for more 
than 90 seconds each time then it needs to change.

My side-point was that VWs may have their own object format in their 
world, and I'm thinking more then just the regions that exist now that 
the monolithic client connects. Perhaps, others only think about SL 
compatible grids, and don't worry about the default format.

Morgaine wrote:
> We've maintained throughout that our protocols would be extensible 
> with regard to data formats, allowing worlds and user expectations to 
> evolve without requiring protocol redefinition.
>
> In the area of meshes, it is very much to be expected that COLLADA 
> will figure strongly among the graphic formats used (particularly 
> since it was chosen for the iED initiative), but it's not of any 
> special interest to the VWRAP protocols other than as a potential 
> content type.� All we have to do is to make sure that we label each 
> transfer with its appropriate type, and possibly also include other 
> metadata that may be needed.
>
> We're certainly not standardizing what graphics are used in virtual 
> worlds, beyond assigning types where they might not yet exist.� 
> Hardwiring them would be a recipe not for extensibility but for 
> stagnation.� Other bodies may be standardizing which graphics formats 
> are used, whereas we're trying to define useful deployment 
> architectures and standardizing the protocols through which they are 
> accessed.
>
>
> Morgaine.
>
>
>
>
> ===================
>
> On Thu, Mar 31, 2011 at 3:34 AM, Dzonatas Sol <dzonatas@gmail.com 
> <mailto:dzonatas@gmail.com>> wrote:
>
>     If we say the conditioner basically authenticates or re-signs an
>     asset from grid X to grid Y, and the refinery would make sure the
>     physics of the object described by the asset is translated from
>     the topology of grid X to the topology of grid Y, then this is
>     basically what COLLADA expects in exchange. This exchange is this
>     different from the usual import/export process. It doesn't have to
>     be this exact process, as this is only an example to us be more
>     familiar.
>
>     It seems a complete waste to not realize that LL has implemented
>     the import process and physics refinery into their browser, and
>     this very feature, though not fully automated as such, could be
>     used to help move assets in-between grids/v-worlds. Since the
>     import is from local basis, the authentication is not implemented.
>     What's to stop to basically export to DAE format on the local
>     storage, from one world, and continue to import that DAE into
>     another grid.
>
>     Note that the refineries may be proprietary. They may produce
>     non-COLLADA formats (from DAE files) that are for optimal
>     render/display capability of the software "client" (i.e. that the
>     end-user has to view graphics).
>
>     As with Google Earth and Sony HOME, they already have their assets
>     conditioned and refined for those virtual worlds such that they
>     can optimally display them. The key note is not the optimal
>     display, as it is about being able to exchange and use in other
>     virtual worlds.
>
>     The DAE format does have extensive abilities, yet the goal of
>     COLLADA is still to define the basic material, scripts, model, etc
>     in the most portable format. The DAE may contain hybrid or
>     specific formats that is stored in the extensions, so that custom
>     objects are retained/transferred.
>
>     If virtual worlds start to not agree upon how they store objects,
>     I see COLLADA as the default format for digital asset exchange.
>
>     https://collada.org/mediawiki/index.php/COLLADA_FAQ#What_are_the_major_features_of_this_format.3F
>
>     (Yes, we can put all inventory items in DAE format through the
>     user-data and asset extensions, despite the format mainly being
>     for 3D... just sayin')
>
>     -- 
>     --- https://twitter.com/Dzonatas_Sol ---
>     Web Development, Software Engineering, Virtual Reality, Consultant
>
>     _______________________________________________
>     vwrap mailing list
>     vwrap@ietf.org <mailto:vwrap@ietf.org>
>     https://www.ietf.org/mailman/listinfo/vwrap
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> vwrap mailing list
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap
>   


-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant