772 replies to this topic

[WanWizard]

The API is provided to the upper layers as a hardware abstraction layer. It shields the application (enigma + plugins) from the complexities of the supported underlying hardware).

 

An abstraction API is explicitly NOT something that returns a simple data structure that the code deals with directly. If you have that in mind (you are clearly not alone then), you've missed the entire point.

 

The main point here is "abstraction". Which means that code should NEVER make any logic decisions on whatever data is returned, that (string) data is for display purposes only.  If this design rule isn't followed, and the functionality of code depends on the (format of) data returned, the entire abstraction is pointless.

 

This implies that there should be a governing body that manages and versions the API, on behave of all teams, to make sure the API provides the functionality each team needs.

 

For example, ATV wants to know if a box has RCA audio output. So the API needs a "hasRCAAudio" method, returning a boolean. They should not have to resort the all the code currently in the SystemInfo's of this world, that should all be removed.

 

The same is true for all interaction with the hardware. For example, to interact with the box LED, don't access proc entries, but call API->setMainLED(0...100) (i.e. a percentage). It is then up to the abstraction layer to deal with the value passed. It can be ignored or throw an exception (box doesn't have a LED), converted to a binary value (box only knows on and off), or used to control the intensity.

 

The calling code (enigma or plugin) shouldn't be bothered with how this works, or even if this works, it is hidden in the abstraction layer.

 

It is the task of the governing body (to give an example) to decide whether or not the aforementioned method ignores the call or throws an error. If it throws an error, it probably also needs a hasFrontLED() or something.

 

The API is not something simple, a one-time thing, it will constantly evolve, and it needs governing to ensure compatibility for all teams involved.

[littlesat]

...

Edited by littlesat, 31 August 2020 - 06:30.

[IanSav]

Hi WanWizard,
 

An abstraction API is explicitly NOT something that returns a simple data structure that the code deals with directly. If you have that in mind (you are clearly not alone then), you've missed the entire point.

 

I am not sure what you mean by this.  Surely the point of this API is to return simple, abstracted data, that code can use without needing to know the intricacies of the hardware or the underlying code that produced that data.

 

The main point here is "abstraction". Which means that code should NEVER make any logic decisions on whatever data is returned, that (string) data is for display purposes only.  If this design rule isn't followed, and the functionality of code depends on the (format of) data returned, the entire abstraction is pointless.

 
I don't think this paragraph meshes with the rest of your post.  I don't actually agree with this paragraph while I do support everything else you said.
 
Regards,
Ian.

[rantanplan]

As someone who has been tinkering e2 for himself for years, but would never claim to really know his way ...
I would also say something about it
For me such queries are an occasional necessary evil.
In general, however, it does not lead to a simplification of the code in any case.
It also won't cause the teams to work closer together. But on the contrary.
The smaller the team, the more busy they are with breaking down any codes and can then no longer deal with the essentials.
That is already the case.
For people like me who tinker with the matter, it is impossible to resolve everything first before you can possibly contribute something.
Larger teams, or teams with one or the other excellent coder, use this more to protect themselves from other teams.
That all leads to the respective classified information.
Then there will be less and less desire to participate.
Unfortunately it is the way of isolation and I think it's a shame.
Will a lot of people then still be interested in the project?
It must be and remain transparent.
If (and this is the danger) something like this develops into permanent code change just because someone can do it, then nobody benefits.
This is also an indication of the topic of starters.
greetings

[WanWizard]

I am not sure what you mean by this.  Surely the point of this API is to return simple, abstracted data, that code can use without needing to know the intricacies of the hardware or the underlying code that produced that data.

 

As soon as you start doing that, you make code dependent on the implementation of the API itself, which defeats its purpose.

 

A simple and maybe stupid example:

 

Say the API has a method "getMachineName()". For the Zgemma H9 Combo and Zgemma H9 Twin, we both return "h9combo" (as that is what we use for MACHINE). But OE-A images return "h9combo" and "h9twin".

Which means that any code that does if  getMachineName() == "h9twin" will fail on OpenPLi.

 

This should be avoided at all costs.

 

If there is a legitimate reason to be able to distinguish the "h9combo" from the "h9twin" (following the example), the API should have a method for that, that will internally test the difference and return a boolean. It will then be up to the teams how to implement this inside the API, but the implementation will be shielded from Enigma or the plugin.

 

I don't think this paragraph meshes with the rest of your post.  I don't actually agree with this paragraph while I do support everything else you said.

 

Then you failed to have understand what the hardware abstraction layer should do.

 

Any attempt of either Enigma or a plugin to apply logic to strings being returned will potentially make that code break on other images, as it is up to each individual team to implement the API, and decide what data to return.

[WanWizard]

To be clear:

 

I am talking about a proper hardware abstraction layer, not a simple list of values like OE-A has implemented, or OpenVision is proposing.

 

You can compare it with the DVB API that is used by Enigma. The hardware drivers provide the API, following the DVB API v5 specification. What happens inside the drivers, and how it interacts with the hardware, is from Enigma's perspective a black box.

 

