[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proper way of connecting to apps

From: Richard Frith-Macdonald
Subject: Re: Proper way of connecting to apps
Date: Sun, 22 Jun 2003 14:49:51 +0100

On Sunday, June 22, 2003, at 01:37  pm, Stefan Urbanek wrote:

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;

There are *many* usages for such functionality.

Ok ... let's see if I can clarify what I think you mean :-)

You are *not* talking about a mechanism whereby the programer of one app writes code specifically to use another 'server' app and the facilities are known at compile time (though your example above seems to imply this) .... since the standard use of protocols and the NSConnection class is ideal for that situation.

You are *not* talking about a system whereby the user can select something to be done at runtime, and another application can do it ... since the services mechanism is ideal for that.

What you are thinking of is something more akin to Java webservices ... where a set of methods and their arguments is advertised, and an applications can pick up a list of all locally advertised services at runtime, and provide optional functionality to use those services.

While the idea has always seemed enticing, and many people have attempted it over the years (webservices being but the latest), it has always failed. I think this is largely because, if the characteristics of this 'public functionality' is not well known to the developer of an application whe s/he writes the application, it is very hard to make use of them in any serious way ... the app just does not know how to deal with the 'public functionality' available. As developers, we naturally tend to think in terms of how cool it is to provide these easy to use functions, but we forget that the end user actually has to select what they want to do and how they want to do it.

So ... for this application, the issue of launching an app and establishing a connection to it is the tiniest, most trivial issue imaginable. If we want to try to provide this sort of system we need to think about how the public functionality is to be advertised (this is also probably quite simple ... based on a similar, but extended model to that used by the services system), and much more importantly, how an application might actually make use of such functions.

IMO if the decision to use functionality has to be made at runtime in an intelligent way, it's practically impossible for the app to do it on its own ... the developer has to spend so much time/attention on writing the code to decide what to do and when to do it, that it's easier for them just to write the functionality into a library so that they can depend on it being there. The only sensible way for this sort of thing to work is where the system provides standard functionality, and other apps can replace it with 'better' versions.

In practice, this means that the decision about any truly dynamic use of additional functionality need to be left to the end-user.

For the services system, this magic worked because it was kept so simple for the user ... they just select something, then click on a menu item which (hopefully) had a reasonably self-explanatory name. This either triggers an operation in some other app that they can see, or causes the selected data to be replaced with something new (which again they can see).

I am not a good enough human-interface designer to see how this can readily be achieved for functionality taking complex sets of arguments.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]