subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@apache.org>
Subject Re: Media-Type for SVNPubSub
Date Sun, 02 Jun 2013 08:34:47 GMT
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@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


Mime
View raw message