Hi Slava,
I understand that! It makes things easier for you guys.
But we had to avoid certain compile-time dependencies in ofono, and a
straightforward (and perhaps the only) way to achieve that was to use
binary plugins. For us plugin API is not subject to change (plugins
don't necessarily get upgraded together with ofono), meaning more
changes between our fork and upstream in case if upstream breaks it,
more maintenance work and more room for errors. Obviously, I would
like to keep differences to a minimum.
So I sympathize, but really it might also be a hint to finally start
getting things upstream.
I'm just humbly asking - if there's a way to keep plugin API backward
compatible, please do it that way. There is at least one person in the
world who would appreciate it.
The problem is, the next time this comes up there may be no way to avoid
it... Or we break binary compatibility inadvertently. It is just not
something we're going to be looking out for.
Actually, in our fork we have already modified enum
ofono_gprs_auth_method and that's what we have there:
enum ofono_gprs_auth_method {
OFONO_GPRS_AUTH_METHOD_ANY = 0,
OFONO_GPRS_AUTH_METHOD_NONE,
OFONO_GPRS_AUTH_METHOD_CHAP,
OFONO_GPRS_AUTH_METHOD_PAP,
};
So you already made life very hard for yourself ;)
(ANY = PAP_CHAP, and don't ask me why we added new values to the
beginning of the enum - it was before we started using binary plugins).
I would be more than happy if upstream started to use the same enum!
That assumes that we should support your METHOD_ANY thing. I've not
heard any good arguments for that yet...
Regards,
-Denis
_______________________________________________
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono
