72 replies to this topic

[Huevos]

Elke developer vindt zichzelf het beste sinds gesneden brood, dus dat is niet nieuw.

 

En hij heeft gelijk dat ABM zowel qua design als qua implementatie niet de schoonheidsprijs verdiend. Maar dat is niet zo relevant als er geen alternatief is, dus dat moet er dan komen als dit niet goed genoeg is.

Why does this discussion start every time someone mentions ABM? ABM is very clean, easy to understand, Python code. Much cleaner and easier to understand than a lot of C-layer code found in enigma2. And apart from Fastscan/Cablescan I don't know of any plugin that has any CPP code. And locking plugin code in the enigma2 binary means the plugin can't be shared between images.

 

Anyway, the end result is it can read LCNs from some 50 providers, and there is no other solution that can do that.

[littlesat]

simple. Because the same can be made in a more structured way with hundreds of code lines less... you don’t need to parse the tables in python as good old dmm’s authors made a nice cpp libary for it... see cablescan. It’s just a pitty I’m also limited in time resources and cpp experience here... so I lack of demonstrate it again... (see hotkey, online flashing, fall back tuner channels import, etc...)
For me it is more than just the end result... for me it is also imported what engine is doing it!

Edited by littlesat, 6 March 2018 - 20:34.

[Frenske]

I moved this topic from the dutch to the english section.
One request to all, please behave like adults and respond with respect to eachother.

[Rob van der Does]

The problem is clear: Littlesat always asks for help/patches/pullrequests/bb-files, and when he gets what he wants he always starts a huge complaint about how bad/inefficient/ineffective the result is, and how much better and shorter the code should be, instead of showing happiness about the offered help.

 

Let me be clear: I'm not able or even willing to judge the quality of code; I can only judge the quality of the end result as it's being presented to the user, i.e. the functionality and user-friendliness.

But what I can be the judge about, is that always being greeted with negativism drains the enthusiasm of any coder to help PLi. And I know quite a few of them who refuse to offer any help/pushing-back to PLi, solely for this very reason.

 

