772 replies to this topic

[WanWizard]

If one team think certain data is important (e.g. 7segment) and another team thinks the same data is not important it has to go with the team that does. And that data must be available in all images. If not the project is dead

 

I never said that, it is absolutely true that the API MUST be the same for all images, otherwise it is not going to work. Code should be able to call has7SegmentDisplay() whether or not the box has one.

 

And to continue on the previous point: is it relevant for the code where has7SegmentDisplay() gets its information from? Whether it comes from an environment variable, generated code, runtime detection, a binary boxbranding process, a custom /proc process, etc?

 

This is the point I am making from day one: the API must abstact the source of the information, so code can rely on a fixed and well defined API, but every team is free on how they implement it, based on what they already have (or plan to have).

[Huevos]

How can we all run the same API and get identical results if the data does not come from the same source?

 

And if the data doesn't come from the same source we need a different API for each distro.

Edited by Huevos, 15 September 2020 - 13:16.

[WanWizard]

Huh?

 

If the API defines this prototype:

bool: has7DigitDisplay(void)

method does not accept any arguments; method returns a boolean, True if the box as a 7-segment display, False if not.

why whould I care how that True or False return value was determined? I only care if it does what it says on the tin.

 

Besides that, since when does the way some piece of data is stored or retrieved say anything about the correctness of it?
 

[XRayhTec]

Hi WanWizard,
"it is absolutely true that the API MUST be the same for all images, otherwise it is not going to work"
I think you have to define this in other words.
The api can be different for different images because answers can come from different sources, but api requests and responses to that request should be same.
Regards,

[Huevos]

How can the API be the same for all distros if the data sources are different?

[littlesat]

Omg

[Huevos]

Omg

I am talking about the internals of the API, not the return values. How can we be certain the data will be identical if the source, storage and retrieval mechanisms are different on every distro.

 

I can't follow this discussion, too abstract and intellectual for me. So now is the plan to build a different API for every distro and hope (and pray) that the return values will be identical, right?

Edited by Huevos, 15 September 2020 - 21:42.

[Huevos]

....

Edited by Huevos, 15 September 2020 - 21:39.

[WanWizard]

I am talking about the internals of the API, not the return values. How can we be certain the data will be identical if the source, storage and retrieval mechanisms are different on every distro.

 

I can't follow this discussion, too abstract and intellectual for me. So now is the plan to build a different API for every distro and hope (and pray) that the return values will be identical, right?

 

And people find it weird I get exasperated?

 

For the last time: the internals are not relevant, and no, there is only ONE API (otherwise, which methods to call?).

 

And for those I have lost along the way: an API is nothing more than documentation. What classes, what methods, what arguments, what return values.

 

In terms that you may understand better: the Python os.path API is defined here: https://docs.python....ry/os.path.html. In it, it describes the method isdir(), like so:

os.path.isdir(path)
    Return True if path is an existing directory. This follows symbolic links, so both islink() and isdir() can be true for the same path.

You understand it, you don't question what isdir() exactly does internally, and you trust that what it returns is correct.

 

Are you now suggesting that if we define a "box API" the same way, you don't trust the differerent image builders to honor the API description and return the correct values? No matter how they are obtained?

 

And even if that is not the case, who cares?

 

Say we decide to have the method has7DigitDisplay() return False hardcoded. So what? Maybe something doesn't work on a specific box as expected, but that is then our problem, and not yours as Enigma or plugin developer. All you need to know is that the method exists, and it returns a boolean.

 

For the same reason, it doesn't matter if that True or False is obtained:

• from a key=value text file inserted during the box for every specific box
• from a boxbranding binary compiled from box specific source during the build
• from runtime detection of proc entries and values
• ...

In all cases you can trust you get a boolean back if you call the method in your code. And you don't need to know more.

[IanSav]

Hi,

 

I think that XRayhTec has expressed the appropriate reactions.  It may not matter how the information is acquired what *is* important is that when an API call is used the *exact* same information must be provided from *every* image for the same hardware.

 

Huevos appears to be concerned, with reasonable logic, that if the source information is obtained in different ways from different sources that the data returned from the common API calls may not always be consistent.  This is a very valid concern.

 

I accept that we need to expand and refine that data set proposals in the BoxInfo.txt file and then work on ensuring that all images do provide consistent results.  During implementation it may well be found and proved that we *do* need to have more in common at the back end.  Time will tell.

 

Regards,

Ian.

[Huevos]

isdir() is written by Python developers. It is the same for all users.

 

Right now you are talking about every team having its own API and the only thing in common (if we are lucky) is the return values.

 

I thought the purpose of this discussion was to produce an app that could be used on all distros, not just a set of rules that all teams must follow.

[WanWizard]

You thought wrong.

 

Guess you haven't been paying attention, every time I wrote that is is about design and not implementation.

 

So, it boils down to the old issue here: "we are better than you, and we don't trust you to do your job".  Great. So it ends here, this is an attitude I can't fight against.

 

Huevos appears to be concerned, with reasonable logic, that if the source information is obtained in different ways from different sources that the data returned from the common API calls may not always be consistent.  This is a very valid concern

 

No, it is not.

 

Give me one example, only one, where it actually is a problem if the data is not consistent.

[IanSav]

Hi WanWizard,

 

You request for an a response will force me to make guesses about the API that you will probably reject.  I will try to respond as best I can in abstract terms.

 

let us say that one of the API calls returns some statistic about the hardware.  If the results returned from the API are different then the image may change the UI in some inappropriate or incompatible way.  The issue could be slight or it could be significant.  For example, if for some reason the APIs return different opinions about MultiBoot this could result in one image offering the MultiBoot menu option and another believing that MultiBoot is not available or has different parameters may not offer the option or else offer different parameters.

 

I used this example specifically as we already already seen issues with MultiBoot between images.  Differences already matter.

 

Regards,

Ian.

[WanWizard]

That doesn't help, as it is not an example.

 

The only reason I can think of where it can go wrong, is that the API method returns a string, and the code is going to make some assumptions about the value of the string returned.

 

Which is a great example of what NOT to do, as soon as you code up something like that, you haven't understood the word "abstraction", and you invalidate the reason for the abstraction layer to be there in the first place

 

If an API method doesn't return what it should, there could only be two reasons:

1. It is not properly documented, it wasn't clear enough about function, arguments or return values.
2. The person that implemented it made an honest mistake, so it should be fixed.

In general, as explained about a million times now, if you are using a return value from an API to deduce other values, you're doing it wrong!

 

But as you refuse to give clear examples, I can't show you that it is wrong, and why.

[WanWizard]

let us say that one of the API calls returns some statistic about the hardware.  If the results returned from the API are different then the image may change the UI in some inappropriate or incompatible way.  The issue could be slight or it could be significant.  For example, if for some reason the APIs return different opinions about MultiBoot this could result in one image offering the MultiBoot menu option and another believing that MultiBoot is not available or has different parameters may not offer the option or else offer different parameters.

 

Ok, so lets say for arguments sake that is the case.

 

Now what is the problem with that? Does the box crash? Does it record everything in purple? Does it encrypt the flash?

 

No. Nothing happens, other than possibly the user complaining to the builder of the image. Which is that builders problem, not your problem, and not the problem of all other image builders out there, as they are not affected.

[IanSav]

Hi WanWizard,

 

Any malfunction of any image due to this core shared function should be a concern to all!

 

You insisted that this early stage ge general discussions so I told you I didn't want to give a specific example and then you complain about the example.  Sorry but I did say that you shouldn't be asking me such a question so early.

 

That said, why don't you ask me why I picked that example?

 

I picked it because for a few OpenPLi builds the OpenPLi code did *not* respect the MultiBoot structure used by the other main images.  So "who cares" you say.  I care I say because it left me booted into OpenPLi on one of my boxes and totally unable to boot to any other slot or any other image.  It was unwarranted nightmare that should *NEVER* have passed the coder's self testing.  Now you want to apply similar logic to many more core functions of the code?  I'm sorry but I compelled to be concerned and agree with some of the concerns expressed by Huevos.

 

Still neither you nor Littlesat have weighed in with any plans or ideas.  Isn't it time you guys contributed to the ideas and planning.  Let us see what you guys are thinking.

 

