Hello Devs,

I'm looking for input on the image I added to:

https://ted.nu/wiki/index.php/Shows.ted

It shows the object hierarchy of objects that could be in the Shows.ted file.

I'm looking to better define the domain model, and figure out which objects should be transient. This will allow us to create a better, less coupled, domain model that is needed for a proper web ui.

What I would like help with is identifying which objects in that image hold state that is required between restarts of the program.

I can slowly figure this out by seeing where the objects are created, and what information they store, but I'm hoping one of you will know already.

For example I'd like to decide that SeasonEpisodeScheduler is transient, and therefor doesn't need to be saved. I already know that they are created the first time you ask for one, so it's not a problem to create a new one. What I don't yet know is if they are customizable by the user, or if any of the objects they hold are customizable by the user.

Once I know this I can work on a translation/upgrader layer to a simple jaxb domain model. Then I'll be able to eliminate the binary shows.ted domain.

If you guys don't know, that's fine as well, I can figure it out.

Thanks

I think this diagram is almost correct.

A 'standardstructure' is a superclass of a DailyDate or SeasonEpisode class. But a TedSerie only has 1 of those instances. The vector of episodes is kept in the SeasonEpisodeScheduler

The SeasonEpisodeScheduler now holds the whole schedule of a show. We might want to move that to the TedSerie class, or split the class in a schedule and a schedulecontroller.

In the end, it would be nice if we could lose the TedDailyShow as well, such that only the class of the schedule determines the episodes we are looking for (Daily episodes/Season Episodes/Sequential episodes). But we kept the difference because the way of parsing is different. , can you explain why that is? I think it had something to do with the fact that you can set a maximum number of episodes for a daily show, but you can't for a normal season/episode show.

In my view, you have one show class that has a schedule which contains episodes. Those episodes are where the difference between the kinds of show become clear. We now have a DailyDate, SeasonEpisode datastructure. In my ideal view, that is the only difference between a normal show and a daily show.

Correct, good catch. I missed one link from a TedSerie to a StandardStructure



How come? Could we not look up the show schedule again when we needed it? Would a user change this schedule?

I think the main problem now is that it holds on to so many other classes. I'd like to start with just generating this data on startup, and then add caching to the different schedule sources (ted.guide.*), so they can look locally for most of their information.

TVDB already supports this by saving the XML files as you load information, and querying the server for just what has changed since the last update.



I completely agree, and this would be the direction I'd be moving in.

Thank you for the comments. Any other of the classes you can help me with? I'm really hopeful most of these objects won't need to be serialized.

Well, the schedule is needed all the time to display the release date in the main dialog to give an example. Don't know if that is a good reason to store it at its current position but that's why it's done.


How do you mean? To give him the option to adjust the schedule? That would be nice, but also quite tricky. Currently the schedule is created from 2 different sources so you don't know where specific information comes from. You would have to store that information then somewhere which gives extra overhead.


The DailySerie indeed only downloads the latest x released episoded. This is done so ted doesn't download 30 episodes after you've been on vacation. Also you are most of the time only interested in the latest episodes.

Sorry Jofo, I think I'm being confusing. I meant could we look up the information each time ted is started. Instead of persisting it to disk between restarts. I'm trying to figure out the minimum set of 'user data' that we need to persist between restarts of the program.



. Actually at the moment I'd rather a user not be able to change the schedule. If the user doesn't customize it, then we shouldn't have to persist it.

If I'm reading your response correctly, then currently a user cannot change the schedule. That's perfect.



Very good to know. I'll keep this design decision in mind with any refactoring of that code.

Thanks Jofo.

Note that one thing we always tried to do was to not overload other services. So at this point we load the schedule one time a week and that's it (unless you press the update button). We could do this more often but we're not sure if these services would like that


That's correct, at one point in time they could make there own schedule (well, at a release day or put ted on hold till a certain date) but we removed that feature as we think it's obsolete. Apparently some people don't like that.


Thank you I think your diagram nicely shows what is currently wrong. You even didn't draw all the lines coming from the TedDailySerie class