Activation design draft
Tue, 20 Jan 2004 11:27:15 +0100
-----BEGIN PGP SIGNED MESSAGE-----
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 ;-)
email@example.com -=|[ KDE: K Desktop for the Enterprise ]|=- firstname.lastname@example.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
-----END PGP SIGNATURE-----