| Summary: | Status messages should be able to carry structured XML or JSON content | ||
|---|---|---|---|
| Product: | Ytstenut | Reporter: | Olli Salli <olli.salli> |
| Component: | protocol | Assignee: | Robert Staudinger <robert.staudinger> |
| Status: | NEW --- | QA Contact: | |
| Severity: | major | ||
| Priority: | medium | CC: | olli.salli |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
FWIW the C stack allows sending freely structured XML content already. Would there be any reason not to support arbitrary XML inside <ytstenut:status> ? I'd favour that and maybe even get rid of <ytstenut:description>, but restrict the possible xml attributes of <ytstenut:status> in exchange. (In reply to comment #2) > Would there be any reason not to support arbitrary XML inside <ytstenut:status> > ? I'd favour that and maybe even get rid of <ytstenut:description>, but > restrict the possible xml attributes of <ytstenut:status> in exchange. The <yts:descr>s are mandatory, so unless we remove them I think it'd be weird to have free-form optional stuff mixed with them. Why restrict the attributes? Attributes can be namespaced just like element tags, so foreign ones can be easily ignored. We might want to mandate an XML namespace for non-standard attributes though? (In reply to comment #3) > Why restrict the attributes? Attributes can be namespaced just like element > tags, so foreign ones can be easily ignored. We might want to mandate an XML > namespace for non-standard attributes though? The plan we discussed with Will in November was to move to JSON payload for messages and status. By not allowing custom attributes and encoding the payload inside in JSON we have a clean separation of protocol and data. You can of course still use XML payloads, but ytstenut-glib will not offer any facilities for that, you'll just have to pass the xml string. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
The Ytstenut statuses offer a useful mechanism for Ytstenut applications to broadcast their state to all interested receivers. This is more efficient than sending unicast Ytstenut messages/commands when there are many receivers, and works in the presence of client-only applications, which can't receive incoming commands. However, the spec document currently restricts the contents of the <ytstenut:status/> elements to a flat list of <ytstenut:description/> nodes. Arbitrary attributes are supported on the <ytstenut:status/> node itself, but these are not sufficient for many kinds of data. I propose adding an optional <ytstenut:payload/> element to those allowed as children of <ytstenut:status/> nodes. If present, this element could contain arbitrary XML structured content. I think a separate container element is nice to have for this free-form payload, so it won't get confused / collide with the <ytstenut:description/>s of the status itself. E.g. a music player might want to transmit the contents of its playlist to allow choosing the next song like this: <ytstenut:status version='1.0' from-service='org.kde.Amarok' capability='yts-caps-audio' activity='yts-activity-play' uri='file:///song1.mp3' volume='0.75'> <ytstenut:description xml:lang='en-GB'> Playing a song about indifference towards weather. </ytstenut:description> <ytstenut:payload> <playlist> <entry uri='file:///song1.mp3' artist='Art Blakey & The Jazz Messengers' title='Come Rain or Come Shine' /> <entry uri='file:///song2.mp3' artist='Art Blakey & The Jazz Messengers' title='Moanin'' /> </playlist> </ytstenut:payload> </ytstenut:status> A client receiving this would be in a good position to issue a ytstenut/command with activity='yts-activity-play' uri='file:///song2.mp3' if they want to switch to the true masterpiece from the album.