772 replies to this topic

[Abu Baniaz]

Lots of things are already obtained from systeminfo. OE-A images feeds this with some data from box branding, machine features as well as manual entries. PLI do similar but with hardware info.

Surely it makes sense to continue with that process? If that is agreed you can then go on to cross reference/replace names so that Enigma2 code reads variables from one place (API).

However, it won't resolve issues that are at build level.

Sent from my Moto G (5S) using Forum Fiend v1.3.3.

[WanWizard]

I don't care what it is, or how it is called. The point is that all images use the same interface. For EVERYTHING.

 

I know for example that lots of code in the OE-A world call boxbranding functions directly. So all that will have to go before a system like this is going to work. It really needs to be an abstraction layer.

[WanWizard]

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...

 

That won't work as it is a Python only solution. Unless it is generated during the build, together with the C and shell equivalent.

[IanSav]

Hi Guys,

 

I called the proposal "BoxInfo" because some people perceive an issue with "SystemInfo".  There was some quite specific objection to the "SystemInfo" name so I thought it appropriate to base the proposal on a different name to get all people to look as the proposal.  I don't care if the actual program is called "SystemInfo", or anything else for that matter .  If we choose to stay with "SystemInfo" the we just need to transition from direct access to the dictionary items to an API interface.  If people are happy to accept the name "SystemInfo" I am more than happy to rename the proposal.

 

@WanWizard, what API do you think will be applicable for a shell?  I would have thought that we would use normal shell commands to directly access the source data in "/etc/enigma2/systeminfo".  For C++ I would assume that the data could be obtained via the Python API layer.  I am thinking that the Python API should be dominant as I suspect that most interaction with the API will be at the Python layer.  If that is deemed unacceptable then it would be easy to write an equivalent C++ API that also uses the same base data in "/etc/enigma2/systeminfo".

 

Regards,

Ian.

[Abu Baniaz]

If you are going to use a different file to system info, best to use a different name.

Sent from my Moto G (5S) using Forum Fiend v1.3.3.

