772 replies to this topic

[IanSav]

Hi WanWizard and Littlesat,

 

We are still waiting for your proposals and ideas.

 

Regards,

Ian.

[littlesat]

When you ask for this you still do not get the clue... sorry...

[IanSav]

Hi Littlesat,

 

When you ask for this you still do not get the clue... sorry...

 

You and WanWizard have been very fast to criticise others yet you say nothing yourselves.  You keep telling me that I don't have a clue, why don't you tell me what I don't know.  I think it is well overdue that you two start putting forward some input into the design and discussions.

 

Regards,

Ian.

[IanSav]

Hi,

 

We have had over 300 posts over the last two months and OpenPLi members WanWizard and Littlesat are yet to provide *ANY* input into this discussion.  All they have done is criticise or attack others trying to get discussions going.  It is time that one of them present input on behalf of OpenPLi.  I will no longer answer questions from WanWizard or Littlesat while they refuse to post anything the explains their opinion or plan.

 

Regards,

Ian.

[littlesat]

I’m afraid all input is given. But as long some are still stuck in implementation phase this might need another 300 pages...

Edited by littlesat, 17 September 2020 - 11:06.

[IanSav]

Hi Littlesat,

 

Please point me at *ANY* input you or WanWizard has posted that moves this process forward?  Are you expecting this problem to solve itself?  The problem has already been defined, what are you expecting next?

 

Regards,

Ian.

Edited by IanSav, 17 September 2020 - 11:52.

[WanWizard]

I am completely clueless as to what input it is you want.

 

I have posted what the tasks at hand are several times, and clarified them on the 12th  and the 13th.

 

The first task was "all agree on creating an abstraction layer and every team provide a representative in charge of defining and maintaining it".

 

But that hasn't happened yet, as appearently after 17 pages of explaining we're still at the "I have no clue what an abstraction layer is and why that is needed" stage.

 

I am afraid your mind is still at code. I am NOT going to provide code, this isn't about code at all.

[IanSav]

Hi WanWizard,

 

What I want is for you and Littlesat to add to the conversation rather than be critical of anything that anyone else posts.

 

We are all now waiting for you and Littlesat to post your thoughts and ideas to move the project forward.  At the moment there is nothing here to which anyone can agree, other than we all agree that something needs to be done to make code and skins more portable between images.  We have that agreement so what next?

 

You don't want anyone to talk about code so why don't you lead us in the type of content you want to be raised.

 

Regards,

Ian.

[WanWizard]

I don't know what more to add.

 

You don't want anyone to talk about code so why don't you lead us in the type of content you want to be raised.

 

I have explained, time and time again, what needs to happen. All you can do is present a textfile with a variable list extracted from a system that isn't fit for purpose, which is totally not relevant at this point.

 

I gave several examples, I referred to a python example to make it even clearer, but I'm getting nowhere. Only XrayTec seems to have understood it immediately.

I am not going to put any effort in anything that as no chance of succeeding, as nobody here even seems to understand what needs to happen.

 

As long as there is no understanding of what an abstraction layer is, why it is needed, how it should be constructed and why it is imperative it should ALWAYS be used and never circumvented, it is pointless to go on, as this has nothing to do with code or programming, but with basic software design principles.

[IanSav]

Hi WanWizard,

 

No-one is stopping you from contributing something to lead the discussion forward.  You don't respect my opinion, my input or me so over to you.  Time for you to post something, anything, that will move the thread forward.  This is not my thread.  This is not my project.  I am interested in the project.  I am not the only interested party.  I am in no way obligated to be the only person who has to provide all the posts or answers.  I have put up with your belittling posts enough.  I did it to try and get the conversation moving.  Enough is enough.  You have done nothing to encourage input.  I suspect that all that is happening here is that no-one wants to post for fear of being belittled by you or Littlesat.

 

Don't tell everyone what they need to do.  You appear to have all the answers.  Do some of the work yourself.  Lead by example and post information to which others can react.  When you say something constructive then perhaps you will encourage posts that give you what you want.

 

Regards,

Ian.

[XRayhTec]

Here and there I sense some irritations but I'll give it a try.

 

As Wanwizard says

"The first task was "all agree on creating an abstraction layer and every team provide a representative in charge of defining and maintaining it"."

 

I think WanWizard wants teams to make a clear statement that they want to be part of the design proces and also implement the api/abstraction layer between Enima2/Plugins and the OS/DISTRO/HW in their image.

 

I can also understand not everyone is immediately enthusiastic because as far as I see a lot of work in implementation phase needs to be done by the teams and it may not be quite clear at this moment what the impact of the api implementation in the current images is. (When the api will be implemented E2/Plugins/skins need to be adapted to that.)

 

But I think it is important teams make a decision if they want to do it or not.(maybe do impact analysis first before decision?)

 

When teams state their commitment to the project then it makes sense to start with defining the api:

- Give it a name

- Decide how it will be implemented. In Python?

- Create the list with functions, something like the list attached, but other formats will do also. The list of Ian is usefull in this process I think.

 

After definition phase implementation phase can start. Implementation of the E2/Plugin-api may still be common job, The interface part between api-DISTRO/OS/HW looks team specific to me.

 

Regards,

Attached Files

•  Box API.pdf   80.83KB   19 downloads

Edited by XRayhTec, 17 September 2020 - 16:34.

[IanSav]

Hi XRayhTec,

 

The BoxInfo.txt file was effectively my attempt to provide the same discussion topics as your Box API.pdf document.  It was deemed unacceptable by WanWizard and Littlesat.

 

No team is going to sign up to a plan if there is no plan to consider signing up to.  I know that a number of teams are interested in achieving compatibility but nothing being said here is encouraging the other teams to post.  Those who have posted have been rebuked and no longer wish to post.  Others don't want to post while there is no information and a hostile environment.

 

