Re: Libmailcheck- take two

["I.J. Campbell" <ijc25 cam ac uk>]

firstly I should say I only have a basic knowledge of CORBA, so if
anything here is not possible just say so and I'll shut up.... 

On Sun, 28 Feb 1999, Miguel de Icaza wrote:

> > they would each have their own registration function, which could
> > potentially accept whatever parameters they needed (hostname,
> > username, password, etc).
> 
> Sounds good.  
> 
> Now, I do suggest that we do not implement various gtk-level objects
> for each method, as we want a corba server to actually take care of
> the task, so we would have a unified creation routine:

I definately agree with this on the client end, however in the
implementation of the server I think objects for each type of mailbox make
perfect sense, it allows use of gtk-args for config (see below), as well
as making the server code much more moduler and clean, and easily
supporting dynamic loading of mailbox types.

> gnome_mailcheck_new (char *descriptor)
> 
> Where the descriptor would be a string that identifies the protocol
> and then protocol-specific data, like this:
> 
>     "unix:/var/spool/mail/miguel"
>     "pop3:miguel:password@mailserver.unam.mx"
>     "imap:yadayada"

I think this becomes complicated when a mailbox server has several/many
options, especially if the options change from version to version. It
hard-codes into every client the descriptor format of each mailbox, or
else expects the user to enter a fairly complicated descriptor string (not
nice for newbie types). I think that the client's should have no compile
time dependancies/knowledge of any particular type of mailbox, especially
if mailbox types are being added/removed dynamically to the server.

Instead of inventing a new method for setting the parameters of an object
at run time I think we should use the already provided gtk-args stuff,
which I believe was invented exactly for use in run-time configuration of
objects.

Firstly the client calls a function on the server to get a list of mailbox
types that are supported and allows the user to choose the one they need.
It then builds an object using it's type name.. Functions involved here:

GList *gnome_mailcheck_list_mail_types();   /* list of strings */
MailBox *gnome_mailcheck_new(char *desc);

here desc is the type of the mail box ("unix", "pop", "imap", "funky-new",
etc), notice that there are no mailbox type specific paramters in desc at
all.  gnome_mailcheck_new would just create a new server-side gtk-object
for that type of mailbox, with default settings. 

Next, provide CORBA functions to interface with the gtk-args of the
server-side object's gtk-args functions, functions such as

GList *gnome_mailbox_args_query();    /* list of strings or something */
GtkType gnome_mailbox_arg_type(char *name);
void gnome_mailbox_set_arg(char *name, some_value)

these would interface with the gtk_object_set(), gtk_object_query_args() 
etc methods on the server-side objects... 

A client could also build a GUI properties box for each type of mailbox
(similar to the widget properties box in glade, perhaps). 

addional functions would tell a server side object to save it's config, so
that next time we don't need to specifically setup each option, etc etc. 

note that the client never needs to know anything about any mailbox at
compile time, everything is queried at run-time. 

> Now, the notification issues: instead of using a new notification
> mechanism, I suggest you use regular GTK signals, so that the client
> code can attach in any way it wants.

I agree here completely.

Thanks for listening,
Ian