Frameworks vs. applications (Was: Re: Third party extensions to apps)

[Stefan Urbanek]

Hi,

I am cross-posting this to the gnustep mailing list for comments.

The original email is here: 
http://d2dc.net/list-archives/desktop/2004-June/000071.html

On 2004-06-19 18:45:20 +0200 Nicolas Roard <address@hidden> wrote:

> 
> Le 19 juin 04, à 17:34, Nicolas Roard a écrit :
> 
> To clarify: working at the document level instead of the current pasteboard 
> selection is imho not very different; it's just working with another data, 
> but the behavior/mechanism is quite similar (you are working on the current 
> selected thing). So I think it should be done in a quite similar mechanism 
> than services (and perhaps directly using services).
>

Sure, it is just working with another kind of data.

> On the other hand, it could perhaps be interesting to have "services" 
> directly callable by the application -- the programmer will then be able to 
> build is application in reusing directly some components of other programs...
> That's something that could be done using frameworks, but not every app will 
> provide frameworks. Basically, it would be to provide services not directly 
> related to the pasteboard content, using DO for communicating. A simple 
> broker could be used to advertise/find services.
>

I have proposed this some time ago. This will require advertising of such 
services in a way the scripting capabilities are advertised. Concerning the app 
vs. framework, perhaps it could be interesting to try different approach to the 
whole operating environment like it is used today. We can have "thick 
frameworks" and "thin applications". What does that mean? Frameworks will 
provide whole functionality, applications will just glue them. Ideally an 
application will be only simple app controller + document controller class. 
Then we can have high interoprability between applications. Moreover! The data 
will not be owned by an application as it is today.

> It won't work with embedded gui components (I think that using a DO gui 
> component is not possible), but I think we could work at the window/panel 
> level. For example; instead of using Adresses framework, an application could 
> call directly the Addresses application, get a dialog, etc. (ok in this case 
> we could use the adresses framework ;-) but that's the same idea than with 
> services. After all, why not using frameworks instead of services ? because 
> using services is simpler...
> 

Yes! Another thing would be "active frameworks". Active framework is nothing 
more nothing less than an application with public communication interface. It 
is "modernised unix daemon". There should be native support for "active 
frameworks" or "application daemons" in the environment, including -make.

Requirements for the system are:
- headers for .app bundles
- building system should know about the headers
- there is no linking, therefore one does not have to have the application 
installed

Another thing are protocols for applications for interoperability. The 
interface does not have to be tied to one app. -make system can provide 
creation of "Protocol" packages, where only headers will be stored. 
Applications then can "conform to" certain protocol, like "Contact Viewer" 
protocol for AddressBook.app. Suggested storage of the protocols can be either 
Library/Headers/protocol_name or Library/Protocols/protocol_name.

Again, -make support is required for this functionality and perhaps some 
automagical classes and methods.

With this system, applications can provide services for each other. What do you 
think?

Stefan Urbanek
-- 
http://stefan.agentfarms.net

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