[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Kash Kontinued.
From:       Kurt Granroth <granroth () kde ! org>
Date:       1999-10-30 22:31:08
[Download RAW message or body]

Michael J. Bedy wrote:
> The question I do have though is this: How do you start a server that
> isn't already running. For instance if we were to make the database
> portion a seperate "chunk" and the GUI needed to load it up, how would you
> do that?

Hmm.. I'm not entirely sure what you mean here.  A "server" in DCOP is
a class/object derived from DCOPObject.  Take a look at
kdebase/kxmlrpc/test/testxmlrpc.cpp for a simple example.

The AddressServer class is a DCOP "server" (I put it in quotes since
*technically* DCOP is peer to peer -- everything is a *client*).  I
know it is a server since it inherits from DCOPObject (and this could
be a multiple inheritence if necessary).

  class AddressServer : public DCOPObject

Then I see that it will register itself as 'email' from the
constructor definition:

  AddressServer() : DCOPObject("email")

And then I have my implemented 'process' function which completes the
picture.

Keep in mind that this is all just the definitions of a class -- the
server doesn't actually start until it is instantiated.  So until I do
a:

  AddressServer *server = new AddressServer;

the server won't be started.

Now at this point in your development, I'd not worry *too* much about
this.  Just make everything as OO as you can.  If you have well-
contained objects with well-defined input/output methods, you'll have
no problems at all attaching the DCOP servers even after the fact.

> Well, the GUI, reports and other stuff parts of the project could be
> a "get-some-code-out-and-hack-on-it model," but the database should
> be carefully designed to safe-guard the users data. I would prefer
> that we followed a software engineering process for the whole thing,
> but I know better then to expect something like that to happen
> easily :-)

I *strongly* suggest you evalute using an existing database for the
backend.  Databases of any sort can be veeery tricky and storing
sensitive information will make it even tricker (as you well know).
Going with a proven implementation would make your job a lot easier
and a lot more worry-free.
-- 
Kurt Granroth            | granroth@kde.org
KDE Developer/Evangelist | http://www.pobox.com/~kurt_granroth
        KDE -- Putting a Friendly Face on Linux

[prev in list] [next in list] [prev in thread] [next in thread]