[Ovmsdev] Network Manager Ideas
Michael Balzer
dexter at expeedo.de
Wed Dec 13 06:58:45 HKT 2017
It's actually done both ways in other modules up to now, i.e. the simcom module does it in the Init class, the locations does it in the constructor.
A disadvantage of doing it in the Init classes is, especially if we add instance defaults to the registration, all configs of all modules compiled in will
always be listed, regardless of the user actually needing or using them.
Regards,
Michael
Am 12.12.2017 um 23:48 schrieb Michael Balzer:
> Another option would be to do the RegisterParam() call in the framework registration class, .i.e. OvmsVehicleRenaultTwizyInit. This would assure access rights
> are set on boot if the module is included, regardless of it being actually started.
>
> That smells a bit like breaking the factory class pattern, but seems to be an alternative.
>
> Regards,
> Michael
>
>
> Am 12.12.2017 um 23:35 schrieb Michael Balzer:
>> It's necessary if we want to be able to see configs of not yet loaded modules, i.e. vehicles. Without the persistance the configs are not readable before the
>> module is actually loaded by the user -- so a module configuration can also not be checked without loading the module.
>>
>> That was my reason to change this: without persistance, I cannot see my Twizy configuration after boot before issueing "vehicle module RT". If a part of my
>> config needs to be changed before starting the module, I cannot see what I've set before.
>>
>> You're right in the special meaning of instance names prefixed with "#" -- these should not be allowed for this serialization form. I chose "#" as that's a
>> typical comment line character, and I thought names like this will normally not be used. I'll add a check to prevent using instance names colliding with that
>> pattern, if you agree on the basic solution.
>>
>> Regards,
>> Michael
>>
>>
>> Am 12.12.2017 um 23:19 schrieb Mark Webb-Johnson:
>>> It is the second one I am not sure is necessary.
>>>
>>> If access is controlled by the Register, why persist at all? What would happen if the permissions in Register were changed? What would happen if an instance "#access" was set?
>>>
>>> Regards, Mark
>>>
>>>> On 13 Dec 2017, at 5:54 AM, Michael Balzer <dexter at expeedo.de> wrote:
>>>>
>>>> I've pushed two commits regarding this, the first only fixed the primary problem of not setting the access rights again on RegisterParam() after loading the
>>>> config cache.
>>>>
>>>> The second one adds storage persistance, as I think it's OK to persist this info. The RegisterParam() call will always set the current access rights as
>>>> programmed, this is only meant to restore the latest access rights of parameters registered by loadable modules like vehicles.
>>>>
>>>> So I think this should be OK?
>>>>
>>>> Regards,
>>>> Michael
>>>>
>>>>
>>>>> Am 12.12.2017 um 22:45 schrieb Mark Webb-Johnson:
>>>>> Michael,
>>>>>
>>>>> I don't think this is correct/necessary.
>>>>>
>>>>> The access rights are provided in the Register command, when the parameter is registered. This is done each and every time. We don't need to persist this to /store file system.
>>>>>
>>>>> There was an issue with load order - where parameters could be loaded before the Register function call. Perhaps that is what is causing the bug you are seeing? The code was fixed to work around this, but perhaps it is not setting the access rights correctly in that case?
>>>>>
>>>>> Regards, Mark
>>>>>
>>>>>> On 13 Dec 2017, at 3:32 AM, Michael Balzer <dexter at expeedo.de> wrote:
>>>>>>
>>>>>>
>>>>>>> Am 12.12.2017 um 20:12 schrieb Michael Balzer:
>>>>>>> Btw: I've always registered my config "x.rt" as readable, but "config list x.rt" will no longer show any values. I'm pretty sure it did before.
>>>>>> Found & fixed, the access rights wouldn't be restored on loading the config.
>>>>>>
>>>>>> Regards,
>>>>>> Michael
>>>>>>
>>>>>> --
>>>>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>>>>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>>>>>
>>>>>> _______________________________________________
>>>>>> OvmsDev mailing list
>>>>>> OvmsDev at lists.teslaclub.hk
>>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>>> _______________________________________________
>>>>> OvmsDev mailing list
>>>>> OvmsDev at lists.teslaclub.hk
>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>> --
>>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>>>
>>>>
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.teslaclub.hk
>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.teslaclub.hk
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
More information about the OvmsDev
mailing list