«« Software Needs Communication MVC Part II: Attack of the Mutators »»
blog header image
Showdelayers

Wow, been a pretty slow week. Two things I'm working on for AudioMan right now: threading and file library issues.

The file library issues are easy to fix but will take some refactoring. The code that reads the file meta data has the AudioMan object AudioData throughout it. From a coupling standpoint, this is bad. So even though it will make the libraries less efficient (copying data), I'm making libraries that can be used on any other project not just AudioMan. I may even release them under the LGPL later, assuming I can get everyone's permission.

The threading issue is really sticky. Once you start to get more than one thread going in a program the complexity skyrockets. You have to think of all of the situations a simple operation could be interrupted and how events can conflict or resources can deadlock. There's no question that AudioMan should be multi-threaded, the only question is how and how much.

The major problem causer at the moment is letting people browse the collection will files are being included, on a long Include Directory operation that crawls all of your directories. While the view is switching models, the mutators are sending messages to the models and they get shown by the wrong views. Other tracks are getting lost. I think I will have to suspend the mutators while the view is swapping ... but that's not as easy as it sounds.

At any rate, I'm taking some time to figure out those things before I attack. These are both basic problems that need to be addressed right now.

Posted at March 06, 2004 at 06:39 PM EST
Last updated March 06, 2004 at 06:39 PM EST
Comments

"The code that reads the file meta data has the AudioMan object AudioData throughout it. From a coupling standpoint, this is bad."

I was looking over this section of the code yesterday and thought the same thing.

» Posted by: James at March 7, 2004 07:33 PM

Why did we do it that way? Well, we were following the admittedly lazy YAGNI (you ain't gonna need it) principle, which favours simplicity over an involved design. We weren't going to support other file formats then, so it wasn't necessary to "design" for it. Now we can go back and refactor the code.

» Posted by: Ryan at March 7, 2004 09:19 PM

I forgot to add that the benefit of this "lazy" strategy's simplcity is that it is more agile and therefore easier to maintain. Because we only had one type of file to read, the coupling offered a simpler more direct solution to the problem.

Seperating them would have been cleaner architecturally but would have left people asking "why?". Exactly. Overdesign slash extreme up-front design solves nothing. It looks great on paper but ultimately by the end you have no product, just paper. We spend more time producing, iterating and getting feedback and less time pontificating on the architect chair.

» Posted by: Ryan at March 8, 2004 05:36 AM
Google
 
Search scope: Web ryanlowe.ca