RTT_COMPONENT_PATH with Corba and Ros

Hi,

I successfully deployed an application with the deployer-corba
application, and I am starting to browse its components with the
ctaskbrowser. Some thing are working, some are not. In particular I
have this warning when launching the ctaskbrowser :

ard@ard-host(9.1):/opt/ros_addons/orocos_toolchain/ocl/bin$
./ctaskbrowser HmlMonitor -ORBInitRef
NameService=corbaloc:iiop:192.168.1.41:2809/NameService
0.028 [ Warning][Thread] Lowering scheduler type to SCHED_OTHER for
non-privileged users..
0.028 [ Warning][Activity] Lowering scheduler type to SCHED_OTHER for
non-privileged users..
0.090 [ ERROR ][OrbRunner] Looked up Property float64
propCanRequestTimeout: type not known. Check your RTT_COMPONENT_PATH.

TaskBrowser connects to all data ports of HmlMonitor
0.466 [ Warning][Thread] Lowering scheduler type to SCHED_OTHER for
non-privileged users..
0.466 [ Warning][TaskBrowser.CorbaDispatch] Lowering scheduler type to
SCHED_OTHER for non-privileged users..
Switched to : HmlMonitor

So I checked my RTT_COMPONENT_PATH which is empty. As I am using the
ROS installation of the toolchain it may be related.

I don't know if this is related but I also have for ages this warning
in my normal deployer (on both computers tried in the Corba network) :
root@beta(9.1):/opt/ard/arp_hml# rosrun ocl deployer-corba-gnulinux -s
/opt/ard/arp_hml/script/orocos/deployment/deploy_ubiquity.ops
0.130 [ Warning][DeploymentComponent::import] The ROS package 'ocl' in
'/opt/ros_addons/orocos_toolchain/ocl' nor its dependencies contained
a lib/orocos directory. I'll look in the RTT_COMPONENT_PATH next.

and RTT_COMPONENT_PATH is still empty but nothing complain and I can
use my stuff anyway.

Should I force the RTT_COMPONENT_PATH ?

RTT_COMPONENT_PATH with Corba and Ros

On Thu, Mar 29, 2012 at 10:58 AM, Willy Lambert <lambert [dot] willy [..] ...> wrote:
> Hi,
>
> I successfully deployed an application with the deployer-corba
> application, and I am starting to browse its components with the
> ctaskbrowser. Some thing are working, some are not. In particular I
> have this warning when launching the ctaskbrowser :

The problem with the ctaskbrowser is that it can not import typekits
'on command'. So it has only the RTT_COMPONENT_PATH to look for
automatically loading typekits. Any typekit in this path will be
loaded by the ctaskbrowser. The normal deployer does not have this
issue because you instruct it to load a typekit explicitly using
'import'.

>
>
> ard@ard-host(9.1):/opt/ros_addons/orocos_toolchain/ocl/bin$
> ./ctaskbrowser HmlMonitor -ORBInitRef
> NameService=corbaloc:iiop:192.168.1.41:2809/NameService
> 0.028 [ Warning][Thread] Lowering scheduler type to SCHED_OTHER for
> non-privileged users..
> 0.028 [ Warning][Activity] Lowering scheduler type to SCHED_OTHER for
> non-privileged users..
> 0.090 [ ERROR  ][OrbRunner] Looked up Property float64
> propCanRequestTimeout: type not known. Check your RTT_COMPONENT_PATH.
>
> TaskBrowser connects to all data ports of HmlMonitor
> 0.466 [ Warning][Thread] Lowering scheduler type to SCHED_OTHER for
> non-privileged users..
> 0.466 [ Warning][TaskBrowser.CorbaDispatch] Lowering scheduler type to
> SCHED_OTHER for non-privileged users..
>   Switched to : HmlMonitor
>
>
> So I checked my RTT_COMPONENT_PATH which is empty. As I am using the
> ROS installation of the toolchain it may be related.
>
>
> I don't know if this is related but I also have for ages this warning
> in my normal deployer (on both computers tried in the Corba network) :
> root@beta(9.1):/opt/ard/arp_hml# rosrun ocl deployer-corba-gnulinux -s
> /opt/ard/arp_hml/script/orocos/deployment/deploy_ubiquity.ops
> 0.130 [ Warning][DeploymentComponent::import] The ROS package 'ocl' in
> '/opt/ros_addons/orocos_toolchain/ocl' nor its dependencies contained
> a lib/orocos directory. I'll look in the RTT_COMPONENT_PATH next.
>
> and RTT_COMPONENT_PATH is still empty but nothing complain and I can
> use my stuff anyway.