And since not everything is catered for by the API, you see Enigma use ioctl's to access the hardware directly. Which introduces all sorts of "if thisbox then...." code, because each vendor has its own hardware implementation.

 

I want to avoid that.

[littlesat]

I want to avoid that

+1... and once done code (at high level) will be less complicated...

[Huevos]

 

I am not sure what you mean by this.  Surely the point of this API is to return simple, abstracted data, that code can use without needing to know the intricacies of the hardware or the underlying code that produced that data.

 

As soon as you start doing that, you make code dependent on the implementation of the API itself, which defeats its purpose.

 

A simple and maybe stupid example:

 

Say the API has a method "getMachineName()". For the Zgemma H9 Combo and Zgemma H9 Twin, we both return "h9combo" (as that is what we use for MACHINE). But OE-A images return "h9combo" and "h9twin".

Which means that any code that does if  getMachineName() == "h9twin" will fail on OpenPLi.

 

This should be avoided at all costs.

 

If there is a legitimate reason to be able to distinguish the "h9combo" from the "h9twin" (following the example), the API should have a method for that, that will internally test the difference and return a boolean. It will then be up to the teams how to implement this inside the API, but the implementation will be shielded from Enigma or the plugin.

 

I don't think this paragraph meshes with the rest of your post.  I don't actually agree with this paragraph while I do support everything else you said.

 

Then you failed to have understand what the hardware abstraction layer should do.

 

Any attempt of either Enigma or a plugin to apply logic to strings being returned will potentially make that code break on other images, as it is up to each individual team to implement the API, and decide what data to return.

 

Which is why box branding works. i.e. we are all using the same data. Anyway if the point of this API is to return data that is not fit for use in logic I can't see any value in the API.

[WanWizard]

Yes, and that is why the current boxbranding solutions are useless for a cross-image solution.

 

It returns a data stucture, with all logic either in Enigma or in each individual plugin. Code like exists in SystemInfo should NOT exist in Enigma, it should be in the API, hidden from Enigma and plugins, because not every image is the same!

 

It saddens me that there is absolutely no one here with this level of application architecture and design knowledge to understand this. It probably explains why Enigma development is virually dead...

[WanWizard]

From ATV an example:

	def getDefaultKeyboardMap(self):
		# This is a code proposal to make the default keymap respond
		# to the currently defined locale.  OpenATV initialises the
		# keymap based on hardware manufacturer.  Making the
		# selection based on language locale makes more sense.  There
		# are other code changes coming that will allow this to happen.
		#
		# locale = language.getLocale()
		# if locale.startswith("de_") and "de.kmap" in self.keyboardMaps:
		# 	return "de.kmap"
		from boxbranding import getMachineBrand
		if getMachineBrand() in ("Zgemma", "Atto.TV"):
			return "us.kmap"
		elif getMachineBrand() == "Beyonwiz":
			return "eng.kmap"
		return "de.kmap"

This method should be part of the API, not in Enigma.

 

https://github.com/o...onents/About.py is another great example of code that should not be in Enigma.

 

So boxbranding is a very basic start of a proper abstraction layer, but never properly implemented...

[IanSav]

Hi WanWizard,

 

If you believe that we don't understand the issues then perhaps you should document them and what you are advocating in more detail with some examples.

 

Regards,

Ian.

[WanWizard]

I just did so, in my previous post?

[Persian Prince]

We have

	if socfamily in ("7376","7444"):
		modes["DVI"] = ["720p", "1080p", "2160p", "1080i", "576p", "576i", "480p", "480i"]
		widescreen_modes = {"720p", "1080p", "1080i", "2160p"}
	elif socfamily in ("7252","7251","7251s","7252s","72604","7278","3798mv200","3798cv200"):
		modes["DVI"] = ["720p", "1080p", "2160p", "2160p30", "1080i", "576p", "576i", "480p", "480i"]
		widescreen_modes = {"720p", "1080p", "1080i", "2160p", "2160p30"}
	elif socfamily in ("7241","7358","7362","73625","7356","73565","7424","7425","7435","7581","3716mv410") or brand == "azbox":
		modes["DVI"] = ["720p", "1080p", "1080i", "576p", "576i", "480p", "480i"]
		widescreen_modes = {"720p", "1080p", "1080i"}
	elif chipsetstring == "meson-6":
		modes["DVI"] = ["720p", "1080p", "1080i"]
		widescreen_modes = {"720p", "1080p", "1080i"}
	elif chipsetstring in ("meson-64","S905D") or socfamily == "AML905D":
		modes["DVI"] = ["720p", "1080p", "2160p", "2160p30", "1080i"]
		widescreen_modes = {"720p", "1080p", "1080i", "2160p", "2160p30"}
	else:
		modes["DVI"] = ["720p", "1080i", "576p", "576i", "480p", "480i"]
		widescreen_modes = {"720p", "1080i"}

in Open Vision but I think WanWizard wants

		modes["DVI"] = getDVImodes()
		widescreen_modes = getWSmodes()

something like I did for our RcModel.py:

