[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MimeType changes during transfer?



In a talk, Marcel and I had recently, I learned, that this is a
undocumented feature or a bug, depending on the point of view.

Actually the subject of this mail should be something like:
'MimeType changes _not_ during a session'

But what am I talking about?
If a message is been published with a certain oid, it's been put in the
xmlblaster intern database including all relevant message info like
mimeType.

Later publishes of these messages with different mimeTypes would _not_
force an update of the xmlBlaster intern database stored mimeType.
Therfore I'm not able to receive the MimeType in the subscriber I just
pulished in the publisher if it differs from the first mimeType of this
message ever published.

This would lead to 2 possible solutions:

1. To check and/or set the mimeType for every message which has been
published.

2. To expand the qos with an argument like mimeTypeForce=yes or something
appropriate else.

to 1. this would slow down the communication and the throughput of
xmlblaster dramatically.

So I would intend to proposal 2.

We would get the opportunity to subscrib(e) to a message independently of
it's mimeType.

What dou you think?

How would one expect a MOM (or xmlBlaster) working in this case?

Any ideas?

Marcel, am I correct?


regards

Heinrich




On Sun, 6 May 2001, Heinrich Götzger wrote:

>Heinrich Götzger wrote:
>>
>> Hi
>>
>> in my little application, which uses pub/sub of xmlBlaster, I try
>>topublish and subscrib (this typo is by purpose, since s u b s c r i b e
>>is a key word for majordomo and makes this eMail not being deliverd :-)
>>jpg-imges and text. If text is published, all things going fine.
>>
>> But if I try to publish an jpg-image, somehow the MimeType turns from
>> image/jpg at the publisher to text/plain at the subscriber within the
>same
>> message.
>
>I just tried the following (starting xmlBlaster and sending/receiving
>a binary image):
>
>1. java org.xmlBlaster.Main
>
>2. jaco org.xmlBlaster.client.feeder.PublishFile
>        -c MyTest.gif
>        -xmlKey "<key oid='MyTest.gif' contentMime='image/gif'
>contentMimeExtended='Version1.0'><TestTag></TestTag></key>"
>        -xmlQos "<qos><isDurable/><ForceUpdate/></qos>"
>
>3. java org.xmlBlaster.client.reader.SubscribeMessage
>        -name Tim
>        -passwd secret
>        -oid MyTest.gif
>
>and all works fine.
>
>>
>> Any ideas?
>
>How can i reproduce your problem?
>
>>
>> In the example in xmlBlaster/src/java/org/xmlBlaster/client/feeder the
>> xmlKey is set to "<key oid=\"MyTest.gif\" ...
>> In my App I'm setting the xmlKey to an unique value, does this make
>> a difference?
>
>\"MyTest.gif\" is unique as well, if you don't reuse this
>oid for another message.
>
>>
>> Would I need the contentMimeExtended=\"Version1.0\" attribute?
>
>It is additional information for the receiver only,
>if the receiver is not interested in such information
>just don't send it (xmlBlaster does not care at all).
>
>best regards,
>
>Marcel
>
>--
>Marcel Ruff
>mailto:ruff at swand.lake.de
>http://www.lake.de/home/lake/swand/
>http://www.xmlBlaster.org
>
>
>PS
>this is the answer Marcel send to me personally..... (10 days ago ....)
>