Hi Luca,
I agree that 1) is doable. It wouldn't really break the API. It is only a matter of having it done.
Number 2) is out of the question, I would say.
The API has been broken once, and some, if not most, people have taken the hit.
To break it again would be disastrous.
But, I'm not the one doing the work, so others should have the last word here.
Regards
///jon
Jon Maloy M.Sc. EE
Researcher
Ericsson Canada
Broadband and Systems Research
8400 Decarie
H4P 2N2, Montreal, Quebec, Canada
Phone + 1 514 345-7900 x42056
Mobile + 1 514 591-5578
jon.maloy@...
http://www.ericsson.com
> -----Original Message-----
> From: Leandro Lucarella [mailto:luca@...]
> Sent: October-01-10 12:24
> To: tipc-discussion@...
> Subject: Re: [tipc-discussion] TIPC 2.0 and TIPC_SUB_SERVICE
>
> Jon Maloy, el 1 de octubre a las 11:22 me escribiste:
> > > 1. There is no way to add transparent binary and source
> compatibility?
> > > I mean, a patch for that wouldn't be accepter (either
> by you or the
> > > David Miller)? For example, assigning a new subscription port
> > > name/instance that accept subscription messages and
> send events in
> > > the old way?
> >
> > We discussed this, but decided to take the hit, and not try to be
> > backwards compatible. Ok, if this becomes a BIG problem,
> we may have
> > to reconsider, so far I don't have that impression.
>
> Just to know how you weight the size of the problem, your
> impression is that is not a BIG problem because not many
> people brought it up?
>
> Because for me is kind of painful, to install a system that
> is based on TIPC, we have a pre-compiled image, that should
> run with different kernels. Before this problem we didn't
> have to care much about the kernel, now we have to build
> different binaries for different kernels and that is a
> maintenance problem. I'm providing this information only to
> help you to weight the problem, I don't know if you are
> considering this issues when you do it.
>
> > > 2. Why the sockaddr values have to be in HBO and the
> subscription and
> > > event data in NBO? Is there any reason for that?
> Wouldn't be better
> > > to be consistent and have them all in NBO. It would be more
> > > consistent with how sockaddr_inet is handled.
> >
> > The difference is that the subscription interface is a
> protocol, that
> > may potentially go between nodes. Originally, it was nod-internal,
> > that is why we used HBO from the beginning. The socket API is, and
> > will always be node local, and represents an API, not a protocol.
>
> I understand that, but is the same with sockaddr_inet, and
> it's members are in NBO. I can't think of any reason for
> sockaddr_tipc not doing the same, except for backwards
> compatibility, but it's already gone, so that being out of
> the table, what is the reason to keep the inconsistency?
>
> > Anyway I think it is a bad idea to do any more changes to
> the API now
> > for obvious reasons.
>
> I don't agree, at this point, there is no difference, you
> already broke backwards compatibility, there isn't a better
> moment to fix this inconsistency. Among all the BO changes
> one would have to make to be 2.0 compatible, I guess changing
> the sockaddrs too is not much painful.
>
> Seriously, I think things are they are now, have the worse of
> both worlds, you have broken backward compatibility and
> introduced inconsistencies to the API.
>
> Just as a side note, this new inconsistency is very painful
> for me because I have a thin C++ wrapper for TIPC structures
> (for the BSD sockets API in general), which automatically
> handle the BO issues. Now I have a Name and NameSeq objects
> that can be used both for constructing a SockAddrTIPC and a
> Subscription. With this change, I have to handle BO
> differently in SockAddrTIPC and Subscription, because I can't
> abstract the BO issues directly in Name and NameSeq because
> of the new inconsistency. This problem doesn't exist with
> INET address family, I can abstract BO in the InAddr
> structure, and use it to construct a SockAddrIn without any problems.
>
>
> I hope you can reconsider at least one of the two issues I mentioned.
>
> Thanks.
>
> --
> Leandro Lucarella (AKA luca) http://llucax.com.ar/
> ----------------------------------------------------------------------
> GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
> ----------------------------------------------------------------------
> Agarré, me fuí pal monte
> Para ver el horizonte...
>
>
> --------------------------------------------------------------
> ----------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> tipc-discussion mailing list
> tipc-discussion@...
> https://lists.sourceforge.net/lists/listinfo/tipc-discussion
>
|