#!/usr/bin/python
# -*- coding: utf-8 -*-
import os
from Tools.Directories import SCOPE_SKIN, resolveFilename
from boxbranding import getRCName

class RcModel:
	def __init__(self):
		pass

	def getRcFile(self, ext):
		remote = getRCName()
		f = resolveFilename(SCOPE_SKIN, 'rc_models/' + remote + '.' + ext)
		if not os.path.exists(f):
			f = resolveFilename(SCOPE_SKIN, 'rc_models/dmm1.' + ext)
		return f

	def getRcImg(self):
		return self.getRcFile('png')

	def getRcPositions(self):
		return self.getRcFile('xml')

rc_model = RcModel()

Am I thinking correct?

Edited by Persian Prince, 2 September 2020 - 18:34.

[WanWizard]

Yes, correct.

 

And this is why cross-team governance is needed, as OpenPLi might not need those methods, but OpenVision does, and we need to make sure methods are implemented consistently.

 

It also means that, following this example, if a new box with for example an Xilinx SoC comes along, no code changes are needed in Enigma or plugins, it will work automatically when the box is added to the abstraction layer implementation.

[Huevos]

I don't get it. What is the remote control doing in this API? You can run whatever remote you like.

 

And anyway box branding already puts the default remote in /usr/share/enigma.

 

Also PP's example is code that depends on box branding, so nothing new, just variable swapping.

Edited by Huevos, 2 September 2020 - 20:27.

[Persian Prince]

I don't get it. What is the remote control doing in this API? You can run whatever remote you like.

 

And anyway box branding already puts the default remote in /usr/share/enigma.

 

Also PP's example is code that depends on box branding, so nothing new, just variable swapping.

This is what OE-A has: https://github.com/o...ding/RcModel.py

 

This is what we have: https://github.com/O...ents/RcModel.py

 

And you want to tell me the OE-A one is better?! 418 lines VS 24 lines!

 

About the example that was a question for WanWizard so I could understand what exactly he means and I'm working on it to have only 2 lines.

[Huevos]

Also, not sure what that code is... We already have that stuff in SystemInfo...

SystemInfo["VideoModes"] = getChipSetString() in (  # 2160p and 1080p capable hardware...
	"5272s", "7251", "7251s", "7252", "7252s", "7278", "7366", "7376", "7444s", "72604", "3798mv200", "3798cv200", "hi3798mv200", "hi3798cv200"
) and (
	["720p", "1080p", "2160p", "1080i", "576p", "576i", "480p", "480i"],  # Normal modes.
	{"720p", "1080p", "2160p", "1080i"}  # Widescreen modes.
) or getChipSetString() in (  # 1080p capable hardware...
	"7241", "7356", "73565", "7358", "7362", "73625", "7424", "7425", "7552"
) and (
	["720p", "1080p", "1080i", "576p", "576i", "480p", "480i"],  # Normal modes.
	{"720p", "1080p", "1080i"}  # Widescreen modes.
) or (  # Default modes (neither 2160p nor 1080p capable hardware)...
	["720p", "1080i", "576p", "576i", "480p", "480i"],  # Normal modes.
	{"720p", "1080i"}  # Widescreen modes.
)

 

[Huevos]

 

I don't get it. What is the remote control doing in this API? You can run whatever remote you like.

 

And anyway box branding already puts the default remote in /usr/share/enigma.

 

Also PP's example is code that depends on box branding, so nothing new, just variable swapping.

This is what OE-A has: https://github.com/o...ding/RcModel.py

 

This is what we have: https://github.com/O...ents/RcModel.py

 

And you want to tell me the OE-A one is better?! 418 lines VS 24 lines!

 

About the example that was a question for WanWizard so I could understand what exactly he means and I'm working on it to have only 2 lines.

 

I don't get what you are saying. Your code just downloads from box branding. So box branding does all the work, and then you add 24 lines of code to read a variable from box branding.

[Persian Prince]

 

 

I don't get it. What is the remote control doing in this API? You can run whatever remote you like.

 

And anyway box branding already puts the default remote in /usr/share/enigma.

 

Also PP's example is code that depends on box branding, so nothing new, just variable swapping.

This is what OE-A has: https://github.com/o...ding/RcModel.py

 

This is what we have: https://github.com/O...ents/RcModel.py

 

And you want to tell me the OE-A one is better?! 418 lines VS 24 lines!

 

About the example that was a question for WanWizard so I could understand what exactly he means and I'm working on it to have only 2 lines.

 

I don't get what you are saying. Your code just downloads from box branding. So box branding does all the work, and then you add 24 lines of code to read a variable from box branding.

 

Check our boxbranding and compare it with OE-A you'll get which one is faster with less code, if you don't care about speed and having simple checks then that RcModel.py with 418 lines of code is what you need exactly.

 

This discussion is about to provide "something" to do exactly what you think is "right to do inside enigma2" which is "100% wrong" in our opinion here!

[Huevos]

from boxbranding import getRCName

It is just reading a value from boxbranding.so.

 

Is that what this API is about?