72 replies to this topic

[Huevos]

Well then if there is an HTTP UI any Python plugin could talk to it. So what is the difference between that and Python accessing the SQL DB directly? And why would you loaded an SQL DB and then go out of your way to make it unavailable to any plugins that might want to access it?

 

Probably, I am not intellectual enough to understand. The way I see it, it is just another hoop to jump through that will lead to OpenPLi having less contributors.

[WanWizard]

If you have an API, the API determines what you are and aren't allowed to do. It can also do input validation, deal with referential integrity.

 

Encapculation via an API also means you can change the internals without impacting the API. You could even swap out the SQL backend by something completely different, and Enigma and plugins would be none the wiser. So the code is loosy coupled of even completely decoupled. If you access the SQL DB directly, you haven't improved anything compared to the current situation. You can still incorrectly modify the data, and if something in Enigma changes, all plugins break. Tight coupling is evil.

 

So it is about stability, compatibility, and extensibility. API's should be documented, and have a known input and output. Encapsulated code can be tested in isolated, and tested code is stable code. Code changes can be tested without having to test the API, as that is tested seperately and known to work. It also greatly reduces regression errors.

 

Something every developer should welcome. And don't forget the users, they will get a much better and more stable and profesionally build product.

 

So it has nothing to do with intelligence, these are completely normal and standard development practices. 

[Pr2]

Hi,

 

What are the benefits of having a SQL DB just to store transponders informations and services?

 

With the current approach it is really easy to take a backup of the files and store them elsewhere to quickly duplicate the channels lists between different STB, to create a custom backup/restore shell script.

 

Willing to switch to SQL database let me think of what Microsoft did with the registry. Before each application have its own individual configuration file, you want backup or delete an application was easy just one folder contain it all. Do you really think that registry is a great idea of Microsoft?

 

Why not simply keep the "flat file" approach but switching it to an XML file this will allow the extension of the structure when needed.

 

So why turn something simple that works quite fine into something complex only accessible from API?

 

Pr2

[WanWizard]

You're missing the point completely. It was used as an example. 

 

Having said that, the main idea behind using an API and encapsulation is exactly that you CAN'T hack your way in anymore. The mechanism to store that actual data is totally irrelevant. I would even go as far as to say that for the uninitiated user, the Microsoft registry is a lot safer than the collection of text files in /etc in a Unix environment.

 

The entire discussion started because of the misery you get when you simply copy files, instead of copy data.

[Abu Baniaz]

We still haven't implemented lamedb5 even though it is better.

[Erik Slagter]

And that is besides the point even so.

 

Maybe it helps everybody can still use their favourite channel settings editors WHEN these also implement access to the enigma data structures using the well-defined (to be) API? And when that happens, well-known problems will be gone (like the random insertion of "pid 0" subtitles).

 

And also as soon when that's done, there version of the lamedb will be completely irrelevant. The lamedb could be stored using some sort of database, ASCII file and we could change it at any time. And the external tools would still work.

[WanWizard]

It seems to be a recurring issue here, that every time an architectural or design discussion starts, it quickly races to the bottom of the pit to discuss all sorts of implementation details.

 

I can only repeat, the "SQL database" was used as an example to illustrate the need for proper architecture and design before you start implementing, and to show the importance of doing so.

[Erik Slagter]

And somehow examples then always very quickly become the goal. Guys, once again an example of how we rush to things instead of thinking them over and dicussing them.

[Rob van der Does]

As has been said many times before. Heading into coding before knowing what to achieve.....

Edited by Rob van der Does, 11 March 2018 - 10:58.

[Huevos]

Hi,

 

What are the benefits of having a SQL DB just to store transponders informations and services?

Means the data and the format of the storage system are separate items. If you write directly to the flat file there is a chance you will write the data to it incorrectly. With the API you would have a validation process. So instead of relying on your app to sanitize the data you can rely on the API.

 

And don't think the data can't go in a flat file. SQLite is probably the most the most popular SQL application of all and that stores the data in flat files without there even being an SQL database daemon.

 

But the reality is there are much worse things than this in E2 that need correcting. People just talk about this one because it is easy, unlike the others which would require a lot of skill to sort out.

[WanWizard]

But the reality is there are much worse things than this in E2 that need correcting. People just talk about this one because it is easy, unlike the others which would require a lot of skill to sort out.

 

Hence the statement it was an example.

 

