[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;
@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.
- Proper way of connecting to apps, Stefan Urbanek, 2003/06/20
- Re: Proper way of connecting to apps, Richard Frith-Macdonald, 2003/06/21
- Re: Proper way of connecting to apps, Stefan Urbanek, 2003/06/21
- Re: Proper way of connecting to apps, Richard Frith-Macdonald, 2003/06/22
- Re: Proper way of connecting to apps, Richard Frith-Macdonald, 2003/06/22
- Re: Proper way of connecting to apps, Stefan Urbanek, 2003/06/22
- Re: Proper way of connecting to apps, Richard Frith-Macdonald, 2003/06/22
- Re: Proper way of connecting to apps, Stefan Urbanek, 2003/06/22
- Re: Proper way of connecting to apps, Richard Frith-Macdonald, 2003/06/22
- Re: Proper way of connecting to apps, Stefan Urbanek, 2003/06/22
- Re: Proper way of connecting to apps,
Richard Frith-Macdonald <=
- Services (Was: Re: Proper way of connecting to apps), Stefan Urbanek, 2003/06/22
- Re: Services (Was: Re: Proper way of connecting to apps), Richard Frith-Macdonald, 2003/06/22
- Re: Services (Was: Re: Proper way of connecting to apps), Richard Frith-Macdonald, 2003/06/22
- Re: Proper way of connecting to apps, Alexander Malmberg, 2003/06/22