For The Record - The rule-based scheduling suite (8 Viewers)

[Broceliande]

Hi DVDfreak
I don't know why you exactly just don't wanna even think changing your mind ,
but as you already know , we don't want to store epg data somewhere else than where it is actually. At least for now , and surely not soon.
For us that's a collective though , and choice.
At this time we don't really know other abstraction layers than gentle wich are 'stable enough, and free to use'
In my opinion , it would have been really easy for you to just use the Program Table for storage and retrieval.
As i told you while our last meet, you seem to be waiting for us to rewrite a lot of working parts of MP in order to fit your piece of software , rather than trying to make it compliant.
For those reasons , and because you couldn't convince me , i won't be the one who will support this project for MP.
Regardless of your features , wich sounds to be nice and working for some users , we cannot reinvent the whole weel just for it.
I know you told it's not a plugin
But nevertheless it's a third party software , and should be able to work with no changes in so many parts of MP .
Hopefully you'll think about it again.
For my own part , for now , i just cannot support it.
Regards
Broceliande

 

[dvdfreak]

Hi DVDfreak
I don't know why you exactly just don't wanna even think changing your mind ,
but as you already know , we don't want to store epg data somewhere else than where it is actually. At least for now , and surely not soon.
For us that's a collective though , and choice.

It's too bad the benefits of what I propose are not clear to the MP team.

At this time we don't really know other abstraction layers than gentle wich are 'stable enough, and free to use'

Well, Gentle is a "basic" ORM, not more, not less. It's hardly comparable to a service-oriented approach.

In my opinion , it would have been really easy for you to just use the Program Table for storage and retrieval.
As i told you while our last meet, you seem to be waiting for us to rewrite a lot of working parts of MP in order to fit your piece of software , rather than trying to make it compliant.
For those reasons , and because you couldn't convince me , i won't be the one who will support this project for MP.
Regardless of your features , wich sounds to be nice and working for some users , we cannot reinvent the whole weel just for it.
I know you told it's not a plugin
But nevertheless it's a third party software , and should be able to work with no changes in so many parts of MP .
Hopefully you'll think about it again.
For my own part , for now , i just cannot support it.
Regards
Broceliande

Again, if you don't see the benefit, what can I say? Maybe read up on some documents about service-oriented architecture?

A complex piece of software, and I'm sure we all agree that MP is complex enough , should be broken up in manageable pieces. Choosing a good architecture for this is key to getting a product stable. Otherwise you will only get it stable by very carefully tweaking the code and never touch it again once it's stable. The moment you touch the code, pooooof goes the stability.

So what I have here is one of those manageable pieces, the scheduling nicely split off in a well-controlled subsystem. I keep repeating myself, if you don't see the value of this, what can I say?

Guess your reply simply means there will be no TvScheduler in TVE3 then.

And please, don't make this look like I refuse to do something "easy" in TvScheduler, that's a distortion of the truth. There's nothing "easy" about me reading the TVE3 database, for one it's too limited in information, and secondly, since I can't know when the database changes (whereas now I do) this would add another layer of complexity, which is exactly what I was trying to avoid. Not to speak of totally throwing the design out of the window.

 

[infinite.loop]

Guess your reply simply means there will be no TvScheduler in TVE3 then.

currently the TV-Server is in a feature freeze which means that we can not do that big changes as integrating your application would cause.

but to be able to discuss the possibility of integrating your application, the developers will need to take a look at your code.
so could you please publish your sourcecode?

 

[dvdfreak]

Guess your reply simply means there will be no TvScheduler in TVE3 then.

currently the TV-Server is in a feature freeze which means that we can not do that big changes as integrating your application would cause.

Sure, I can understand that. I never suggested anyone started modifying the code immediately. As I mentioned before, better to have a decent and stable solution in the long term than a bad and flaky solution in the short term.

but to be able to discuss the possibility of integrating your application, the developers will need to take a look at your code. so could you please publish your sourcecode?

I do not understand in how looking at the code will change e.g. Broceliande's opinion. What I propose has little to do with source code, and everything with design/architecture.

 

[infinite.loop]

but to be able to discuss the possibility of integrating your application, the developers will need to take a look at your code. so could you please publish your sourcecode?

I do not understand in how looking at the code will change e.g. Broceliande's opinion. What I propose has little to do with source code, and everything with design/architecture.

