Re: API changes on TnyAccountStore



Forwarding this from private discussions:

> The two methods for adding either store or transport accounts to a
> TnyAccountStore have been removed from Tinymail's API.

All I see in the ChangeLog is 
"
Changes to the TnyAccountStore API
"

Could you be more specific about how application code should be ported
to the new API, ideally in the ChangeLog, please.

> Although they might come back, especially when needed for the ACAP
> support, they are incorrectly implemented in all existing
> TnyAccountStore implementations.
> 
> The API would also be drastically different.
> 
> Therefore I think it's better to remove it from the interface's struct,
> and therefore I for now removed them.
> 
> This makes it possible to later 'append' them back, not interfering with
> the valid API function pointers's offsets. And therefore making it
> possible to commit changes to the type, without breaking ABI.
> 
> All existing implementations have the implementations kept in place for
> now. These implementations, however, are now each of them specific to
> the implementation. Their function prototypes are in the public .h file
> of the specific type and don't use the "TnyAccountStore" type but rather
> the "TnyMyAccountStore" one as their "self" type.
> 
> Although small, this might have an impact on the account-store
> implementation of Modest. Feel free to ask me for assistance (it comes
> down to removing the function pointer assignments in the GTypeInterface
> initialisation function for TnyAccountStore).
> 
> 
-- 
Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com




On Sun, 2007-04-29 at 11:27 +0200, Philip Van Hoof wrote:
> To port existing application code, you simply remove the two
> corresponding function pointer assignments from your
> tny_account_store_init function.
> 
> Optionally you can un-static your existing implementations and put their
> function prototype in he public .h file of your type.
> 
> Note though, that if this functionality comes back to the type, that it
> will probably be drastically different. If so, don't mirror your current
> existing implementation with the requirements of that new API, when the
> change happens.
> 
> It's likely that a more "update, remove, create"-style API will be put
> in place. It will have error handling and it will be optional. It might
> also be put in a new interface (so that you can dual-implement the type,
> if you don't want your type to be a writable store).
> 
> 
> On Sun, 2007-04-29 at 11:21 +0200, Philip Van Hoof wrote:
> > The two methods for adding either store or transport accounts to a
> > TnyAccountStore have been removed from Tinymail's API.
> > 
> > Although they might come back, especially when needed for the ACAP
> > support, they are incorrectly implemented in all existing
> > TnyAccountStore implementations.
> > 
> > The API would also be drastically different.
> > 
> > Therefore I think it's better to remove it from the interface's struct,
> > and therefore I for now removed them.
> > 
> > This makes it possible to later 'append' them back, not interfering with
> > the valid API function pointers's offsets. And therefore making it
> > possible to commit changes to the type, without breaking ABI.
> > 
> > All existing implementations have the implementations kept in place for
> > now. These implementations, however, are now each of them specific to
> > the implementation. Their function prototypes are in the public .h file
> > of the specific type and don't use the "TnyAccountStore" type but rather
> > the "TnyMyAccountStore" one as their "self" type.
> > 
> > Although small, this might have an impact on the account-store
> > implementation of Modest. Feel free to ask me for assistance (it comes
> > down to removing the function pointer assignments in the GTypeInterface
> > initialisation function for TnyAccountStore).
> > 
> > 
-- 
Philip Van Hoof, software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://www.pvanhoof.be/blog







[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]