772 replies to this topic

[WanWizard]

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.

[Huevos]

"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.

[littlesat]

@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.

[Persian Prince]

 

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.

[Abu Baniaz]

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.

[littlesat]

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.

[WanWizard]

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

[WanWizard]

And then: no response anymore. Disappointing...

[stro11]

Hi,

 

First of all, sorry for polluting this thread. (I can not help with this level of development)

When i saw this thread i was so happy to read about this new Revolution, that's why i followed it.

Some time ago the teams worked together to make the new multiboot sytem for the arm boxes, that cooperation was a big success to my opinion.

You (all developers involved) have the skills and knowledge to make this work.

Please, please, please, don't give up now, and make this happen.

 

regards

stro11

Edited by stro11, 28 August 2020 - 21:35.

[IanSav]

Hi WanWizard,

 

And then: no response anymore. Disappointing...

 

I am not sure what more I can add or do at this point in time.  I suggested and posted a framework of information / data that needs to be available (I'll attach the latest draft to this message).  I also provided some template code to deliver the API in Python.  That same data and code can be made available to C++ from Python via SWIG.  This same data that primes the Python data structures can be readily accessed by the shell.

 

What more is required to make this happen?  What more input is required?  What more agreement is required?  How would you like for this to proceed?

 

Regards,

Ian.

 

Attached Files

•  BoxInfo.txt   3.18KB   15 downloads

[Pr2]

So in this approach we don't have a text file to grab the information from? Can be useful for some shell scripting.

[WanWizard]

What more is required to make this happen?  What more input is required?  What more agreement is required?  How would you like for this to proceed?

 

This project is pointless without having all teams behind it. For the moment OE-A is completely absent, without them on board it won't bring us much.

[WanWizard]

So in this approach we don't have a text file to grab the information from? Can be useful for some shell scripting.

 

WIthout a principle agreement, and no full list of requirements, it is pointless to start talking about implementation.

[IanSav]

Hi WanWizard,

 

OE-Alliance members are watching this thread but so far there is nothing for them to comment about or contribute.

 

Regards,

Ian.

[Erik Slagter]

A "I don't agree" or "I am not interested" could also be a valuable contribution. Just not keeping the silence.

[WanWizard]

I'd rather see a "good idea", "we're on board" or "this is our suggestion"...

[Erik Slagter]

At least a "we do see the advantage".

[Huevos]

 

What more is required to make this happen?  What more input is required?  What more agreement is required?  How would you like for this to proceed?

 

This project is pointless without having all teams behind it. For the moment OE-A is completely absent, without them on board it won't bring us much

Two reasons why I can never see this project gaining momentum...

 

1) The data must be identical in all distros. It has already been made clear in this thread that will never happen.

2) OpenPLi doesn't have any data, so no point preparing an API if there is no data to go in it.

[WanWizard]

That means that absolutely nobody in any of the teams is able to think in terms of strategy, design and architecture?

 

That is an absolutely sorry state of affairs, but probably explains why nothing significantly changed in Enigma in the last god knows how many years.

 

I'm a bit disappointed in your response as well (given your background) in that regard, as both your points are irrelevant, because "data" is not relevant.

 

NO code should act on data.

 

The API must hide that, the only data the API should return is logical data (does or doesn't support something) or static data (like the commercial name of a box, which is just a display string). Same for data going the other way, the API should provide methods to interact with the hardware, instead of code talking directly to the hardware.

 

The role of a hardware abstraction layer is precisely to decouple the code from the hardware and its implementation.

[Huevos]

T

 

"data" is not relevant.

Now I'm confused. If the data is irrelevant what is the purpose of the API? I thought the API was supposed to be a common way to access data. But if that is not the case what is the API for?

 

The way I see it the API is like a bank vault and the data is like money. You could build the strongest, most secure and technically perfect bank vault in the world, but what good would it be if you had no money to put in it.

 

For me the API is the easy bit. The success of the project relies on the data. Every time I mention this it gets played down.