Investigation - Installing apache on Raspberry pi

[Geektoolkit]

Just starting a topic to let the team / community know that I'm going to spend time investigating removing the web component from Dynaframe and utlizing a proper apache web server. This would give us a number of powerful advantages, clean up some messy code we have, and help divide some things that we currently join together. i'll still likely have a back channel to control a dynaframe directly, either via tcp commands or similar.

One benefit is that only one frame would take the hit of hosting a webserver....other frames would 'talk' to it to find their settings and should be very simple image / video renderers at that point. This means that we will save the memory/processing of having webserver code/threads running on every frame.

It'll also open us up to some nicer and quicker UI development. The web code for dynaframe is getting to be a bit much to dig through and it's tough to keep it clean.

Synced frames would also benefit, and frame management would be much more powerful...you could manage all frames from one UI.

This is likely part of what I'd call 'dynaframe 3', along with proper tag support. But I want to put it out there that I'm investigating it. First thing that needs to be done is apache running a website needs to happen at the same time dynaframe is running to ensure they can coexist.

[Archonw]

Sounds cool to me. I am already in love with your fantastic program and it looks like you are still are not at the end of the line with it and this is fantastic.

[RichN001]

Ive been tumbling this around for sometime. Im not sure what the best way to handle this really... create a master frame that runs apache... sorta like what your saying above. I guess then on install you would have to answer the question of is it a master or slave install have to have a static local ip... etc...

or

Is it time to create a public webserver where users register for a free account. and when they install Dynaframe it gives them a code or displays a QR code (UUID from the Pi) that they would link to their account. Have the main server do a tunnel API for commands to the frames. This would allow linking multiple frames to accounts and control over the internet. No IP's needed for normal use.

Something like this could probably handle sending Update API commands automatically or based on user preference.

When I started helping out my thought was to just create an app that would allow this functionality to work but locally only (Unless it was made with a FQDN). But if it helps any at least for discussion and brainstorming, Ill give a link to a screen shot video of how the app was going with multiple frames. It was just a theory and very RAW, but it works..haha.. I think with a central server there would really be no need for a physical app like this, a WebApp could be done the same as well.

Keeping things local is great, but having universal access by just entering a frame ID and having a central place to manage it all might be a goal worth working on.

I don't think at least for now that server resources would be that much of a burden and I have no problem spinning up something to handle it. if the user base got crazy I guess we would have to look at something for scale, then there would be cost for hosting and the debate on a small fee for user accounts would have to be looked at. But Im not sure the user base would ever be that big that it would happen... not for some time anyway.

Theory app Link

[Geektoolkit]

Hmm. I'm hesitant to offer any cloud capability just yet, but it's something I've thought about to enable things like easier updates, the ability to stream down art packs from artists, etc. But I'd like to wait on that.

The idea of multiple apache clients is a good point. if I have two apache clients on two machines how do I say which one controls both frames,, and how do I spin one down in a way it can be spun back up if needbe. I'll think on it more. I also think a service is needed to provide a watchdog of the frame, and if it crashes, restart it. but also to help make an autoupdate / update mechanism possible...it'd kill the frame processes, backup needed stuff, remove the folder, clean install, and then restore the folders.

[Archonw]

I would prefer when everything stays selfhosted, without any need for cloud services, as long as possible.