Re: Proper way of connecting to apps

[Stefan Urbanek]

Hi,

At first, thank you for your answer. Thing is, that I know all you have 
suggested me, but this does not solve the problem i am pointing at. I'll put 
something together here, instead of under-writing it.

1. is it somewhere explicitly stated, that using NSConnection is the official 
way how to get remote application object? I know, that with current 
implementation I can do that.
2. I think that using same namespace for application objects and distant object 
registered with NSConnection is not good. Another name server should be used 
for applications ... or betyter solutions is: same with separated namespace and 
interface for applications.
3. [NSWorkspace -launchApplication:] does not work correctly. The method 
returns immediately after executing application binary, i would expect it to 
wait until successfull application launch, so i can connect to it immediately 
and start communicating with it. Now I have to create a loop where I check 
whether application is running.
4. Following code is not making using application services attractive in any 
way:

if(!myApp)
{
   [NSWorkspace launchApplication:name]

   while(!myApp)
   {
       myApp = [NSConnection rootProxyForConnectionWithRegisteredName:name 
host:nil];
       [NSRunLoop runUntilDate:[NSDate dateWithTimeIntervalSinceNow:0.5]];
   }
}

MOREOVER, this code does not work correctly if i do not have application 
installed and i want to use its services (from other application). I can wait 
for application to be connected forever. Therefore this code is missing check 
for application presence, which should be done somehow with NSWorkspace.

Ho would you explain that anyone who would like to use application services has 
to write this long piece of code (that has to be changed when application 
registration changes)?

... (i'll continue underwriting) ...

On 2003-06-21 07:37:31 +0200 Richard Frith-Macdonald <address@hidden> wrote:

> On Saturday, June 21, 2003, at 01:34  am, Stefan Urbanek wrote:

<snip>

> > Moreover, in the future we can add mechanism/interface for using another object 
> > than app itself if authors of the app care about security. But it is not 
> > necessary at the moment.
>
> That's already there ... the private GSListener class is used to handle 
> standard application methods, pasteboard/service requests, and forwarding of 
> other methods to the application delegate.  It would need to be extended a 
> little to provide real security (eg with a method to register the names of 
> methods which are allowed to be forwarded).

I had in mind some 'proxy' object that can be specified by the user. Is there a 
way how to *explicitly* specify application listener for *custom* service and 
message handling? (Custom listeneror at least some listener delegate)

> > I think this method can be very useful gnustep extension to support application 
> > services and better cooperation of applications. ( 
> > http://wiki.gnustep.org/index.php/Application%20Services )
>
> It's not an extension ... it's standard.

No, currently it is not a standard and this kind of 'services' are not 
documented. They are not services that are to be used from application menu, 
but from other apps/programs and they are more general services. AFAIK, 
Terminal.app is the only gnustep app providing such kind of service (just two 
methods) :-)

My suggestion is to wrap something like code mentioned before into a method of 
NSWorkspace (which know everything about gnustep applications) with well 
defined behaviour. This method is supposed to be used many times in different 
application suites or other cooperating applications.

Stefan Urbanek
--
http://urbanek.host.sk

First they ignore you, then they laugh at you, then they fight you, then you 
win.
- Mahatma Gandhi