Re: Libmailcheck- take two

[Ian Campbell <ijc25 cam ac uk>]

oops, I forgot to mention that there should be methods to allow clients to
get a list of mailcheck's that already exist and to connect to those as
well as just creating new ones, so that many clients can share the same
object (which is the whole point... ;-)

GList *gnome_mailcheck_list();    /* list of mailbox names */
MailBox *gnome_mailcheck_get_ref(char *name)

thanks,
Ian

On Mon, 1 Mar 1999, I.J. Campbell wrote:

> 
> 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
> 
> 
> -- 
> To unsubscribe: mail gnome-devel-list-request@gnome.org with "unsubscribe"
> as the Subject.
> 
>