772 replies to this topic

[Huevos]

@Littlesat, I don't understand your point about static. If an STB has a 7 segment display how does it make the data better because it was read from a /proc? And the worst thing about a /proc is it relies on the manufacturer to provide the data (and we all know how unreliable that is, i.e. if this /proc do this else if that /proc do that).

 

@WanWizard, I can't see how we can have a discussion about APIs if there is no data. OE-A images have the correct data available on the STB and no need for some special API. And BTW, this is not just about plugins. Enigma itself also uses this data, for example in the setup wizard.

 

And I already explained in another thread how easy it is to do this just using a .bb file, but unfortunately OpenPLi OE core doesn't have any environmental variables available in the build to be able to do this.

 

I even bothered to collect all the "static" data for every PLi supported model but that was rejected too even though it was just a third party  plugin.

Edited by Huevos, 14 July 2020 - 00:39.

[betacentauri]

You can write a kernel module which creates the /proc entries by yourself. Is not very difficult. So you don’t need the manufacturer for it.
I only say it’s possible. I don’t say it’s better when we write it.

[Huevos]

You can write a kernel module which creates the /proc entries by yourself. Is not very difficult. So you don’t need the manufacturer for it.
I only say it’s possible. I don’t say it’s better when we write it.

Ok, but what is the point if there is no data available? And even if you write a /proc, what data will it return, and is that just "static" data that Littlesat does not want?

[littlesat]

Who say I do not want it... I think it is preferable to have a good designed and condensed api that is less complicated then the existing branding module from oe-a... and for example the h9 boxes where we have one build a static arrange thing may not work... so it is indeed challenging...

Edited by littlesat, 14 July 2020 - 08:18.

[WanWizard]

@WanWizard, I can't see how we can have a discussion about APIs if there is no data. OE-A images have the correct data available on the STB and no need for some special API. And BTW, this is not just about plugins. Enigma itself also uses this data, for example in the setup wizard.

 

Not very complicated.

 

My point is that an API should describe for example that there is a method called getModel(), which returns a string containing the model name, exactly as specified by the manufacturer, with the correct case and spacing, and implementing this method is compulsary.

 

How a specific image gets its data is and should not be specified, it could be determined in code from runtime info, it could come from a file, it could be generated hardcoded in the build process, etc.

 

Not relevant for any code using the API, all that code needs to know is that the method exists, and what it returns.

[WanWizard]

Ok, but what is the point if there is no data available? And even if you write a /proc, what data will it return, and is that just "static" data that Littlesat does not want?

 

You (and littlesat too) still miss the point that how it gets the data to returns is not relevant for this discussion.

 

If OE-A wants to return static data, OpenVIX wants to generate the code, OpenVision wants to read it from a file, Littlesat wants to write 2000 lines of complicated oneliners, who cares?

 

All you need to know:

• which methods always exist, which methods may exist (needed because the API needs to be versioned)
• what information each method returns

The code calling these methods should not need to apply any logic to the return values, if that is needed, the API design is wrong.

 

So, as a plugin developer or an E2 maintainer, you call getModel(), and get the string "VU+ Duo 4K" back. The rest is black box, and not relevant for the developer.

[betacentauri]

And it should include all possible features that a box can have. I mean there should be for example a method which tells you whether the box supports transcoding.
So you don’t need to use “if getModel() = ‘sf8008’ then transcoding = true”

[betacentauri]

By the way: It would be easier when we could use same implementation for all images, because then we know that we all get always the same result. But this is as WanWizard wrote not mandatory.

[WanWizard]

Yes, correct.

 