how can we decide/find out how your application can be integrated/how it works without having a look at the code?

if it will get integrated then the code will be opensource/gpl, question is if you are fine with that.
somehow it seems like you are not.
or did i get the wrong impression there?

i personaly would like to see it integrated, but befor that the developers always go throught the code of a potential new feature.

 

[dvdfreak]

how can we decide/find out how your application can be integrated/how it works without having a look at the code?

You don't need the code for that, honestly. What I posted is sufficient, and I never got feedback on that actually.

And anyway, from what Broceliande posted it is clear there is no room for integrating TvScheduler the way I propose it.

if it will get integrated then the code will be opensource/gpl, question is if you are fine with that.
somehow it seems like you are not.
or did i get the wrong impression there?

I'm perfectly fine with that, but I defend the architecture I'm using I think the stability of TvScheduler is enough "good press" for the architecture I propose. The scheduling is many times more powerful than the one in TVE3, and from the feedback I get there are very few bugs so far.

I have no wish to prematurely release the source code and see it being mashed up into something I cannot support. Because it looks like that is exactly what is going to happen.

i personaly would like to see it integrated, but befor that the developers always go throught the code of a potential new feature.

I'm definately not dropping this project, I will see how this will progress. I will keep posting beta's here if there's still interest in people testing this and following how this continues to grow into something usable and stable.

I was really hoping TVE3 would be the recording part of the big picture, with TvScheduler being the scheduling part. But I guess it will play out differently

 

[gemx]

But in the meantime, what about my suggestion of having a TVE3 plugin which just copies the epg infos once per day or so?
Such a plugin is no big task and would increase the number of potential testers not to forget: you don't have to change YOUR architecture and we don't have to change anything on our side.
Also having the infos twice/ in 2 dbs is not perfect but shouldn't be a problem as far as hd space is regarded

 

[GoldenEye]

For my own part , for now , i just cannot support it.
Regards
Broceliande

Brocelande,

From my (an end user's) perspective, dvdfreak's new features are critical. And IMO it is a need to integrate the functionality into TVE3. Otherwise I fear that the WAF will decrease and that the funtionality will only be used by technical people.

I am not a programmer so I cannot estimate the effort needed for adapting TVE3 to dvdfreak's suggested architectural changes. However, I have to admit that dvdfreak's approach (externalisation of the EPG and making it accessible through a stable API) makes sense to me because this sounds like more long-term stability and less side-effects due to changes, which is what we all are looking for (and which seems to be a general MP issue).

I am confident that the development team will think deeply about their decision whether to incorporate changes like dvdfreak's although I can understand your point of view. Probably, this discussion would not be needed if dvdfreak had discussed the archtectural topic before starting his project.

G.

 

[dvdfreak]

But in the meantime, what about my suggestion of having a TVE3 plugin which just copies the epg infos once per day or so?
Such a plugin is no big task and would increase the number of potential testers not to forget: you don't have to change YOUR architecture and we don't have to change anything on our side.

Yes, that could be an option. Too bad the Program table doesn't have a last-modified timestamp, so I'd have to either synchronize everything, or only programs with a start-time newer than the last time I synchronized (but then you'd miss out on updates).

I am confident that the development team will think deeply about their decision whether to incorporate changes like dvdfreak's although I can understand your point of view. Probably, this discussion would not be needed if dvdfreak had discussed the archtectural topic before starting his project.

Actually, I did Read the very first posting all the way to the end, the architecture is described there.

And thanks for understanding, glad someone sees what I am trying to accomplish.

 

[joboehl]

dvdfreak, sorry just jumping in now.

I agree with i-loop. Looking at the code (or the least the schematics) help a lot to estimate the coding effort to integrate your solution.

I don't know how many classes, interfaces or how your API looks like. I can see a lot of integration points all over the place from the TVEngine and the scheduler.

You see, refactoring TVE3 is a big change, adding a last updated column to a table is not that big of a change. Maybe we can find somewhere in the middle?

Don't get me wrong, I known your features are good, I respect and understand your architecture proposal, but it's something we can't change that easily, especially during a freeze and not knowing how much change we actually need. Without that, we don't know how much we can break in TVE3 for example.

As of now, TVE3Server structure is defined and new code should obey to it. Can it be improved? Probably, but it's how it is for V1. We are focusing on having it stable and reliable. You are more than welcome to help on it.