772 replies to this topic

[WanWizard]

@Wanwizard I think this will only get speed if we start implementing it, to show what's the concept and why it's really better that way. We don't need to do it in a big bang, we can start small and while going extend the interface. Which must of course be properly designed to start with, the basic concepts.

Possibly.

 

I can start with a proof-of-concept after next week, and do the Python / Bash stuff, but my C is way to rusty to do that.

 

The only worry I have is that once people see it, they loose themselfs in implementation again, and respond "we won't do it like that" or "we can't do it like that".

 

There are only two things important (taking your example):

• Define what "hardwareAbstraction" looks like from a Bash, Python and C point of view (i.e. the Interface).
• Define what functions / methods "hardwareAbstraction" should get, what their arguments are, and what there return value is.

The actual code that goes into these functions / methods can be (and probably is) different for every team, as that depends on where they get their information from (runtime, text file, something else, ...).

[IanSav]

Hi,

 

I await the further information and proposals.  I have some reservations but I prefer to keep them to myself until we can review these next steps.

 

Regards,

Ian.

[WanWizard]

I'd rather hear them up front that to find out later I have wasted my time...

[IanSav]

Hi WanWizard,

 

My concern relates to simply issuing commands to hardware blindly and expecting the abstraction layer to work out what was intended.  Some commands and aspects of the UI need to be designed and coded to look or react differently depending on what hardware is present.

 

For example, if I have understood the abstraction plan as recently discussed is it expected that users be presented with a list of configuration screens for absolutely every possible type of hardware such that the commands can be sent to the abstraction layer for appropriate processing?  The hardware abstraction layer can use or ignore all these generalised and abstracted commands as appropriate.  Enigma2 is not to know anything about the hardware in use.  Surely we want the UI to only offer choices appropriate for the hardware they are actually using.  To me that means that Enigma2 must have some awareness of the hardware upon which it is running.

 

When I spoke about hardware abstraction I thought we were talking about knowing there was an LCD front panel but *NOT* trying to work out what make or model of box has that screen.  We ask the abstraction layer for the critical details about which we need to know and no more.

 

As I said, when I get more insight to what is being proposed either my reservations will be shown to be irrelevant and not matter or else they can be taken into consideration for a future iteration.

 

Regards,

Ian.

[WanWizard]

If you want the UI to offer choices that are appropriate, you don't need to know what box it is, you need to know what the appropriate choices are. In other words, Enigma needs to know available features or functionality. You should not have to code that logic in Enigma (or a plugin) yourself.

 

So the abstraction layer needs a method or function to return those, instead of getting the boxmodel and then hardcode the selection of choices itself.

 

And no clue what you mean by "users be presented with configuration screens"? This is about methods/functions returning hardware related data, not about users, nor about screens?

[IanSav]

Hi WanWizard,

 

I suggested I should wait to see what you are proposing.  Lets see what your next stage brings.

 

If I explain my concerns is any more detail I think you will just tell me that I am jumping to implementation.  I suggest you proceed as you indicated and lets see where this goes.

 

Regards,

Ian.

[Erik Slagter]

This discussion is interesting. Indeed I think that once we have a few examples, it may get more clear and we may be able to take away some reservations.

 

BTW I think the interface (the actual interface and the supplied methods, e.g. functions) is most important, the implementation we can always optimise afterwards, so it doesn't need to be perfect at once.

[WanWizard]

Implementation is specific for each image, so that shouldn't be discussed here anyway.

 

This is only about the design specifics of the API.

[IanSav]

Hi WanWizard,

 

Implementation is specific for each image, so that shouldn't be discussed here anyway.

 

This is only about the design specifics of the API.

 

I don't agree.  If the implementations are not compatible then we will not get the most important result and benefit of having most, if not all, of Enigma2 code interoperable between images.

 

Regards,

Ian.

Edited by IanSav, 11 September 2020 - 19:14.

[Huevos]

If [...] Enigma needs to know available features or functionality. You should not have to code that logic in Enigma (or a plugin) yourself.

We already have that in SystemInfo.

[WanWizard]

We already have that in SystemInfo.

 

No.

 

Systeminfo is global.

Systeminfo is mutable.

Systeminfo is a data array, not an interface.

Systeminfo is not consistent between all images.

Systeminfo is far from complete (which is why code is still littrted with hardware related logic).

Systeminfo is not used in the C code.

Systeminfo is not available from the commandline.

...

[WanWizard]

I don't agree.  If the implementations are not compatible then we will not get the most important result and benefit of having most, if not all, of Enigma2 code interoperable between images.

 

Explain.

 

If the API has a documented method

bool has7SegmentDisplay()
- method has no arguments
- method returns True if the box a 7-segment display, or False if not,

why would if be of interest to know where that True of False value came from?

 

It could be from environment variables during the build, from text files, from templates during the build, detected with logic at runtime, you name it.

 

Totally irrelevant for an Enigma or plugin developer.

 

If with your statement you mean that you don't trust image builders to make an abstraction layer that does what it says, then we really have a big problem, as a community.

[IanSav]

Hi WanWizard,

 

