Page 1 of 1

MimeStreams for neobook?

PostPosted: Sat Mar 25, 2006 8:07 am
by HPW
A follow-up of this discussion:

http://www.neosoftware.com/forum/viewtopic.php?t=13883

Neobook has string-typed variables.
The internet is based on Text.
The internet handles binary data through Mime-encoding.
Neobook's scripting can not handle binary data. Really?

Think simple and make the binary data to text and neobook can handle them.

Code: Select all
Conzept for future neobook updates:

Support for such stream-content usable in neobook Standard-objects:

[MimeStreamed]Test.BMP

Can use internal the following generic variables:

[Test.bmp.MimeStreamContent]          Mime-Characterstream-string
[Test.bmp.MimeStreamCreator]          "hpwImage"
[Test.bmp.MimeStreamType]             "Bitmap"
[Test.bmp.MimeStreamLength]           "165798"


Optional type-specific variables possible:

Type: "Bitmap"

[Test.bmp.Width]      "640"
[Test.bmp.Height]      "480"


This is not only a hypothetical conzept, starting with upcoming hpwImage 2.11 I will use this conzept for communication between 2 plugin-instances or 2 different plugins. Everywhere the user does not want to use file/clipboard, he can use neobook variables to secure share digital content between plugins. When neobook would support this conzept in future releases it would even possible to feed content back into standard objects on runtime.

Re: MimeStreams for neobook?

PostPosted: Sat Mar 25, 2006 11:49 am
by dpayer
HPW wrote:This is not only a hypothetical conzept, starting with upcoming hpwImage 2.11 I will use this conzept for communication between 2 plugin-instances or 2 different plugins. Everywhere the user does not want to use file/clipboard, he can use neobook variables to secure share digital content between plugins. When neobook would support this conzept in future releases it would even possible to feed content back into standard objects on runtime.


Help me understand what you are attempting to do.

Binary data *if converted to text using MIME* would be useable in NB components/objects. Are you saying, for example, you could have the mime representation of a graphic, manipulate it in one program and have that representation accepted / displayed in another?

I assume you are talking about something more than simply converting to text via mime and then transfering here and there.

David P.

PostPosted: Sat Mar 25, 2006 3:07 pm
by HPW
Binary data *if converted to text using MIME* would be useable in NB components/objects. Are you saying, for example, you could have the mime representation of a graphic, manipulate it in one program and have that representation accepted / displayed in another?


Yes, when all plugins/neobook-core use the the same LoadFromStream/SaveToStream. Only for the storage in neobook the streams are converted to a MIME-stream to be stored in a neobook string variable. When neosoft implements the the decode-method like they did for [Embedded] files than it could be even used in NB objects.

Edit: Changed 'programs' to 'plugins/neobook-core' because it use the neobook variable space of the running main-neobook app.

PostPosted: Wed Mar 29, 2006 12:20 am
by HPW
Another improvement to this conzept would be:

neobookDB gets a command to prevent the temp-writing of picture/blob fields to disk.

neobookDB gets a command 'dbfExportMimeStream' to export to variable.


Then standard objects and plugins could load content secure from DBF to memory.

PostPosted: Wed Mar 29, 2006 6:07 am
by Gaev
Hans-Peter:

If my understanding is correct, MIME consists of 2 parts ...

a) Conversion of binary data to/from Base64 representation

b) Some metadata to inform the "Base64 to Binary Conversion" program what the resulting binary data represents (bmp, jpg, wav, swf, zip, exe etc.)


Assuming that the NeoBook variable can contain data to accomodate very large images/video etc. (Base64 data takes up 33% more bytes than its binary format), then is the real important part of your suggestion to be able to ...

i) have NeoBook objects accept one additional type of input viz. [variables] containing Base64 encoded data e.g. Picture Object can display ...

- "c:\abc.jpg"
or
- "[Embedded]abc.jpg"
or
- "[thisFile]" ... where [thisFile] contains the value "c:\abc.jpg"
or
- new addition ... something like ".jpg@[thisBase64Data]" ...where [thisBase64Data] contains the binary to Base64 converted data for a jpg format file


ii) perhaps provide commands like ...

- Base64ToBinary "[thisBase64Data]" "c:\xyz.png"

- BinaryToBase64 "c:\xyz.png" "[thisBase64Data]" ... could include BinaryToBase64 "[Embedded]xyz.png" "[thisBase64Data]"

Would be a lot less work for NeoSoft if NeoBook's role was limited to such base functionality ... rather than get into support for a (new) non-flat memory structure ... and assign responsibility for handling mime type info (for base64 data in variables) to script developers and plug-ins e.g. ...

abcPlugIn_DoXYZ "Rectangle99" ".jpg@[thisBase64Data]" "other param1" "other param2"

... or am I missing something in your request ?


Separate Discussion:

When you traverse a dbf with Picture fields, the file represented by the Picture Field's content in the CURRENT record is placed on disk ... but only temporarily (until the next record is accessed) ... and with a randomly generated file name ... hence, dbfExportPicture provides an opportunity for developer to "save this file in another (more permanent) location on disk.

But your suggestion for developers to be able to direct NeoBookDB to "destination" of Picture Field data ... temp file, [variable] (Base64) .. or even "none" (when data is not needed for current application) ... has merit e.g. ...

dbfSetPictureDestination "dbfAlias" "Picture Field Name" "file|variable|none"

... and if ...

dbfSetPictureDestination "myDbf" "myPicture" "variable"

... [myDbf.myPicture] would contain the contents of the field for the current record (in Base64 format).

