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 <gst...@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
