Jump to content


Photo

One proc file for detecting the MACHINE in all enigma2 images.


  • Please log in to reply
206 replies to this topic

Re: One proc file for detecting the MACHINE in all enigma2 images. #201 WanWizard

  • Forum Moderator
    PLi® Core member
  • 53,852 posts

+1,071
Excellent

Posted 2 August 2020 - 22:48

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

 

Not sure where you got that from, I have no objection against anything.
 

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.

 

They are two different things, because OE-A / ATV has implemented them that way. Both return information about the hardware and OS specifics of the box.

 

Again, I don't care of its called systeminfo, boxbranding, modelinformation or yourgranniesfalseteeth.

 

What I do care about is a proper and universal API design, and the current OE-A / ATV implementation isn't it, it's a collection of bits all over the place, with an implementation all over the place.

 

You don't want to call boxbranding to get A, systeminfo to get B, and modelinformation to get C. Or modelinformation to get A too, but it returns a different value...

 

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

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

 

That makes it even worse, two interfaces to the same (hopefully) or different (potentially) data.

 

It should be replaced by one API, to be used by everyone, everyone. It is the only way to more portable code.


Currently in use: VU+Duo 4K (2xFBC S2), Amiko Viper T2C (T2), Octagon SF8008 (S2+T2), SAB Alpha Triple HD (S2+T2), Zgemma H9.2H (T2+fallback)

Many answers to your question can be found in our new and improved wiki.

note: I do not provide support via PM !

 


Re: One proc file for detecting the MACHINE in all enigma2 images. #202 Huevos

  • PLi® Contributor
  • 2,777 posts

+123
Excellent

Posted 3 August 2020 - 01:18

"two interfaces to the same (hopefully) or different (potentially) data."

 

The data is identical. Both are using the same environmental variables available in the build.



Re: One proc file for detecting the MACHINE in all enigma2 images. #203 littlesat

  • PLi® Core member
  • 51,888 posts

+589
Excellent

Posted 3 August 2020 - 06:51


@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?
Good point.... when using this kind of api then we should also use eModelInformation and not do something else in python.. with also different names... now you touch one of the points I do not like about oe-a’s boxbranding... duplicate things with different names is for me an alarm bell. So now we hit exactly the point!!!!! But doing this in e2 binary also means it is not available when e2 is not running and Huevos just mentioned this is somehow required as well.... And I still do not understand why...

Edited by littlesat, 3 August 2020 - 06:56.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: One proc file for detecting the MACHINE in all enigma2 images. #204 Persian Prince

  • Senior Member
  • 1,755 posts

+237
Excellent

Posted 3 August 2020 - 08:49

 

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.

 

Lots of teams are forking PLi, we (Open Vision), SatDreamGr and most of the times ViX so there will be common grounds don't worry.


If you like my post click on green arrow :)

 

Open Vision image for your STB: https://github.com/OpenVisionE2


Re: One proc file for detecting the MACHINE in all enigma2 images. #205 Abu Baniaz

  • PLi® Contributor
  • 1,647 posts

+38
Good

Posted 3 August 2020 - 09:03

As part of ViX team, I have no objection to an API. My only caveat is there should be no pointless variable name changes, they risk breaking things. If any are made, they should be backward compatible.

I'm sure most of the other ViX members won't object. I'll start thread on ViX Dev side so any objections/concerns can be highlighted.

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

Re: One proc file for detecting the MACHINE in all enigma2 images. #206 littlesat

  • PLi® Core member
  • 51,888 posts

+589
Excellent

Posted 3 August 2020 - 09:08


My only caveat is there should be no pointless variable name changes, they risk breaking things. If any are made, they should be backward compatible.

 

I do not fully agree... Backwards compatible should be a goal of course, but there are borders...

 

Thinks that may break should be fixed and they can be fixed. So no need for backwards compatibility.

 

And as we're open source minded (I hope) we cannot and will not support binary closed source blobs into account.


Edited by littlesat, 3 August 2020 - 09:10.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: One proc file for detecting the MACHINE in all enigma2 images. #207 WanWizard

  • Forum Moderator
    PLi® Core member
  • 53,852 posts

+1,071
Excellent

Posted 3 August 2020 - 11:38

As I see it:

  1. All agree on the API and the interface
  2. Document and version it in a team-neutral place
  3. All teams to implement the interface in the image
  4. Announce to the world this API is the only one that should be used
  5. Convert the current interfaces (systeminfo, boxbranding, emodelinformation, etc) to call the new API.
    This may involve moving code if data is determined dynamically. This will provide backward compatibility.
    I suggest calls print a deprecated warning to the log, so they can be found and traced.
  6. Remove all current interface calls in the teams own E2 and plugin code and replace it by calls to the new API
  7. Plan the phase-out of the old interfaces

Currently in use: VU+Duo 4K (2xFBC S2), Amiko Viper T2C (T2), Octagon SF8008 (S2+T2), SAB Alpha Triple HD (S2+T2), Zgemma H9.2H (T2+fallback)

Many answers to your question can be found in our new and improved wiki.

note: I do not provide support via PM !

 





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users