Yeasah Pell wrote:
Manu Abraham wrote:
Yeasah Pell wrote:
Hmm. I dunno, I see the argument both ways.
Well, we've got a situation where we have a collection of 'n'
drivers, 'm' applications, and 2 APIs. API #1 (the older API) has a
certain set of functionality, and API #2 (the multistandard API) is
a proper superset of this functionality -- it includes everything
the first API had, plus has significant additional flexibility to
allow the multistandard stuff, etc.
As far as I can tell from looking at multiproto7.diff, right now
it'd be a straight mapping of stuff for the API. Assume for a minute
you have access to the following set of conversion functions:
int to_old_params(const struct dvbfe_params* new_p, struct
dvb_frontend_parameters* old_p);
int to_new_params(const struct dvb_frontend_parameters* old_p,
struct dvbfe_params* new_p);
int to_old_info(const struct dvbfe_info* new_p, struct
dvb_frontend_info* old_p);
int to_new_info(const struct dvb_frontend_info* old_p, struct
dvbfe_info* new_p);
int delsys_to_caps(enum dvbfe_delsys new_p, fe_caps_t* old_p);
int caps_to_delsys(fe_caps_t old_p, enum dvbfe_delsys new_p);
Having bidirectional compatibility will cause people to be stuck with
the compatibility layer itself, rather than to use the new API, which
will be just another half baked approach. Anyway there should be
ideally compatibility in one direction only as we decided to move
eventually.(ie compatibility to applications)
It will be nice to have this featureset (ie, bidirectional
compatibility), but will need to handle swzigzag and inversion
handling etc. IMHO, this will be a bit too much duplication inside
dvb_frontend.
Manu
Yeah, I agree that bidirectional support is probably too much,
anything that can be done to discourage the future use of the old API
is welcome :-) I only specified bidirectional conversion because the
structures would need to be converted both ways (i.e. params is used
as an in for tuning, as well as an out for status), my comment about
using it to support bidirectional API conversion was off-the-cuff and
not very well thought out.
Really all I'm trying to suggest is that once the new API is made
available, every card should be accessible through it.
Yes, it will be that way. I think the confusion came in because i
mentioned the implementation of tuning algorithms, which need more time
to be implemented.
Anyway, will keep that thing separate, since i found that to cause
confusion as well.
If that means having a translation layer in the short term (i.e. until
all the drivers are updated), I think it might be a good idea --
unless of course it's going to be almost as much work as just updating
all the old drivers, in which case it makes more sense to just do
that. But I'm not really fond of the idea of a lengthy period of time
wherein drivers slowly migrate from the old API to the new one.
Regarding app. backward compatibility, we don't need a huge translation,
i will post those changes soon. But yet needed to know whather the
previous API changes were acceptable, waiting for JS's ACK on that.
I think having the new API be fully capable will speed its adoption by
application developers, and I'm thinking it adds more benefit (when
you think about the linux DVB system as a whole, including the API,
the drivers and the applications) than it costs.
ACK
Manu
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
