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

List:       kmail-devel
Subject:    Re: [PATCH] UI abstraction proposal (partially only)
From:       Don Sanders <sanders () kde ! org>
Date:       2003-06-04 8:48:32
[Download RAW message or body]

On Wednesday 04 June 2003 06:43, Andreas Gungl wrote:
> On Tuesday 03 June 2003 16:11, Zack Rusin wrote:
> > On Tuesday 03 June 2003 13:57, Andreas Gungl wrote:
> > > That still doesn't answer the question how to get there. I see
> > > my example as a proposal for how to separate logic and UI in a
> > > first step. That doesn't prevent anyone from any further steps.
> > > In the opposite, I believe this makes the next steps easier.
> >
> > Well, these are completely two different approaches and there's
> > definitely more than one correct way of achieving the goal.
> > I'm not sure I understand how you see the next step. You mean
> > implement the interfaces with DCOP implementation? If so then why
> > not do it in the first place? By doing it your way, we'll be
> > reimplementing a lot of dcop and adding a lot of useless stuff.
> > Like for example, lets say my app wants to get some simple info
> > from the core, I definitely won't want to implement all
> > interfaces, I'll want to get the info from DCOP, but if KMail GUI
> > is already running then I can't do that. So we'll have to add
> > classes that change the interfaces independently of each other.
> > [...]
> > There's so many problems here, that with this approach a
> > timeframe of KDE 4.0 seems mightely optimistic. Pretty much
> > everything could go wrong. Now imagine if instead of all that you
> > have one core that propagates the events through dcop. How much
> > simpler would that be? No indirect calls. Error? DCOP emits error
> > signal. New message? DCOP emits where and when. Who catches those
> > signals? Who cares. Interested apps connect and we're done. GUI
> > issues a dcop call to get the list of folders - displays them, -
> > queries message list - displays them (this is already prettu much
> > possible, look at the classes I added lately).
>
> Don't get me wrong, I still understand my patch as some kind of
> initial ignition. It's okay, when the discussion in this thread
> leads to a clearer picture of what is planed for KMail. IMO it's
> important to define the way to go to be able to make other steps
> conformant to the far goal.
>
> > > If I understand correctly then you don't want such a fine
> > > grained coupling of UI and logic as I did. Well, in this small
> > > piece are a lot of callbacks when the code for the logic
> > > remains mainly untouched (except for the function calls).
> > > Instead, if you want to have better abstraction (coarse grained
> > > coupling), then you'll also have a lot more work with the
> > > logic. In my example, this would mean to define much finer
> > > return codes (e.g. enumerations) for the methods which trigger
> > > any UI interaction. The return codes need to get passed some
> > > layers (in the call stack) upward, so that the UI "shell" can
> > > react appropriate. Did you think about that, resp. is this what
> > > you intend?
> >
> > Well, ideally I wouldn't want to have any gui code in the core
> > just DCOP calls to everything that should be GUI presented.
> > In the example above you mention return codes also note all the
> > stuff I added above. Some of that stuff DCOP already solved and
> > the rest dcop only implementation wouldn't need. So to get it
> > right we'd have to reimplement a good deal of DCOP in KMail and
> > then have to add a DCOP interfaces to get it working with other
> > apps.
> > So although your way might seem neat it simply would make the
> > KMail the most complex app the world has ever seen and we would
> > end up with every app using the dcop interface anyway, so why
> > bother?
>
> Well, I thought only about having an interface of choice when I
> start KMail - working from remote using the text UI, working
> locally using the GUI. I didn't think about many concurrent
> applications using the core simultaneously.
>
> So the conclusion out of the thread is up to now:
> - KMail should have a core which is able to manage more than one UI
> client. An UI client could be another programm like KOrganizer too.
> - Currently we see DCOP as the way to go for the interaction
> between core and UI client.
> - Usually, that kind of communication uses coarse grained
> interfaces. - As I understood, the core is working singular (no
> parallel threads or so). Calls will be needed to be queued somehow.
> (Did I get this right?)
>
> The requirements above make my example approach nearly obsolet.
> However, I still think, there are some more issues to be discussed.
> The architecture you prefer has some more challenges. What about
> session states (stateless, I guess), what about transactions (e.g.
> deleting 10 messages in one folder; no problem when the core is not
> working parallel), what about response times towards the UI (might
> be a problem when the core is not working parallel)?
> In the office, there I'm working on a large J2EE project. There
> we're facing many of the problems which seem to be natural for
> architectures like mentioned above. We better don't underestimate
> them.
>
> I'm also interested in comments from Ingo and Don, as well as from
> Marc, who is a talented pattern user ;-) and has good architectural
> ideas. Perhaps the Kroupware guys have some ideas too. I would not
> like to have a dialog only between you, Zack, and me, when the
> topic is so important - except when it will be decided to get
> delayed, then it was only a nice thread in the list archive. ;-)

