This project is read-only.

Gettin Up to work with

Topics: Developer Forum
Nov 13, 2006 at 3:08 PM

so, lets get all points we need to start working with this project.

here's my list of information that would be great

Information from the actual stuff
.) an big overview. what is implemented (maybe with mappings to the source)
.) how to start the thing. tried some stuff, but really selfexplaining is something different. didn't get it to work at home. does it have an windows client?
.) good/bad stuff. where should we extend it (or refactor it)

then points we should discuss for the next points at the project
.) featurelist. we should make an wiki article about features that we (or others) wish. with a small explanation and popularity
.) Architectural overview whitepaper. what should be the artitecture, what should we stick to, also guidelines to programming
.) a list of similar projects, or libs that could be interresting
.) programming guidelines. what do we want to use.

also some discussion points
.) do we want to have here implemented the greatest programming patterns? or just that we can go on, refactor some small parts and comment as we want?
.) extension of the project. do we want to have an plugin structure for additional player support?
Nov 14, 2006 at 12:24 AM
Where to start?


There are 3 main sections

Both Server and PCClient are NT Services.
Controller is a client that sits on windows mobile

So, you really need 1 PC and 1 PDA to make this work

I've created an install project for the Server, I will do the same for the PCClient tomorrow so this should be available shortly. I will also post the master control file (configuration.xml in the Server install directory) as it needs to be configured.

I also need to start posting docs to cover the main class structures. I've been putting class diagrams in the code (there's one in the device, messaging namespaces) but I need to do more documentation to make sense of the app.

Best way to look at it (By Namespace)


Device is the root class for most of the classes that deal directly with playing music. Device holds configuration, name, IPAddress, etc so is very important.

A Player is a device. A Controller is a Device. A Music Server is a device (you get the picture).

Player holds some generic Player type stuff. It maintains the music queue. ExStreamer and PCClient inherit from Player and provide device-specific implementations of the Player class.

MusicServer is used by the PCClient to contact the music server and maintain a record of its IPAddress.

DeviceManager is a generic manager of devices. It has a list of devices that can be searched, added to and removed from. PlayerManager and ControllerManager inherit from DeviceMananger and provide implementations to manager Players and Controllers.

The messaging namespace has 3 classes:MessageGenerator (which creates an XML Message), MessageProcessor (which receives an XML message from a TCP or UDP stream) and Message, which is the message.

The Xml namespace has some classes for making XML work easier. I hate these. I wrote them late one night and they work but they are not nice at all. They're also really important to the working of the system...

Library contains a collection of classes. Library holds the base library class. Audio inherits from Library and implmenents an audio library. This is built up of Artists and Tracks. The entire thing is designed to manage an XML document holding the entire music library.

Command is designed to abstract away how a message is received and processed by different devices. The main class here, CommandRouter, is designed to generically route a message to the correct type of class, invoking its method or setting its property in a generic manner. This comes with a couple of interfaces and a methodInvoker and PropertyInvoker class that allow the CommandRouter to generically execute a method or a property using the same code.

Good/Bad stuff:


Player implementation allows devs to add players quickly. PC client implementation only took a couple of hours.

Music library is actually really fast and very stable.


I wrote a lot of this late at night. It shows.
Not really documented
Xml helper classes are horrible.
There are a couple of "gotchas" lurking in the code. One is the configuration.xml file.

Feature list:

go for it. What I'd like to do?

Add Last.FM support
Add internet radio support
re-write the PDA app completely

Everyone else, add to the list

Programming Guildlines:

What do you suggest?

What am I aiming for?

Yeah, I'd like to improve the code. I'd really like to build in new features that make the app better. This will involve lots of iterations and re-factoring so I see these as pretty much compatible.

Plug-in Structure.

Show me what you mean. How would we look at implementing this?
Nov 20, 2006 at 5:24 PM
hmm... since i have no ppc, i'll like to have an windows client. or the shoutcast stream should also be easy to do. but i'm not really good in doing this core byte transferring stuff. what i could do is making something like an file transfer client. so you have an media player/winamp plugin, that downloads the files and store them local temporary and play them from there.

otherwise i could start with an tag library replacement.

i'll go thru the code again and post an coding guidelines post about stuff, i would change in an "perfect project" or do in an new project. so we can deside afterwards, what to implement and what to delay.
Nov 21, 2006 at 2:36 PM
Shouldn't be hard. I'll document the message format over the next couple of days and post it on the site. Messaging is basically taken care of so you really don't need to worry about any of the networking stuff - it just works.
Nov 22, 2006 at 6:57 PM
OK, I've documented the messaging code, provided a message template sample and provided some xsds to explain how things work. What you should find is the following:

MessagingExplanation.txt - explains the messaging format
MessagingTemplate.xml - contains a sample message for reference
Messaging.xsd - basic xsd of the Messaging nodes and their rules
CommandRoutes.xsd - basic xsd of the CommandRoutes.xml file and its rules

Also explains that CommandRoutes.xml contains a list of all Valid Commands to be sent to the server (so you have both the message format and all the current messages that the server receives).

If you want to go down the route of writing a PC-based controller this should make things easier.

All docs are in Emp3thyCommon in the Classes/Xml folder

Let me know any comments/feedback