Am 29.03.2006 um 22:09 schrieb Peter Amstutz:
By the way, there is someone else who is working on getting things
to work on OS X (adu on #vos, I don't know/can't remember his email
address so would the real adu please stand up).
I talked to adu on irc recently. Nice to have you on board of the Mac
train :-)
That part isn't part of autoconf, it's part of inplace.mak which I
wrote to make those symlinks. I'm confused though, what is the
difference between .so, .dylib and .bundle on OS X?
I am somewhat new to OSX development myself, this is a point of
confusion to everybody it seems :-) However, as I understood it,
there is no .so in OSX per se, except in UNIX ports of some
libraries, most notably all the fink packages.
Instead, OSX uses .dylib for regular shared libraries that are bound
on program loading. It also has .bundle, which is intended for plug-
ins etc. that are loaded dynamically while the program is running. I
forgot the details of this separation, it had something to do with
pre-binding of symbols or somesuch. I think they are in fact
different binary formats, so you cannot even use .dylib for plugins,
or .bundle for dynamic libraries.
Hmm, on second look, it may be that it is the plugin loader code
which is looking for .bundle (it selects the default file extension
based on OS of course). Perhaps that just needs to be changed/
added to look for .dylib and .so.
See above, imho the behavior of the extension code is basically
correct, omnivos plugins should be compiled with -bundle and
named .bundle accordingly.
(Btw. I noticed that mesh extensions suffer from the same problem...)
[...snip...]
BUT it does not have the expected children associated with them,
e.g. misc:talkative is missing. Only the default geometry hildren
are present,
I want to say that misc:talkative isn't actually created until it
is used. So I wouldn't expect it to be there. Come to think about
it, the factory metaobject keeps its configuration elsewhere in /
vosapp:configuration.
Right, the interreality site has the configuration, my local omnivos
has not. I assume it is the same issue.
[...snip...]
- From your description, it actually sounds like it is working
fine! What else is missing besides misc:talkative (which I think
is not really missing?)
The missing thing is not the misc:talkative type or even the
corresponding metaobject facet,
but the misc:talklisteners child, in combination with an ACL issue or
so. When mesh (-a) does not find the misc:talklisteners child, it
tries to insert it itself, but omnivos rejects it:
<<<(incoming)<<<
<message length="221"
to="vop://alu.mi.fu-berlin.de:4231/world"
method="core:insert-child"
nonce="1591519765">
<pos>-1</pos>
<name>misc:talklisteners</name>
<path>vop://alu.mi.fu-berlin.de:4231/332338614</path>
</message>
>>>(outgoing)>>> priority 0
<update length="275"
to="vop://alu.mi.fu-berlin.de:4232"
from="vop://alu.mi.fu-berlin.de:4231/world"
method="core:insert-child-update"
nonce="1591519765">
<error>permission to insert vop://alu.mi.fu-berlin.de:
4231/332338614 denied</error>
<errorcode>403</errorcode>
</update>
I remember that this was proper behavior in S4, i.e. the client
adding the missing child itself if necessary, and looking at libs/vos/
metaobjects/misc/talkative.cc, Talkative::getRelayListeners(),
apparently this is till the case. Funnily enough, omnivos allowd the
creation of the relay vobject, vop://alu.mi.fu-berlin.de:
4231/332338614, without any complaints...
Regards,
Karsten Otto
_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
