[tipc-discussion] TIPC native API evolution

[Stephens, A. <all...@wi...>]

Hi Paul:

It's no problem that you didn't make it to Friday's call ... we're all
busy and I know where TIPC rates on most people's priority lists. (As I
mentioned in the meeting, I'm having enough trouble finding cycles
myself these days!)

I broached the idea of eliminating TIPC's native API with Jon, but he
said we should keep it as there are people at Ericsson who make use of
it. However, he was OK with idea of making it an optional component of
TIPC that would only be included if people explicitly configured it in.
Do you have any suggestions about the best way of doing this (or, just
as importantly, ways *not* to do it)? We assumed that it would be better
to have a Kconfig option that would incoporate the native API into the
TIPC module than it would be to have a totally separate module, but
you're the real expert on this sort of thing ...

I've copied the TIPC discussion list (and Jon) on this reply, since
that's the normal place for email discussions about TIPC design issues.
I'm not sure that there'll be a lot of interest on this topic, but it'll
give people a chance to contribute if they want to.

Regards,
Al

> -----Original Message-----
> From: Gortmaker, Paul 
> Sent: Monday, August 30, 2010 2:33 PM
> To: Stephens, Allan
> Subject: Re: More TIPC 1.7 migration patches
> 
> On 10-08-25 02:45 PM, Stephens, Allan wrote:
> > Great. I've attached an email with the meeting details so 
> you know how 
> > to dial in.
> 
> Hi Al,
> 
> Sorry for missing this ...
 <snip>
> Do you thin we can get somewhere if we start an 
> e-mail dialog on this, if it is really just you and John from 
> Ericcson on the calls anyway?  Or are there a lot of other 
> stakeholders and interested parties wrt. the drafted TIPC API?
> 
> Thanks,
> P.