We need to get rid of this warning :-)

>
>
> Should I force the RTT_COMPONENT_PATH ?

For the ctaskbrowser, yes. We could also invent a -s option that loads
a script/xml file which imports the necessary typekits.

Peter

RTT_COMPONENT_PATH with Corba and Ros

2012/3/29 Peter Soetens <peter [..] ...>:
> On Thu, Mar 29, 2012 at 10:58 AM, Willy Lambert <lambert [dot] willy [..] ...> wrote:
>> Hi,
>>
>> I successfully deployed an application with the deployer-corba
>> application, and I am starting to browse its components with the
>> ctaskbrowser. Some thing are working, some are not. In particular I
>> have this warning when launching the ctaskbrowser :
>
> The problem with the ctaskbrowser is that it can not import typekits
> 'on command'. So it has only the RTT_COMPONENT_PATH to look for
> automatically loading typekits. Any typekit in this path will be
> loaded by the ctaskbrowser. The normal deployer does not have this
> issue because you instruct it to load a typekit explicitly using
> 'import'.
>
>>
>>
>> ard@ard-host(9.1):/opt/ros_addons/orocos_toolchain/ocl/bin$
>> ./ctaskbrowser HmlMonitor -ORBInitRef
>> NameService=corbaloc:iiop:192.168.1.41:2809/NameService
>> 0.028 [ Warning][Thread] Lowering scheduler type to SCHED_OTHER for
>> non-privileged users..
>> 0.028 [ Warning][Activity] Lowering scheduler type to SCHED_OTHER for
>> non-privileged users..
>> 0.090 [ ERROR  ][OrbRunner] Looked up Property float64
>> propCanRequestTimeout: type not known. Check your RTT_COMPONENT_PATH.
>>
>> TaskBrowser connects to all data ports of HmlMonitor
>> 0.466 [ Warning][Thread] Lowering scheduler type to SCHED_OTHER for
>> non-privileged users..
>> 0.466 [ Warning][TaskBrowser.CorbaDispatch] Lowering scheduler type to
>> SCHED_OTHER for non-privileged users..
>>   Switched to : HmlMonitor
>>
>>
>> So I checked my RTT_COMPONENT_PATH which is empty. As I am using the
>> ROS installation of the toolchain it may be related.
>>
>>
>> I don't know if this is related but I also have for ages this warning
>> in my normal deployer (on both computers tried in the Corba network) :
>> root@beta(9.1):/opt/ard/arp_hml# rosrun ocl deployer-corba-gnulinux -s
>> /opt/ard/arp_hml/script/orocos/deployment/deploy_ubiquity.ops
>> 0.130 [ Warning][DeploymentComponent::import] The ROS package 'ocl' in
>> '/opt/ros_addons/orocos_toolchain/ocl' nor its dependencies contained
>> a lib/orocos directory. I'll look in the RTT_COMPONENT_PATH next.
>>
>> and RTT_COMPONENT_PATH is still empty but nothing complain and I can
>> use my stuff anyway.
>
> We need to get rid of this warning :-)
>
>>
>>
>> Should I force the RTT_COMPONENT_PATH ?
>
> For the ctaskbrowser, yes.

