On Mon, 2007-02-05 at 19:19 -0800, Michael Beal wrote: > I've thought this through for quite some time. I have many reasons > for wanting to go in a different direction. I will state that none of
I certainly can't hold against you the desire to go in a different direction. Even I have desires to go in a different direction, which is what MeBox is. However MeBox was and remains a loose collection of ideas in my head. My main disagreement with Freevo is with scope of hardware support. Freevo wants to support a large range of hardware -- which is a good idea on the surface -- but in doing so, because supporting hardware properly with an excellent user experience is exceedingly difficult and because we have such little man power, it ends up supporting no hardware very well. It also requires a considerable amount of additional abstraction and complicated code, as in the case of handling both directfb and X11. My foray into Freevo development (roughly speaking) has been with Kaa, which intends to provide the architecture I would need to write MeBox -- if I ever write it. But it just made good sense to work closely with dischi on Kaa, because the code sharing potential is pretty obvious. > lists. There are development goals I'd like to persue with the now > deprecated 1.6 code that I do not feel are currently being pursued. I > also do not feel that my development goals will fit with the majority > of the current developers on this list. I can safely say that the > current version running on my system is very far from the original > 1.6.2 package I installed. In general, I have no problems with forks when the purpose of the fork is to take the project in a direction that is contrary to where the core development team is going. Obviously we'd like to see that effort put into trunk, but if forking is the difference between hacking and not hacking, I think the net gain of a fork is likely positive. The only thing I would ask is that you name your fork in a manner that would not be confused with Freevo. But there's truly a good reason we've started from scratch in 2.0. The 1.x architecture isn't very good and it's quite limiting. As you begin to morph your fork into something more manageable, I believe you will find a lot of what you end up with will look quite a bit like what we're doing in 2.0 -- except worse, because we had the benefit of a clean slate and could make any decision without the bother of having to retrofit existing code. > My primary goal is to develop a stand-alone system; one which competes > well against M$ Media Center; requires no outside supporting hardware; > fully interfaces with both conventional and widescreen monitors; and > requires no more than a TV or monitor and 2, 4, 6 or 8 speakers. The > current state of the project, from my personal experiences, does not > indicate that these goals are being considered. The current state of 1.x, perhaps. But everything you mention is something we are considering for 2.x. Competing "well" against Windows Media Center is noble but incredibly complicated goal. We know what needs to be done as far as the user experience is concerned. Everything else is just a matter of design and, more onerously, finding time. > Some of you use SPDIF for audio playback into external equipment. > Others use their 2-channel audio cards. Some have widescreen monitors > while others have 4:3 screens which do not operate at maximum > resolution. Because of these differences, there are strange quirks in > the system that need attending and demand development of a more > simplified yet standardized system. Simplified from 1000 feet, perhaps. But if you think the architecture to do what you suggest above in a flexible manner is going to be simplified relative to what exists now, I believe you are mistaken. I'm also not quite sure what you mean by standardized, but from a design perspective, if you mean that above a certain layer the details like screen resolution and aspect or speaker arrangement are fully abstracted, this is also a goal for 2.0. > I don't feel that testing has been accomplished to the degree required > in order for Freevo to be a complete, polished multimedia system. Too > much time is being spent developing new toys and gadgets while little > time is going toward spiff and polish. Toys, gadgets, spiff, polish, they're all equally meaningless without a solid architecture. The 1.x branch simply hasn't got that. Duncan has done a remarkable job maintaining 1.x, and knowing that the ultimate plan for 1.x is to scrap it, I think it's strongly commendable as it demonstrates all the hard work is done primarily to keep the Freevo community going. But anyone who has been following this list for a while knows that we recognize the limitations of 1.x. You are not going to get spiff and polish with the 1.x approach. Oh sure you can polish it up a bit, but the true integrated, smooth experience we all want is only going to happen with a lot of crazy low level support, with teeth sunk deeply into media players like mplayer and xine, as well as a well performing graphics subsystem. This is what 2.0 is. > I am now turning toward building an autoconfiguration plugin for my > system. This, I believe, can not be accomplished on a system that is > still under extensive development as is 2.0. I also do not believe > that a reasonable balance can be struck between the 2.0 branch and the > 1.6 branch that I am currently using. You may well be right about that. Trunk is not at a point where working on the higher layers (such as an autoconfig system) will be productive. However the config system in 1.x is awful too. :) > For these reasons, I respectfully ask approval to branch the Freevo > project. I find your reasons superficial without taking into account the goals (based on discussions in this list) of trunk. However you certainly don't need our approval for a fork, nor would I personally have any problem with it especially as the 1.x code base is of no interest to me, provided that whatever you call your fork will not be confused with Freevo. Cheers, Jason. ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Freevo-devel mailing list Freevo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-devel
