This project is read-only.

First Draft of Architecture Document checked in

Dec 3, 2007 at 4:41 PM
Look under \Project Docs

If you have Microsoft Office 2003 you can open these files by installing the compatibility pack from
Dec 4, 2007 at 1:53 PM
I have had a look over the document that you checked in and I like the ideas in there.

I like the idea of the separate podcatching engine. I was thinking that it would be a service in a service layer of some sort (in process), but taking it that step further and moving it, potentially, out of process opens up lots of interesting prospects.

Could you expand on the fact that the Object Model will be the primary way in which programs interact with the podcast engine?
I was under the impression from other areas of the document that the interaction point with the podcast engine would be the WCF interfaces.
Dec 4, 2007 at 6:14 PM
Sure - the podcast engine will have a SOA style API but that does not necessarily mean that it has to run out of process. It simply opens up the fact that it could be deployed that way to support interesting scenarios. For example, I'm running Windows Home Server here in my house. What if I deployed the podcast engine as a service on the Windows Home Server. Then I setup my Zune to simply sync those podcasts when my laptop is docked at home. They get downloaded whenever and I don't even think about it.

The goal of interacting with the podcast engine through an object API is to provide an abstraction layer to the things above. The pattern we use here is sometimes referred to as a "service agent" or "proxy". The obejcts will know how to invoke the podcast engine (locally or remotely).

I would not want to always install Doppler as a service because this greatly complicates the setup and the footprint would be way to much for the typical user but as you said it introduces many very, very interesting possibilites.