Source language: Translate to:

MimeStreams for neobook?

Post your suggestions for future versions of NeoBook

Moderator: Neosoft Support

MimeStreams for neobook?

Postby HPW » Sat Mar 25, 2006 8:07 am

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.
Hans-Peter
User avatar
HPW
 
Posts: 2510
Joined: Fri Apr 01, 2005 11:24 pm
Location: Germany

Re: MimeStreams for neobook?

Postby dpayer » Sat Mar 25, 2006 11:49 am

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.
User avatar
dpayer
 
Posts: 1380
Joined: Mon Apr 11, 2005 5:55 am
Location: Iowa - USA

Postby HPW » Sat Mar 25, 2006 3:07 pm

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.
Hans-Peter
User avatar
HPW
 
Posts: 2510
Joined: Fri Apr 01, 2005 11:24 pm
Location: Germany

Postby HPW » Wed Mar 29, 2006 12:20 am

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.
Last edited by HPW on Wed Mar 29, 2006 7:06 am, edited 1 time in total.
Hans-Peter
User avatar
HPW
 
Posts: 2510
Joined: Fri Apr 01, 2005 11:24 pm
Location: Germany

Postby Gaev » Wed Mar 29, 2006 6:07 am

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).
User avatar
Gaev
 
Posts: 3716
Joined: Fri Apr 01, 2005 7:48 am
Location: Toronto, Canada

Postby HPW » Wed Mar 29, 2006 6:53 am

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. ;-)
Hans-Peter
User avatar
HPW
 
Posts: 2510
Joined: Fri Apr 01, 2005 11:24 pm
Location: Germany

Postby Gaev » Wed Mar 29, 2006 7:43 am

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.
User avatar
Gaev
 
Posts: 3716
Joined: Fri Apr 01, 2005 7:48 am
Location: Toronto, Canada

Postby HPW » Wed Mar 29, 2006 8:42 am

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:
Hans-Peter
User avatar
HPW
 
Posts: 2510
Joined: Fri Apr 01, 2005 11:24 pm
Location: Germany

Postby HPW » Mon Aug 20, 2007 12:06 pm

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"
Last edited by HPW on Mon Aug 20, 2007 11:18 pm, edited 1 time in total.
Hans-Peter
User avatar
HPW
 
Posts: 2510
Joined: Fri Apr 01, 2005 11:24 pm
Location: Germany

Postby Neosoft Support » Mon Aug 20, 2007 3:04 pm

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?
NeoSoft Support
Neosoft Support
NeoSoft Team
 
Posts: 5593
Joined: Thu Mar 31, 2005 10:48 pm
Location: Oregon, USA

Postby HPW » Mon Aug 20, 2007 10:42 pm

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.
Hans-Peter
User avatar
HPW
 
Posts: 2510
Joined: Fri Apr 01, 2005 11:24 pm
Location: Germany

Postby Neosoft Support » Tue Aug 21, 2007 11:33 am

Thanks Hans-Peter. I will look into it.
NeoSoft Support
Neosoft Support
NeoSoft Team
 
Posts: 5593
Joined: Thu Mar 31, 2005 10:48 pm
Location: Oregon, USA

Postby HPW » Mon Jan 26, 2009 12:30 pm

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.
Hans-Peter
User avatar
HPW
 
Posts: 2510
Joined: Fri Apr 01, 2005 11:24 pm
Location: Germany


Return to NeoBook Suggestions

Who is online

Users browsing this forum: Bing [Bot] and 0 guests

cron