1:02 a.m.
Hi,
First, doc/API.txt seems to be missing from dleyna-server repo. If the
idea is that only web page is updated, we should probably include a
url in docs/.
API.txt from media-service-upnp says this (looking at code, it seems
to accurately describe dleyna-server):
Additional Values for the Type Property:
----------------------------------------
The Type property tells what kind of object we are dealing with and
which can take the below values in addition to those described
in MediaServer2Spec specification (3).
in case of Items:
'video.musicclip', 'video.broadcast'
'audio.broadcast', 'audio.book',
'playlist', 'item'
and in case of Containers:
'album', 'album.music', 'album.photo'
'person', 'person.musicartist'
'genre', 'genre.music', 'genre.movie'
I think this is a mistake and makes the implementation non-compliant
with the org.gnome.MediaObject2 spec in a way that is harmful to
client developers. I realise there are other places where
dleyna-server does not implement some things or implements additional
things, but this is more problematic, basically an API break: The
MediaObject2 spec clearly says containers _must_ have type
"container", and applications will rely on that. Adding new types will
break clients.
As an example of this, dleyna-control makes this mistake -- I can't
browse by artist or genre:
https://github.com/01org/dleyna-control/issues/8. As another example
even the same document (API.txt) includes this example:
def tree(server_path, level=0):
bus = dbus.SessionBus()
container = dbus.Interface(bus.get_object(
'com.intel.media-service-upnp', server_path),
'org.gnome.UPnP.MediaContainer2')
objects = container.ListChildren(0, 0, ["DisplayName", "Path",
"Type"])
for props in objects:
print " " * (level * 4) + ( props["DisplayName"] +
" : (" + props["Path"]+
")")
if props["Type"] == "container":
tree(props["Path"], level + 1)
I believe this will not work for all containers.
If the additional container types are required, could we add another
property for them instead?
- Jussi
2:59 a.m.
Hi Jussi,
I agree with you, the application should not do the container filtering itself (i.e. test
for all possible container type values).
Probably the best option would be, as you suggest, always get "container" in the
Type property and add a new property for holding the sub-type ("album.photo",
etc.)
By the way, I see that our download_sync_controller sample is wrong too, testing only
against the "container" type value...
Regis
________________________________________
From: dleyna-bounces(a)lists.01.org [dleyna-bounces(a)lists.01.org] on behalf of Jussi
Kukkonen [jussi.kukkonen(a)intel.com]
Sent: Monday, March 04, 2013 15:02
To: dleyna(a)lists.01.org
Subject: [dLeyna] non-compliant MediaObject2.Type values
Hi,
First, doc/API.txt seems to be missing from dleyna-server repo. If the
idea is that only web page is updated, we should probably include a
url in docs/.
API.txt from media-service-upnp says this (looking at code, it seems
to accurately describe dleyna-server):
Additional Values for the Type Property:
----------------------------------------
The Type property tells what kind of object we are dealing with and
which can take the below values in addition to those described
in MediaServer2Spec specification (3).
in case of Items:
'video.musicclip', 'video.broadcast'
'audio.broadcast', 'audio.book',
'playlist', 'item'
and in case of Containers:
'album', 'album.music', 'album.photo'
'person', 'person.musicartist'
'genre', 'genre.music', 'genre.movie'
I think this is a mistake and makes the implementation non-compliant
with the org.gnome.MediaObject2 spec in a way that is harmful to
client developers. I realise there are other places where
dleyna-server does not implement some things or implements additional
things, but this is more problematic, basically an API break: The
MediaObject2 spec clearly says containers _must_ have type
"container", and applications will rely on that. Adding new types will
break clients.
As an example of this, dleyna-control makes this mistake -- I can't
browse by artist or genre:
https://github.com/01org/dleyna-control/issues/8. As another example
even the same document (API.txt) includes this example:
def tree(server_path, level=0):
bus = dbus.SessionBus()
container = dbus.Interface(bus.get_object(
'com.intel.media-service-upnp', server_path),
'org.gnome.UPnP.MediaContainer2')
objects = container.ListChildren(0, 0, ["DisplayName", "Path",
"Type"])
for props in objects:
print " " * (level * 4) + ( props["DisplayName"] +
" : (" + props["Path"]+
")")
if props["Type"] == "container":
tree(props["Path"], level + 1)
I believe this will not work for all containers.
If the additional container types are required, could we add another
property for them instead?
- Jussi
_______________________________________________
dLeyna mailing list
dLeyna(a)lists.01.org
https://lists.01.org/mailman/listinfo/dleyna
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
10:58 p.m.
Hi All,
In the past the only Type we supported was container so the code below used to work.
Unfortunately, we added all these new types without thinking about the spec or realising
that we were breaking existing code.
An alternative would be to add a new property called TypeEx that behaves as our current
Type behaves and then change Type so that it conforms to MediaService2Spec. This might be
better for search queries and would make things simpler for applications. Otherwise
applications that want to take advantage of the advanced Type information would need to
inspect two properties.
Mark
-----Original Message-----
From: dleyna-bounces(a)lists.01.org [mailto:dleyna-bounces@lists.01.org] On Behalf Of
Merlino, Regis
Sent: Monday, March 04, 2013 4:59 PM
To: Kukkonen, Jussi; dleyna(a)lists.01.org
Subject: Re: [dLeyna] non-compliant MediaObject2.Type values
Hi Jussi,
I agree with you, the application should not do the container filtering itself (i.e. test
for all possible container type values).
Probably the best option would be, as you suggest, always get "container" in the
Type property and add a new property for holding the sub-type ("album.photo",
etc.)
By the way, I see that our download_sync_controller sample is wrong too, testing only
against the "container" type value...
Regis
________________________________________
From: dleyna-bounces(a)lists.01.org [dleyna-bounces(a)lists.01.org] on behalf of Jussi
Kukkonen [jussi.kukkonen(a)intel.com]
Sent: Monday, March 04, 2013 15:02
To: dleyna(a)lists.01.org
Subject: [dLeyna] non-compliant MediaObject2.Type values
Hi,
First, doc/API.txt seems to be missing from dleyna-server repo. If the idea is that only
web page is updated, we should probably include a url in docs/.
API.txt from media-service-upnp says this (looking at code, it seems to accurately
describe dleyna-server):
Additional Values for the Type Property:
----------------------------------------
The Type property tells what kind of object we are dealing with and
which can take the below values in addition to those described in
MediaServer2Spec specification (3).
in case of Items:
'video.musicclip', 'video.broadcast'
'audio.broadcast', 'audio.book',
'playlist', 'item'
and in case of Containers:
'album', 'album.music', 'album.photo'
'person', 'person.musicartist'
'genre', 'genre.music', 'genre.movie'
I think this is a mistake and makes the implementation non-compliant with the
org.gnome.MediaObject2 spec in a way that is harmful to client developers. I realise there
are other places where dleyna-server does not implement some things or implements
additional things, but this is more problematic, basically an API break: The
MediaObject2 spec clearly says containers _must_ have type "container", and
applications will rely on that. Adding new types will break clients.
As an example of this, dleyna-control makes this mistake -- I can't browse by artist
or genre:
https://github.com/01org/dleyna-control/issues/8. As another example even the same
document (API.txt) includes this example:
def tree(server_path, level=0):
bus = dbus.SessionBus()
container = dbus.Interface(bus.get_object(
'com.intel.media-service-upnp', server_path),
'org.gnome.UPnP.MediaContainer2')
objects = container.ListChildren(0, 0, ["DisplayName", "Path",
"Type"])
for props in objects:
print " " * (level * 4) + ( props["DisplayName"] +
" : (" + props["Path"]+
")")
if props["Type"] == "container":
tree(props["Path"], level + 1)
I believe this will not work for all containers.
If the additional container types are required, could we add another property for them
instead?
- Jussi
_______________________________________________
dLeyna mailing list
dLeyna(a)lists.01.org
https://lists.01.org/mailman/listinfo/dleyna
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company) Registered headquarters:
"Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros
This e-mail and any attachments may contain confidential material for the sole use of the
intended recipient(s). Any review or distribution by others is strictly prohibited. If you
are not the intended recipient, please contact the sender and delete all copies.
_______________________________________________
dLeyna mailing list
dLeyna(a)lists.01.org
https://lists.01.org/mailman/listinfo/dleyna
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
12:19 a.m.
Hi Jussi,
On 03/04/2013 03:02 PM, Jussi Kukkonen wrote:
Hi,
First, doc/API.txt seems to be missing from dleyna-server repo. If the
idea is that only web page is updated, we should probably include a
url in docs/.
You're correct. This docs are missing and need to be added. I've
created two github issues to track the missing docs.
https://github.com/01org/dleyna-server/issues/20
https://github.com/01org/dleyna-renderer/issues/19
Regards,
Mark
11:51 p.m.
Hi All,
On 03/04/2013 03:02 PM, Jussi Kukkonen wrote:
Hi,
First, doc/API.txt seems to be missing from dleyna-server repo. If the
idea is that only web page is updated, we should probably include a
url in docs/.
API.txt from media-service-upnp says this (looking at code, it seems
to accurately describe dleyna-server):
> Additional Values for the Type Property:
> ----------------------------------------
>
> The Type property tells what kind of object we are dealing with and
> which can take the below values in addition to those described
> in MediaServer2Spec specification (3).
> in case of Items:
> 'video.musicclip', 'video.broadcast'
> 'audio.broadcast', 'audio.book',
> 'playlist', 'item'
> and in case of Containers:
> 'album', 'album.music', 'album.photo'
> 'person', 'person.musicartist'
> 'genre', 'genre.music', 'genre.movie'
I think this is a mistake and makes the implementation non-compliant
with the org.gnome.MediaObject2 spec in a way that is harmful to
client developers. I realise there are other places where
dleyna-server does not implement some things or implements additional
things, but this is more problematic, basically an API break: The
MediaObject2 spec clearly says containers _must_ have type
"container", and applications will rely on that. Adding new types will
break clients.
This issue was fixed in a recent pull request. dLeyna-server's
implementation of Type is now mostly consistent with MediaServer2Spec's,
e.g., the Type of all containers is now 'container'. Extended type
information is accessible via a new property, TypeEx. For more
information about exactly what has changed, please see the comments in
the following PR
https://github.com/01org/dleyna-server/pull/103
Best Regards,
Mark
3370
days inactive
3485
days old
4 comments
4 participants
participants (4)
-
Jussi Kukkonen -
Mark Ryan -
Merlino, Regis -
Ryan, Mark D