-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Lalo, yes this was exactly the intended use of OTDs, but they were
abandoned because there was more important things to do.
Is there still any OTD documentation on the website? If not, I'll try to
find some in my archive and put it on the wiki. There was also going to
be an OTD repository on the website with a certain directory hierarchy,
and also a metaobject or site extension which could send you an OTD if
you asked for it.
Reed
Lalo Martins wrote:
> There are, I believe, two "levels" of supporting a given object type.
> Let's call them "full" and "client" support (and then there is "no"
> support)
>
> Full support means you can have local objects of that type;
> without full support, you can still have that type in the type chain of
> your Vobjects, but you don't get any of the actual behaviour expected from
> the type.
>
> For remote objects, full support would be necessary if there is any
> special behaviour you want from remote objects; that would be the case,
> for example, of a3dl for Ter'angreal (I think), or talkative.
>
> If, however, all the local behaviour you want will be implemented by your
> application code -- for example, most types as seen by Mesh -- then you
> can go with client support, or no support.
>
> Client support allows you to access the "local" behaviour on the remote
> object; or in other words, if your application code will do the displaying
> work, but you want to be able to call methods on your remote objects, then
> you want client support.
>
> Comparing to the C++ API, if the Remote* class of your metaobject
> definition only implements proxy methods -- or, in other words, there are
> no methods that do anything more than sending a message to the object on
> the other side and possibly waiting for a reply -- then you can use this
> type with only client support.
>
> Full support needs actual code, on any language; it will be either
> built-in to your application, or loaded as a module.
>
> However, on dynamic languages, client support can be deduced from an OTD,
> and built on runtime by VOS. Of course, "OTD" right now is a vapour
> term ;-) but this is the whole point of this message. If we specify
> the OTD format well enough that it usefully describes the child
> objects and the messages, then we make this deduction system possible.
>
> Here's how I imagine it used from Python, for example::
>
> obj = vos.vobject.find_object_from_root(siteurl + "/hello")
> hello = obj.meta_cast("tutorial:hello")
> print "Saying 'Good day to you sir.'"
> print "received back:", hello.hello("Good day to you sir.")
>
> The OTD says that there is a message with method "tutorial:hello", and
> that it should map to a local method "hello". It might also say
> something about arguments.
>
> Conceivably, we could extend this to also encompass methods defined in
> terms of child or property access; Metadata is a good example:
>
> def print_basic_meta(path):
> obj = site.find_object(path)
> metadata = obj.meta_cast('misc:metadata')
> if metadata is None:
> print "Object at %s has no metadata" % path
> else:
> print "Object at %s has metadata:" % path
> print "Title:", metadata.getTitle()
> print "Description:\n " + \
> "\n ".join(metadata.getDescription.split("\n"))
> print "Author:", metadata.getAuthor()
> print "Modified:", metadata.getModificationTime()
>
> So my pitch is -- if the focus of .24 is scripting, we could spend
> some time setting up this deduction system, and define the OTD format
> usefully. I think it opens the door for a lot of cool stuff.
>
> If we define a standard location where sites may make OTDs available
> -- say, at "/type-descriptions/$TYPENAME" -- then clients can download
> them and add client support for arbitrary times at runtime. This
> could tie into downloading UI rules from somewhere else, for example.
>
> best,
> Lalo Martins
> --
> So many of our dreams at first seem impossible,
> then they seem improbable, and then, when we
> summon the will, they soon become inevitable.
> --
> personal: http://www.laranja.org/
> technical: http://lalo.revisioncontrol.net/
> GNU: never give up freedom http://www.gnu.org/
>
>
>
> _______________________________________________
> vos-d mailing list
> vos-d@interreality.org
> http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFESsanFK83gN8ItOQRAi7UAJwIAYXD3xLcPd8t/3cNHFybHU/v9gCfRvQD
RE1nXJbKHvWRoHyaPBHxht4=
=B8U2
-----END PGP SIGNATURE-----
_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
