On Thu, Apr 16, 2009 at 11:48 AM, Michael Abato <maeng...@gmail.com> wrote:

>
> Even if the stream of bytes has no semantic meaning without
> the .proto, its "format" is still protobuf binary, so the MIME type
> makes some sense even if it is not sufficient.


Did this discussion ever continue past this single thread?  The only other
thread I've noticed that matches on the term mime type doesn't really go
into a great depth on the topic, so I can only assume no.  That said, if I'm
mistaken and this conversation has long since taken place and a
determination made my apologies in advance for reopening a closed
discussion.

With the above disclaimer in place, might I make a suggestion to use the
widely accepted (and for that matter, recommended)
[category]/[type+serializationFormat] format where -- in the case of
protocol buffers might look something like application/foo+protobuf where
foo represents .proto for a given object? (e.g. application/atom+xml where
atom represents the type and xml the serialization format)


>
> Putting a ref to the appropriate .proto in the HTTP headers REST-style
> seems sensible - loosely similar to declaring a schema or dtd on an
> XML file:


>From the standpoint of HTTP this makes a lot of sense: You can certainly
specify to the .proto of a given type via an X- response header.  But when
it comes to anything /other/ than HTTP you're left to your own devices as to
how to go about specifying the .proto type which, to me anyway, is just
begging for fragmentation issues between transportation protocols.

Of course, there is one obvious problem with the above and that is the
dynamic nature of types compared to the very static, and slow moving process
of requesting/registering/receiving an official IANA registered mime-type.

But this is only a problem if you consider gaining an official IANA
mime-type pertinent to the usage of the given mime-type string within your
applications.  If this is not something that you see as a barrier for
adoption, then the one obvious approach to dealing with things like
namespace clashes is to adopt a solution that has worked well for other
dynamically driven spaces where name clashes are inevitable, that of using
the tld.domain.classpath.type format adopted by the Java community to ensure
that my application/foo+protobuf and your application/foo+protobuf can
easily co-exist by simply using application/com.mydomain.foo+protobuf and
application/com.yourdomain.foo+protobuf

Thoughts/comments/criticism/suggestions?

-- 
/M:D

M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: m.da...@3rdandurban.com | m.da...@amp.fm
Mobile: (206) 999-0588
http://3rdandUrban.com | http://amp.fm |
http://broadcast.oreilly.com/m-david-peterson/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to