Ok here are my comments.

I think making KMail run as a server process that allows UI's running 
in different processes including web/terminal frontends is not such a 
hard problem.

I think there is a clear and intentional distinction in the KMail 
architecture between server code and client code.

KMail can already be run as a server process without any graphical 
interaction from the user. It does require X11 to run, and only a 
restricted DCOP interface is exposed. So just to make that clear 
KMail can already be run as a server.

The main restriction is the limited DCOP interface which means you 
can't even browse folders/mails really. I think it only makes sense 
to add more official DCOP methods as the folder and message classes 
become more stabilized (e.g. after ref counting of folders and 
messages is achieved).

But it would be possible (but not necessarily advisable) to quickly 
fill in the missing dcop interfaces and allow someone to write a 
terminal based client that uses KMail as a server.

This is because majority of the KMail Kernel code is GUI free in the 
sense that it never blocks on user input. There are some exceptions, 
I see two calls to KMessageBox::sorry in kmfoldermaildir.

These exceptions are unfortunate regressions and it would be nice to 
eliminate them. It seems to me that this is basically what your patch 
is doing but for kmaddrbook instead of kmfolder.

That leads me to a question is kmaddrbook part of the KMail kernel 
code? I think this question is basically equivalent to can any of the 
kmaddrbook.cpp code be hit when KMail is being run as server process? 
(That's an actual not a hypothetical question).

A kmkernel object is always created when KMail is running, including 
when KMail is running as a server process. Looking at kmkernel.h I 
can see parts of KMail that are part of the kernel. Those parts 
include KMFolderMgr the folder manager and hence as the folder 
manager owns folders all the KMFolder* code is part of the kernel.

As indicated by kmkernel.h the UndoStack, KMAcctMgr, KMFilterMgr, 
KMFilterActionDict, KMSender, KMMsgDict, KMMsgIndex are all part of 
the kernel code so it is desirable to elimiate all GUI code from 
these classes as is the intention of your patch for 
KMAddrBookExternal.

Also the kernel includes actual QWidget based classes such as a 
progress bar and a label this is bad, ideally we don't want to have 
the kernel display windows and instead pass the responsibility on to 
ui process.

Now in regards to KMAddrBook specifically I'm not convinced that class 
is even part of the kernel code, I think it's probably part of the ui 
code, and as such should only be used from the ui process and never 
called from any kernel classes. (Okay it's possible for the kernel to 
create a composer object and then have that use kmaddrbook, I'll 
address that later in this mail).

In regards to your approach of using a AddrBookGuiCallback class. I 
think this is basically a step in the right direction. But only an 
early step. Instead of a GuiCallback class for each kernel class I 
think only one univeral UiCallback class is needed this should cater 
for all types of ui requests that the kernel needs to make.

This UiCallback class should have a DCOP API. Then the graphical 
process can register this UiCallback class with the kernel, and 
whenever the kernel class needs to do some Ui it can use the DCOP API 
of the UiCallback.

This will work if the UiCallback object is running in a different 
process. Or if the UiCallback code is running the same process which 
would give a smooth transition path from having KMail run as a single 
process to having it run as two seperate server/ui processes.

The UiCallback class should support creating new composers and 
mainwindows and stuff like the kernel code that creates composers and 
new main windows should be ported to using UiCallback via dcop.

So I think it's possible to modify your approach to fit in naturally 
with the DCOP approach that Zack and I guess I prefer.


Regarding queuing multiple requests this is already something dcop has 
to deal with as dcop calls can be sync or async. Basically the client 
will block until the server has finished. You could 'fix' this by 
making a kmail server proxy process that has the same DCOP API as 
KMail but queues dcop requests until KMail is ready to respond to 
them.

Regarding transaction processing that's a tough one and I suspect it 
would be a lot of work to change the folder classes say to cope with 
that. It might be better to focus on supporting storing mail in a 
conventional sql database that support transactions.

In summary I think your basic approach has merit but:
1) A single unified UiCallback class with a dcop interface should be 
used.

2) It may well be not necessary to use this UiCallback code in 
kmaddrbook.cpp, as kmaddrbook.cpp code may only be reached from ui 
rather than kernel code.

3) The main restricting force that is preventing KMail from being 
useful as a server is the sparse dcop interface, this interface 
should not be completed before the folder and message class 
interfaces have stabilized, and that is probably lower priority than 
the imap work. I guess it would be ok to create the needed dcop 
methods as long as they were marked as experimental and temporary.

Hope that made sense, a bit hurried today.

Don.

_______________________________________________
KMail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail
[prev in list] [next in list] [prev in thread] [next in thread]