Your example, is the reason I didn't want to provide my reservation.  That code is the sort of code I was expecting the UI to need.  Given that this sort of data is available my reservation has been addressed.

 

Regards,

Ian.

[IanSav]

Hi WanWizard,

 

Systeminfo is global.

Systeminfo is mutable.

Systeminfo is a data array, not an interface.

Systeminfo is not consistent between all images.

Systeminfo is far from complete (which is why code is still littrted with hardware related logic).

Systeminfo is not used in the C code.

Systeminfo is not available from the commandline.

• I am not particularly concerned that it is global.  That is far better than it being replicated.
• I gave an example of how entries can be made immutable.
• I gave an example of how the data can be made available as an interface rather than a data array.
• The point of providing the BoxInfo.txt file was to show how the data could be organised to provide a consistent data identifier interface between images.
• The data within SystemInfo is actually more complete than you suggest but some coders have not had the discipline to use the available data appropriately.  Part of this effort will be to define and expand on the data identifiers to ensure that all appropriate abstractions are made.
• I believe that a simple SWIG interface is all that is needed to make SystemInfo data available to the C++ code.
• As has been suggested previously, a small self contained Python code module could be written to expose the abstracted data to a shell interface.

The other good thing about reworking SystemInfo is that it exists now and is already accepted by all images.  We can leverage this to allow the SystemInfo data to be improved and expanded without making Enigma2 unusable over the development process.  Improvements can be applied progressively.  Yes, I know this is implementation but I think these facts need to be considered.

 

Regards,

Ian.

Edited by IanSav, 12 September 2020 - 03:43.

[Huevos]

Whatever it is it needs to be readable from multi-boot when the image is NOT the currently active image.

[WanWizard]

Whatever it is it needs to be readable from multi-boot when the image is NOT the currently active image.

 

Why? This is a new requirement to me?

[WanWizard]

@Ian,

 

Nobody is talking about replication. I never said I have a problem with calling the API "SystemInfo".

 

Also, you are way ahead of the curve again, probably because you focus too much on implementation.

 

My only concern at this point is:

• all image teams need to agree on the interface. whatever the interface may be
• all image teams need to agree on the methods of that interface, their prototype, and their return value
• all developers need a single set of documentation that documents the above
• all image teams need to agree on how to maintain that documentation, and to keep their code in sync with it through versioning

You suggest keep using SystemInfo, and stick a get() method on it to access the list instead of having the list global.  These are implementation details, none of my points are about implementation, but are a prerequiste for success.

 

If those points are not dealt with, who will make sure that  if ATV invents a SystemInfo.get('hasBicycleWheels'), other images will introduce that value too? Correctly implemented? If that doesn't happen, if those mechanisms are not in place, this entire excercise is moot.

 

And to adddress some of your other points:

• I don't like text files, I don't like 200 environment variables in the build. The way it is implemented is up to every image team individually. What is behind the interface is and should be a black box.
• Accessing Python data from C or v.v. is a pain, leads to instability of the image, and should be avoided if possible. Calling class methods maybe less so.
• No issues with a Python stub to access the data from the shell, I think that is the way to solve that too.

I don't think that we're that far apart, all I'm saying is that we need to agree on the number of bedrooms and the type of roof, and make the building plans, before start laying bricks...

[IanSav]

Hi WanWizard,

 

Feel free to carry on your drafts.  Hopefully you will provide the design you want and then we can start getting agreement and then move onto building.

 

Regards,

Ian.

[WanWizard]

That suggest you think otherwise, which makes me reluctant to continue, as appearently nobody is on board yet.

 

For example, you seem to be adamant that the SystemInfo.get() interface as implemented in ATV is the way to go, while OpenPLi will not implement that, as that interface does not allow the use any runtime data, only static variables. So it is not flexible enough.

 

Appearently there is no will and/or no expertise available to have a grown-up discussion at functional and architectural level, without dropping down to "I already know how to do it" and "our solution is the best" level.

 

I have to say I am very disappointed, but not very suprised, this is exactly the reason why architecturally and functionally nothing has changed in E2 in the last 15 year...

[IanSav]

Hi WanWizard,

 

We all have different knowledge and experiences.  I am not the only interested party.  Please don't treat this as a "me against you" private discussion.  Various people have tried to contribute and you have shut them all down.  This thread should be inviting input rather than criticising anyone who dares to post.  Obviously you want to deal with this in your own way so why don't you demonstrate your way and plan to us.  You offered to facilitate the plan and I am encouraging you to do exactly that.

 

By the way, I disagree that "architecturally and functionally nothing has changed in E2 in the last 15 years".  I am one of a number of people who have been making significant changes to improve Enigma2.  Not everything I have prepared has been offered to OpenPLi as yet.  You know about the improved skin engine, you know about the new skin selector, you know about the improved and common Directories library, you know about the unified key definitions.  Feel free to look at the current Developer versions of OpenViX to see some of the other current changes in development and testing.  The entire Setup engine has been completely overhauled.  Summary screens are being improved.  Menu is being reworked next.  There is also a completely new Help engine coming as well.  I would rate this a significant change.  What's more it is being done without significant disruption to all the running images.

 

Regards,

Ian.

Edited by IanSav, 12 September 2020 - 15:51.