772 replies to this topic

[IanSav]

Hi WanWizard and other contributors,

 

I know that this comment will be contentious but I think that the only way to deliver the desired information to *all* layers of Enigma2 will be to have a text file to hold the data.  This text file can be processed by the shell and shell scripts before Enigma2 starts, it can be accessed by the C++ layer and it can be processed by the Python layer.  All three layers can use the *same* source of data and information.

 

At the moment OpenPLi does not have the build system to create this data but I believe that the current OE-Alliance system can be adjusted, simply, to provide a text based profile/configuration file that can be used by all images.  The OE-Alliance system has data and profiles for a very large collection of legacy and current receiver hardware.  I believe that the OE-Alliance data is a superset of all the data held by any one image.

 

I propose that this environment description file could be placed in /etc/enigma2 along with all other Enigma2 configuration files.

 

Can we discuss and workshop this proposal of a way to make a start and move forward with this project?  I suspect that this aligns with the proposal from OpenVision.  I have spoken with Captain in openATV on this idea and believe that it is achievable.  I think Twol in OpenViX has even prototyped the build system to create such a file.

 

Regards,

Ian.

[Persian Prince]

I believe that the OE-Alliance data is a superset of all the data held by any one image.

That's not true my friend, we have more brands/models and more data in Open Vision

 

Take a look at our imports: https://github.com/O...ing/lib/test.py

 

And our bitbake recipe to provide the needed files: https://github.com/O...version-info.bb

 

We have a folder with needed files and it's /etc/openvision

 

Anyway a common goal would be great and easier to support.

Edited by Persian Prince, 31 July 2020 - 19:48.

[WanWizard]

Can we discuss and workshop this proposal of a way to make a start and move forward with this project?  I suspect that this aligns with the proposal from OpenVision.  I have spoken with Captain in openATV on this idea and believe that it is achievable.  I think Twol in OpenViX has even prototyped the build system to create such a file.

 

You fall into the same trap of talking about implementation. As long as there is no defined interface, and no agreement on that interface, the rest is moot.

 

If you limit yourself to "lets store data in a file", then that will be your interface, and you'll end up with every bit of code trying to read that file. That will lead to a lot of redundant code, and a permanent lock-in of your implementation, as every bit of code directly interacts with it, something I want to avoid at all costs.
 

It could very well be that we end up with "data  in file", but that should not be the starting punt. I don't want to dictate how every image maker implements it. Implementation isn't relevant, a standardized interface in all images is.

[littlesat]

Wte comes with a ‘boxbranding’ file created with the build.... looks how simple the basics are... at least to get the information....
Regarding implementation I suggest we can consider to put the stuff from SystemInfo in a config.... then we also have it extreme easy in cpp.... so instead of SystemInfo[“xxx”] we can do config.systeminfo.xxxx.value or adapt it a bit so we can also do SystemInfo.xxx.value.... But this is implementation, but unless this still part about how e2 and it’s plugins can obtain the information.... but my idea is using the config system... that was my idea for years. No cpp code needed for branding by using what is already there and use for default the values given by a static file made during the build.

Edited by littlesat, 1 August 2020 - 07:29.

[betacentauri]

I don't think using python config is a good idea. As far as I remember someone used a config value in cpp code several months ago and afterwards we got unexpected crashes. Problem was that the config was accessed in a separate thread. You have to access the python config value in the main thread. Otherwise you'll get earlier or later crashes.

[littlesat]

Why should you get a crash on a config? If so we have to fix the threaded stuff for it.... but it was just a suggestion..
As far Remember we had a crash on variable type....

Edited by littlesat, 1 August 2020 - 11:26.

[betacentauri]

Here is the mentioned commit:

https://github.com/O...189ce982d80a5f2

[littlesat]

Indeed.... but it also gives the solution....

[IanSav]

Hi Persian Prince,

 

I stand corrected.  So perhaps your data set can be used as the starting point model for a combined effort.

 

Regards,

Ian.

[IanSav]

Hi WanWizard,

 

The data master can certainly be a text file and that text file can be processed by a central code module.  The shell would need to process the file directly but the C++ and Python layers can either implement their own single APIs to access the data or an API can be created that access the data for both.

 

I am preparing a Python example of an API that I will post when the model is complete.

 

Regards,

Ian.

[littlesat]

You still need more than that as each plugin etc need to get the info on the same way../ otherwise plugins that need that info stay in compatible...

[jenseneverest]

At least everyone seems to agree that real manufacturer help is not going to happen. The time for that passed long ago. 

[IanSav]

Hi Jenseneverest,

 

At least everyone seems to agree that real manufacturer help is not going to happen. The time for that passed long ago. 

 

I am relatively new here but even I can see and appreciate the validity of your comment. 

 

Regards,

Ian.

[WanWizard]

The data master can certainly be a text file and that text file can be processed by a central code module.  The shell would need to process the file directly but the C++ and Python layers can either implement their own single APIs to access the data or an API can be created that access the data for both.

 

Not debating that, just saying that the only important thing at the moment is an agreement on that API, from shell, from C, and from Python.

 

The rest is black box, behind that interface, and it is up to every individual team how to implement that. Therefore, implementation is afaiac out of scope of the current discussion.

 

And as long as there is no cross-team agreement on that interface, implementing anything is a waste of time.

[WanWizard]

At least everyone seems to agree that real manufacturer help is not going to happen. The time for that passed long ago. 

 

Never thought that would happen...

[IanSav]

Hi,

 

Okay, here is a prototype of a Python API that could be used to manage the boxinfo data.  I suggest that this become "Tools/BoxInfo.py".  Currently there are 4 proposed methods "loadBoxInfo()", "getItem(key, default)", "setItem(key, value)" and "deleteItem(key)".

1. loadBoxInfo() reloads the "/etc/enigma2/boxinfo" file.  This is automatically done when the code first loads but the method can force a reload at any time.
2. getItem(key, default) returns the current value of the item key if it exists or default if it doesn't.
3. setItem(key, value) sets the key to value.  Returns True if it worked or False if that key is immutable.
4. deleteItem(key) deletes the key.  Returns True if it worked or False if the key did not exist or is immutable.

The keys should be the text strings that we previously discussed in "boxinfo.txt" file.

 

This code could either replace the SystemInfo module or else compliment it.

 

What do people think?

 

Regards,

Ian.

 

Attached Files

•  BoxInfo.py   2.1KB   9 downloads
•  BoxInfo.txt   2.99KB   6 downloads

[WanWizard]

I doubt you'll ever get this past the other image teams, as they are currently using different methods for each value, instead of a generic getItem().

[IanSav]

Hi WanWizard,

 

You asked for an API proposal that fits in with using the text file as a base so I put this forward for people to consider.

 

If some solid ideas are presented then perhaps we can workshop the ideas into something that everyone can agree upon.  As you were the only person with some specific requirements I coded this with those requirements in mind. 

 

Regards,

Ian.

[WanWizard]

I have no problem with it, for me

boxinfo.getItem('somevalue', False)

is the same as

boxinfo.getSomeValue(False)

And a lot more extendable.

 

For OE-A images, it would mean moving their current boxbranding code to boxinfo, and use it as a stub for code that hasn't been converted to boxinfo yet:

import boxinfo

def getMachineName()
    return boxinfo.getItem('MachineName', "")

[littlesat]

SystemInfo is already somehow doing this..... as you have the same with dicts in python.... then instead of Boxinfo you can already do SystemInfo and extend that...