Activation design draft

[Waldo Bastian]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue January 20 2004 03:36, Mikael Hallendal wrote:
> > > I don't have a personal preference, but the reasoning was that the bus
> > > configuration is XML, other things like the new MIME files are XML, the
> > > suggested split of properties would make the file look less like a
> > > desktop file, could be validated with e.g. DTD, and the aggregated
> > > cache file would contain all service entries so XML could fit better.
> >
> > I like xml myself for this, but the .ini has some argument in terms of
> > familiarity to dcop users.
>
> It would be great to hear something from the KDE guys about this (and
> other things proposed).

KDE has a general notion of service with "applications" (The stuff you see in 
the start menu) a subset of that. All services are described by .desktop 
files in .ini format.

In general, service activation happens explicit and under reference to 
the .desktop file that describes the service.

The only exception to that are the services provided by KDED (KDE Daemon), 
which are demand loaded by KDED when accessed. 

Abstraction of services is provided by the trader (KTrader).

It should be noted that communication (DCOP), service activation (KDED / 
KLauncher) and the trader (KTrader) are all pretty much independent. E.g. 
klauncher can be used to start services that have no DCOP communication 
ability at all.

I think you must be a bit careful not to overengineer it, we already have 
CORBA for that ;-)

Cheers,
Waldo
- -- 
bastian@kde.org -=|[ KDE: K Desktop for the Enterprise ]|=- bastian@suse.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFADQKDN4pvrENfboIRAkCYAJ905r1k3WGKn0oqFw19KYXiX3nFiACgggA6
vYegyNjkthcQtudkcpwFvoM=
=pKM7
-----END PGP SIGNATURE-----