[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...

That won't work as it is a Python only solution. Unless it is generated during the build, together with the C and shell equivalent.

That was why I came up using the config system.... that is already available in cpp (except for threaded cpp a work a round is needed)..: why don’t use stuff that is already doing it?! The. You also have one ‘master’ without duplicates and experts may also manipulate it via /etc/settings... but again this is implementation...

Edited by littlesat, 2 August 2020 - 08:20.

[IanSav]

Hi Littlesat,

 

Regarding the config option, if I was looking at the correct code in C++ I noticed that there were deliberate delays to wait for code to synchronise.  If that is really the type of implementation that you prefer then I will need to voice a vote against any such code.  Any code that relies on random timed sleeps or delays to make the code would should never be used as a preferred solution.  Too many code failures occur because of timing errors.  This should not be our preferred design.

 

Regards,

Ian.

[littlesat]

Where did you find that wait stuff?

[WanWizard]

Can I pull this discussion back up to helicopter level please?

 

We need a solution for:

• Python
  This should be a pure Python interface, again with no dependencies.
   
• C
  This should be a pure C interface, with no dependencies.
   
• (Bash) Shell
  This requirement dictates it should either be a file you can source in your bash script, or an executable you can call which returns the requested value. The executable has my preference, as it provides more flexibility to add logic (which we need in our 1 MACHINE = multiple models system). Given the environment we're in, it could either be a C binary (using the C interface internally) or a Python script, using the Python interface internally.

For all it is true that what happens behind the interface is a black box, implementation, and therefore not relevant for this discussion.

 

As to implementation, If we as OpenPLi decide that the C method should call a Python method to retrieve a value, it is entirely up to us. Not relevant for other teams, and not relevant for developers that need access to the box data. However, given the fact that Littesat's suggestion of using the Config system means you have to run under Enigma, and bash scripts don't, that rules that sort of implementation out.

 

The most logical is, like others have already discovered, is to create a OE level solution, that slots into Enigma at compile time.

 

But again, it is pointless talking about implementation as long as we don't have all other teams on board.

[Huevos]

 

 

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...

That won't work as it is a Python only solution. Unless it is generated during the build, together with the C and shell equivalent.

That was why I came up using the config system.... that is already available in cpp (except for threaded cpp a work a round is needed)..: why don’t use stuff that is already doing it?! The. You also have one ‘master’ without duplicates and experts may also manipulate it via /etc/settings... but again this is implementation...

 

Using "config system" is just another workaround/hack. And relies on enigma being active. BoxBranding never needed enigma to be active, so definitely a backwards step.

Edited by Huevos, 2 August 2020 - 14:53.

[littlesat]

A simple (read only) file or proc already solve that.... without boxbranding code running in a thread...

Edited by littlesat, 2 August 2020 - 15:19.

[Huevos]

@WanWizard, OpenATV already have a "CPP" implementation. It is called "modelinformation". And is also available in Python.

 

https://github.com/o...information.cpp

[littlesat]

Yes openatv had it.... we already know that... but is is not a holy gray... it is an implementation or should I also call it hack?!. we’re trying to design something better...
Actually that thing is reading a static file and creates a dictionary of it.... so another clone of something that we already have on a file and double in python... then better keep it somehow once and swig it.

Edited by littlesat, 2 August 2020 - 15:29.

[WanWizard]

@WanWizard, OpenATV already have a "CPP" implementation. It is called "modelinformation". And is also available in Python.

 

https://github.com/o...information.cpp

 

I could live with that API without issues. What is the E2 equivalent, as that doesn't seem to be called ModelInformation? Or do you mean call eModelInformation from Python?

 

Just wondering though,why if ATV has this, is their E2 code littered with boxbranding calls?

[Abu Baniaz]

@Wanwizard, you keep refering to one box for multiple receivers. And your posts suggests that you are implying that OE-A do not have it. Are you 100% sure of this? For Example, the Ceryon, Ini, Dags have "family" of receivers where most of the code is the same but allows you to  have specific/unique attributes for the "siblings" in the family. The build process duration for first child is as normal, but for second, third child, minor adjustments are made.

[Abu Baniaz]

 

Just wondering though,why if ATV has this, is their E2 code littered with boxbranding calls?

 

 

Because boxbranding allows you to check for features a machine/box has. An example in Vix which came off some changes in ATV. But as you say, that can be moved into the API so that E2 code just refers to the API.

 

https://github.com/O...Picon.py#L7:L13

 

 

 

 

 

 

[WanWizard]

@Wanwizard, you keep refering to one box for multiple receivers. And your posts suggests that you are implying that OE-A do not have it. Are you 100% sure of this? For Example, the Ceryon, Ini, Dags have "family" of receivers where most of the code is the same but allows you to  have specific/unique attributes for the "siblings" in the family. The build process duration for first child is as normal, but for second, third child, minor adjustments are made.

 

No, I wrote "one MACHINE for multiple receivers". As in the OE definition of MACHINE. Using your example, we build 1 image for all incarnations of the "dags family", OE-A builds 1 image for every receiver in that family.

 

Not really relevant for the discussion, the only point I want to make is that the implementation can be different from one image team to the next, dependent on their requirements. That doesn't change the API.

 

Because boxbranding allows you to check for features a machine/box has. An example in Vix which came off some changes in ATV. But as you say, that can be moved into the API so that E2 code just refers to the API.

 

That doesn't explain why both boxbranding and modelinformation exist, since they seem to serve exactly the same purpose.
 

[Abu Baniaz]

It is very relevant because your objection to branding module as the API is mainly based on that misconception.

 

That doesn't explain why both boxbranding and modelinformation exist, since they seem to serve exactly the same purpose.

 

They are two different things, model information won't show you what a model can do.

 

To me, we already have an API for Enigma2 code, systeminfo.py. We need to expand it and import other definitions/functions. Yes, some of the definitions on OE-A images are in box branding, but it is a minor change to add them to system info. But you then get the "why not get data directly from source?" debate from those who do not accept your API need/definition.

 

For other higher level factors, boxbranding does that for OE-A images. Once the notion that "one image for multiple receivers"  is reconsidered as "one biscuit packaged in different wrappers", lots of things will fall in place.

 

BTW, OpenEight and TeamBlue are part of OE-A and they use mainly PLI E2 as far as I know.

[Huevos]

Yes openatv had it.... we already know that... but is is not a holy gray... it is an implementation or should I also call it hack?!. we’re trying to design something better...
Actually that thing is reading a static file and creates a dictionary of it.... so another clone of something that we already have on a file and double in python... then better keep it somehow once and swig it.

It is already accessible from Python.

[Huevos]

It is very relevant because your objection to branding module as the API is mainly based on that misconception.

 

 

That doesn't explain why both boxbranding and modelinformation exist, since they seem to serve exactly the same purpose.

 

They are two different things, model information won't show you what a model can do.

Actually it has the full range of static info, very similar to boxbranding.

https://github.com/o...info.bb#L23-L68