www.f-in-box.com

I have a need to store a file that contains data generated from flash. The length of the data is arbitary.

If I use external interfaces, Flash tries to be "smart" about the data and attempts to type it prior to delivering to the external interface, resulting in a mess.

I don't have a problem book-keeping the actual type of the object and if necessary re-casting the object when flash wants to load it, but I can't find an easy way to handle creating a storage mechanism.

Poking around the source, it appears that I may be able to intercept CreateURLMoniker-- assuming that flash calls it internally. Would that be a decent path to take?

Any other suggestions?

Thank you for your question.

CreateURLMoniker is called when Flash tries to load something using URL.

Could you please explain me this moment:

If I use external interfaces, Flash tries to be "smart" about the data and attempts to type it prior to delivering to the external interface, resulting in a mess.

Easiest explanation-- if I pass "foo" as an argument in an external interface, Flash sends it to the host as "<string>foo</foo>". If I pass a complex object, then Flash attempts to serialize it. If that object contains binary data, such as a bytearray, then all bets are off. If we encode that binary data with Base64, then it's better-- but it takes more memory.

We are now successfully intercepting flash.net.URLRequest from FiB, but still analyzing the payload of the com object so we can find the actual raw HTTP request. We have the source code, but it's slow going.

Since we are going to be dealing with data up to 20MB, I think it is a better approach to intercept an HTTP post than to use an external interface.

It also appears that we may be able to define our own URL "handler" eventually.

Thanks for a great product!