google / google/sagetv

Need to separate app space from user space.

Open
#298 6 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

In an effort to modernize the general architecture, it would be wise to split actual application files from user space files. Some of the groundwork appears to have been put in back in the port for MacOS X many years ago, but it wasn't universally utilized.

In Sage.java:
```java
/*
paths used by Mac OS X currently:
"core" = server files, read-only, version dependent, not user modifiable
"data" = settings, database, other files maintained by the server
"tools" = helper tools used by the server (eg: ffmpeg, jpegtran, etc..)
"logs" = where log files go
"plugins" = third party add-ons, like IR blaster, new hardware, etc...
"cache" - where generated thumbnail files go
The paths are determined at startup and set when the JVM is loaded via System.setProperty.
Each path is prepended with sage.paths. eg: "core" is specified as sage.paths.core
In the absense of these properties, we'll always fall back on "user.dir"
*/
public static String getPath(String which)
{
String defaultPath = System.getProperty("user.dir");
String propPath = System.getProperty("sage.paths."+which, defaultPath);

// slap a separator on the end since we'll be referencing something inside this directory
propPath += System.getProperty("file.separator");

return propPath;
}

public static String getPath(String which, String name)
{
return getPath(which) + name;
}
```

The major issue that needs to be tackled first is that there are many places in the core of sagetv that don't use this call, and instead reference `System.getProperty("user.dir")` instead.

Additionally, it seems that many plugins likely also use this instead of the sage provided call. To emulate current behavior and allow them to continue to access a writeable directory, we should be able to actually set the "data" folder as the current folder and launch the JVM from there, thus making the 'System.getProperty("user.dir")' point there.

I see this as a long-term goal, ultimately, but the internal core changes to get rig of the user.dir calls should be able to be done progressively through small fixes over time, then once we're all done with those, the launcher changes can be made, and the options to customize installations based on platform can be made in a more major version change.

Contributor guide

Open the contributing guide

Research direction

Start with Sage.java and its getPath methods, then search the core for System.getProperty("user.dir") references. Inventory which calls should use the sage.paths data or other folders, while noting plugin and launcher behavior. Done is not defined as a single change; the issue describes a progressive migration followed by launcher changes.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
backend
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.