Re: [gupnp] gupnp-av

Hey!

On Sat, 2007-07-28 at 15:23 +0300, Zeeshan Ali wrote:
> Hey jorn!
> Attached is the basic skeleton (client-side only) of gupnp-av i
> could think of. You would immediately note that the pxoxy objects are
> not derived from the GUPnP device and service proxy objects and the
> reason for that is that AVControl point would not have any control
> over the creation of the the proxy objects and hence can not create
> these AV specific proxies. So either we make GUPnPControlPoint more
> extensible or we have the av-specific proxies to "contain" (instead of
> derive) the GUPnP proxy objects.

Hmm, I see no clear distinction between client and server classes in
your design? Also, will we really need the "Info" classes - I doubt
there is any "info" that would (sensibly) be available for query from
both client and server sides?

I rather envisioned something simpler: A set of classes for implementing
all the different AV services, and a set of classes for controlling
them: all taking the relevant Service or ServiceProxy objects as
constructor arguments. We shouldn't need any control point or device
wrappers (devices merely contain services).

> One easy way to make control point extensible that comes to mind
> straight-away, is to make the static methods of control point that
> creates the proxies when the description document is ready, virtual.
> What do you think?

Yes maybe, but I intentionally chose not to do this in order to keep
things as simple as possible. The present setup is like D-Bus where you
don't subclass proxies.

Let's see how it goes with the present setup, we can always add these
virtual methods if necessary. It won't change the API.

Cheers,

Jorn

--
To unsubscribe send a mail to gupnp+unsubscribe\@o-hand.com