772 replies to this topic

[Huevos]

API is just presentation... and sorry if I disappoint you...

 

My question to you is if you don't want the data to come from the build, where is it going to come from?

[Huevos]

If anyone can send in PR's that anyone can accept, and we don't have any say it in, anyone can completely break OpenPLi at any point in time, it is not indepdent, and that is unacceptable.

 

Is that so hard to understand?

Yes it is really difficult to understand when most of the stuff that makes up what you build at the moment you already have no control over. Literally hundreds of files in sources.

[WanWizard]

API is just presentation... and sorry if I disappoint you..

 
No, the API is a definition, something external components can rely on. Like a C++ method or a Python function, all you need to know is the API (what are the parameters, what type are they, what input is required, what does the method return, which exceptions does it throw, etc), how it is implemented is not relevant.
 
If we want plugins to be compatible across images, this is very important. It should not be maintained one-sided by one team. If that team decides to make a backward incompatible change, they will break all other images, and that is unacceptable. And we know that will happen, as that is the entire reason of the existence of OE-A.
 

My question to you is if you don't want the data to come from the build, where is it going to come from?

 

We can decide ourselfs how to do that. It cloud be hardcoded (which would reduce the code considerably and make it faster), it could come from a file (either at compile time or runtime), etc.

 

But again, not relevant for this discussion. All that is relevant is that every team uses the same API, so that any plugin that calls a boxbranding method can depend on getting a result back.

 

So we can finally stop duplicating effort on multiple versions of plugins.

[littlesat]

Implementation != API... I understand Huevos. I know it is difficult to forget about an implementation you think that is perfect and therefore forgot the ‘helicopter’ view...
Btw for the box name we e2 had already an api as far I now via About.py.
First I think we should start with a question: Why do plugins need a branding module? And maybe also a question how can we solve it differently?.... maybe we do not need a branding module at all for plugins?!

Edited by littlesat, 16 July 2020 - 07:03.

[Taapat]

If we talked only about the API for the box name, then of course it doesn't matter what result the API gets, because it's just the name in the text.

But I think we need such API for all box specific things.

And in that case, for a universal plugin, it is important to get the same result from the API regardless of the image.

Of course the implementation can vary in each image, but not only the API but also the API response should be the same in all images.

[Taapat]

I can imagine where it is necessary to use a box name not just as text. This is a specific manufacturer specific bug (for example in drivers) that not exist on another manufacturer's same hardware box.

In that case, you need an exception for a specific box.

By the way, SystemInfo has many such box-specific exceptions, which is renamed as hardware-specific things.

But regardless of the name, they are still box-specific exceptions because they are derived from the box name.

Edited by Taapat, 16 July 2020 - 07:31.

[littlesat]

Yes years ago I moved all box specific things to SystemInfo.py and tried to go for a feature driven system.... so SystemInfo.py was the only place with if box x then do y.... but actually we should totally get rid of this somehow as well... and likely this should also be involved in the api we try to define maybe we can also remove the global dict that way...

Edited by littlesat, 16 July 2020 - 07:52.

[Persian Prince]

https://github.com/O...e-core/pull/842 will do it for PLi if you're up for it.

[littlesat]

This puts just the machine name in a proc.... if we go that way why not put all stuff we are doing now in systeminfo.py + more in one ‘thing’?

[Persian Prince]

This puts just the machine name in a proc.... if we go that way why not put all stuff we are doing now in systeminfo.py + more in one ‘thing’?

Yes exactly that's what I suggest, something not so complicated

 

If we agree to use

/proc/stb/info/enigma2model

and more like

/proc/stb/info/enigma2brand
/proc/stb/info/enigma2type

we could get rid of all

/proc/stb/info/hwmodel
/proc/stb/info/gbmodel
/proc/stb/info/boxtype
/proc/stb/info/vumodel
/proc/stb/info/azmodel

then reduce the checks and use it everywhere we want as we could check it inside Python, C and Shell so easy.

 