To do it right, half of E2 needs to be rewritten. Not an impossible task, but time consuming, needs (indeed) lots of skilled hands, but even more it requires proper architecture and design work up front, documented, and professional project management and good team work to see it through.

 

At the moment the available hands and skills are scattered over different competing projects, reinventing wheels instead of working on a common project, all run (and I explicitly include OpenPLi in this) pretty amateuristic, ad-hoc, and driven by seperate ego's.  Exacty the reason why so many open source projects fail, the fact that it is open source and one works on it in their free time doesn't mean it shouldn't be run professionally.

 

As long as this is not addressed, it will simply never happen.

[IanSav]

Hi,

 

As an external contributor I would like to offer some comments:

1. There will always be lots of opinions on how to write every piece of code.  It is important to be open to someone making suggestions that may well well be valid improvements to your code contribution.
    
2. If you want to criticise some code do it constructively.  Explain what the problem may be.  (The reason "we always do it that way" is often a poor reason.)  Try to offer an explanation on how your idea could be improved to make it more acceptable.  If the code can't be used then explain why this is the case and try to find out what the contributor was trying to achieve and perhaps suggest ways that the objective could be met.  Remember to be open to having things done in a new way that may prove to be better.
   
   Being told your code is crap does not inspire people to come back and contribute more.  Teaching a new contributor how to make better contributions will be far more rewarding for everyone.
    
3. Documentation for Enigma2 is VERY important and sorely lacking.  I perceived an issue with colour button handling in the UI so I wrote a document to explain how I thought it could be handled.  This can now become a template of how this should be done in the future.  There needs to be more of this sort of documentation and it shouldn't be buried in the code.  Some people, like skin authors, often don't work at the code level and will not see such embedded documentation.  Any documentation should be easily accessible to all.
    
4. APIs and standardised interfaces are very important to creating large but manageable systems.  For those who don't understand what is meant to an API, think of it like a waiter in a restaurant.
   
   A customer comes to the restaurant to get food.  They don't want to know the fine details of where the food was bought, how it was prepared, how it was cooked.  They just want the meal that they would like to eat.  They give their order to the waiter and the waiter places the order to the kitchen.  Similarly the staff in kitchen don't need to worry about who ordered the meal, where they are sitting, how they are going to pay.  The waiter will liaise with the customer to handle that part of the process.  The waiter (or API knows what needs to happen to manage both ends of the transaction and asks for and / or formats the details so that each side are able to do their part of the task.
   
   As new customers come and go or kitchen staff are hired and fired the business of the restaurant continues.  The waiter makes any appropriate adjustments to that regular customers can get what they want even if the chef has changed and similarly a regular meal made by the kitchen can be served to any customer without needing to know anything specific about the customer.  That is neither side needs detailed information about the other side to have the system work smoothly.

I hope people don't mind me weighing in on this topic but as a recipient of some of the harsh treatment I felt my opinion may be of interest.

 

Regards,

Ian.

[Frenske]

As I definitely aren’t a developer, far from that, but just a member of OpenPLi I can only say one thing, or actually two.
Hear hear!!!

I hope that the ones you’re referring to may learn from your proposal.

[IanSav]

Hi,

 

Is there a reason why users are not permitted to edit their own posts?  There are a few errors in my post I would like to correct but can't. 

 

Regards,

Ian.

[Frenske]

As far as I know you are allowed to edit your post to a max of five minutes. You can post it again and i will copy it to the original and delete your second one.

[IanSav]

Is there a reason for the 5 minute time limit? Seems a bit odd.  I think it would be better to always allow users to edit their posts.  This would allow errors to be corrected for those that may find / read the post later.

[littlesat]

Because you can twist threads with it

Edited by littlesat, 16 March 2018 - 07:30.

[WanWizard]

Is there a reason for the 5 minute time limit? Seems a bit odd.  I think it would be better to always allow users to edit their posts.  This would allow errors to be corrected for those that may find / read the post later.

 

Yeah, there is. We have had people that changed posts, or even removed entire posts, days or weeks after they were posted, destroying the context of threads. As always, the good have to suffer because of the bad...

[Huevos]

It would be good if we could edit the post up to when there is a new post.

[WanWizard]

I agree.

 

But the current codebase of the forum doesn't support that functionality. There is a major upgrade overdue, we'll have to see what features that version has, and if the vendor is willing to accept this as a feature request.