On Thu, 2017-06-01 at 14:04 +0100, Philip Withnall wrote:
On Tue, 2017-05-30 at 21:56 +0200, Krzesimir Nowak wrote:On Sun, May 28, 2017 at 12:53 AM, Philip Withnall <philip tecnocode co uk> wrote:Origin naming scheme --- So that origin IDs can match remote names, they must share the same naming scheme (currently, for example, ‘gnome-apps’). We might want to transition to a different naming scheme (reverse-DNS, for example, ‘org.flathub’) in future if it would make uniqueness easier. In any case, origin IDs have to be globally unique. If this is hard to achieve with free-form IDs, we might instead want to use GUIDs, and match them to local remote configuration by including the origin GUID in the remote configuration as an additional key. This would require a migration step for existing configurations, whereas matching by origin ID = remote name potentially doesn’t, if we assume that most people give their remote configuration a predictable name.I'd prefer to stick and to enforce one scheme to avoid having a situation where we have a mix of conventions for naming the origin ID. Also, anything but GUID. Or maybe we shouldn't care if the name is not going to be used/seen/typed by the user.The branch I’ve got at the moment uses origin IDs which are like remote names (and matches the two based on that), and it seems to fit into the code fairly well. In the absence of arguments against that, or disasters when I try to integrate this approach into flatpak, I’ll go with that.
Actually, I’m going to have to make the link between remote configuration and origin ID more explicit than linking them by name. I think there’s going to have to be an origin-id key in each [remote "blah"] config section, otherwise we can’t enumerate the local remotes and unambiguously work out which ones correspond to origins (and which don’t). This is needed for the §(Publishing on a P2P server) example from my original e-mail. Philip
Attachment:
signature.asc
Description: This is a digitally signed message part