search

jellyfin / jellyfin

The Free Software Media System
https://jellyfin.org
GNU General Public License v2.0
33.5k stars 3.05k forks source link

Consolidated Roadmap #59

Closed dcrdev closed 5 years ago

dcrdev commented 5 years ago

I'd like to put in some significant time this weekend to development on this, but I feel the direction at the moment is slightly fragmented -

Have we considered creating a roadmap and pushing feature requests to something like: https://feathub.com ?

Additionally have some questions that I'd like some feedback on:

Cheers

ryanjerskine commented 5 years ago

I see at the moment there's work being done migrated startup preferences to an App.config file. The App.config concept isn't really used in .NET Core, would it not make more sense to migrate this to a platform agnostic json manifest and store this in /etc/default and %\AppData in windows?

I'm a big fan of using environment variables for simple configuration. You also have the benefit of not having to bake all of the configuration into a docker image. https://12factor.net/config

dcrdev commented 5 years ago

@ryanjerskine even better yes - we'd probably have to pick those environment variable up from the init script and pass them as args to the server component, but definitely feasible and a good suggestion.

anthonylavado commented 5 years ago

Have we considered creating a roadmap and pushing feature requests to something like: https://feathub.com ?

IIRC, @joshuaboniface set up a link in the Readme, but something about that website unsettles me. It seems like it's pretty stale, and a few of the projects they showcase don't even use Feathub anymore.

I was considering another repo in the Org for feature requests.

I don't know where we could collaborate on a roadmap, but definitely one will go in the Wiki once we have it.

ryanwalder commented 5 years ago

A platform agnostic config file (JSON would by nice). I kinda disagree with the envars options (if the only way), jellyfin is about as far away from a 12factor app as you can get.

Disregard me, I can't read.

dcrdev commented 5 years ago

@ryanwalder sure but if this was picked up from the init script and passed in as runtime args - it would be entirely optional. In certain circumstances event beneficial.

In any case my overarching point is that the App.config concept is deprecated in the .net core ecosystem.

ryanwalder commented 5 years ago

Ah, I missed that part! Disregard my comment.

As for packaging it's been a while since I've packaged anything for yum but I can take a look this weekend if you like. One option is to build jellyfin + deps and host with someone like bintray.

Though that does mean a long term commitment to doing that.

dcrdev commented 5 years ago

Cool I was going have a go, but if you want to do it great.

For my packages I wrote a simple wrapper around mock that might make your life easier: https://raw.githubusercontent.com/dcrdev/brimstone/master/brimstone

ryanwalder commented 5 years ago

Neat, will take a little look when I get some time. Glad to help, I can't code for toffee but I can definitely sysadmin my way out a paper bag.

I assume the end goal is CI outputting builds to distro specific repos (and docker)?

BnMcG commented 5 years ago

Since clearly there is significant interest in WIndows builds, what is the plan for the service daemon here. Since .NET core does not support the service controller API is windows only and therefore does not exist in .NET core. I've been using this wrapper around the .NET Core compatibility layer for months at work: https://github.com/PeterKottas/DotNetCore.WindowsService . Thoughts?

I think NSSM is also a popular tool for this, not sure what the pro's/con's between the two are.

+1 for moving to Skia instead of having this ImageMagick fork kicking about.

joshuaboniface commented 5 years ago

I see at the moment there's work being done migrated startup preferences to an App.config file. The App.config concept isn't really used in .NET Core, would it not make more sense to migrate this to a platform agnostic json manifest and store this in /etc/default and %\AppData in windows?

I think this makes a lot of sense, anything we can do to avoid Mono/legacy cruft is a good thing.

Any reason we can't get rid of ImageMagick and solely use Skia? Upstream are already doing this on their .NET Core builds.

Skia from what I've read sounds good, better than keeping a bad fork of ImageMagick around. Like the idea!

Packaging - what's the plan here? So many distros don't have the .NET Core runtime and SDKs in their core repos (I'm mainly talking RHEL/CentOS and Fedora) , so is the plan here to just provide instructions on where thes dependencies can be sourced from? Or is providing self contained packages a consideration as upstream is already doing?

Packaging - again, for the benefit of packaging systems that require valid upstream source urls - again mainly rpm. Can we split packaging off into another repo within this Org?

I'm not in a huge rush to support RHEL distros - Debian-based is far more commonly used, along with Docker. I think instructions-only for .NET Core is fine, and we can split this out if someone is willing to take it on or expresses interest in it (I'm 100% Debian).

jeffkeller87 commented 5 years ago

@anthonylavado regarding a wiki roadmap: here's the high-level feature wiki page I started the other day (and probably got lost in the Riot room). I don't have permissions to add it to this repo, so it's in my fork. Things have been moving quickly so this may not be that relevant anymore--sharing in the event it's useful as a starting point.

Bond-009 commented 5 years ago

AFAIK Skia is already being used and ImageMagick serves as a fallback.

LogicalPhallacy commented 5 years ago

Since Windows is the only platform that really utilizes the "Service" model refactoring the project to support it natively I probably not worth the time, especially since there are valid reasons that someone might not want Jellyfin to run as a windows service. While I personally have a dislike of NSSM it is VERY good at what it does and its a perfectly fine option for anyone who wants the native binaries to run as a Service on windows.

Replacing App.config with something more modern is fairly inconsequential, but the more Linux-y collection of environment variables is particularly frustrating on Windows. Traditionally when those are used on windows they get stored in the registry. Right now Jellyfin is very very clean for a windows app, near as I can tell it confines itself to a few directories in userspace which makes it eligible for several of the windows modernization efforts (sandboxed apps, clean install/uninstall) with a fairly minor amount of effort. A JSON config would be preferable here IMO because it lets us keep that cleanliness.

joshuaboniface commented 5 years ago

@dcrdev Any further thoughts on this? Things have moved quite a bit over the last 3 weeks.

sparky8251 commented 5 years ago

Is it time to close this issue? About a month since a there was substantial conversation on it.