smcv, fledermaus http://pastebin.com/NjE6EGwN I can add this to the bug if you prefer reading having this discussion on something permanent, like the mailing list or a bug, seems like a better idea than on pastebin agreed, but using a pastebin as an "agenda" for discussion we'll summarize elsewhere seems fair (as long as we actually do summarize it elsewhere :-) s/above/below obviously wjt, as smcv said once we agree on something here I will add it to the bug Different CMs can support the same services. ← actually, I think it's fair to say a service is CM specific. I think so too different CM implies different parameters. indeed also, the case of "we have 17 connection managers for MSN and none of them work" is not desirable (obviously, I exaggerate) and at its heart a service consists of parameters + limitations on what the CM can really do but for service in this case I mean, google-talk, so different CMs can support google-talk, but each CM has it's own google-talk requirements for example the intention seems to be that profiles are defined by either "the platform" or third party service providers right? yeah smcv, yep let's assume the platform is Maemo, because we know how the analogous concept looked on Maemo 5 ok (for Maemo read "Maemo or Meego or Debian or GNOME or...") sure and yes let's have Google Talk as our example two possibilities, then 1) Maemo explicitly supports Google Talk 2) it doesn't if it has specific support for Google Talk (as it does in reality), then the Maemo platform developers get to choose which CM is best the other CMs are unsupported fair. agreed e.g. Maemo 5 doesn't have UI to make Google Talk accounts with Haze, and that's correct and good if something is installing in the system directories, it's up to the platform to handle collisions, cf debian diversions if the platform doesn't have specific support for GTalk, but we hypothesize some mechanism for a service provider to ship a third-party profile, then it becomes that service provider's problem continuing our example: if Maemo didn't support GTalk, but Google wanted it to, they could package their own google-talk.profile which, again, would only support Gabble right. ok people have hypothesized that SIP providers would ship profiles somewhere in the cloud and Maemo users could install them somehow in practice I'm not aware of anyone actually doing so I think that with this in mind we are willing to choose solution #2, and let the platform choose what are the main CMs that are able to install service-name.profile files all other CMs should install $service-name-$cm-name.profile if they want to install profiles I concur. side point: if we want profiles to be a user-installable thing, where user-installable means "downloaded from ekiga.net" rather than "downloaded from maemo extras", then we should try to avoid profiles being able to fuck up your system they should look like, I don't know, firefox search engine definitions (sandboxed, declarative, not very capable) rather than browser plugins (arbitrary code execution) most "users" not developers install packages/files/etc from platform packages, so I think we are _ok_ if we choose #2 let's just make this clear somewhere in the docs XDG_DATA_DIRS gives us a canned definition of what the search path is, I don't see any reason to deviate from that any other pros/cons I can't see? don't think so... so we're saying "the location is well defined", "the filename is a guideline" & "the content of the file actually determines the service name" , yes? fledermaus, nope, the content of the file actually defines the manager name (for main CMs mainly), the service name is always in the filename the service name in the filename is mandatory ok if the filename was a guideline, then we'd have to define a precedence order a reader MUST ignore profiles with mismatched filenames/contents? or do we want to say which takes precedence if they don't match? probably asciibetical, 00-google-talk < 99-google-talk smcv, the precedence order is XDG_DATA_HOME, XDG_DATA_DIRS, like in .manager files but if we can avoid doing that, everyone wins soo google-talk.profile in XDG_DATA_HOME should be used over google-talk.profile in any XDG_DATA_DIRS you got the idea I don't think run-parts style ordering is too hideous... andrunko: yeah, "XDG_DATA_DIRS" is shorthand for "XDG_DATA_HOME (default ~/.local/share) followed by XDG_DATA_DIRS (default /usr/local/share:/usr/share)" so no need to have 00, 99 as the service name is unique in our case google-talk service name will only exists for 1 cm andrunko: users of XDG dirs have to define what happens in a collision, and our definition is "the one in the most important dir wins" other cms defining google-talk will have google-talk-foo as the service name side benefit, the user can override the system :-) yep andrunko: tbh, don't even mention or support secondary CMs. butterfly pretty much wins on everything these days I think regarding mismatches between content and filename so the file format should not include service name, but it must include the manager name the canonical way to resolve that is to have the content not duplicate the filename, a la .manager one problem with that is if you want to be able to download profiles like and not they're not self-identifying by content I think self identifying by content is good smcv, they are self-identifying by the name unless someone puts a 123.profile to install that defines google-talk andrunko: if you're downloading you don't necessarily have control over the name which makes no sense andrunko: I emailed an evolution user a profile, here's /tmp/evolution_49f8yuwy5.bin. quick, what protocol is it? ;-) we can add the service name to the file format, but it should be ignore by parses, that should only use the filename so we know the precedence based on dirs arggg, *ignored by parsers if we say that the content duplicates the filename, and installed files whose content doesn't match their name are a syntax error (fallback: ignore), would that be OK? I think so, it's just a tip for users smcv: sure. not mandatory for parsers wait, not mandatory? I think that's asking for weird bugs later. I was going for: it's a syntax error, fail noisily and recover by pretending the file had never existed fledermaus, I mean if the parser parses google-talk.profile that defines ignore that file it's wrong to avoid the weird bugs fledermaus imagines yes i think we all agree there. the file name and service id MUST match facebook doesn't support groups? felipec: you can't edit them via XMPP felipec: you make a facebook-specific thing on the website and they're mapped to read-only groups ah :( felipec: I think they're called "lists", by default there's an empty one called Limited Profile fledermaus, andrunko: so are we agreed on what these files look like? I think so, I need to add the namespace stuff to the example. and make a couple of other tweaks we decided on, I'll get them from the log smcv, fledermaus resume http://pastebin.com/6tiBXG46 andrunko: you volunteered to summarize discussion on the bug, I think? smcv, yep, I will do it smcv, so am I right in the resume? andrunko: please do put the reasons in, not just the conclusions smcv, ok andrunko: but I agree with the conclusions in your pastebin great, I will summarize what we discussed in the bug fledermaus, are you going to do any change in the file format? or should we consider the latest draft as the file format? \o/ andrunko: I'm making the changes I mentioned towards the end of the discussion yesterday one moment... I'd like to have a definition of the format that is a definition, not just a commented example fledermaus, ok, please post them in the bug as well just one thing, we ignore right? (of course, it can *contain* some commented examples) andrunko: if we don't define a tag, it should be in a namespace other than ours spo we can ignore it I think we agreed to omit unless/until we actually need it ok this will apply to setting - so it's outside our scope, as it were we won't define it. so we agree \o/ iirc the one thing we wanted to add was My Google Talk account, defined as "you're meant to append stuff as necessary to make it unique"? I'm not sure under what circumstances that'd differ from the displayed name for the service, mind, so perhaps we don't need it smcv: I think that ended up as "put it on your own namespace, we're not bothered" ok, so, rename the inside , add xmlns, shake fist at sky about duplicated type info... is what I have listed as things to change. I think that is it for now fledermaus: fair. I think having the default Account.DisplayName for new accounts be "%s (%s)" % (, JID-or-whatever) makes sense but that's a job for UIs in any case right smcv: by actual definition, you mean DTD? fledermaus: DTDs can't do arbitrarily-namespaced extension points; XMPP uses XML Schema, I hear the cool kids prefer relax-NG fledermaus: I didn't necessarily mean anything that formal, although it'd be great ok. just checking. fledermaus: just that there's some text analogous to telepathy-spec right.