Why not DCOP as a public interface server?

That question has two answers:
1. There will be a DCOP interface, through the GUI search client (while it's running, of course)
2. DCOP is just technically unsuitable for the task

To 2., here are the reasons:
- DCOP needs that the metadata service connect to the same dcopserver as the user,
  while the metadata service is, by design, to run as root
- DCOP interfaces are notoriously difficult to create, compared to the XML-RPC interface
- DCOP does not support identification of the caller's security credentials, because it assumes it's working on the same security context as the caller's.

Fixed gripes:
- DCOP needs the KDE mainloop.  Metadata service does not require KDE.  Plus,
  the mainloop.  We do not want to be dependent on the Qt mainloop, or KApplication.
  Besides, the mainloop blocks POSIX signals, and we've had to work around that, because
  KFile needs the KApplication object, and DCOP clients connected to the same server as
  the metadata service (does happen, run the metadata service on a terminal and see) hang
  if the mainloop isn't started.  That's why we run the mainloop on a different thread:
  to protect the signals from being blocked, and to prevent hangs in DCOP applications,
  specifically kdcop.implement dcop and dbus wrappers around this
the dcop wrapper could be implemented in a simple KDE app which resides in the systray
or perhaps a separate kded daemon (i don't know) and the search app contacts the daemon
via dcop.
