Re: [Evolution-hackers] evolution-data-server details

[JP Rosevear <jpr ximian com>]

On Wed, 2003-11-05 at 13:25, Rodrigo Moya wrote:
> On Wed, 2003-11-05 at 20:13, JP Rosevear wrote:
> > On Wed, 2003-11-05 at 13:08, Rodrigo Moya wrote:
> > > On Wed, 2003-11-05 at 07:01, JP Rosevear wrote:
> > > > 
> > > > 2. What to call the backend libraries
> > > > 
> > > > The backends were called pas and pcs and name spaced as such.  With the
> > > > client libs being libecal and libebook, and all of this being in
> > > > evolution-data-server, I named the backend bits libedatabook and
> > > > libedatacal.  Obviously, these names need some work.  The main problem
> > > > is too have the corba objects in the backend (like the book, the book
> > > > view and book factory) not conflict with the client name for the C
> > > > wrappers to said objects nor the C classes that do the actual work which
> > > > are called by the corba objects (e-book-backend-file, which derives from
> > > > e-book-backend).
> > > > 
> > > why not use a eds_ prefix for all backend-related functions, and put
> > > those in a libedataserver library. I don't think it adds too much
> > > overhead to have both the calendar and addressbook backend-related code
> > > in the same library.
> > 
> > Using "eds_" destroys the consistency of having e_, e- and E_ for
> > type/class macros, file names, and global name spacing for evolution.
> > 
> right
> 
> > There is already a libedataserver which contains utilities for all
> > backend implementations (ie the current libedatacal and libedatabook
> > already link to it).
> > 
> that's what I'm talking about, putting the already exiting
> libedataserver and the calendar and addressbook backends all in one
> library.

Ok, but I don't really see how this solves the name space issue for the
calendar and addressbook backend corba objects.

-JP
-- 
JP Rosevear <jpr ximian com>
Ximian, Inc.