On 02.06.2013 04:07, Ben Reser wrote:
> I was hoping someone else would weigh in here. But I guess not.
> On Tue, May 28, 2013 at 11:15 AM, Greg Stein <gstein_at_gmail.com> wrote:
>> You guys are over-thinking it. Simply state this format is ASF-wide
>> and be done with it.
> Okay but should we ask anyone before we go and start using something
> like application/vnd.apache.pubsub+json? Daniel seemed to think we
> shouldn't use the apache namespace without talking to operations.
I frankly fail to see what operations (I suppose you mean infra@) have
got to do with it. It would probably make sense to notify pmcs@ through.
>> Are these obvious?
>> Not really. But we just started using them.
> Yes assuming they were defined when Subversion was under the
> Subversion Corporation. Interestingly they appear not to be
> registered (at least they aren't on the IANA list).
Yup; at the time, I got the impression that registration was not in fact
strictly required; only useful.
>> Anyway, you suggested:
>> and I suggested:
>> cuz we don't need the -subversion in there. And the -stream will be
>> inherent in the format. As you state: it is also generic, so no need
>> for svnpubsub or whatever.
>> For existing "conventions" (for whatever that's worth):
>> I'll note that a vnd.apache does not exist. So it's empirically true
>> that per-project naming for conflict resolution isn't worthwhile.
> The desire to include the top level project name in there was to avoid
> stepping on any toes. If that's not an issue then we can remove it.
We're talking about a format for "publishing notifications from version
control systems". There's nothing Subversion- or project-specific about
that, so it seems wrong to mention Subversion.
In that context, the farthest I'd go would be to put the 'vc' in there
or even better,
as the format of the notifications does not in fact imply any kind of
publish/subscribe architecture. You could create a server which clients
would periodically poll for the set of changes -- in fact, we may need
that eventually so that svnpubsub clients can catch up on events that
happened while they were not connecteded to the server.
> I'm not so sure we can clearly drop the -stream, because technically
> SVNPubSub has two formats. The format between the server and the
> commit-hook and the format between the subscribers and the server.
> The commit-hook/server format is unambiguously JSON, so we're not
> bothering to talk about it. Without it I think which format you're
> talking about is ambiguous.
Ambiguous how? The other format already has a well-known registered
media type. Media types do not say which program generated a specific
format, only what the format actually is. So we definitely don't need
another media type for that end of the protocol.
Received on 2013-06-02 10:34:57 CEST