Each team could provide their desired info but at least we use the same path

 

MACHINE name is the best to provide and check instead of relying on a proc file provided by manufacturers.

[littlesat]

If you do it this way why multiple procs while you can give all in one proc string?

Edited by littlesat, 16 July 2020 - 11:15.

[WanWizard]

If we talked only about the API for the box name, then of course it doesn't matter what result the API gets, because it's just the name in the text.

But I think we need such API for all box specific things.

And in that case, for a universal plugin, it is important to get the same result from the API regardless of the image.

Of course the implementation can vary in each image, but not only the API but also the API response should be the same in all images.

 

Exactly. Finally someone who understands it.

[WanWizard]

If you do it this way why multiple procs while you can give all in one proc string?

 

Please read, as that  is EXACTLY what he is proposing.

 

p.s. if we have a universal solution for boxbranding, then backupsuite can also use that, and a new proc node is no longer needed ( = a typical example of why we need it, and why it needs to be universal! )

[Huevos]

 

This puts just the machine name in a proc.... if we go that way why not put all stuff we are doing now in systeminfo.py + more in one ‘thing’?

Yes [...] MACHINE name is the best to provide and check instead of relying on a proc file provided by manufacturers.

 

Except MACHINE in OE-A distros contains something totally different to what it does in PLi (which I already explained). That means this can never work cross distro.

 

And if you don't understand this you need to look in the makefile. i.e. the names of the boxes in the PLi build do not correspond with the names of the boxes in the OE-A build. That means this can't be used in common plugins. So what point is there to it?

Edited by Huevos, 16 July 2020 - 16:09.

[foxbob]

root@et1x000:~# cat /proc/stb/info/enigma2model
et1x000

root@et1x000:~# cat /proc/stb/info/model
dm800se

[littlesat]

(quote]Please read, as that  is EXACTLY what he is proposing.[/quote]

nope.... two procs wherry suggested. One for brand and one for model....

 

cat /proc/stb/info/branding

model=h9combo

brand=Zgemma

....etc....

 

but again this is implementation....

 

At the end you need a function... and that we already have via /Components/About.py for a long long time... 

Edited by littlesat, 16 July 2020 - 16:47.

[Taapat]

Except MACHINE in OE-A distros contains something totally different to what it does in PLi (which I already explained). That means this can never work cross distro.
 
And if you don't understand this you need to look in the makefile. i.e. the names of the boxes in the PLi build do not correspond with the names of the boxes in the OE-A build. That means this can't be used in common plugins. So what point is there to it?

 

I understand this as follows.
If you use a box name to display it in about the screen, it doesn't matter what exactly name is displayed.
If you need a box name to define a hardware-specific case, for example DVB-S support, you need to implement in the API key DVB-S support, and use it instead of the box name.

How you in distro get this DVB-S support key in the API doesn't matter. The API only needs to give the same result in all distros for the DVB-S support key.

[WanWizard]

Exactly.

[Persian Prince]

This puts just the machine name in a proc.... if we go that way why not put all stuff we are doing now in systeminfo.py + more in one ‘thing’?

Yes [...] MACHINE name is the best to provide and check instead of relying on a proc file provided by manufacturers.

Except MACHINE in OE-A distros contains something totally different to what it does in PLi (which I already explained). That means this can never work cross distro.
 
And if you don't understand this you need to look in the makefile. i.e. the names of the boxes in the PLi build do not correspond with the names of the boxes in the OE-A build. That means this can't be used in common plugins. So what point is there to it?

It doesn't matter what kind of name you wanna give it as long as we use a same path with some information we need.

Some infornation would be the same some with differences.

[Persian Prince]

root@et1x000:~# cat /proc/stb/info/enigma2model
et1x000
root@et1x000:~# cat /proc/stb/info/model
dm800se

Most of the times /proc/stb/info/model is fake because stupid companies wanted to cheat DMM locks and at last they became garbage code.