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
