[Ovmsdev] Network Manager Ideas

Wed Dec 13 15:59:14 HKT 2017

I think:

  * framework modules should register their configs, commands & metrics on init
  * pluggable modules should register their configs, commands & metrics on load
  * once a user has actually set configs for pluggable modules, he/she should be able to see and modify them also when the module isn't loaded

That's what the current implementation now provides (except I've missed adding the config title to the storage meta data section as well).

This keeps both RAM usage as low as possible and the name spaces as clean as possible.

On the Twizy module I've implemented this approach, Geir has done it likewise.

Config deregistration is not really necessary unless a module wants to hide its config. Or at least DeregisterParam() / "config rm" currently works that way, it
doesn't delete the storage file.

Also, instance names actually do not need to be restricted. My storage meta data syntax uses '=' as the value separator, instances use tab, so we can easily
tell them apart.

Regards,
Michael

Am 13.12.2017 um 01:09 schrieb Mark Webb-Johnson:
> I think locations does it in the object initialiser, because there is no Init style initialiser for locations (as there is only one location object).
>
> If we make these dynamic, we would need an ability to de-register a config parameter as well (presumably in the vehicle destructor). Steve recently made some changes/fixes to config to support ‘orphan’ config parameters (in /store, but not registered), and I think that might impact things here as well.
>
> I think it is just simpler to make these parameter registrations permanent, and do them at boot time.
>
> If we really want to make them dynamic, then we need to deal with the destructor Unregister case, as well as harden the protection around ‘#access’ style instances. Presumably Command registration has similar issues? How are RT specific commands handled?
>
> Regards, Mark.
>
>> On 13 Dec 2017, at 6:58 AM, Michael Balzer <dexter at expeedo.de> wrote:
>>
>> 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
>>
>>
>> _______________________________________________
>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20171213/62fe1b79/attachment.htm>