What should I put here then ? rtt+ocl+my packages paths ?
what is a RTT_COMPONENT_PATH ? the path to package/lib ? or
package/lib/orocos ? or something else ?

We could also invent a -s option that loads
> a script/xml file which imports the necessary typekits.
>
> Peter

Fwd: RTT_COMPONENT_PATH with Corba and Ros

2012/3/29 Willy Lambert <lambert [dot] willy [..] ...>:
> 2012/3/29 Peter Soetens <peter [..] ...>:
>> On Thu, Mar 29, 2012 at 10:58 AM, Willy Lambert <lambert [dot] willy [..] ...> wrote:
>>> Hi,
>>>
>>> I successfully deployed an application with the deployer-corba
>>> application, and I am starting to browse its components with the
>>> ctaskbrowser. Some thing are working, some are not. In particular I
>>> have this warning when launching the ctaskbrowser :
>>
>> The problem with the ctaskbrowser is that it can not import typekits
>> 'on command'. So it has only the RTT_COMPONENT_PATH to look for
>> automatically loading typekits. Any typekit in this path will be
>> loaded by the ctaskbrowser. The normal deployer does not have this
>> issue because you instruct it to load a typekit explicitly using
>> 'import'.
>>
>>>
>>>
>>> ard@ard-host(9.1):/opt/ros_addons/orocos_toolchain/ocl/bin$
>>> ./ctaskbrowser HmlMonitor -ORBInitRef
>>> NameService=corbaloc:iiop:192.168.1.41:2809/NameService
>>> 0.028 [ Warning][Thread] Lowering scheduler type to SCHED_OTHER for
>>> non-privileged users..
>>> 0.028 [ Warning][Activity] Lowering scheduler type to SCHED_OTHER for
>>> non-privileged users..
>>> 0.090 [ ERROR  ][OrbRunner] Looked up Property float64
>>> propCanRequestTimeout: type not known. Check your RTT_COMPONENT_PATH.
>>>
>>> TaskBrowser connects to all data ports of HmlMonitor
>>> 0.466 [ Warning][Thread] Lowering scheduler type to SCHED_OTHER for
>>> non-privileged users..
>>> 0.466 [ Warning][TaskBrowser.CorbaDispatch] Lowering scheduler type to
>>> SCHED_OTHER for non-privileged users..
>>>   Switched to : HmlMonitor
>>>
>>>
>>> So I checked my RTT_COMPONENT_PATH which is empty. As I am using the
>>> ROS installation of the toolchain it may be related.
>>>
>>>
>>> I don't know if this is related but I also have for ages this warning
>>> in my normal deployer (on both computers tried in the Corba network) :
>>> root@beta(9.1):/opt/ard/arp_hml# rosrun ocl deployer-corba-gnulinux -s
>>> /opt/ard/arp_hml/script/orocos/deployment/deploy_ubiquity.ops
>>> 0.130 [ Warning][DeploymentComponent::import] The ROS package 'ocl' in
>>> '/opt/ros_addons/orocos_toolchain/ocl' nor its dependencies contained
>>> a lib/orocos directory. I'll look in the RTT_COMPONENT_PATH next.
>>>
>>> and RTT_COMPONENT_PATH is still empty but nothing complain and I can
>>> use my stuff anyway.
>>
>> We need to get rid of this warning :-)
>>
>>>
>>>
>>> Should I force the RTT_COMPONENT_PATH ?
>>
>> For the ctaskbrowser, yes.
>
> What should I put here then ? rtt+ocl+my packages paths ?
> what is a RTT_COMPONENT_PATH ? the path to package/lib ? or
> package/lib/orocos ? or something else ?
>
> We could also invent a -s option that loads
>> a script/xml file which imports the necessary typekits.
>>

