Import and export zip packages of content where binaries not embedded as base64 encoded character data inside the xml but as separate files

When you export content including big binaries (image or asset) in CMS
Console, you could meet OutOfMemoryError because the exporting process
tries to convert the binary data into BASE64 encoded string in memory.

The current way cannot avoid this risk without changing the way of
binary inclusion in XML.

So, I tried to figure out what kind of improvements we can make in this
area to avoid this risk in the future.
My idea is to have a hippo specific property which contains the link
of the binary file instead of having to convert binary data into base64
all the time.

For example, an asset could possibly be written like the following:

<sv:node sv:name="hippogallery:asset">
<sv:property sv:name="jcr:primaryType" sv:type="Name">
<sv:value>hippo:resource</sv:value>
</sv:property>
<sv:property sv:name="hippo:text" sv:type="Binary">
<sv:value>blahblah==</sv:value>
</sv:property>
<sv:property sv:name="hippo:import" sv:type="String">

<sv:value>binaries/8ae65bcb-c04c-45ec-b321-51ff9ced3484.pdf</sv:value>
</sv:property>
<sv:property sv:name="jcr:data" sv:type="Binary">
<sv:value/>
</sv:property>
<sv:property sv:name="jcr:lastModified" sv:type="Date">
<sv:value>2013-08-26T22:46:09.509-04:00</sv:value>
</sv:property>
<sv:property sv:name="jcr:mimeType" sv:type="String">
<sv:value>application/pdf</sv:value>
</sv:property>
</sv:node>

My idea is to introduce 'hippo:import' (string) property which just
contains the (context relative) link to the physical binary file.
So, when importing, if it reads the property, then it just reads the
data from the file when importing with ignoring the 'jcr:data'.

The CMS Console UI should somehow handle this. e.g, downloading xml + binary files in ZIP file format and handle the uploaded tar file maybe.