google / google/sagetv

Refactor SageTV into multiple projects

Open
#300 10 comments 0 reactions 0 assignees View on GitHub
enhancement
Dominant language
Java
Stars
287
Forks
172
PR merge metrics
No merged PRs in 30d

Description

SageTV has long history of development, and as it happens, that tends to lead to monlithic code structures where everything is in a single project. This makes it harder to manage in the long run.

Initially there are some obvious boundaries
- sagetv server
- sagetv placeshifter
- sagetv studio
- sagetv client
- sagetv shared

There maybe circular dependencies there, that would need to be solved in the process.

In addition to these projects, I'd like to see the "native" parts split out as well. Some time ago, I started this process, because I wanted to introduce unit tests that could run withtout the native parts. In the end I just did a "hack" and introduced the Native class that would load a library and optionally, not fail, if it wasn't there. (this is big task in how to logically structure things, not a big task in how it's done)

But, I think that the native parts should be accessed via more concrete interfaces. Currently Sage.java uses a lot of "native" method implemetations, and I think much of that should be delegated to native implementation classes. eg, there might be a WindowsNative class that defines getRegistryNames() and in Sage.java we can initialize the native implementations on startup, something slie getRegistryNames in Sage.java calls "nativeImpl.getRegistryNames()". This helps keep the native parts separate, but also allows for us to swap out the native parts with non-native parts should we need to (ie, for unit testing, etc).

I also would like to see OS specific implementation code in a separate project, or at least in a separate package space; sage.linux, sage.windows, sage.mac, sage.android.

In the process of moving to multiple projects, I'd like to see the UI/AWT/SWING code in a separate projects as well. There are numerous places in Sage where AWT libraries are used, and because of this, it makes it hard to port a server to something like Android. SageTV doesn't "depend" directly on awt to run (with the exception of some dependenices on Dimension, etc, but these can be abstracted out, and awt implementations can be injected when needed).

Lastly, sagetv has a lot fo "EMBEDDED" flags. We should determine if we still need/want to support an EMBEDDED mode.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.