I'll try something. I suggest to do a proper boost::program_option
management of cmd line arguments aka :
_ introduce a -n --name option for the IOR/ComponentName (currently it
is the only functionnal option)
_ introduce a -s --start option for reading a script/XML file.
_ maintain the -v --version and -h --help options already existing.

taking as a model the deployer-funcs.cpp deployerParseCmdLine function.

Then I'll try do implement the -s function reading and I'll be back
for questions I think ^^

>> Peter

RTT_COMPONENT_PATH with Corba and Ros

Please have a look at this enclosed patch (note that I did my best to
play with git, crossed fingers...). Generated with :
git format-patch origin/toolchain-2.5

This is what I did :
_ conversing the argument parsing to boost::program_option into a
separated parseArgs function
_ add a default "Deployer" value of the researched Proxy
_ updated the README
_ add boost_program_option libraries to ctaskbrowser linked libraries
_ add a new readScript function that is supposed to read an ops (or an
xml if it doesn't cost much to implement) for typekits loading.

I have doubts of what I am doing then. In a standard deployer the
runScript function is done by the Deployer TaskContext. Here I just
have a proxy, should I really use the scripting->runScript function in
it ? I succeeded in adding the Scripting service to the proxy but it
doesn't seem to read it (cause I can type any bullshit in it it
doesn't complain).

I think I can take the occasion to add the log Level option of
classical Deployer, what do you think of that ?

2012/3/29, Willy Lambert <lambert [dot] willy [..] ...>:
> 2012/3/29 Willy Lambert <lambert [dot] willy [..] ...>:
>> 2012/3/29 Peter Soetens <peter [..] ...>:
>>> On Thu, Mar 29, 2012 at 10:58 AM, Willy Lambert <lambert [dot] willy [..] ...>
>>> wrote:
>>>> Hi,
>>>>
>>>> I successfully deployed an application with the deployer-corba
>>>> application, and I am starting to browse its components with the
>>>> ctaskbrowser. Some thing are working, some are not. In particular I
>>>> have this warning when launching the ctaskbrowser :
>>>
>>> The problem with the ctaskbrowser is that it can not import typekits
>>> 'on command'. So it has only the RTT_COMPONENT_PATH to look for
>>> automatically loading typekits. Any typekit in this path will be
>>> loaded by the ctaskbrowser. The normal deployer does not have this
>>> issue because you instruct it to load a typekit explicitly using
>>> 'import'.
>>>
>>>>
>>>>
>>>> ard@ard-host(9.1):/opt/ros_addons/orocos_toolchain/ocl/bin$
>>>> ./ctaskbrowser HmlMonitor -ORBInitRef
>>>> NameService=corbaloc:iiop:192.168.1.41:2809/NameService
>>>> 0.028 [ Warning][Thread] Lowering scheduler type to SCHED_OTHER for
>>>> non-privileged users..
>>>> 0.028 [ Warning][Activity] Lowering scheduler type to SCHED_OTHER for
>>>> non-privileged users..
>>>> 0.090 [ ERROR ][OrbRunner] Looked up Property float64
>>>> propCanRequestTimeout: type not known. Check your RTT_COMPONENT_PATH.
>>>>
>>>> TaskBrowser connects to all data ports of HmlMonitor
>>>> 0.466 [ Warning][Thread] Lowering scheduler type to SCHED_OTHER for
>>>> non-privileged users..
>>>> 0.466 [ Warning][TaskBrowser.CorbaDispatch] Lowering scheduler type to
>>>> SCHED_OTHER for non-privileged users..
>>>> Switched to : HmlMonitor
>>>>
>>>>
>>>> So I checked my RTT_COMPONENT_PATH which is empty. As I am using the
>>>> ROS installation of the toolchain it may be related.
>>>>
>>>>
>>>> I don't know if this is related but I also have for ages this warning
>>>> in my normal deployer (on both computers tried in the Corba network) :
>>>> root@beta(9.1):/opt/ard/arp_hml# rosrun ocl deployer-corba-gnulinux -s
>>>> /opt/ard/arp_hml/script/orocos/deployment/deploy_ubiquity.ops
>>>> 0.130 [ Warning][DeploymentComponent::import] The ROS package 'ocl' in
>>>> '/opt/ros_addons/orocos_toolchain/ocl' nor its dependencies contained
>>>> a lib/orocos directory. I'll look in the RTT_COMPONENT_PATH next.
>>>>
>>>> and RTT_COMPONENT_PATH is still empty but nothing complain and I can
>>>> use my stuff anyway.
>>>
>>> We need to get rid of this warning :-)
>>>
>>>>
>>>>
>>>> Should I force the RTT_COMPONENT_PATH ?
>>>
>>> For the ctaskbrowser, yes.
>>
>> What should I put here then ? rtt+ocl+my packages paths ?
>> what is a RTT_COMPONENT_PATH ? the path to package/lib ? or
>> package/lib/orocos ? or something else ?
>>
>> We could also invent a -s option that loads
>>> a script/xml file which imports the necessary typekits.
>>>
>
> I'll try something. I suggest to do a proper boost::program_option
> management of cmd line arguments aka :
> _ introduce a -n --name option for the IOR/ComponentName (currently it
> is the only functionnal option)
> _ introduce a -s --start option for reading a script/XML file.
> _ maintain the -v --version and -h --help options already existing.
>
> taking as a model the deployer-funcs.cpp deployerParseCmdLine function.
>
> Then I'll try do implement the -s function reading and I'll be back
> for questions I think ^^
>
>>> Peter
>

