772 replies to this topic

[Huevos]

 

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?

 

Boxbranding is currently used in this way. i.e. you can obtain details about any image even if it is not the active image.

[WanWizard]

@Ian,

 

You still fail to understand it.

 

There is nothing to demonstrate, as it is not about code. It is about all agreeing about required functionality, agreeing to using the same interface, to define and design that interface, and to have a body that makes joined decisions about evolutions to that interface.

 

This is design and documentation work, it doesn't require a single line of code. Code only comes when the work is complete.

[WanWizard]

Boxbranding is currently used in this way. i.e. you can obtain details about any image even if it is not the active image.

 

Ok, so the requirement is that the bash and/or Python interface should support multiple sources?

 

That definitely rules out any global data structures, in favour of objects of which you can have multiple instances.

[Huevos]

 

Boxbranding is currently used in this way. i.e. you can obtain details about any image even if it is not the active image.

 

Ok, so the requirement is that the bash and/or Python interface should support multiple sources?

 

That definitely rules out any global data structures, in favour of objects of which you can have multiple instances.

 

Not sure what you mean by this.

 

Say you have an image unpacked in a folder you should be able to read the details of that image even though it is not active.

[IanSav]

Hi WanWizard,

 

@Ian,

 

You still fail to understand it.

 

There is nothing to demonstrate, as it is not about code. It is about all agreeing about required functionality, agreeing to using the same interface, to define and design that interface, and to have a body that makes joined decisions about evolutions to that interface.

 

This is design and documentation work, it doesn't require a single line of code. Code only comes when the work is complete.

 

You don't have to demonstrate code, you can demonstrate ideas, concepts, plans or anything else you like.  The idea is to COMMUNICATE!

 

I think that it is you who doesn't get it.  Stop criticising people (me) and say something constructive and useful. I am not designing this system I am contributing to it.  If you are the design expert then you define or design or do something productive.

 

Have you wondered why so few people are saying anything here?  Could it be that I one of the very few trying hard to get conversations going.  All you do is tell me I am stupid.  You scare others off from posting or engaging in discussions.  Are you deliberately trying to sabotage the process?  Let people speak, hear what they have to say and then sift whatever it is you want and then respond to it.  I have tried many times to provide you with my input and requirements.  I have absolutely no idea what it is you are expecting me to say or do.

 

By the way, please don't tell me I can't conceptualise, plan or design things.  That has been a significant part of my working life.  I happen to be quite good at it.

 

Regards,

Ian.

[WanWizard]

Ian,

 

It wouldn't be the first time my mind is on a different plane from everyone elses, extremely annoying (also for me ).

 
These are the tasks at hand for the moment:
 

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

 

And maybe before that:

• all image teams need to agree on the required functionality.

We had a bit of discussion about functionality:

• Needs to be accessable from Python code
• Needs to be accessable from C code
• Needs to be accessable from Bash script / CLI
• Needs to support runtime determined data
• Needs to be accessable from the running image in case of multiboot

We had a bit of discussion about interface:

