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?
>>
>> application/vnd.svn-svndiff
>> application/vnd.svn-skel
>>
>> 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:
>> application/vnd.apache-subversion.pubsub-stream+json
>> and I suggested:
>> application/vnd.apache.pubsub+json
>>
>> 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):
>> http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types
>>
>> 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
somewhere; e.g.,
application/vnd.apache.vc-pubsub+json
or even better,
application/vnd.apache.vc-notify+json
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.
-- Brane
Received on 2013-06-02 10:34:57 CEST