On Mon, 2010-11-15 at 11:45 -0500, Matthew Barnes wrote:
> I was a bit horrified to realize over the weekend the way we select a
> backend from the factory processes when requesting a new EBook or ECal.
> We convert an ESource object to XML and transmit the -entire- XML string
> over D-Bus, only to have the factory process reconstruct the ESource
> object from the XML string, extract the URI string from the ESource
> object, and extract the scheme from the URI.  The scheme is used as a
> hash table key for registered backends.

Well, it's not complete, the reconstructed ESource is passed into
e_data_book_new, so the backend can access it and knows where to

> With the new APIs, apart from GConf migration we won't be constructing
> ESources from XML anymore.  So here's how it's gonna work: getCal() and
> getBook() will just take the ESource's UID string, the factory process
> will look up the corresponding ESource object from its own registry and
> call e_source_get_backend() to get the hash table key.  Done.

That's kinda limiting, isn't it? As you allow only saved sources to be
opened, though for example all test suits are not saving their sources,
but just construct them on the fly and pass them to the factory.

> ...
> If there's no objections I'd like to get new interface names into 2.91
> now so I can increment the interface versions on my account-management
> branch and not have to worry about this anymore.

Sounds fine to me.

evolution-hackers mailing list
To change your list options or unsubscribe, visit ...

Reply via email to