diredev / podcache Goto Github PK

Spring 5 and SpringBoot 2 have been out for a while already. Try updating the project to use the new framework.

This includes:

• Update dependencies, clean up
• Replacing the Checker Framework with Spring's own annotation(?)
• Replace Jetty with an even smaller container(?)
• Try the new Reactive APIs

Spring 5 (#5) allows us to create reactive REST services. This could save on resources a bit (idle threads).

Might need to use a non-blocking (document) database (#6) or use workers.

The current implementation uses a very simple relational file database (containing just one small table and no relationships at all) and holds stream and content files in the file system.

Consider using a NoSQL database to hold metadata and the feed. Will probably still hold feed content in a directory though.

---

See also #2 for a directly related enhancement that will need to be solved as well due to different locking behaviors.

Commit 218fc6e made the web UI work (mostly) on mobile devices. This should work reasonably well for tablets and other "landscape" devices. The table looks very ugly on small-width devices however.

Change the style even more to make things look correctly. Or force "landscape"-mode for phones if that's possible (manifest-file, etc.?).

Podcache will create a directory for every feed and will download files to this directory.

There are currently no limitations on the possible feed names and no logic that will make sure the path used is sane.

Need to either limit the possible values for feed name or sanitize the directory names beforehand. Files should be sane since they are based on the feed URLs, but sanitize them anyway.

---

Also: Is there no proper Java API to do this?

Whenever a new entry is added to a feed, then FeedUpdater.updateContentFiles() will try to download those files in addition to any files already downloaded.

Note that the files aren't actually downloaded from localhost when the file exists. When a file is lost however, we cannot download the file anymore because the original URL isn't available anymore. It will try to download from localhost though...

Podcache will perform a full update of all feeds once a day (and possibly on startup). During the update (which could take a while on slower connections), HSQLDB will lock the table (for update).

The change from c5ae073 means that existing feeds can be read during this time at least, but adding or modifying a feed still has to wait for the entire update operation to complete.

It also seems like HSQLDB does not support lock timeouts (AFAIK), so the transactions literally wait forever.

---

Consider improving this situation. Maybe there is a better way (Java-side locks?) to enforce consistency?