[Vortex] about mime types

[Francis Brosnan Blazquez]

El lun, 27-03-2006 a las 22:05 -0500, Philip Kovacs escribió:
> Hi Francis,
> 

Hi Phil!

> I must ask you about mixing mime types on a profile/channel.    If I
> have
> a MSG/RPY exchange on the control channel, e.g.
> 
> MSG=catalog   (text/plain)
> RPY=<catalog> ... </catalog>  (text/xml)

I see.

> 
> how do I alter the Content-Type header when sending the message or
> reply?  

See below.

> Or, is it a better design to have all messages on a profile of the
> same 
> mime type,
> i.e. all exchanges on the control channel are text/xml.   

It is not clear which is the best, I mean, mime types are one more tool
you can use.

> RFC 3080 
> indicates that
> message payloads can be whatever you want as long as the Content-type
> is 
> indicated.  

Right, and, by default, some mime headers are suposed implicitly if not
defined.

> I see that Vortex has a way to indicate content type in 
> vortex_frame_create_full(),
> but it seems to me that this api is rather low-level. 

You are right, this function should be used under normal circumstances.

>  AT the highest 
> level, you have
> an api vortext_profiles_set_mime_type() which is very high-level and 
> operates
> above the message level.

Again, you are right, see below.

> 
> If it makes more sense to stick to one content-type for each 
> channel/profile, then
> wouldn't I need multiple data channel profiles, i.e. one for each 
> content type i wish
> to support?  For example:
> 
> phil-control-profile (text/xml)
> phil-data-profile-plain (text/plain)
> phil-data-profile-xml (text/xml)
> phil-data-profile-binary (application/octet-stream)

I see your point. In short, I think it is better to have one
phil-data-profile, and support any MIME format on top of it. See below.

> 
> I see how you suggested using a piggyback message on channel create
> to 
> indicate
> content type, but implied in your response is essentially "ignoring"
> the 
> mime header. 

;-)

>  From a practical point of view, I understand how you can ignore the 
> content-type
> header and just consider the semantics of the messages, given that we 
> know what
> the exchanges will look like.   However, a purist might argue that
> the 
> content-type
> headers should always be correct and reflect the actual contents of
> the 
> payload.

We have to consider several issues while talking about MIME and MIME
inside BEEP. 

Initially, mime was designed to allow transport application protocols,
especially SMTP, but extended to HTTP, to notify application level the
content of the object being received. The same happens with BEEP. 

But, what happens when application protocol designers just ignore MIME
information, no matter which transport protocol they are using? Again,
this is not clear, mainly because MIME is just an indicator.

If you pretend to develop a kind of bridge that is able to transport
*everything* without a previous knowledge, it is likely MIME is
required.

My conclusion is, if your system will be the message producer and the
message consumer at the same time, you can safely ignore MIME. But, if
third party software is required to be supported, that is initially
unknown, you'll need MIME.

Now, let's talk about MIME support inside Vortex.

Initially, if you send a message, without taking into account the MIME
type, because you didn't configure anything or your messages didn't
include any MIME headers, then frames generated won't have any MIME
hearders, supposing the following values:

	Content-Type: application/octet-stream
	Content-Transfer-Encoding: binary

This means that the remote peer will have to recognize that the frame
received doesn't have any MIME configuration and previous values should
be implicitly notified (again, even when they are not found).

If you require to set a MIME type configuration, but you don't want to
append such information for every message you send, you can configure
default mime headers to be used for every profile registered, using the
functions you have found. 

However, this mechanism doesn't fit very well if it is required to send
arbitrary MIME objects under the same profile, that is, the same running
channel, as you have noted

To my understanding, I'm with you that it is not a good option to create
a profile per MIME object type you have. This will create you lot of
problems, making your software fragile to future changes. 

What you can do is to take advantage of the implicit MIME headers
configuration. Just don't configure anything about MIME headers, and
include such information in the message you are passing in to the
sending functions [1].

Because you didn't configure anything about MIME headers, Vortex will
take you message as a hole, sending it to the remote peer. At the remote
peer, the framing mechanism will detect the MIME configuration, setting
it to frames delivered into your application.

Cheers!

[1]
http://www.aspl.es/fact/files/af-arch/vortex/html/group__vortex__channel_gd71a2df5324d7122e98fa52bb534b05d.html#gd71a2df5324d7122e98fa52bb534b05d

> 
> Phil
-- 
Francis Brosnan Blazquez <francis at aspl.es>
Advanced Software Production Line, S.L.