RPi_Cam_Web_Interface
RPi_Cam_Web_Interface copied to clipboard
silvanmelchior
Web interface
👋 Hi, I'm a front-end developer and am using this software for a baby monitor quite successfully! Because my wife and I use this as a baby monitor, we're often using our phones to view the camera. The web interface is decently mobile friendly but there's definitely some love that could be given and I'd be glad to help. It's been quite awhile since I've done anything in PHP and would propose not to do a rebuild in regular PHP/HTML/CSS and instead move over to a framework like Angular.
I pulled down the code and started poking around and it seems like it would be a lot of effort to make that conversion and so I want to chat about it first before starting down that path only to have it not be inline with the project's direction.
Please let me know if this kind of redesign is something you're interested in. Thanks!
Yes. I would be interested in this.
As you can probably tell I am not a front end developer. I started contributing a few years ago when it had a very basic interface. I rewrote and added quite a lot of functionality into the underlying raspimjpeg process and gradually expanded the web side bit by bit to include the preview and scheduler side.
I could foresee 2 basic approaches here.
First is to keep the php server side functionality dealing with video generation and support of command processing (i.e. injection of commands into the raspimjpeg command pipe); and then rework the html, css, javascript client side to do the presentation. Today, that is still concentrated primarily server side with the html being fairly fully generated. The server side would need extra support functions (e.g. responding to requests for preview file details (json) rather then generating the html, but that is fairly easy to do and I would be able to support that..
The second approach is to do a radical rework of the back end as well using a framework as you suggest. That is probably quite a lot of work and sometimes one can spend quite a bit of time fighting the philosophy of the framework to fit in specific functionality. The scheduler is maybe one example here where the scheduler.php actually provides 2 functions. The first is the user access to changing settings, but secondly the scheduler.php is also running as background process to perform the scheduling actions. It would be fairly straightforward to provide setting functions to a new front end for display and editing as these are already json. The background process is reasonably complex and would be quite a lot of work to rewrite that.
The other comment I would make is that myself and a lot of users base the camera server side on Raspberry Pi Zero platform (cost, power, size). The current software runs nicely on this and with fairly modest CPU utilisation as a lot of the heavy duty work is in the GPU, I would want to make sure that any changes keep the server side processing low enough to keep this.
Let me know your further thoughts.
Thanks for getting back so quickly!
It's very easy for me to get lofty ideas for web-based apps but I 100% appreciate the ability to iterate quickly. As much as I personally love the second option you proposed, I frankly don't know enough about the server-side complexities but I do think if I had your support for backend services that we could accomplish it. The biggest change would be migrating the PHP server code to perform more like a RESTful API instead of a page-request model. I understand the performance concerns for the Raspberry Pi Zero as that guy does not have great specs but in my mind, the biggest CPU hurdle would be the video streaming. Standing up a simple API served up by PHP should not crush the server (unless many users were hitting it at once which I don't think is the use-case we are concerned about).
Could we work off an experimental 7.0.x branch to see what's possible? Are there any reasonable lightweight PHP frameworks for serving up a RESTful API? As for scheduler.php
The background process is reasonably complex and would be quite a lot of work to rewrite that.
I don't think that needs to be rewritten, especially if it already interacts with json unless I'm missing something.
OK. I think I could handle most aspects of RESTful API support at the server side. I would need to think a bit about the data model as I am not keen to introduce a database. Currently, everything is generated on the fly from the filing system.
On the performance side the preview streaming is actually fairly lightweight on the main CPU.
From a development perspective it may be easiest to generate a separate fork into my github account. That is where the current source for the raspimjpeg process lives. The web side lives under silvanmelchior who was the original developer. Although I am effectively the sole developer I don't have the administrative control so I don't think I can add additional contributors.
I won't be able to respond further till tomorrow due to other commitments.
I have forked over to my github account (roberttidey).
If you are still interested in trying to proceed then I can add you as collaborator on that and start to investigate making php RESTful server side.
Yes I would love that! I should have time tomorrow and Thursday this week. Hopefully can sprinkle in some time during the weekend as well.
This is great, something I had thought about contributing before but I just don't have the necessary skills to do a good job on the UI. Anyway, I commend the effort! Happy to participate in any testing, etc if needed
@ffcruz85 UI skills aren't all that's needed! To begin with we need to document the API domain models and endpoints (kicked off here https://github.com/roberttidey/RPi_Cam_Web_Interface/blob/master/API.md). Any feedback or contribution there would be very helpful!
I have opened a development discussion issue on the fork'd repo to make it a bit easier and avoid any confusion here.
I made some quick comments on API.md but will add more after giving more thought.
@SirZach Will look at it over there - I will have some time in a couple of weeks
I am going to start adding a template manager, probably smarty as that is what I am most familiar with. I should have something worth looking at in a day or two. Once that is done the rest of the UI work could continue from there since the JS and HTML will be separated from the PHP.
I am not sure this project really needs a "Framework" but that's a discussion that should happen up front and soon as it's easy now to code it into one whereas with each change it gets harder.
