Closed ZyanKLee closed 3 years ago
ZyanKLee
commented
4 years ago I'd like to notify and invite at least the six most recent contributors (Micz has been mentioned in the post above) to this discussion: @andreasbrett @s-martin @patrickweigelt @splitti @veloxidSchweiz @xn--nding-jua
s-martin
commented
4 years ago Questions:
- Is it ok to have all those parts in one repo or is a github organisation with multiple projects better?
I think one repo with sub directories for each component is fine. Phoniebox isn’t that big and I think different repos adds another level of complexity, which could be hard to integrate in a working product.
- How can we organize the project without one of those parts constantly interfering with the others?
Different sub directories with maybe directories for common stuff could work. Adding (automated) unit tests for each component could be added more easily as a separation in components forces clear interfaces.
- What could a git workflow look like that allows us to maintain a stable version (currently: master branch) and development of new code / rewrites of existing code that can deviate in large parts from the stable version?
I think the current workflow is fine in general. Alternatively we could use GitHub Flow, which is very lightweight. Master is always deployable and each feature/fix branches from master and after review/test is merged in master.
- Do we need another communication method beside GH Issues?
I think something like Gitter, Slack or similar could help for quick questions and discussions of ideas.
- With @MiczFlor as the sole maintainer of this project: how can we help him not to get burned up in the process? Is Micz trusting anyone enough to help him out with MR approvals and such?
I think, if we try to add more tests like @veloxidSchweiz has already started (and automate them with Github Actions), we become more confident that changes don’t break the product, so @MiczFlor doesn‘t need to review and test everything so thoroughly.
- Is there a "masterplan" on what Micz / we envision for the phoniebox to look like in a year or so? (core-features, UI, addons, etc)
Yes, I’m really interested what plans or ideas exist.
- Is the effort that would be needed for the definition of a formal plugin system worth the probably enhanced stability of the whole system?
Difficult question :)
xn--nding-jua
commented
4 years ago Hi,
because you asked me to give my opinion:
I think one repo with sub directories for each component is fine. Phoniebox isn’t that big and I think different repos adds another level of complexity, which could be hard to integrate in a working product.
I agree with @s-martin to keep the Phoniebox in one single Github-repo. In the past weeks I've created two pull-requests and was able to understand the functionality of the code within some evenings. If the code is splitted into several individual repositories, for people like me (with low/middle skills in php but some ideas) it could be harder to contribute to Phoniebox. Keep in mind that the project is focused on parents and childrens.
If a more complex version is nescesary, maybe the repo can be forked to a "PhonieBoxPro" with enhanced functionality? It may then be justified to create a distributed repository.
By the way: thank you for this wonderful project!
MiczFlor
commented
4 years ago Hi guys, this is the right thread, just at the right time. I took a little time to write up a few thoughts regarding Phoniebox. Possibly this should - eventually - become a small manifesto about the idea, progress, community and future of phoniebox?
I believe the few posts above already illustrate the nature of the Phoniebox community. Generally speaking: I am very much open to the idea of sharing responsibility, giving access to merge and plan together. From the past (years!) of experience, I have seen great minds and coders come and go. So all in one place is a good idea, to make sure the project actually has a future. (I am also happy to have a Phoniebox meetup of developers in Berlin, if there are enough around. Any interest?)
https://github.com/MiczFlor/RPi-Jukebox-RFID/wiki/Architecture_HowWeWork
MiczFlor
commented
4 years ago From my more abstract statement above, I deduce the following action points:
... what did I miss?
s-martin
commented
4 years ago I'd like to add: Testing and test environment.
Adding first unit tests was already done in #763 (can't wait until that is merged). This could be improved step by step, maybe even for integration tests with hardware (mockups). In #738 docker files were added, so this will be a big help.
If we can write a wiki article how to set up a test environment on real hw or docker, this could help many people and improve overall test coverage.
Flowdeeps
commented
4 years ago I think one repo with sub directories for each component is fine. Phoniebox isn’t that big and I think different repos adds another level of complexity, which could be hard to integrate in a working product.
I agree with this. If you look at how Google organises something like the NSynth project which has four different very definitely interconnected but also very different components (hardware schematics, audio pipeline, interface software, firmware, and PCB…) it's all separate folders each with a README but a root level README giving the overall information.
Flowdeeps
commented
4 years ago 6. Contributing means great responsibility: major rewrites and refactoring are only taken on if the one or more developers plan to see it through to the bitter end...
This is why you force contributors to make forks with feature branches and create pull requests based on their suggested changes. I've seen some quite correct suggestions about master being always deployable and only merging after manual and automated pipeline acceptance testing. 👍
MiczFlor
commented
4 years ago @s-martin great energy, a wiki article would be great. And how would you write Testing and test environment. into the above list. Here my suggestion:
https://github.com/MiczFlor/RPi-Jukebox-RFID/wiki/Architecture_HowWeWork
...
...
Flowdeeps
commented
4 years ago @MiczFlor I would love to join a Phoniebox group. Have you considered starting a meetup? It might be a good fit for the Embedded Linux or Linux Audio groups that already exist here in Berlin and have an active userbase. I could potentially do an introduction to some local hardware folks if you're interested. Alternatively there are the always excellent C-Base and XHain hackspaces who might be interested in hosting an event in exchange for exposure and beer money through the door.
splitti
commented
4 years ago First of all: sorry for my late answer, my time in the early year is really expensive, but i look forward to invest the time i can give to this Project.
Questions:
- Is it ok to have all those parts in one repo or is a github organisation with multiple projects better?
The basic Installation should be one repo in my opinion. I would like to see more repos, that can be attached like modules, maybe also as an installer. I also think, that config files, which will be edited manually, and also Shortcuts, Music, Playlists and so on should be seperated from the basic github repo in the installation. That makes it much easier to get an update working... But this is only my point of view.
- How can we organize the project without one of those parts constantly interfering with the others?
First of all, we should think of a stable and actual repo. @MiczFlor this is in german, because i don't find the words in english: Das Projekt hier ist der Hammer und ich bin Dir dafür mega dankbar. Aber es ist in dieses Repo so viel rein geflossen, dass es sehr schwer zu überschauen ist. Nimm das nicht als Kritik, sondern eher als Verbesserungsvorschlag, dass man Modulbasiert verschiedene Repos anbietet.
- What could a git workflow look like that allows us to maintain a stable version (currently: master branch) and development of new code / rewrites of existing code that can deviate in large parts from the stable version?
The main problem is, that there must be a main developer and tester for each step. One problem is also, there are maybe only two contributers, but both checking in to develop. Maybe it is better to make a repo like develop_username_timestamp? I am not sure, this is not easy for @MiczFlor to handle.
- Do we need another communication method beside GH Issues?
If there were different developers that organize the developent: yes. At this stage, i think no, because contributers are coming and going. There a just a handful of developers here about months.
- With @MiczFlor as the sole maintainer of this project: how can we help him not to get burned up in the process? Is Micz trusting anyone enough to help him out with MR approvals and such?
Ask @MiczFlor
- Is there a "masterplan" on what Micz / we envision for the phoniebox to look like in a year or so? (core-features, UI, addons, etc)
This would be a nice plan! But you need main contributers always working for this project, not just for a couple of weeks.
- Is the effort that would be needed for the definition of a formal plugin system worth the probably enhanced stability of the whole system?
Do you have an example.
So, i orderd three more Pis, i will build three more boxes to test. I hope, the project goes on and i try helping as much as i can.
veloxidSchweiz
commented
4 years ago Hi, Thanks @ZyanKLee for starting this discussion. I think this is a goo opportunity to go forward. @MiczFlor: I like your 'HowWeWork', this would have helped me when I started/thought about working on that project.
Here some personal opinions from my experiences. I am not a full-stack developer (whatever that means), but I already worked in some software projects from different perspectives. The company I am workin in, is building electronic devices which requires some quite advanced software. What I learned there is that, first of all testing is one of the key components to have a code which is always deployable. This includes good unit tests but also a bunch of system tests. We experienced having one mono-repo seems to be the best way to guarantee the testing the code. This does not mean that the code should be separated in different modules, The modules could, for example, be maintained in different folders. Setting up multiple build-chains/different test chains for each module seems to be an overkill for me and does not really simplify the workflow. One important step I see is that one should think about the interfaces. I.e. how is the interface between the php code, the gpio control ,.... For the testing the deployment I like the idea of using docker and/or ansible. Some more comments on testing:
I am not an expert on running docker on RPis, but if there is possiblity to containerize the functionalities this would probably allow a very easy deployment.... One would run separate containers for each subject of concern and it would be quite easy to update single compontents... here i would suggest to have one for the html interace, one for the mpd (or one of his spotify sisters), one for the control of the RFID reader, one for the gpio handling (maybe one separate for the oled display).... By only 'mounting' the music- and setting-directory, the system is very likley to be good upgradable. Even though docker is quite lightweight and does not cost many resources, I am not sure what would be the effect on systems based on RPiZero.... Such an idea is in my opinion a very nice option, especially as most communcation happens by mpc, bbut it would need some tests for evaluation.
This is only my personal view and I am open for such a discussion. Having such an open-source-project in which many people invest a marginal time of their free time is really great and I love this projects, If I can show my acknowledgement by contributing this is even better ;-)
MiczFlor
commented
4 years ago Thanks for the input, this is really cool.
Regarding the code repo: I agree with ...
I know what it's been like to answer questions regarding other peoples forked repos who once posted a link to their file and then changed it a few weeks later to fit their specific, it didn't work for others and suddenly I had to take the heat and try to awake the contributor from the dead (who did great work, and meant to do good, and did). Then suddenly everybody was annoyed for no reason. I prefer people creating pull requests and merge to develop - then they want to be proud of their code, comment their code and I know it is tested (enough) even if I don't have the hardware (ok, sure @veloxidSchweiz this is not the type of testing you are talking about :)
... and would like to restructure the folders and rename the files to make it easier for new people to dive into the deep end. In terms of components or functionality, and following @ZyanKLee list in the first post, I think these are the "folders" we need - not sure how to name them... (what am I missing?)
shared, together with the shortcuts for RFID tags)htdocs Webinterface incl mpd-controller)Any suggestions for naming and folder structure? I started this document in the wiki, please put suggestions there (the wiki might be the more collaborative editing space) https://github.com/MiczFlor/RPi-Jukebox-RFID/wiki/Architecture_FoldersFiles
ZyanKLee
commented
4 years ago First of all: I'm glad this discussion was so well received and on time. :) Thanks to all of you for all those great comments and ideas.
After @MiczFlor's latest post I thought about how to go on from here with his plan while avoiding any interruption to the installation of new Phonieboxes and came up with this idea:
First of all, I think that new github feature "projects" might come in very handy to organize the planned steps and workpackages without us cluttering up the main issues too much. If @MiczFlor would create a project by the name of "reorga" (or something else along those lines), we can cut this massive undertaking in small manageable chunks and keep track of them in the project.
To also separate the code from the "legacy" system, I would suggest a new long-living branch with a similar name; i.e. "reorga".
Then master and develop could go on as they do with the maintenance of the current code. In the meantime reorga would be used as base-branch for everything related to the reorganization; with its own feature branches for each reorga ticket ( - ideally :laughing: ).
After we are satisfied with its status, it will be merged to master (replacing everything in there) and develop will be refreshed from the new base as well.
New functionality would ideally only be added to the reorga - but I'm not sure if this is feasible as the reorga might run some time.
This is an attempt to illustrate the git flow:
The reorga branch should be set as protected - similar to develop and master to avoid commits being pushed directly.
ddbkva
commented
4 years ago maybe you can change the phoniebox software so that it can be integrated into the Logitech Media Center. Squeezelite runs very well on a Raspberry pi.
MiczFlor
commented
4 years ago (I pinned this thread in github, so it's at the top now, in case you miss it)
Re @ZyanKLee suggestion for structure and workflow, I was being pushy and started the components folder... you can see it in the develop branch already.
Inside the file CONTRIBUTING.md I added a few lines, which read like this (please comment):
Files & folder names
- (less keystrokes, better autocomplete recognition, in HTML links dashes can not be confused) not camel/PascalCaps or underscoresraspberry, not juicy-red-thing)food-fruit-raspberry, not raspberry-food-fruit)README.md
README.md fileInside the root folder or the repo, these folders are important:
scripts
scripts directory during installation / activationcomponents
ZyanKLee
commented
4 years ago Hey @ddbkva Please create a new issue for this feature request and explain there a little more about how you envision this integration.
ZyanKLee
commented
4 years ago
- Local audio files and folders (currently under
shared, together with the shortcuts for RFID tags)
this should not be in the project folder in my opinion. We should rather fall back to common directories from the desktop world /home/pi/Music, /home/pi/Playlists, etc to avoid deleting them on updates or clean re-installs.
s-martin
commented
4 years ago this should not be in the project folder in my opinion. We should rather fall back to common directories from the desktop world
/home/pi/Music,/home/pi/Playlists, etc to avoid deleting them on updates or clean re-installs.
Added reference #797
ZyanKLee
commented
4 years ago should we move
shared/shortcuts/ to ~/.phoniebox/shortcuts/ or ~/.phoniebox/rfid-cards/settings/global.conf to ~/.phoniebox/global.conf?
s-martin
commented
4 years ago I think that would make sense. We have to check, if there are other config files, too. @veloxidSchweiz added some config files in #763, too.
MiczFlor
commented
4 years ago
- Local audio files and folders (currently under
shared, together with the shortcuts for RFID tags)this should not be in the project folder in my opinion. We should rather fall back to common directories from the desktop world
/home/pi/Music,/home/pi/Playlists, etc to avoid deleting them on updates or clean re-installs.
I like the idea of separating the media from the code. And I doubt that people would use their Pi for Phoniebox AND some other audio solution that would require the system style folders /home/pi/music. Is there any advantage in creating media folders like /home/pi/PhonieMedia/or the like?
Using the ~/.phoniebox/shortcuts/ is possible. Currently, samba still allows access to the audio folder so that you can push files via the file browser. I use this sometimes also for quick backups. Should we point sambe to such a personal, hidden folder instead?
veloxidSchweiz
commented
4 years ago I like the idea of using the default music folder. I actually started to just symlink the Music folder into the phonbox shared folder. This is for me already so much cleaner and seems to work ( I had quite some problems at the beginning with changing the folder..)
if I do not see an advantage of creating a separate audio folder and to put the music in the standard place makes sense for me.. A valid question is where to put playlists and shortcuts... Any other opinnion on that?
@MiczFlor , I started to use ~/.config/phoniebox maybe we should use only one location, for configs or similiar things... We can also switch to use ~/.phoniebox instead...
@s-martin , @ZyanKLee: How do you like the idea of having separate docker containers for each concern? (GPIO, RFID, html, mopidy,....)
Taytay
commented
3 years ago First, thanks to all of the contributors for Phoniebox! Second, I realize that this issue might not be the best place to ask this question, so forgive me if I'm asking it in the wrong place.
I'm about to add support for reading QR codes, so I needed to understand the code a bit better. I discovered that quite a bit of the logic is implemented in bash scripts as opposed to Python scripts. This project is obviously not opposed to Python, so I'm curious how intentional or necessary implementing core logic in bash is, as opposed to writing them in Python. Have there been any efforts or interest in rewriting some of the fundamental .sh scripts in another language?
s-martin
commented
3 years ago AFAIK know in the beginning Phoniebox was written mostly with bash scripts (@MiczFlor correct me, if I'm wrong ;).
Python scripts only came later and I think most new code is written in Python.
There were some attempts to rewrite the code in Python (see RPi-Jukebox-RFID/scripts/python-phoniebox/), but this code was mostly abandoned and not updated for quite some time now.
As the core logic and - if you will - the core API is written in bash scripts and up to date I'm reluctant to rewrite this in another language. The issue is that much know how and many bug fixes are now in this code base and I'm a little worried this may get lost when rewriting the code. As this is the core logic of Phoniebox, bugs would affect many users. I'm myself not very fluent in bash, but I think a rewrite would be a major task.
Of course @MiczFlor would have to decide this ultimately.
Taytay
commented
3 years ago Thanks for the insight. Makes sense :)
Luegengladiator
commented
3 years ago Hello everybody , as an offside contributor, I was involved in the initial phase of the switch to mpd. Unfortunately, I don't have much time to get involved more intensively in the project. Hence my very late comment here.
I've been running the box as a stationary music player on the local network for years. The audio files are stored on a central storage and are mounted accordingly. For some time now, the complete configuration has been on the NAS, so that all Phonies in the WLAN use the same configuration, which enables card exchange (~ 400 active RFIDs and rising).
I presumably use the box far from its intended function as a children's music box. Since an RFID collection is smaller and more practical than a CD collection and the box can be integrated anywhere, it is easy to make larger audio collections available digitally in the Network ( not even limited to your own house / network due to VPN connections ). I've been thinking for a long time for a way to transfer the current music from one box to the next using a special RFID. "Music tracking" would then be possible in-house.
Since the introduction of mpd, I have been thinking about whether it makes sense to store the files in the user home or whether an integration in Linux style could bring advantages. Especially if the execution should no longer be limited to just one Raspi or the functionality of the system is no longer limited exclusively to the Phoniebox. (Keyword Firewall / VPN #1275 or HotSpot #956) Configuration in / etc, files in / opt (as optional software) and audio files configurable in a user-defined location. Unfortunately, due to the time, I couldn't pay any attention to the whole thing.
arne123
commented
3 years ago Dear all,
I'd like to propose some architectural changes to the phonibox:
I am aware that this might address one of the fundamental pillars of this project and will encounter some objections, but let me explain my observations and proposal in more detail:
Maybe this is more an issue of people using a weaker controller like the rpi zero as I do, here the playoutcontrols is causing huge delays each call as it also reported in several issues. I think the playoutcontrols.sh is definitely doing much to complex things as a part of the code which is called that frequent.
whilst there were for sure very good reasons to do it like this, and I can really can Imagine how this has developed, from maintainability and expandability perspective I see many drawbacks.
For example you can see in the code base that fundamental coding principals like "don't repeat yourself" and "single point of truth" have not consequently been followed
I think to improve here is not possible when such an central part of the program will be on the shoulder of a shell with its limitations and in two different environments (python and shell)
The actual playoutcontrols acts a kind of central command execution library combined with some variable and storage handling. The shell works her also as a kind of interprocess communication (ipc)
The Major components are dealing with this:
So we need an ipc which works within python based code and between python and php
Basically I investigated 3 ways
Finally I decided to go for ZERO MQ
The reason is mainly the small footprint and huge availability in for many programming languages. And its thread safe! I decided against the REST API and MQTT Aproach because it is too much overhead as an IPC and too much dependencies.
The architecture will look like this:
please have a look to this branch: https://github.com/arne123/RPi-Jukebox-RFID/tree/zeromq redirecting the WEB Player Play and volume functions via zeromq Reqest/Response sockets
htdocs/api/zmq.php < php queue client scripts/phonie_access_objects.py < python queue client scripts/test_zmq.py < quneu server
Modifications have been made to htdocs/api/player.php htdocs/api/volume.php components/gpio_control/function_calls.py
The turnaround time on a rpi zero is between 8ms and 20ms. This now feels as it should, the reaction to play or volume changes are instant.
While doing this I decide for a more hirachical / object orient aproach for the function calls as a first step for later class organisation. (see proposal at the end)
If all program parts would be started from one single python program (as threads) I see the following benefits:
There is a good technical reason to have separated configuration files right now, but I think to move all configuration into one file will also reduce the overall complexity. It will also make different configurations better compare - and shareable despite the point that more configurations could easily be made available on the web interface
In general I would tend to reduce the complexity of the installation in favor of a more powerful configuration
I think this has been already clearly addressed in the reorga branch, so I'd definitely like to vote for this. I think the installer should never ever move or rename source files, it is very difficult to work with git due to that matter.
The Playoutcontrols.sh has about 50 commands, which i'd like to group and turn in a more hierarchical/ object orientated way, just a quick thought:
objects:
volume
player
playlist
recoder
system
config_items:
maxvolume
startupvolume
volumestep
idletime
s-martin
commented
3 years ago Hey, thanks for your thorough investigation.
I think this would be a major undertaking (e.g. for a 3.0 release), but I definitely see the advantages.
I have no real experience with IPC, so I also would like to ping @MiczFlor as project owner and @veloxidSchweiz.
pabera
commented
3 years ago I am referring to @arne123's most recent comment. And apologies for my opinions without being much involved in this project before; I want to change that though.
I agree with @s-martin ... the vision is great but it'll be a lot of work, also because there are major parts of the software not tested. I recently suggested to refactor the playout_controls.sh file and divide it into smaller junks - essentially a parent file (still playout_controls.sh) calling individual Bash files (maybe in the hierarchy you suggested).
From there, you'd be able to sequentially migrate functions from Bash to Python in a separate branch while you can continue to merge updates from develop.
"5. Object Orientation" .. I wanted to know more about that. Are you actually thinking of using object-orientated programming using Python unter the hood or did you just refer to the different function groups?
MiczFlor
commented
3 years ago Hi @pabera the refactoring is a good idea. And I think we should keep that in the discussions thread: https://github.com/MiczFlor/RPi-Jukebox-RFID/discussions/1298 I will answer there.
StefanMinke
commented
3 years ago Hi,
I look at the topic of refactoring the files and implementing the playoutcontrols in python scripts with tension.
I experimented a lot with the code on my box. The reason is that I think the interaction with mopidy could be much better.
Esp. when you think about using python more and more, have you ever thought about implementing an own mopidy frontend (or use the JSON api - https://docs.mopidy.com/en/latest/api/http/)?
With an own frontend you have more dedicated options to interact with mopidy beside the normal functions like start, stop, pause, seek, ... What I think would be the biggest advantage is that you have access to the different Listeners, e. g. Core Listener (https://docs.mopidy.com/en/latest/_modules/mopidy/core/listener/) or Audio Listener (https://docs.mopidy.com/en/latest/_modules/mopidy/audio/listener/). You can handle and react on events like changing playlists, chaning volume, reaching the end of a playlist or what ever. Esp. for the resume functionality this would be a big advantage.
With your current way to deal with mopidy you will obviously never have the possibility to do so in the future.
Just think about this. Thank you!
s-martin
commented
3 years ago I see the advantages and if enough people are willing to pull up their sleeves I think this could be done.
Easiest way to propose changes is to start a PR and maintain the changes.
Main reason why most of the very good improvements are not implemented is that nobody took care of it, yet. Anybody is welcome to bring in suggestions and start improvements. Phoniebox is a collaborative effort.
arne123
commented
3 years ago I am now confused, if we continue the discussion here or as proposed in #1298 ?
Esp. when you think about using python more and more, have you ever thought about implementing an own mopidy frontend (or use the JSON api - https://docs.mopidy.com/en/latest/api/http/)?
That's probably a very good hint also to have a look for as an API for the Phonibox itself. The JSON-RPC 2.0 looks quit similar to what I had in mind and seems quite reasonable.
@pabera
From there, you'd be able to sequentially migrate functions from Bash to Python in a separate branch while you can continue to merge updates from
develop.
Even so I perfectly agree with you from structural point of view, I have the concern that additional shell script calls will lead to further forking, which will lead to additional delays (which was my original motivation to have a deeper look here) To step by step improve will also be possible by sequentially migrating to python, and removing that particular parts from the playout control.
"5. Object Orientation" .. I wanted to know more about that. Are you actually thinking of using object-orientated programming using Python unter the hood or did you just refer to the different function groups?
I meant it philosophy wise, What I mostly miss when reading through the code is structure. Things are doing to much, the scope is to big. So applying some principles of OOP (in what technology ever) would help others to understand the project better.
pabera
commented
3 years ago It is an interesting idea to think about using Mopidy as a player only. It's already running when using Spotify and keeping both softwares in sync just increases the complexity. To be fair, this goes opposite to what the Phoniebox software initially had been made for.
There is still a lot of stuff the Phoniebox software entails.. but it might make sense to focus on this more.
MiczFlor
commented
3 years ago Hi
I want to give a little background, so we can move forward together. At the end of this post, a very top level idea of what I believe we need in place to make that bold move to mopidy.
@arne123 Regarding: where is the discussion happening? - we go with the flow :) and the general discussion would be here. Specific ideas, like the refactoring of the playout script should move to the discussions, like here: https://github.com/MiczFlor/RPi-Jukebox-RFID/discussions/1298
@pabera
Regarding mopidy as the standard player, you are right about pointing out a big inner conflict. My hope would be that the Phoniebox is always also a very low level entry project (like an IKEA kitchen: everybody can set it up, BUT experts can make it something very special and take it to a new level).
Phoniebox has been a fun project that has brought families together :) How so?
Then there is the other Phoniebox
The Phoniebox + makes me very humble, seeing the quality of code coming in and the innovative ideas. I guess everybody here knows the codebase enough and has possibly been around long enough to know the components folder where all these ideas and gadgets find their home. (Thanks to @s-martin again for doing such great work in supporting new community members to make their code contributions documented and standardised in a way that everybody benefits. Again, this is needed in an open source project. And Martin is doing a great job.)
The future of Phoniebox should provide both. And I believe it can provide both.
If you look through the issues filed here on GitHub, they are either newbies who are inspired and motivated, but fail to install the Classic version. And on the other end of the spectrum issues related to specific hardware, integrating Spotify, ... and mopidy, which has been a fountain of issues in the past. Especially Spotify together with mopidy has created headaches and frustration in threads in the past. Nobody went to capitalised messages yet, but you know that somebody is frustrated when they post questions at 9:17pm, 01:12am and 03:29am :)
At times this was also about the Spotify API which had changed. It's frustrating for us, too, because you can not control it, but you still get the blame :)
Phoniebox went through a major shift in the past: migrating the playout from vlc to mpd. If you want to see who was involved in that time, take a look at this extract from the contributor's timeline. From this past experience with Phoniebox, this is what I think would be needed:
mopidy for version 3.0 (new branch) - which should be shipped in autumn 2021, so it's all stable for ChristmasWhat am I missing?
And who would raise their hand to say: "I am in"
s-martin
commented
3 years ago I'm in!
pabera
commented
3 years ago I appreciate that you have taken the time to summarize those thoughts. It made me laugh too. I am a dad with tech background, but my Elternzeit is yet to come .. all of it makes sense and I like the separation of Classic and +. Which must be kept as a recognition and tribute to the initial, great idea.
I help where I can. I want to say I am in, but I don’t want to give wrong expectations.
arne123
commented
3 years ago @MiczFlor I like to say thank you for the extensive background information and your thoughts I absolutely agree with your points, especially the contributor and namespace /architecture part. Same as @pabera I was struggling a bit to raise the hand to say yes I am in since I don't want to promise something I can not really keep. But I do like the project very much and therefor I'd like to give my best in contributing.
I totally agree that one of the major goals should be the a simple box as a low level entree project. But I am not entirely convinced if these should be really 2 Versions where you need to make a hard decision at a very early point in time where not all consequences are clear. I would think more about and feature based approach, which you can gradually increase (in complexity) Also from technical perspective and my personal experience I know that it can be really painful to maintain 2 different versions of basically the same.
I hope more people will join this discussion. And say I am in, at least a bit.
In the past days I was a little bit looking around in the project, and I'd like to ask in what kind of state the code in python-phoniebox folder is. Was this already somehow running? Does it make sense to continue from there or at least start over from there? Or is it kind of abandoned?
Luegengladiator
commented
3 years ago Thanks @MiczFlor and @s-martin for taking the project to the next level. I would also like to vote for a modular extension. You should avoid having to restart from scratch if you want to switch to Phoniebox+ after successfully working with Phoniebox. Otherwise I like the idea, even if I have significantly fewer opportunities to participate in Python.
I would like to break a lance again for standardization. Maybe you can now also think about packaging for a Raspbian repository? Even if the package causes additional work, modularization using expansion packages could make life easier for the end user.
MiczFlor
commented
3 years ago Hi @pabera @arne123 Thanks for being in (a bit and possibly a bit more :) I see now how my question raise your hand and say: "I am in" sounds really creepy :) I got carried away there by my own memories how far this project has travelled by the community. If you are in, that mainly means that people like you for the good you do, collecting kudos for happy families (even more valuable in covid times) and at the end of the year, the Phoniebox calendar will mean a little more to you, when you think: "gee, the ideas that people come up with to wrap the ugly Pi in a cute box". And being in means to have a say in architecture, namespaces, modularity and the like. Because you'll also be digging into the code after decisions are being made (and we actually have to figure out how to discuss and make decisions, if this is here in the issue section, under discussions on github or what other communication tool would be best for that).
MiczFlor
commented
3 years ago @Luegengladiator we all agree: "You should avoid having to restart from scratch if you want to switch to Phoniebox+ after successfully working with Phoniebox" :) you are very right...
the idea of modularity is great, the idea of Pi packages is also great (but, see below).
Modularity will actually increase productivity, I assume. Making and maintaining packages will decrease productivity, I assume.
a) It's an extra skillset that would really only make sense if there was dedicated developer for that task. b) The entry level for code contributions would change quite a bit.
Regarding modularity (and standardization, of course) what do you have in mind?
Luegengladiator
commented
3 years ago Hi @MiczFlor,
Professionally, I am on the road as an IT delivery manager in larger Linux environments and therefore familiar with the challenges of system operation. Even if that sounds a bit like "overkill" now. Which child wants to go without the box for 3 days and instead have a frustrated dad just because the update doesn't work as expected? I can see parallels here.
That's where I want to bring modularity into play. I could imagine that there is a module
which then the modules
could reload. The personally used box can easily be assembled using modules and each module can be developed separately. You can then still consider whether you want to support a packet manager. Personally, I would love to see this as you can simplify the tutorial by automatically installing necessary packages as a dependency and then automatically updating the box via system updates.
On the subject of standardization, there are defined rules within the project. Your instructions and coding guidelines are the best examples. I think the project has grown in the meantime so that it can step out of the "shadowy existence" of the user directory and integrate itself as a program into the respective Linux (currently Raspian). Examples: Optional software is usually under /opt Logs in /var/log PIDs in /var/run (might be easier with package manager support)
This does not make handling the application any more difficult, but it also enables further customization options. For example, it is not necessary to attach the entire storage space to /home, which may enable further combinations of uses, for example with retropie. Such a phonie game box would be able to take audio books and music and additionaly a game console with you. I've seen some Boxes with little Displays on the calendar. Perfect combination! Conversely, there are beautiful retropies that look like an old Gameboy, which would work perfectly as a portable Phoniebox. Especially with older children, I could easily imagine the combination.
To sum it up briefly: So far, the Phoniebox has focused on a dedicated raspbian and has been completely oriented towards running perfectly on this. Using the modules and standards described, it would be possible to address a significantly larger number of users who may see combinations of usage. Some use a Retropie and "only" want to expand it, others may use other project-driven raspberries and do not want to rebuild everything by hand. Last but not least, it would also be possible to use any Debian-based system as a Phoniebox. The basic focus on the individual machine is correct and important as the origin of the idea! Many parents without background knowledge are able to easily build a working box (main use). However, the background knowledge of the end user or the associated parent does not matter to the software as it is built. The software runs just as well on any other Raspberry;)
ZyanKLee
commented
3 years ago Hello everybody,
It's been a while, but the recent uptick in discussion here woke me from my slumber. At least a little. 😀
So first and foremost: thanks to Micz and Martin for their continued work on managing the project. Thanks to everyone for driving it further.
Since my time with the project there is a sore spot for me in this project. But that is not due to it being ugly nor bad code - those aspects are great. But using PHP for the web interface in addition to python brings overhead that might not be necessary. Porting the web ui over to python would be my suggestion if you are willing to look into this?
To go deeper into the side-tracked topic about the code future on #763 I open this issue (as we are lacking an alternative communication method).
Yesterday I had a short look into the build, install and update scripts of LibreElec.tv - it left me barely any wiser after an hour reading through all the scripts, testing the build script and trying to figure how the heck the actual update of a LibreElec system works. (not the download but the flashing of the new version - what does it and where is that piece of code?)
Anyway: as far as I can see this project can be divided into some more or less separate sub-projects.
... did I miss something vital?
Questions: