Attachment 37573 Details for Bug 24897 – IRC log

IRC log

log.txt (text/plain), 10.42 KB, created by Andre Moreira Magalhaes on 2010-08-04 10:53:54 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Andre Moreira Magalhaes

Created: 2010-08-04 10:53:54 UTC

Size: 10.42 KB

patch

obsolete

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

Actions: View

Attachments on bug 24897: 37573

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.