Ok, I finally was able to pull away from work for a few days to work on this project again. Owning your own business has its disadvantages. I have been focusing on creating a viable rpm for Fedora Core 4. I only have one more section to test (the Database update routines.) When developing this RPM I realized just how broken this project really is. I focused on only fixing the Show-Stopping bugs. The patches are in the RPM the RPM (and a few accompanying rpms) will be posted on my site http://www.mentaljynx.com/MultiLingual/gjukebox/. I will port the patches over to the CVS version shortly.
With that said. I have learned many tricks over the past years. And I think that If we are to move forward we need to really re-do much of the jukebox. A few others have already said that they are in the process of doing this (however it is a huge project, and I suspect that they have lost interest.) I am thinking that much of this project is complicated and overwhelming to a programmer that is just getting started with it not to mention if you ever open up the right.php file (yes, Ive had to work on it.) My feelings are that we should first develop a plug-in api, that does nothing. (well almost nothing) simply use that api to tie everything together . Lets call this the core the core would call a plug-in for almost all aspects of operation. I think the following plug-in classes could be defined:
1. Data Accessor Plug-in (1 active at a time)
2. Display Accessor Plug-in
3. Queue/Voting Plug-in
4. Output Plug-in
5. ..
There should be a few others, however I cannot think about them at the moment. Obviously, some Plug-ins would be packaged with the distribution, other would not be. Before starting we would want to draft a design document and design standards
My final issue is that if we are to Re-Work the jukebox to this extent, (being from the ground up), I would want to transfer it to a different name with a standard license and use subversion for the repository. (Great Jukebox Was a little play on the name someone came up with maybe GreatBox ???) Unless Globecomm would want to contribute to the development of this new system, I dont feel they would deserve to have their name on it. As the code would be completely rewritten. Oh, and why Subversion if youve worked with subversion you know why. Its a lot nicer when it comes to moving stuff around, tracking when there are changes, and handling large projects.
So, what is the communities opinion? Is there much of a community out there??? Are the people that were re-working the system still working on it?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sounds interesting. I think I'd be interested in helping out with this. The API route sounds like a solid idea. It will start the project off in a manner that will allow it to scale.
What kind of time do you forsee being able to devote to this project in the near future?
cheers
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think that I would have between 6 and 12 hours a week to work on it.... It may not sound like a lot, but for me it is.
And yes, my main goals would be
1. allow the project to scale... in ways that I can forsee, and in ways I cannot.
2. Lower the cost of entry for devlopers. (that's why documentation would be a must)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Cool to see that this project awakes again, and I think I can offer a few hours a week for it.
Some thoughts and ideas:
Plugin-design sounds great - I think output and frontend should be independent parts. One output can be controlled from diffrent frontends (web, lirc/lcdproc, a gnome-applet, a feel-like-itunes-XUL-frontend...)
Rebuild from scratch - seems useful, especially for the php-parts. There are nice concepts, but many parts of the code are completely unmaintainable.
Naming.. what about NGJukebox. Keeps the credits for this project but also shows that there is a new approach.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Would be sweet to mimic the XMMS API in order to allow use of their pre-existing plugin base. There must be some 30 plugins including crossfade, coverart, scrobbler, etc. etc. etc.
Re-use in OSS is a beautiful thing...
--Bill
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Nice Idea.... but.... as far as i know xmms requires X... and many of the plugins use X libraries... in fact, at first glance, a large part of the api would require X, and I don't want that requirement and headaches....
I'm looking at implementing most of this in Perl anyway (including the plugin api) which would make writing a C api very difficult (for me at least).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, I think I've made my decision.... I'm going to go ahead with work on this. I am going to use svn and trac at a soon-to-be defined website. It includes a wiki, so no problems there.
I'm also going to start a new project here simply to release tarballs and rpm's. (this would address the popularity and dissapearing issues.)
My very first issue is going to be to draft project description and treory document. The second will be getting the inital core constructed.
The purpose will be to address 2 major issues. 1. be as easy to use as possible (sorry, settings will be typed (as in checkboxen and the like)) and 2. Work
Yes, you read that right.... I want it to work, anotherwards any changes to the core is going to be changed by 1 or 2 people and that's all. (now plug-in submission will be open to any and all... )
so, as soon as I initialize the site I will post the link here. I will encourage all code jockeys who can contribute to do so, however, I'm not too big on non-constructive critisism. So just don't do it. (The easiest test to tell which type of critisism you are using is to see if you have offered to solve the problem or offered a solution.)
So, Cheers everyone, and I'll see you all later.
p.s. yes, the rpms for this box will be going online today or tomarrow... I have one more bug to fix.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
my 2 cents (hopefully regarded as constructive):
1. I would like to see some amount of compatibility with the existing jukebox... even if "compatibility" means a hacked script that translates database A to database B. I think this would possibly drag folks from one project to the next.
2. (sort of my own personal wishlist item, not sure how high it would be on a project list) a decent plugin for importing rips. My jukebox runs on a POS computer circa 1998 (because it doesnt take much horsepower to run the basic jukebox). The downside is that it takes hours to rip, which means everything is an import.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
yeah I currently use import.pl.... I was just thinking if this project was getting reworked, there might be a slicker way to do this.
Right now I have my own ugly scripts that rip locally, copy files to the jukebox, run import.pl, runs createalbums.pl, runs getpictures.pl, does some automatic group creation (if needed) and then runs a homespun database consistancy checker.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1.) DEFINTLY!!!!! beacause I myself would need this.
2.) SOunds like my jbox computer.... yes, this is something that is on my wishlist too... (my mother (no I don't live with her) likes to rip disks herself... and importing them is a real pain ....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, I finally was able to pull away from work for a few days to work on this project again. Owning your own business has its disadvantages. I have been focusing on creating a viable rpm for Fedora Core 4. I only have one more section to test (the Database update routines.) When developing this RPM I realized just how broken this project really is. I focused on only fixing the Show-Stopping bugs. The patches are in the RPM the RPM (and a few accompanying rpms) will be posted on my site http://www.mentaljynx.com/MultiLingual/gjukebox/. I will port the patches over to the CVS version shortly.
With that said. I have learned many tricks over the past years. And I think that If we are to move forward we need to really re-do much of the jukebox. A few others have already said that they are in the process of doing this (however it is a huge project, and I suspect that they have lost interest.) I am thinking that much of this project is complicated and overwhelming to a programmer that is just getting started with it not to mention if you ever open up the right.php file (yes, Ive had to work on it.) My feelings are that we should first develop a plug-in api, that does nothing. (well almost nothing) simply use that api to tie everything together . Lets call this the core the core would call a plug-in for almost all aspects of operation. I think the following plug-in classes could be defined:
1. Data Accessor Plug-in (1 active at a time)
2. Display Accessor Plug-in
3. Queue/Voting Plug-in
4. Output Plug-in
5. ..
There should be a few others, however I cannot think about them at the moment. Obviously, some Plug-ins would be packaged with the distribution, other would not be. Before starting we would want to draft a design document and design standards
My final issue is that if we are to Re-Work the jukebox to this extent, (being from the ground up), I would want to transfer it to a different name with a standard license and use subversion for the repository. (Great Jukebox Was a little play on the name someone came up with maybe GreatBox ???) Unless Globecomm would want to contribute to the development of this new system, I dont feel they would deserve to have their name on it. As the code would be completely rewritten. Oh, and why Subversion if youve worked with subversion you know why. Its a lot nicer when it comes to moving stuff around, tracking when there are changes, and handling large projects.
So, what is the communities opinion? Is there much of a community out there??? Are the people that were re-working the system still working on it?
Sounds interesting. I think I'd be interested in helping out with this. The API route sounds like a solid idea. It will start the project off in a manner that will allow it to scale.
What kind of time do you forsee being able to devote to this project in the near future?
cheers
I think that I would have between 6 and 12 hours a week to work on it.... It may not sound like a lot, but for me it is.
And yes, my main goals would be
1. allow the project to scale... in ways that I can forsee, and in ways I cannot.
2. Lower the cost of entry for devlopers. (that's why documentation would be a must)
Cool to see that this project awakes again, and I think I can offer a few hours a week for it.
Some thoughts and ideas:
Plugin-design sounds great - I think output and frontend should be independent parts. One output can be controlled from diffrent frontends (web, lirc/lcdproc, a gnome-applet, a feel-like-itunes-XUL-frontend...)
Rebuild from scratch - seems useful, especially for the php-parts. There are nice concepts, but many parts of the code are completely unmaintainable.
Naming.. what about NGJukebox. Keeps the credits for this project but also shows that there is a new approach.
Thinking out loud:
Would be sweet to mimic the XMMS API in order to allow use of their pre-existing plugin base. There must be some 30 plugins including crossfade, coverart, scrobbler, etc. etc. etc.
Re-use in OSS is a beautiful thing...
--Bill
Nice Idea.... but.... as far as i know xmms requires X... and many of the plugins use X libraries... in fact, at first glance, a large part of the api would require X, and I don't want that requirement and headaches....
I'm looking at implementing most of this in Perl anyway (including the plugin api) which would make writing a C api very difficult (for me at least).
Yes... Looks like most of the xmms includes point to glib.
Well, I think I've made my decision.... I'm going to go ahead with work on this. I am going to use svn and trac at a soon-to-be defined website. It includes a wiki, so no problems there.
I'm also going to start a new project here simply to release tarballs and rpm's. (this would address the popularity and dissapearing issues.)
My very first issue is going to be to draft project description and treory document. The second will be getting the inital core constructed.
The purpose will be to address 2 major issues. 1. be as easy to use as possible (sorry, settings will be typed (as in checkboxen and the like)) and 2. Work
Yes, you read that right.... I want it to work, anotherwards any changes to the core is going to be changed by 1 or 2 people and that's all. (now plug-in submission will be open to any and all... )
so, as soon as I initialize the site I will post the link here. I will encourage all code jockeys who can contribute to do so, however, I'm not too big on non-constructive critisism. So just don't do it. (The easiest test to tell which type of critisism you are using is to see if you have offered to solve the problem or offered a solution.)
So, Cheers everyone, and I'll see you all later.
p.s. yes, the rpms for this box will be going online today or tomarrow... I have one more bug to fix.
my 2 cents (hopefully regarded as constructive):
1. I would like to see some amount of compatibility with the existing jukebox... even if "compatibility" means a hacked script that translates database A to database B. I think this would possibly drag folks from one project to the next.
2. (sort of my own personal wishlist item, not sure how high it would be on a project list) a decent plugin for importing rips. My jukebox runs on a POS computer circa 1998 (because it doesnt take much horsepower to run the basic jukebox). The downside is that it takes hours to rip, which means everything is an import.
Mark:
Have you tried import.pl and then organizemp3.pl?
--Bill
yeah I currently use import.pl.... I was just thinking if this project was getting reworked, there might be a slicker way to do this.
Right now I have my own ugly scripts that rip locally, copy files to the jukebox, run import.pl, runs createalbums.pl, runs getpictures.pl, does some automatic group creation (if needed) and then runs a homespun database consistancy checker.
1.) DEFINTLY!!!!! beacause I myself would need this.
2.) SOunds like my jbox computer.... yes, this is something that is on my wishlist too... (my mother (no I don't live with her) likes to rip disks herself... and importing them is a real pain ....
Hello paradxum et all,
I am thrilled to see some activity with the Jukebox. Count me in for any help that I can offer.