If there is a need to use something like that, the API is missing a feature, and a new version should be published (in this case something like "supportsTranscoding()" returning a boolean.

[WanWizard]

By the way: It would be easier when we could use same implementation for all images, because then we know that we all get always the same result. But this is as WanWizard wrote not mandatory.

 

Well,

 

One of the reasons I think implementation is a choice of the image teams is the different way the teams build images.

 

We build a single Zgemma H9 image, in which case the API will return generic information (like "H9 Series" for the Model string) while other teams build an image per indivudual model, and therefore have a need for "H9", "H9T, "H9S", etc...

 

Since we've already established that both Enigma and plugins should not apply any logic to the returned data, that is not a problem.

 

So, a plugin should  not do

if model is "h9t" then
    do-something-terrestrial
elseif model is "h9s" then
    do-something-satellite
endif

but do

if supportsDVBT then
    do-something-terrestrial
elseif supportsDVBS then
    do-something-satellite
endif

 

[IanSav]

Hi WanWizard,

 

 

By the way: It would be easier when we could use same implementation for all images, because then we know that we all get always the same result. But this is as WanWizard wrote not mandatory.

 

Well,

 

One of the reasons I think implementation is a choice of the image teams is the different way the teams build images.

 

We build a single Zgemma H9 image, in which case the API will return generic information (like "H9 Series" for the Model string) while other teams build an image per indivudual model, and therefore have a need for "H9", "H9T, "H9S", etc...

 

Since we've already established that both Enigma and plugins should not apply any logic to the returned data, that is not a problem.

 

So, a plugin should  not do

if model is "h9t" then
    do-something-terrestrial
elseif model is "h9s" then
    do-something-satellite
endif

but do

if supportsDVBT then
    do-something-terrestrial
elseif supportsDVBS then
    do-something-satellite
endif

 

From your fingertips to all coders brains!  This is a massively misunderstood aspect of Enigma2 and is heavily abused.

 

Regards,

Ian.

[WanWizard]

The result of classic software design principles at Uni, formal systems analyst and systems designer training at work, and now coding in an environment where TDD is the norm. Specs first, (unit) tests second, code last.

 

A lot of developers tend to think bottom-up, in terms of solutions, and not in terms of problem descriptions, and often within their own bubble, missing the helicopter view.

[ims]

For me is much worse using 'pass' in except:

try:
    do_something
except:
    pass

[WanWizard]

True. But not really related to this topic.

[Huevos]

I don't understand any of this. OE-Alliance already has an API with all the functions. It is called the branding module. The branding module is available inside and outside enigma. Why re-invent the wheel?

[WanWizard]

I haven't checked it, so I don't know if a wheel is being reinvented, or if a better wheel needs inventing.

 

Even if that is usable, it is still an image specific implementation, and not an independent API definition, which is is maintained ideoendently.  It would need a neutral place, a sort of RFC body with someone from each of the teams. so we can make sure it will remain a generic image-independent API in the future.

 

Without that in place, I am not in favour of starting to use it, since they could change it, and then we're back to square-one.

[Huevos]

I haven't checked it, so I don't know if a wheel is being reinvented, or if a better wheel needs inventing.

 

Even if that is usable, it is still an image specific implementation, and not an independent API definition, which is is maintained ideoendently.  It would need a neutral place, a sort of RFC body with someone from each of the teams. so we can make sure it will remain a generic image-independent API in the future.

 

Without that in place, I am not in favour of starting to use it, since they could change it, and then we're back to square-one.

Branding module is shared by all OE-A distros. Anyone can submit PRs to that repo. Same as any other repo. Not sure what is worrying about not having write access. Pli build lots of things that they don't have write access to.

 

But anyway wouldn't be any good for PLi as PLi doesn't have any environmental variables available in the build.

[WanWizard]

You still don't get it.

 

The branding module is an implementation. I don't want an implementation, I want an agreement on the API, and a guarantee that "anyone that issues a PR" doesn't make a backwards incompatible or an OpenPLi incompatible change.

 

In other words, I want image independent management of boxbranding.h, and I want something similar for the python side.

[Huevos]

You still don't get it.

 

The branding module is an implementation. I don't want an implementation, I want an agreement on the API, and a guarantee that "anyone that issues a PR" doesn't make a backwards incompatible or an OpenPLi incompatible change.

 

In other words, I want image independent management of boxbranding.h, and I want something similar for the python side.

Isn't that the same for code on all repos that you are not in control of? i.e. 90% of code in any distro comes from repos that we don't have write access. e.g. I use OpenWebIF but don't have write access. If I want a change I just send a PR.

 

But anyway the discussion is pointless because PLi doesn't have the environmental variables available in the build.

 

Also, if the variables were available you could make a substitute module just adding a bitbake recipe. No need for a boxbranding.h file at all (that is just one way of doing it).

Edited by Huevos, 15 July 2020 - 20:40.

[WanWizard]

I can only repeat: you still don't get it. I have to say you disappoint me.

 

We don't want that code, as it will never work for us. Therefore having variables or not isn't relevant either. And we are not going to introduce those variables either, our way of building is completely different from OE-A.

 

We need an independent API definition, so we can implement it in OpenPLi.

 

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?