772 replies to this topic

[IanSav]

Hi Persian Prince,

 

What changes do you want to merge?

 

There are a lot of changes on OpenViX that I would like to bring to OpenPLi but there were some objections when I originally discussed them.  Much of the new code is now stabilising but there are more changes to go.  For example the new XML processing and validation on Setup.py is also going into Menu.py.  The common code will then be extracted into a new module to be called Tools/XMLTools.py.  This has not yet happened.

 

The new display skin module is also progressing well but is not yet complete.  There are also other changes in progress.

 

Let me know what you are after and I will help you with them.

 

Regards,

Ian.

[Huevos]

 

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

boxbranding is not just static variables. getBoXType() has logic.

[littlesat]

That is has logic is not the criteria..... it has static results... or not? Just like boxModel etc.... that it does parse procs etc is a different case.... but you can also
do this with a static thing when bullring the image.... the value and the type of function that returns the value in the specific type is bsp.... the way to obtain the value on the function is implementation..:. So the bsp is the bsp and the logic behind it are two different thinks... I hope you now might get the clue!
The box type itself is static as the type does not change.::

Edited by littlesat, 20 September 2020 - 21:44.

[IanSav]

Hi,

 

It has been a month since the last post to this thread?  What is happening now?

 

Regards,

Ian.

[Frenske]

I do not rule out that several members in this debate are fed up with continu this discussion for now and pointed their attention to other pending issues.
‘Just’ 17 pages of pro’s and contra’s and still no clear point which is the right way. 

[littlesat]

When the oe-a fork don’t understand it then it makes no sense to continue this discussion....

[IanSav]

Hi Frenske,

 

I agree that there is definitely discussion fatigue.  That is why I took a step back to let others have their say.

 

The suggestions raised by XRayhTec are more or less exactly what I was proposing but documented in a different style.  Those suggestions appear to have been accepted but still no further action or discussion ensued.  In the past anything I tried to suggest to move the discussions forward was rejected and attacked.  I am now reluctant to say anything more until some direction and guidance is provided.

 

Regards,

Ian.

[IanSav]

Hi Littlesat,

 

When the oe-a fork don’t understand it then it makes no sense to continue this discussion....

 

I believe that everyone knows and understand the issues.  It is just that when anyone from any of the other teams tried to progress the discussion forward, in a constructive way, OpenPLi representatives slapped them down.  Those same OpenPLi people refuse to progress the discussion in any way so that the other teams can react.

 

As I posted above, it is pointless for any of the other teams to comment while OpenPLi team members refuse to constructively engage with them.  I/We have asked OpenPLi to progress the discussions and all we get is accusations that everyone else doesn't have a clue so why should we (OpenPLi) bother.  This is not a good look and is not an inviting environment when we are trying to get all teams to put their history and negative opinions behind them and try to find a collaborative and constructive way forward.

 

Regards,

Ian.

[WanWizard]

If by "OpenPLi people" you mean me, just say so, I'm a big boy, I can handle it .

 

The reason I left it, is that I felt I'd said everything there was so say, and we didn't move an inch closer. Sometimes you have to let things go if there is no progress and everything is stuck.

 

For me, everything is still very simple:

1. We all need to agree something needs to be done about this
2. We all need to agree a common solution is beneficial for everyone
3. We all need to agree there should be a body (with representatives from each team) to guard, maintain and version that specification (to keep the solution common)
4. We al need to agree on the interface (for Python, for C, and for the shell)
5. We all need to agree on the method/function specification ( = documentation! ) for that interface (function, arguments, return values, exceptions, etc)
6. Now everyone can go off and implement it in any way they see fit

I think we've checked 1. and 2. in this discussion, and that is where it stopped, because the discussion constantly jumped to 6. without dealing with 3 to 5.

 

I personally felt it was a waste of my time to start talking about 4, 5 or 6 without having dealt with 3.

 

Also because it really has to be a team effort, if only to prevent old "X has forced crappy solution Y upon us" sentiments...

[IanSav]

Hi WanWizard,

 

It was not just you.    Anyway, in this context it would be rude and/or inconsiderate to blame things on named individuals.

 

I actually think we have agreement on items 1, 2, 3, 4.  Item 5 is where we seem to have fallen off the path.  Not because there is disagreement but more because I think people are too afraid of reprimand if they try to expand and discuss the information required.  For example, you appeared to prefer XRayhTec's Python specification over my generic specification.  Okay, so be it.  I was simply trying to comply with your request to not speak in Python code terms.  If you want the specifications in Python then I can do that.

 

At this point I think we should be expanding on XRayhTec's (or my ) functional specifications.  As you said, we need to know what information is required before we code it.

 

I disagree with your proposed item 6.  I think that someone, from any team should create a template of the proposed code and submit that template for discussion and review.  That template should be workshopped and enhanced until all teams understand and agree with the template.  I would hope that the Enigma2 interface of the template be complete.  That is, the API interface that the Enigma2 code uses should be fully coded even if the data is dummy values until each image can write the code to supply or use the API data.  That template code can then be handed to the various teams for then to implement the code that gets / derives the information that is delivered to the Enigma2 API interface.  If any team finds an issue or an inadequacy of the Enigma2 API interface then it needs to be brought back to the group so that the issues can be discussed and the API adjusted, if agreed and required, and all teams take the *same* interface API.  Asking each team to code their own API is, in my opinion, not going to work.

 

I hope that this doesn't happen but it may be worth formalising that some images may have API requirements that are not wanted or going to be used in other images.  Such APIs should be permitted for use within the image but must not be used by plugins or *any* shared code.  Those image specific API calls must be named in such a way that they are clearly associated with the image and can never create conflicts with any future API interfaces.

 