RTT_COMPONENT_PATH with Corba and Ros

Hi Willy,

On Fri, Mar 30, 2012 at 12:29 AM, Willy Lambert <lambert [dot] willy [..] ...> wrote:
> Please have a look at this enclosed patch (note that I did my best to
> play with git, crossed fingers...). Generated with :
> git format-patch origin/toolchain-2.5
>
> This is what I did :
> _ conversing the argument parsing to boost::program_option into a
> separated parseArgs function
> _ add a default "Deployer" value of the researched Proxy
> _ updated the README
> _ add boost_program_option libraries to ctaskbrowser linked libraries
> _ add a new readScript function that is supposed to read an ops (or an
> xml if it doesn't cost much to implement) for typekits loading.
>
> I have doubts of what I am doing then. In a standard deployer the
> runScript function is done by the Deployer TaskContext. Here I just
> have a proxy, should I really use the scripting->runScript function in
> it ? I succeeded in adding the Scripting service to the proxy but it
> doesn't seem to read it (cause I can type any bullshit in it it
> doesn't complain).

This is not the right way of doing it. You can't use the remote
deployer to load typekits in your local memory !

The most easy solution would be is to take deployer-corba, and extend
it to connect to the
remote deployer (the proxy) in the taskbrowser instead of to the local
one. The local deployer in the ctaskbrowser
is then only used to parse scripts etc, so it's a 'ghost'.

I thought we applied this solution before, so there should be even a
trace in history about this approach.

>
> I think I can take the occasion to add the log Level option of
> classical Deployer, what do you think of that ?

It will only display local logs, so it won't help much in a running application.

Peter

RTT_COMPONENT_PATH with Corba and Ros

2012/3/30 Peter Soetens <peter [..] ...>:
> Hi Willy,
>
> On Fri, Mar 30, 2012 at 12:29 AM, Willy Lambert <lambert [dot] willy [..] ...> wrote:
>> Please have a look at this enclosed patch (note that I did my best to
>> play with git, crossed fingers...). Generated with :
>> git format-patch origin/toolchain-2.5
>>
>> This is what I did :
>> _ conversing the argument parsing to boost::program_option into a
>> separated parseArgs function
>> _ add a default "Deployer" value of the researched Proxy
>> _ updated the README
>> _ add boost_program_option libraries to ctaskbrowser linked libraries
>> _ add a new readScript function that is supposed to read an ops (or an
>> xml if it doesn't cost much to implement) for typekits loading.
>>
>> I have doubts of what I am doing then. In a standard deployer the
>> runScript function is done by the Deployer TaskContext. Here I just
>> have a proxy, should I really use the scripting->runScript function in
>> it ? I succeeded in adding the Scripting service to the proxy but it
>> doesn't seem to read it (cause I can type any bullshit in it it
>> doesn't complain).
>

I am sorry, but I don't see the difference between :

> This is not the right way of doing it.  You can't use the remote
> deployer to load typekits in your local memory !
>

and this

> The most easy solution would be is to take deployer-corba, and extend
> it to connect to the
> remote deployer (the proxy)

I must miss a point :-\

in the taskbrowser instead of to the local
> one. The local deployer in the ctaskbrowser
> is then only used to parse scripts etc, so it's a 'ghost'.

Do you mean that the ctaskbrowser should go to the bin ? and we should
use only the deployer-corba ? even for just connecting to an existing
app ?

>
> I thought we applied this solution before, so there should be even a
> trace in history about this approach.
>

I'm afraid I won't find it alone ^^

>>
>> I think I can take the occasion to add the log Level option of
>> classical Deployer, what do you think of that ?
>
> It will only display local logs, so it won't help much in a running application.

Yes I understood that, but if you are loading typekits and so on
locally maybe you'll need to debug things no ?

> Peter

RTT_COMPONENT_PATH with Corba and Ros

On Fri, Mar 30, 2012 at 4:05 PM, Willy Lambert <lambert [dot] willy [..] ...> wrote:
> 2012/3/30 Peter Soetens <peter [..] ...>:
>> Hi Willy,
>>
>> On Fri, Mar 30, 2012 at 12:29 AM, Willy Lambert <lambert [dot] willy [..] ...> wrote:
>>> Please have a look at this enclosed patch (note that I did my best to
>>> play with git, crossed fingers...). Generated with :
>>> git format-patch origin/toolchain-2.5
>>>
>>> This is what I did :
>>> _ conversing the argument parsing to boost::program_option into a
>>> separated parseArgs function
>>> _ add a default "Deployer" value of the researched Proxy
>>> _ updated the README
>>> _ add boost_program_option libraries to ctaskbrowser linked libraries
>>> _ add a new readScript function that is supposed to read an ops (or an
>>> xml if it doesn't cost much to implement) for typekits loading.
>>>
>>> I have doubts of what I am doing then. In a standard deployer the
>>> runScript function is done by the Deployer TaskContext. Here I just
>>> have a proxy, should I really use the scripting->runScript function in
>>> it ? I succeeded in adding the Scripting service to the proxy but it
>>> doesn't seem to read it (cause I can type any bullshit in it it
>>> doesn't complain).
>>
>
> I am sorry, but I don't see the difference between :
>
>> This is not the right way of doing it.  You can't use the remote
>> deployer to load typekits in your local memory !
>>
>
> and this
>
>> The most easy solution would be is to take deployer-corba, and extend
>> it to connect to the
>> remote deployer (the proxy)
>
> I must miss a point :-\

The point is that the 'ctaskbrowser' also needs a local deployer, as
in deployer-corba. But instead
of connecting the TaskBrowser to this local one, you connect it to the
remote one. The 'script' on
the other hand *is* fed to the local one, such that the local one can
load typekits etc.

>
>  in the taskbrowser instead of to the local
>> one. The local deployer in the ctaskbrowser
>> is then only used to parse scripts etc, so it's a 'ghost'.
>
> Do you mean that the ctaskbrowser should go to the bin ? and we should
> use only the deployer-corba ? even for just connecting to an existing
> app ?

No. We need both, but one connects to a local deployer and the other
to the remote.
My idea was only that they can share 90% of the code.

>
>
>>
>> I thought we applied this solution before, so there should be even a
>> trace in history about this approach.
>>
>
> I'm afraid I won't find it alone ^^

I can't find it either right now....

>
>>>
>>> I think I can take the occasion to add the log Level option of
>>> classical Deployer, what do you think of that ?
>>
>> It will only display local logs, so it won't help much in a running application.
>
> Yes I understood that, but if you are loading typekits and so on
> locally maybe you'll need to debug things no ?

Yes.

Peter

RTT_COMPONENT_PATH with Corba and Ros

2012/3/30 Peter Soetens <peter [..] ...>:
> On Fri, Mar 30, 2012 at 4:05 PM, Willy Lambert <lambert [dot] willy [..] ...> wrote:
>> 2012/3/30 Peter Soetens <peter [..] ...>:
>>> Hi Willy,
>>>
>>> On Fri, Mar 30, 2012 at 12:29 AM, Willy Lambert <lambert [dot] willy [..] ...> wrote:
>>>> Please have a look at this enclosed patch (note that I did my best to
>>>> play with git, crossed fingers...). Generated with :
>>>> git format-patch origin/toolchain-2.5
>>>>
>>>> This is what I did :
>>>> _ conversing the argument parsing to boost::program_option into a
>>>> separated parseArgs function
>>>> _ add a default "Deployer" value of the researched Proxy
>>>> _ updated the README
>>>> _ add boost_program_option libraries to ctaskbrowser linked libraries
>>>> _ add a new readScript function that is supposed to read an ops (or an
>>>> xml if it doesn't cost much to implement) for typekits loading.
>>>>
>>>> I have doubts of what I am doing then. In a standard deployer the
>>>> runScript function is done by the Deployer TaskContext. Here I just
>>>> have a proxy, should I really use the scripting->runScript function in
>>>> it ? I succeeded in adding the Scripting service to the proxy but it
>>>> doesn't seem to read it (cause I can type any bullshit in it it
>>>> doesn't complain).
>>>
>>
>> I am sorry, but I don't see the difference between :
>>
>>> This is not the right way of doing it.  You can't use the remote
>>> deployer to load typekits in your local memory !
>>>
>>
>> and this
>>
>>> The most easy solution would be is to take deployer-corba, and extend
>>> it to connect to the
>>> remote deployer (the proxy)
>>
>> I must miss a point :-\
>
> The point is that the 'ctaskbrowser' also needs a local deployer, as
> in deployer-corba. But instead
> of connecting the TaskBrowser to this local one, you connect it to the
> remote one. The 'script' on
> the other hand *is* fed to the local one, such that the local one can
> load typekits etc.
>
>>
>>  in the taskbrowser instead of to the local
>>> one. The local deployer in the ctaskbrowser
>>> is then only used to parse scripts etc, so it's a 'ghost'.
>>
>> Do you mean that the ctaskbrowser should go to the bin ? and we should
>> use only the deployer-corba ? even for just connecting to an existing
>> app ?
>
> No. We need both, but one connects to a local deployer and the other
> to the remote.
> My idea was only that they can share 90% of the code.
>
>>
>>
>>>
>>> I thought we applied this solution before, so there should be even a
>>> trace in history about this approach.
>>>
>>
>> I'm afraid I won't find it alone ^^
>
> I can't find it either right now....
>
>>
>>>>
>>>> I think I can take the occasion to add the log Level option of
>>>> classical Deployer, what do you think of that ?
>>>
>>> It will only display local logs, so it won't help much in a running application.
>>
>> Yes I understood that, but if you are loading typekits and so on
>> locally maybe you'll need to debug things no ?
>
> Yes.
>
> Peter

Thx for details, I don't really see what to do to help then, tell me
If I can help. I'll provide a clean patch with the log options (this
one was just for comments, as it breaks the -ORBInitRef
NameService=corbaloc:iiop:192.168.12.132:2809/NameService option).