Re: Proper way of connecting to apps

[Richard Frith-Macdonald]

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;
> @end
>
> 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.