Perhaps I am being overly optimistic but I do think that this is a way to move this forward.

 

Regards,

Ian.

Edited by IanSav, 20 October 2020 - 16:07.

[WanWizard]

Not because there is disagreement but more because I think people are too afraid of reprimand if they try to expand and discuss the information required.

 

That is true for myself as well. Over the last years, the atmosphere between teams has become very toxic for some reason.

 

I guess working in a team (let alone across teams) is very difficult for people used to working in isolation.
 

For example, you appeared to prefer XRayhTec's Python specification over my generic specification.  Okay, so be it.

 

I have to revisit that, as I don't have either clear anymore.

We need two things to progress:

 

• The specification of the interface itself

This defines how the solution looks like from the point of the calling C, Python and Shell code.

 

Things like what do we call the beast, and how does it look from the ourside (list of values, public functions, a singleton class, etc). This has to be language specific, otherwise it can never be implemented.

 

• The specification of the individual items (may it be text strings in a file, global variables, functions or class methods)

I don't think my point 6 clashes with your template proposal (the fact it isn't there is undoubtedly related to your first remark).

 

Say for sake of argument we decide to go for a Python interface and implementation, and allow it to be callable from C or Shell, and we have the specification, a code template can be made without much issue.
As I am an avid proponent of documentation in code, the specification could easily be comments/docs, which would reduce the work, only one place for updates.

 

This will provide a class definition, factory code to access it, and method definitions with documentation. But no actual implementation.

 

This is where my point 6 comes in: given the vastly different ways in which teams create images, I don't want to force all teams into a single implementation, because that is doomed from the start, because of those differences.

 

This is no problem because the specification tells you how to call a method, which arguments to use, and what result to expect. How that result is obtained is not relevant, as long as it doesn't violate the specs.

[Persian Prince]

I'm not sure which team is the main team in OE-A but it has to be ViX or ATV and some of the ViX devs are here with good friendship (at least they're good with PLi).

 

Also we're good with PLi so there's no big problem here as the rest in OE-A are followers.

 

Only ATV isn't here and I get they're not so social, they prefer German language, they don't participate in discussions, they don't like PRs, they don't need our sources ... correct me if I'm wrong but they may have most ugly codes in their sources but as long as their images work they don't care.

 

The thing is they may never use our plugins or sources directly so they will be fine and when they think something is needed they will grab it.

 

We may consider our images as PLi's derivents as we merge from PLi's enigma2 but ATV isn't so you may want to not consider them for now.

 

At least create a Wiki for all plugin developers something like below

 

How to check STB model:

 

- PLi: Check x.py ...

- ViX: Check branding module ...

- Vision: Check vision specific files ...

 

So devs find what's needed with a simple wiki not dig up thousands of code lines.

 

I have to fix master branch of Backup Suite again after Zgemma ruined it with new namings and I will do it only because WanWizard helped me a lot with xml tool and I think I have to return the favor but the main problem isn't fixed yet.

 

STILL there's no API for all of us!

 

@IanSav

 

Please share your tool/sources so we start something here?

[Huevos]

Point 6 makes the project impossible. If everyone has to go off and create their own wheel, it is a waste of resources and the output will never be identical. The idea was to make one codebase that all distros will be able to use whether they are participating in the project or not.

 

@PP, I, for one, am not going to start writing plugins that don't work in ATV. Please try to be realistic.

Edited by Huevos, 20 October 2020 - 18:24.

[WanWizard]

One codebase is impossible, the differences between the images are too big.

 

Just look at the build differences between OpenPLi (which uses runtime detection) i and ATV (which uses a million recipe variables) and OpenVisionE2 (which uses text files).

 

The idea has NEVER been to make one codebase, the idea has been to make one uniform interface, so that in whichever image you call the method, you get the correct response.

[IanSav]

Hi @Persian Prince,

 

Please don't assume that openATV aren't following this discussion just because they aren't posting. 

 

I have been told that if and when there is something to post about then they will post.  I have discussed this project and forum thread with Captain.

 

Regards,

Ian.

Edited by IanSav, 21 October 2020 - 00:33.

[Persian Prince]

May I beg for a single proc file that returns PLi's boxtype so I can get the hell of Zgemma shit all over enigma2?

 

I don't care about any common solution anymore as all I can see here is "talk" and I can solve the problem with a simple proc file.

 

Forgive me to say this but I'm 100% disappointed of getting any common result here and I'm man of action.

 

All I read here is this is better that is not good, sorry but not working for me.

 

We're fine becauase we have our own "BAD" thing which works 100% so in order to be sure that something like Backup Suite works without keep getting fucked by Zgemma or any other we need something that won't change each month.

 

The thing is people think I'm the one who's breaking things becaus they say it was working and now it won't, without realizing someone else is responsible.

Edited by Persian Prince, 29 November 2020 - 23:41.

[WanWizard]

I completely share your frustration. I would have done something about it if not for the fact that the chances of it being rejected is very high, and I'm frustrated enough as it is.

 

I won't be able to look into it for the next few weeks, I'll try to come up with something before the RC becomes a Release...

[Persian Prince]

Our new module is up and there's no need for /etc/openvision/ anymore as we have /proc/openvision/ now:

 

https://github.com/O...s_main.c#L5~L37

 

This is called "doing something".

 

And now if anyone has a better idea I would be happy to "See" and "Test" it otherwise this thread could be closed for good.

[WanWizard]

Where does it gei its information from?

[Persian Prince]

Where does it gei its information from?

 

https://github.com/O...dule.bb#L23~L54