While this project remains unspecified and totally abstract all the commitments will be identically abstract.

 

Regards,

Ian.

[WanWizard]

I think WanWizard wants teams to make a clear statement that they want to be part of the design proces and also implement the api/abstraction layer between Enima2/Plugins and the OS/DISTRO/HW in their image.

 
Yes, absolutely.
 
Because once we start, the biggest problem is maintaining it. If one of the contributing images comes with the requirement for a new method "xyz", all images need to agree on its prototype, and need to implement it in their API implementation. As soon as that stops happening, this entire excercise is dead. So that commitment is extremely important.
 

I can also understand not everyone is immediately enthusiastic because as far as I see a lot of work in implementation phase needs to be done by the teams and it may not be quite clear at this moment what the impact of the api implementation in the current images is. (When the api will be implemented E2/Plugins/skins need to be adapted to that.

 

I think in terms of implementation we will have the most work, as we don't have anything yet. Others already have their current "boxbranding", which can stay (for the moment) for backward compatibility, giving them a smooth migration path. We have to make everything from scratch, made extra complex because we build an image per machine, and not per box model like others.

 

When teams state their commitment to the project then it makes sense to start with defining the api:

- Give it a name

- Decide how it will be implemented. In Python?

- Create the list with functions, something like the list attached, but other formats will do also. The list of Ian is usefull in this process I think.

 

After definition phase implementation phase can start. Implementation of the E2/Plugin-api may still be common job, The interface part between api-DISTRO/OS/HW looks team specific to me.

 

As to a name, pick one. I don't really care. As long as it isn't SystemInfo or Boxbranding (as both exist and need to stay for BC reasons).

 

As to implementation, it was already decided, based on Ian's feedback, that is should be Python, as it can be called from both the CLI and from C.

 

And yes, obviously when starting with the method definitions, the starting point is the existing list of values.

 

But as said before, I want the house to be designed and the design approved, before we all start laying bricks. Implementation can only happen after the definitions / documentation is ready and approved, to avoid differences in opinion and interpretation, which can lead to issues Ian and Huevos mentioned before.

 

Sometimes simple things like "should it be 1080p50 or 1080P50"? Other methods will have no detailed specification, just that "it returns a string". A typical example of this is ImageName, Model and ModelName, which are free-form strings.

 

The BoxInfo.txt file was effectively my attempt to provide the same discussion topics as your Box API.pdf document.  It was deemed unacceptable by WanWizard and Littlesat be identically abstract.

Where did I say that?

 

All I said was that talking about implementation comes much later in the process.

 

As long as we are not in agreement:

• that we are going to build a house
• what the house should look like
• to which standards it should be build
• with which materials

it is pointless starting to haul bricks...

 

The problem seems to be that you can't handle the normal steps of software development:

1. you identify a problem
2. you define and quantify the problem
3. you design the solution for the problem
4. you get agreement of all stakeholders
5. you write the code to solve the problem
6. you verify the result against the problem definition

You seem to want to jump straight from 1 to 5.

 

When you do that, and someone involved is not happy with that you created (for example, it is bitbake environment variable based ), you've done all the work for nothing because you skipped 4.

 

And I want to avoid that, I want a solution that we can all agree with, stand behind, are willing to implement, and are willing to maintain for as long as needed.

[Huevos]

 standards2.png   29.32KB   6 downloads

[WanWizard]

Hahahaha... Knew that one.

 

And exactly the situation we want to avoid here.

[Persian Prince]

@IanSav

Will you add your new changes to PLi or should I cherry-pick them from ViX?

Regards,
Persian Prince

[littlesat]

Here and there I sense some irritations but I'll give it a try.

 

As Wanwizard says

"The first task was "all agree on creating an abstraction layer and every team provide a representative in charge of defining and maintaining it"."

 

I think WanWizard wants teams to make a clear statement that they want to be part of the design proces and also implement the api/abstraction layer between Enima2/Plugins and the OS/DISTRO/HW in their image.

 

I can also understand not everyone is immediately enthusiastic because as far as I see a lot of work in implementation phase needs to be done by the teams and it may not be quite clear at this moment what the impact of the api implementation in the current images is. (When the api will be implemented E2/Plugins/skins need to be adapted to that.)

 

But I think it is important teams make a decision if they want to do it or not.(maybe do impact analysis first before decision?)

 

When teams state their commitment to the project then it makes sense to start with defining the api:

- Give it a name

- Decide how it will be implemented. In Python?

- Create the list with functions, something like the list attached, but other formats will do also. The list of Ian is usefull in this process I think.

 

After definition phase implementation phase can start. Implementation of the E2/Plugin-api may still be common job, The interface part between api-DISTRO/OS/HW looks team specific to me.

 

Regards,

 

Actually this is a good direction with the FAN example...

 

You just have functions that check if there is a FAN and then a set and read fan speed.... 

 

When the box e.g. has only 32 fan speeds the API says the value is 0-255.... then the function should adapt it to these kind of values... and in E2 only these functions are called.

 

This is 'more' than just give a box name statically...

 

Kind Regards,

Guido

[WanWizard]

Exactly, this is what abstraction means.

[littlesat]

I hope the rest starts understand it now... thanks PP...

This also means on a lot of locations in E2 changes should be made to do it this way... But at the end the code will becomes much easier... Then the 'boxbranding' module is not just a static table thing... but a thing that is called and drives the procs etc... Then it is designed...!

 

I prefer to make it a python driven thing... 

Edited by littlesat, 20 September 2020 - 12:39.

[WanWizard]

Which is why I proposed not to reuse the existing boxbranding / systeminfo solutions and/or names, as the new solution should co-exist with the current one, until all code is adressed, Backwards Compatibility is important for now.