Re: Proper way of connecting to apps

[Stefan Urbanek]

On 2003-06-22 13:51:31 +0200 Richard Frith-Macdonald <address@hidden> wrote:

> On Sunday, June 22, 2003, at 12:07  pm, Stefan Urbanek wrote:
>
> > This API will be useful for *lots* of people. It is new API for new GNUstep 
> > functionality, not publicaly present on OSX. That functionality is: easy 
> > cooperation of applications by using communication with application listeners. 
> > This will make GNUstep environment more integrated.
> > As I have said, there is currently  only one such kind of service and that is 
> > implemented in Terminal.app. With this method more services can be created and 
> > accessed very easily.
>
> I guess I must have missed it ... What new functionality are you proposing?
> I thought you were talking about wrapping a small piece of code in a 
> convenience method.

See below. The 'wrapper' is creating new interface, where i do not have to care about 
internals of connecting to the application, and i do not have to care about launching it. 
"I just want to use the object named MailClient" adn that is all.

<snip>

> It seems very simple (but very badly documented) to write cooperating 
> applications ...
> but I am probably not completely understanding how you are using the term.
>
> Use of the services  mechanism (services menu in apps) is superbly simple
> for non-programmers, and is pretty versatile.  Its great advantage is that apps
> really need to know nothing about each other to use it.  I'm not sure if you 
> call
> this 'cooperating', as the applications are pretty much independent.
>
> Use of NSConnection is extremely clean/simple (about as simple as it is 
> possible to
> make inter-process messaging) and wrapping another layer round it is only 
> likely to
> make it less simple.  However, the programmers of the applications need to know
> what the other applications are expecting.
>
> Are you suggesting something between these in some way?

YES! :-)

As Alexander Malmberg has said in previous email, the use of term 'service' was 
not very lucky and was causing confucions. Maybe another term should be used. 
Anyway, I'll use 'public functionality' in this email just for the purpose of 
not confucing it with services.

Idea is simple: Advertisement and usage of 'public functionality' of an 
'application object'. In other words, applications advertise methods that users 
can use from other applications by connecting (in some official way) and 
sending messages to the application object. This is also the reason why i was 
talking abou interface for 'custom application listener' where one can replace 
default listener with its own.

Like many times mentioned Terminal, here is the example ... :-)
@protocol TerminalApp
-(BOOL) terminalRunProgram: (NSString *)path
        withArguments: (NSArray *)args
        inDirectory: (NSString *)directory
        properties: (NSDictionary *)properties;
@end

There are *many* usages for such functionality.

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

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