Of course there can be criticism about code, and there usually is (especially if it's not your own code). But is it always necessary to show this criticism so clearly? There are better ways to handle critics. It's all about the way criticism is presented and about the amount of it.

 

What about the following guideline on receiving help:

1- Show being content, being happy about the offered help (instead of the current habit of complaining).

2- See if the help (in whatever which form it took pace) can be used without much difficulty. If so: apply the code.

3- Evaluate the code, make an invent of the goodies and the baddies of it, but do that in an inner circle. There's no need to spread all the critics around the world.

Of course: in this stage contacting the original author can be usefull, but should take place in a respectful way.

4- Start enhancing the code; in the end this may even mean replacing it completely with your own.

 

IMHO this would be a much more pleasant approach than the current continuous bashing of offered 3rd-party code.

After all: c'est le ton qui fait la musique!

[littlesat]

The problem seems not to be clear you. Pleas stop bashing me in person. Stay objective on the code itself.
Yes it is working and yes it is a good reversed engineering project and yes it is helpfull and yes it is currently the only thing that does more than service scans, cable scans and m7 fastscan... and yes it was a lot of work and lot of time to make such complete plugin... and yes I appreciate it!
But please look at the code and compare it how cablescan and fastscan is done... I’m sure when you do it that way you can do the same faster with less more structured code. So I only try to motivate the community to get it beyond the next level... but it seems that this is not appreciated the way I’m attacked in person...

Edited by littlesat, 7 March 2018 - 07:23.

[Rob van der Does]

I'm very sorry I can't seem to get my meaning over to you. 

IMHO "c'est le ton qui fait la musique" should be clear; it's an expression even used in Dutch.

 

To say it in clear English words: It's not about criticism; it's about the way you present criticism.

 

 

Anyway: I can't explain any better/easier/clearer why coders walk away from PLi.

[littlesat]

I cannot change your meaning, but I’m afraid you make a big mistake here as you really don’t know me... probably the ‘hard’ words on a platform like this forum do not help here...
but again this is persoon against person with loosing the real ‘objective’...
Please listen to your own music. I’m the one who is shot in this case as it seems It is crime I deliver critism as I’m littlesat from openpli...
I asked to stop attacking me in person... but it seems it did not stop!
And now back on the topic instead of shooting me... the Q of applications in General....

Edited by littlesat, 7 March 2018 - 07:38.

[Huevos]

The way I see it the thing always getting bashed is ABM.

 

The truth is, it does what it is supposed to do. It does it quickly enough. It reads the SI tables as fast as they come up on the transponder. It would be impossible to do it quicker whatever language the code were written in. The code is clear and easy to read. And there is extra code so users can customise their bouquets to exactly how they want. When you add features, you add code.

 

Please show me the hundreds of lines of code that could be stripped from the plugin, without losing the current feature set.

 

And like almost ever plugin since the start of enigma2 it is written in Python.

[littlesat]

Just to give it one direction to one of my points....

 

https://github.com/o...uquetswriter.py

 

It looks almost duplicate to and it hacks 'around' this...

 

https://github.com/O.../lib/dvb/db.cpp

 

Why not use this to add services and create the bouquets/lamedb? This can be done from python as well... 

 

But why do I continue to defend my opinion? I'm doing it always wrong...!

Edited by littlesat, 7 March 2018 - 15:01.

[arn354]

someone might be able to do it "his" way with the knowledge and capabilities he has, but he probably is not capable doing it "your" way.

[WanWizard]

Apart from all the good, bad, emotional discussions going on, this is actually a good example.

 

There is an official API to write to bouquet files and the lamedb. If in the future we decide to change to a central SQL database (or key/value store), everything that uses that API will keep working, as the backend is hidden from the frontend via the API. All other solutions will break.

 

This is a similar issue to the entire editor discussion: just because you can, doesn't mean you shoud. These files are internal to Enigma.

[WanWizard]

someone might be able to do it "his" way with the knowledge and capabilities he has, but he probably is not capable doing it "your" way.

 

That suggests (more) documentation is needed so everyone knows the core API's that exist, and how to use them. Which might be a valid point.

[Pr2]

Hi,

 

Enigma2 is thousands of code lines (C and python) with nearly no comments in the source code.  So if somebody wants to make a change, there is first a huge reverse engineering search to know where and how to change things.  When you have commented out lines, most of the time, those are debugs print out that are commented out to be disabled.

 

If code itself is well commented there is no real need for an external documentation, but for Enigma2 both are missing.

 

So indeed a developper can (normally) understand what is done by looking at the code but this is not the better approach since it is time consuming. If there was valuable comments in the source code this will ease life for people that want to add/modify/improve features.

 

Pr2

[WanWizard]

It is worse than that, the codebase is also one big bowl of bad-tasting spafhetti (what Littlesat calls "GhostWare" ), so even for a good programmer it is very difficult to understand what it does, the code isn't self-documenting at all.

 

Furthermore, there is a complete lack of architucture and design, even simple design and coding principles like encapsulation, separation of concern, dependency injection and loose coupling aren't followed.

 

Ideally, we should pool all expertise together, have a professionally structurered team, and rewrite the whole damned thing!

[Huevos]

Apart from all the good, bad, emotional discussions going on, this is actually a good example.

 

There is an official API to write to bouquet files and the lamedb. If in the future we decide to change to a central SQL database (or key/value store), everything that uses that API will keep working, as the backend is hidden from the frontend via the API. All other solutions will break.

 

This is a similar issue to the entire editor discussion: just because you can, doesn't mean you shoud. These files are internal to Enigma.

If it is a proper SQL database it will be available to Python and have an external port so other applications, bouquet editors etc can use it. If not it will be a nail in PLi's coffin.

[littlesat]

When ghost was not one of the creators I would call it AtticWhere...
In e1 we had a nice database for the epg... which was never ‘ported’ after all these years to e2...

Edited by littlesat, 8 March 2018 - 07:48.

[WanWizard]

If it is a proper SQL database it will be available to Python and have an external port so other applications, bouquet editors etc can use it. If not it will be a nail in PLi's coffin.

 

Then you haven't understood it at all. Hacking your way into that SQL database would be as bad, if not worse, than hacking your way into text files.

 

The point of having an API is to have unified, validated and controlled access to the backend. An API should completely encapsulate the backend.

 

This is exactly the problem I have with the way everything has been built, and is continued to be build. There is no architecture, there is no design, there is no design authority, there are no development guidelines and programming standards, there is no quality control (and @Littlesat gets bashed when he attempts to say something about quality, sometimes awkard but always with the best of intentions), and the code is a mess because everyone hacks it's way in to get things done without looking at the bigger picture.

 

And the fact that multiple development groups compete instead of work together doesn't really help either, instead of moving forward together we keep reinventing each others wheels... 

[Erik Slagter]

What annoys me most is the absence of abstraction. In other words: no API. They all reverse engineer the internals of enigma and start to use it, very wrong (but there is no alternative (yet)).

[Huevos]

My point is if you somehow modify OpenPLi so the bouquets, etc, are only editable from the GUI, PLi would die overnight.

[WanWizard]

I didn't think anyone mentioned the word "GUI"?

 

The remarks are about programming, and programming principles. If there is a decent CRUD API, code on the box could use it in a unified way. And it would be peanuts to create a HTTP/JSON interface for it, so code outside the box could talk to it to. While keeping Enigma in control and the data consistent.