| Summary: | unclear conceptual model | ||
|---|---|---|---|
| Product: | Ytstenut | Reporter: | Simon McVittie <smcv> |
| Component: | protocol | Assignee: | ytstenut |
| Status: | NEW --- | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | medium | CC: | olli.salli |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
(In reply to comment #0) > has zero or more > * consumed service > (service from which it wants other people's statuses) This is per-capability, actually. I find that a bit weird, unless we heavily standardize the statuses so that a statuses for a given capability can be interpreted uniformly for all services implementing it. > has one or more > * provided service > has zero or more > * localized name > has zero or more > * capability (FQC ID) > receives RPC-style messages from someone else's provided service > has zero or more > * status > > except that when we receive statuses from the network, the FQC ID appears > "bigger than" the service? Or something? Yeah, the thinking in statuses seems to be that which service actually provides the capability is just a minor implementation detail, and the capability is what matters. Again, I find this problematic unless the capabilities are really well standardized across services. > > Also, you shouldn't need to export a service in order to make RPC calls. Well, the BOSH ones just implemented a fake one with no advertised capabilities. While a bit unclean, I think we should still have some means of indicating "this contact is Ytstenut enabled, although it doesn't provide services" even on c2s/xmpp setups. > > I think we should consider a simpler conceptual model: > > * entity > has exactly one > * locally-unique entity identifier (in practice basically a JID) > has zero or more > * capability subscription > (capability whose status it is interested in) > has zero or more > * capability > (capability it offers to others) > receives RPC-style messages from another entity > has exactly one > * status Yeah, dropping the capability<->service distinction sounds good to me. I assume you intend the new "capability" to be rather closer to the old "service" conceptually, as in, it's a certain specialized variant? I mean, instead of "music player" with a few generic commands/statuses it's "mpris2 music player" with its own unique command/status set clients will have to understand? > > Here "entity" is a placeholder: it could be called "service" or something, if > people don't like "entity"? "Entity" is a tad generic to my taste. "Peer"? "Node"? These have a sense of bidirectionality. I wouldn't say "service" as these can potentially act both as producers and consumers of statuses, and also both invoke and execute commands/RPC. > > In this model, the hardware device on which the entity lives is merely an > implementation detail: each entity has its own Avahi service instance, or its > own connection to the XMPP server. > > Provided capabilities are analogous to implementing a D-Bus or Java interface; > we could rename them to interfaces, even. > > ... > > Related functionality on a device would be a single entity (e.g. a media player > might have an MPRIS2-like API that simultaneously has MediaPlayer, > TrackListProvider and PlaylistProvider capabilities). Hmm, I see. Or maybe it would make sense to have the capability/interface concept be rather fine grained, and you'd actually have a generic media player interface, and an another one supplementing it with MPRIS2 specifics, (and the same for the track and play lists). > > Unrelated functionality on a device would usually be in separate entities (e.g. > if my laptop has a Ytstenut-enabled media player and also Ytstenut-enabled > presentation display software, they'd be separate entities). Yes, sounds good. (And means we don't have to reinvent Telepathy account management and channel dispatching when we drop it from the stack :)) |
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.
Yts appears to have a conceptual model looking something like this: * contact (~ hardware device) has exactly one * locally-unique contact identifier (in practice basically a JID) has zero or more * consumed service (service from which it wants other people's statuses) has one or more * provided service has zero or more * localized name has zero or more * capability (FQC ID) receives RPC-style messages from someone else's provided service has zero or more * status except that when we receive statuses from the network, the FQC ID appears "bigger than" the service? Or something? Also, you shouldn't need to export a service in order to make RPC calls. I think we should consider a simpler conceptual model: * entity has exactly one * locally-unique entity identifier (in practice basically a JID) has zero or more * capability subscription (capability whose status it is interested in) has zero or more * capability (capability it offers to others) receives RPC-style messages from another entity has exactly one * status Here "entity" is a placeholder: it could be called "service" or something, if people don't like "entity"? In this model, the hardware device on which the entity lives is merely an implementation detail: each entity has its own Avahi service instance, or its own connection to the XMPP server. Provided capabilities are analogous to implementing a D-Bus or Java interface; we could rename them to interfaces, even. Consumed capabilities are analogous to subscribing to all the signals from a D-Bus interface (like making a GDBusProxy). We could make registering to consume a capability return an object called a proxy, maybe. Entities are analogous to D-Bus (bus name, object path) tuples or Java objects. They more or less only exist as a thing in their own right so that you can have progressive-degradation: foreach entity: if it's an AdvancedMediaPlayer: interact with it in advanced ways, regardless of whether it is also a SimpleMediaPlayer elif it's a SimpleMediaPlayer: interact with it in simple ways else ignore it completely Related functionality on a device would be a single entity (e.g. a media player might have an MPRIS2-like API that simultaneously has MediaPlayer, TrackListProvider and PlaylistProvider capabilities). Unrelated functionality on a device would usually be in separate entities (e.g. if my laptop has a Ytstenut-enabled media player and also Ytstenut-enabled presentation display software, they'd be separate entities).