• The preference is to write it in Python
• Python functions and class methods can be called from C
• Python functions and class methods can be made accessable from the CLI
• No static datastructure (doesn't support runtime data)
• No global datastructure (doesn't support multiple instances in case of multiiboot)
• No single getter (implies having a static datastructure)
• No global functions (doesn't support multiple instances in case of multiiboot)

This implies (I think):

• that the interface has to in the form of a Python class
• that the class needs getters per supported value (so they can contain code instead of only static data)
• that the class needs a factory for instantiation, with the multiboot slot number (or 0 or no parameter for the current running image)
• that we therefore also need to standardize that factory function or method

That factory function or method would replace ATV's current boxbranding_reader(), and by passing the slot number instead of a path, it can create an instance using the Python class file from that slot partition in the same way ATV now loads boxbranding.so. This decouples the interface from it's implementation (ATV can continue to use their boxbranding.so internally, OpenVision their solution, etc)

 

So something like

current = factory_function(0)
print current.getImageName()  # currently running image 

slot1 = factory_function(1)
print slot1.getImageName()    # image installed in slot 1

slot2 = factory_function(2)
print slot2.getImageName()    # image installed in slot 2

This way the entire implementation is abstracted away from Enigma or plugin code, the only things we need to agree on, and document, are:

• the exact name of this factory function or method (as it should be the same for all images)
• the exact name and location of the py that contains the interface class (so the factory can import it, no matter which image is running)
• the exact name of the interface class in that py (so the factory can instantiate it)
• the prototypes of all interface class methods (like the getImageName() in the example above), their arguments, and their return value (secoond task above)

And every team can implement this they way they see fit, without imposing any requirements or restrictions on other teams.

 

And the third and fourth tasks shouldn't be forgotten, because without commitment of all teams involved, and without proper governance of the class API, this project is dead before it is started...

[IanSav]

Hi WanWizard,

 

It seems you have arrived to consider looking at the BoxInfo.txt file a few of us were workshopping quite a while ago.

 

Please look at this file again, the latest version is attached to this post, and this time think about the "Variable" column as an unrefined abstract method name or access reference token to access the described underlying hardware or system data.  The "Type" and "Example" columns can be viewed as explanations and potential sample data that is expected from the "Variable" method / token.  While I have used a Pythonic style please just consider it information being described in a way that most people here should be able to understand.

 

I believe that you will find this the abstract metadata is exactly what you have been trying to identify.  The "Variable" names are not locked in and would need to change, for example, if they are to become method names in the implementation phase.  The final names and implementation will require the wider consensus that you mentioned.

 

So, I hope you now understand and appreciate that a number of us were already working on precisely the information you were trying to obtain. 

 

By the way, your explanation mentioned a number of implementation concepts and steps.  I won't make further comment other than to highlight that you are also thinking more holistically than what you demanded from me.

 

Regards,

Ian.

 

Attached Files

•  BoxInfo.txt   3.49KB   18 downloads

[littlesat]

Some parameters in the txt file do not have any added value eg have7segment should be included in the display type and hasci makes no sense when the number of cis is zero.
Unless this I’ afraid you still do not get what wanwizard means.

Edited by littlesat, 13 September 2020 - 16:55.

[IanSav]

Hi Littlesat,

 

The items in that list are things I have found in boxbranding and things I have wanted to know.  The content of this list is exactly the discussions we need to have.  If there are things that should be removed then mark the "Variable" with an "*" and then add your comments about why it is not needed to the end of the file.  If there are things that are missing and should be added please insert the entries into the list.

 

If representatives from all images can work on the list then I will collate the changes and update this thread with a unified copy on a regular basis.

 

Regards,

Ian.

[littlesat]

You are still focused in coding and implementation instead of design....

Edited by littlesat, 13 September 2020 - 17:56.

[WanWizard]

It seems you have arrived to consider looking at the BoxInfo.txt file a few of us were workshopping quite a while ago.

 

No. Then you haven't read what I wrote.

 

This is why I get so exasperated, I write and I write, but nobody reads, since they have already decided that their solution is the best, and everyone else should adopt it.

 

I don't want a text file in our image. I thought I was clear about that 14 pages ago.

 

And you should not care what we do put in it, just like I don't care what others do. It is hidden behind the abstraction.

[IanSav]

Hi Littlesat and WanWizard,

 

Here we go again! 

 

Where in my post, or that document, do I write or say or imply *ANYTHING* about the structure or source of the information or its mechanism of implementation?  That list is simply a list of ideas and information!  Surely if this thread needs anything it is information with which others can read and discuss.  Neither of you have contributed *ANYTHING* to move this thread forward!

 

Do you guys actually *READ* what I post?  Perhaps I should stop posting my thoughts and ideas as apparently everything I post is "coding and implementation instead of design" and wait for either of you to provide some design structure and input.  So far all I have observed is that if the effort expended in criticising me was expended in writing code we could have rewritten Enigma2 many times over. 

 

I am still waiting for either of you to post something that contributes to discussions rather than stifling them.  It is time that you put forward your ideas and designs rather than attacking those who are trying to do exactly that!

 

Regards,

Ian.

Edited by IanSav, 14 September 2020 - 02:06.

[XRayhTec]

Hi WanWizard,
When creating an api you should have data which can be requested by it.
I think the list of Ian is meant for that purpose. It defines variabeles which Enigma or plugin can request through the api.
It may not be complete or fully fullfils the wishes yet from all but needed I think.
Regards,

[WanWizard]

Ian,

 

My misunderstanding, sorry, I'm away at the moment and reading with a mobile. I missed a list, I thought you were referring to the text file with variables. Was that list attached?

[IanSav]

Hi WanWizard,

 

Ian,

 

My misunderstanding, sorry, I'm away at the moment and reading with a mobile. I missed a list, I thought you were referring to the text file with variables. Was that list attached?

 

Yes, I attached the latest draft with that message.

 

Regards,

Ian.

[WanWizard]

I'll have a look when I'm back home later this week, and I can view it.

[Huevos]

Some parameters in the txt file do not have any added value eg have7segment should be included in the display type and hasci makes no sense when the number of cis is zero.
Unless this I’ afraid you still do not get what wanwizard means.

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.

 

But anyway it is already dead because WanWizard has said there will be no env variables in PLi build env.

[XRayhTec]

Hi Huevos,
I think following is meant.
When you have api request get_number_ci then there is no need for api request has_box_ci.
When number_of_ci=0 then has_ci=no, if number_of_ci=1 or higher then has_ci=yes.
So not requesting certain things does not mean variables does not exist.
Regards,

[littlesat]

The information is duplicated with a bool for 7-segment and a string also telling it... duplication should be avoided.
But you touched a point as it might be helpful to have such booleans. But that is on the implementation layer (every image can add this on their systeminfo.py) and should not be done on the “box-branding api” layer.
Another point is that the box-branding api could be dynamic eg with the sundteck example.

Edited by littlesat, 15 September 2020 - 06:50.

[WanWizard]

But anyway it is already dead because WanWizard has said there will be no env variables in PLi build env.

 

Please explain why environment variables are needed?

 

Isn't it up to us how we organize our build process? Same as we don't dictate how OE-A should build theirs?