Regards,

ian.

[WanWizard]

We have not made any multiboot solution ourselfs, we use whatever the vendors supply to us in the BSP. And the multiboot system for a few brands has changed recently to the same system as other brands, which obviously caused an incompatibilty. And Littlesat decided not to build in support for the old system, good or bad, that is an OpenPLi design choice.

 

Why does it cause an incompatibility? Because there is currently NO abstraction layer, code digs into the hardware and software to try to detect all sorts of stuff. And that goes wrong because of differences between images. This is an example of why EXACTLY we need an abstraction layer.

 

Code, whether it is in Enigma itself, or in a plugin, MUST NEVER probe hardware, setup and OS directly, and make deductions or assumptions of what it finds.

 

As I see it, the problem is still "we don't trust you to do the right thing".

 

I don't seem to be able to get across what an abstraction layer is, and why you should decouple hardware and os from application.

 

I am very disappointed in the way this is going, and the level of expertise shown in this topic. You claim to be well versed in software design and architecture, yet we have this kind of trivial discussions.

[XRayhTec]

Hi WanWizard,

 

Do not get exasperated or disappointed.

 

Speaking for myself. Following caused the confusion at my side.

"For the last time: the internals are not relevant, and no, there is only ONE API (otherwise, which methods to call?).

And for those I have lost along the way: an API is nothing more than documentation. What classes, what methods, what arguments, what return values."

 

For me an API is not only documentation but also the piece of code with the set of functions/procedures which interfaces between application and OS/Hardware and therefore think every Distro has it's own API.

 

Maybe I am wrong but I think we should not make discussion which definition of API is correct but consider more interpretations may exist and try to get everyone in same direction.

 

Resuming:

Goal: An interface between Enigma2/Plugins and Distro/OS/Hardware

Purpose: Abstraction of Distro/OS/Hardware

The Interface has to be described and defined: The functions of the interface (classes, what methods, what arguments, what return values)

Everyone can implement the interface in their own way following the description/definition.

 

Do I understand well?

 

Regards,

[WanWizard]

For me an API is not only documentation but also the piece of code with the set of functions/procedures which interfaces between application and OS/Hardware

 

That is exactly what it is, no more, and no less.

 

And the code INSIDE the functions and procedures can be written by each team individually (or together, or nicked from one, I don't care ). Obviously the code MUST adhere to the documentation and specs, but I went with the assumption that we are all grownups, we all know what we're doing, and we all want everything to work properly, while improving plugin compatibility.

 

Resuming:

Goal: An interface between Enigma2/Plugins and Distro/OS/Hardware

Purpose: Abstraction of Distro/OS/Hardware

The Interface has to be described and defined: The functions of the interface (classes, what methods, what arguments, what return values)

Everyone can implement the interface in their own way following the description/definition.

 

Do I understand well?

 

Yes, 100%.

 

Take for example: the box fan.

• some boxes have a fan, some not
• some boxes report the speed of the fan (in case of a PWM fan)
• Fan speed can be voltage controlled, or use puls modulation (PWM)
• No image currently has this in either boxbranding or systeminfo, they all access the hardware directly

So the API needs something like:

bool: hasFan() - returns True if the box has a fan, False if not.
int|null: getSpeed() - returns the speed of the fan (RPM) if available, or NULL if not.
bool: setSpeed(int) - sets the fan speed. Argument is an integer, between 0 and 255. Returns True if set, False if the speed could not be set.

which will hide the complexities of fan control from Enigma or the plugin.
 

For implementation, it doesn't really matter if "hasFan()":

• checks /proc/stb/fp/fan_vlt, /proc/stb/fp/fan_pwm and /proc/stb/fp/fan_speed at runtime
• returns a predetermined value from a <boxmodel>.txt file containing key-value pairs
• returns the value of a call to a binary boxbranding module
• returns the value of a bitbake environment variable

as in all cases, the team has to make sure the returned value is correct and adheres to the spec of the API.

[littlesat]

There is still a lot of stuff in e2 that checks these kind of procs in e2... stuff that is not (yet) centralized into a SystemInfo/Boxbranding/Feature check like ‘module’...