PostPosted: Wed Mar 29, 2006 6:53 am
by HPW
Gaev,

If my understanding is correct, MIME consists of 2 parts ...
a) Conversion of binary data to/from Base64 representation
b) Some metadata to inform the "Base64 to Binary Conversion" program what the resulting binary data represents (bmp, jpg, wav, swf, zip, exe etc.)


Pure MIME is only a.
The new conzept of integration would be b.

Assuming that the NeoBook variable can contain data to accomodate very large images/video etc. (Base64 data takes up 33% more bytes than its binary format), then is the real important part of your suggestion to be able to ...

i) have NeoBook objects accept one additional type of input viz. [variables] containing Base64 encoded data e.g. Picture Object can display ...

- "c:\abc.jpg"
or
- "[Embedded]abc.jpg"
or
- "[thisFile]" ... where [thisFile] contains the value "c:\abc.jpg"
or
- new addition ... something like ".jpg@[thisBase64Data]" ...where [thisBase64Data] contains the binary to Base64 converted data for a jpg format file


That was what I was suggesting:
[Test.bmp.MimeStreamContent] Mime-Characterstream-string

That variable alone let the reader code know that it is MIME and
what type of bitmap.
Also I made test with BMP format and the whole hpwImage bitmap
producing a 1 MB of MIME with no problems or performance-hogs.
The better use is of cource PNG, because of it's smarter compression.
(You can test yourself)

This was only addon info for later use:
[Test.bmp.MimeStreamCreator] "hpwImage"
[Test.bmp.MimeStreamType] "Bitmap"
[Test.bmp.MimeStreamLength] "165798"

ii) perhaps provide commands like ...

- Base64ToBinary "[thisBase64Data]" "c:\xyz.png"

- BinaryToBase64 "c:\xyz.png" "[thisBase64Data]" ... could include BinaryToBase64 "[Embedded]xyz.png" "[thisBase64Data]"


No Problem. Easy to implement!

Would be a lot less work for NeoSoft if NeoBook's role was limited to such base functionality ... rather than get into support for a (new) non-flat memory structure ... and assign responsibility for handling mime type info (for base64 data in variables) to script developers and plug-ins e.g. ...


This is a flat memory structure and it is not new.
The only thing for neosoft is to detect that it is MIME and to decode it.
Then it is a simple 'LoadFromStream' which is already done in [Embedded] import code.


Separate Discussion:

When you traverse a dbf with Picture fields, the file represented by the Picture Field's content in the CURRENT record is placed on disk ... but only temporarily (until the next record is accessed) ... and with a randomly generated file name ... hence, dbfExportPicture provides an opportunity for developer to "save this file in another (more permanent) location on disk.

But your suggestion for developers to be able to direct NeoBookDB to "destination" of Picture Field data ... temp file, [variable] (Base64) .. or even "none" (when data is not needed for current application) ... has merit e.g. ...


My vote was meant to get direct memory-access to the BLOB-field.
And from there everywhere you can think of.

And when this could not be implemented, you still have the second
choice: Take the MIME-stream put it in a memo-filed and we have stored a picture and have it in memory. ;-)

PostPosted: Wed Mar 29, 2006 7:43 am
by Gaev
Hans-Peter:

Looks like we are talking about "different ways of skinning a Cat" ... :shock: ... an eCat of course ... in case Animal lovers are reading this.

I am in all in favour of loading objects from memory variables instead of (exposed) files on disk.

As far as my comment about "Assuming that the NeoBook variable can contain data to accomodate very large images/video etc", my only point was that ... one needs to be aware that the theoretical maximum size of the content of a variable (whatever that is) might fall short of the Base64 representation of a humungous file ... perhaps not a static image ... but a video stream or library of executable functions or zip file etc. ... probably not a concern to most NeoBook developers.

PostPosted: Wed Mar 29, 2006 8:42 am
by HPW
Gaev,

Agree to your comments.

So similar to my standard quote:

Use the right place to store the stuff to get the job done!
:lol:

PostPosted: Mon Aug 20, 2007 12:06 pm
by HPW
Added support for MimeStreams in hpwUtility:

hpwScreenShot - Now supports mime-streams with BMP/PNG/JPG.

Sample:
Code: Select all
hpwScreenShot "[TX1]" "[TY1]" "[TX2]" "[TY2]" "mimestream:\\\TESTSHOT1.PNG"

PostPosted: Mon Aug 20, 2007 3:04 pm
by Neosoft Support
This is a very interesting idea. It might be beyond the comprehension of many novice users, but still interesting.

HPW, are you using a library to perform the mime/binary conversion?

PostPosted: Mon Aug 20, 2007 10:42 pm
by HPW
Every MIME-package should support the standard encoding.

I use DIMime.
DIMime is part of the Jedi Code Library (JCL).

Separate download:
http://www.yunqa.de/delphi/mime/index.htm

It is pretty fast and stable.

Support for this in neobook's own object would be a real enhancement.
Now it is a working option to interchange binary data between plugins without storing on the filesystem and using the neobook scripting memory.

PostPosted: Tue Aug 21, 2007 11:33 am
by Neosoft Support
Thanks Hans-Peter. I will look into it.

PostPosted: Mon Jan 26, 2009 12:30 pm
by HPW
hpwImage 2.30 now supports loading a custom cursor from mimestream:

http://www.neosoftware.com/forum/viewto ... &start=165

SetVar "[MimeStream]" "mimestream:\\\"


This variable is used similar to the [Embedded] variable.