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

List:       kde-pim
Subject:    Re: Status report #2
From:       Mirko Sucker <mirko.sucker () unibw-hamburg ! de>
Date:       1999-08-22 18:00:00
[Download RAW message or body]

Rik Hemsley wrote:

> Hi folks.
>
> Addressbook:
>
> I (Rik) have had a look at CORBA for doing remote addressbooks. After
> implementing some stuff and asking some questions, it seems that CORBA is
> probably going to make things more difficult rather than easier.

Hello there,
I tried it to, and found it a kind of overkill for the purpose. When using a server
over TCPIP there is not need for it, I suppose.

> One other way of serving up addressbooks remotely is to write a simple server.
> This will require a protocol and some support for serialising objects.
>
> The good news is that I've written the protocol, all the necessary objects
> can be serialised, and the implementation is well on the way.

(While being eager to have a look at the code)
It would be a good idea to merge to entry-structures you and I use. My Entry-class
grow over a long time, and I am sure it suits for the needs of most people. I will
contact you about it after seeing what is done by now.

> In case I didn't mention this before a hundred times, the plan will be that
> the kab2 library is intelligent and doesn't actually store any data itself.
> Instead, it is told which addressbooks to talk to and chats to them over the
> network.
>
> Why ? Well, if you want to centralise your data, this does it.
>
> I'd like some comments, especially from Mirko, on the model I've been working
> on and the design (remote addressbooks, dynamic loading etc).

My comments.
1. I was thinking about a server, but wanted to build the database-independant
approach I talked of. It seems to lead to the same problems I had before - strange
exchange of data between two different kab instances running different database
interfaces, for example. But in general, a server is the best idea.
2. Dynamic loading. Are the problems with dynamic loading and C++ solved? I am not
at the bleeding edge, I suppose.

> Addressbook user interface:
>
> Don, how's it going ?
> I know you're waiting for me to sort out the back end. I'm waiting for comments
> from Mirko before I start shouting "THIS IS THE NEW KAB" :)

May I see it :-)

> Mail:
>
> Recently I (Rik) have done a bit of a redesign of Empath's kernel. The major
> effect is that all mail transactions are now asynchronous. You have to ask
> for a message to be retrieved and wait for a signal. This allows the UI to
> survive while waiting for mail to come down from e.g. an IMAP server. Of
> course, the actual data transfer is done with kioslaves, but the code that
> calls the kioslaves would have had to sit in a while (notDone) {
> kapp->processEvents() } type of loop so it could return the data.
>
> This new design hopefully cleans that up.
>
> Anyone testing the code, please note that the only part I've actually managed
> to port to the new async interface is that which makes a message appear when you
> click on it in the list. You can read the code to learn more ;)
>
> Printing:
>
> How's it going Tim ?
>
> Other issues:
>
> There's still only three people doing work. Of course that's not including the
> authors of related applications, but things like addressbook support are going
> to be very important to all pim-related apps. Likewise the ability to send and
> read mail.

I am planning to jump into it, working on the user interface (like I ever did).
Also database interfaces may be in my interest.

> We need some things doing, including a CORBA interface to a mail server.
> There's an idl example that Simon Hausmann wrote for me some time ago but it
> needs reviewing to see if it's practical and some code needs writing to make a
> mail client actually implement the interface.
>
> If anyone knows of anyone who could be helping out and isn't, please give them a
> nudge !
>
> To restate the (realistic and important) goals of the project:
>
> Provide an interface to mail, addressbooks and scheduling that may be accessed
> by any KDE application, whether through linking to a library providing an API
> or via CORBA.
>
> Each interface should provide for performing general operations, which must
> include the ability to search for entities.

Let me quote a few lines from my draft for Entry objects:
---
  /** Compare the entry to the template given as a reference.
      WORK_TO_DO: More documentation.
      @see AddressBook::filter
  */
  ErrorCode match(DBEntry& templ);
---
Sorry, it was a joke. But what ::match should do are is
° go element for element through the Entry object and compare each member that is
NOT EMPTY in the template as a regular expression with the contents of the member
in the Entry.
I fear to code the user interface for that idea.
Greetings,
--Mirko.

--
Denn der  Mensch  liebt und ehrt den  Menschen,  solange er ihn
nicht zu beurteilen vermag, und die Sehnsucht ist ein Erzeugnis
mangelhafter Erkenntnis. (Thomas Mann)

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