ZLib.pac in WebStart

Andy,

I looked briefly at WebStart when you first announced it.  Very cool.  I
have a question related to your zlib wrapper though.

I need to be able to call some zlib/minizip stuff from a Dolphin app
(other than what you wrapped) and am not quite sure of the best way to
go about it.

I think I can take what you've done and manually add in the other APIs I
need.  However, I'm not sure if that's the best way to do it.

I've read the stuff on the Wiki about using IDL to generate a type
library that you can then use with the TypeLibraryAnalyzer, but am still
not completely clear on how to do that.

Could you walk me through the steps you went through to get there?  If
you went the IDL route, would you be willing/able to share the IDL file
you used?

I'm assuming that there are no licensing/copyright restrictions on
taking (my enhancement of) that package and incorporating it into my
application.  Is that correct?

Thanks,
Randy
--
Randy Coulman
NOTE: Reply-to: address is spam-guarded.  Reassemble the following to
reply directly:
rcoulman at charter dot net

Randy Coulman wrote:

> I need to be able to call some zlib/minizip stuff from a Dolphin app
> (other than what you wrapped) and am not quite sure of the best way to
> go about it.

I don't know if it's any help, or even relevant, but I've been putting together
some fairly complete wrappers for the zlib1.dll (the /offical/ build and
configuration of zlib for Windows ;-).  That includes the ability to manipulate
Zip files directly in memory (rather than having to extract to temporary
files), and some proper stream-oriented wrappers for the compression stuff.

In due course I intend to add it to my website (in fact it will be used to
/create/ the next iteration of the website).

It's currently very new.  I've been using the reader for some time, but the
writer is still very pre-alpha.  Still, if you'd like a pre-release look at it,
then feel free to drop me a line.

    -- chris

Chris Uppal wrote:
>
> I don't know if it's any help, or even relevant, but I've been putting together
> some fairly complete wrappers for the zlib1.dll (the /offical/ build and
> configuration of zlib for Windows ;-).  That includes the ability to manipulate
> Zip files directly in memory (rather than having to extract to temporary
> files), and some proper stream-oriented wrappers for the compression stuff.
>

Sounds good.  How are you generating the wrappers?  By hand, or using
the IDL trick?

>
> It's currently very new.  I've been using the reader for some time, but the
> writer is still very pre-alpha.  Still, if you'd like a pre-release look at it,
> then feel free to drop me a line.
>

For my current project, all I need to be able to do is zip up a single
file, so I need the writing part.  Thanks for the offer, though.  If
anything changes and I find I need more of what you've got ready and
solid, I'll let you know.

Randy
--
Randy Coulman
NOTE: Reply-to: address is spam-guarded.  Reassemble the following to
reply directly:
rcoulman at charter dot net

Randy Coulman wrote:

> > I don't know if it's any help, or even relevant, but I've been putting
> > together some fairly complete wrappers for the zlib1.dll [...]
>
> Sounds good.  How are you generating the wrappers?  By hand, or using
> the IDL trick?

I did wrappers for the zlib1.dll functions by hand.  It was a bit tedious, but
I had no desire to mess with IDL, and it did give me an opportunity to think
about the functions I was wrapping as I did it (I hadn't worked with zlib
before).

Wittering on about wrapper generation: one time when I needed to generate a lot
(>300) of methods I used an intermediate form and auto-generated Smalltalk code
from that.  On that occasion, the intermediate form was just Smalltalk
structures that themselves were generated by hand-written code (there were many
"intelligent" decisions that had to be made about how the 'C' representation
should be translated into Smalltalk), but I think that if I were in that
position again, I'd try going via an XML representation. Some time ago, Blair
posted a link to a nice little application based on the GNU C/C++ compiler that
took C/C++ source and emitted an XML description of the interfaces.  I think
that'd be my starting point.

The Zip file handling itself isn't a wrapper, its done directly in Smalltalk --
after looking for ages for a free Zip file library that wasn't totally
file-oriented, I gave up and wrote my own.  The only difficult parts were the
compression (which is handled very nicely for me by zlib) and creating a
half-decent object model of such a weird format -- and having a handy DLL to
wrap wouldn't have helped with that.  And, of course, the
compressing/decompressing Stream interface to zlib is all in Smalltalk -- the
zlib API itself is not something I'd want to use "raw" in an application, so
that needs a fair bit of wrapping before it can be used as (mostly) just a
fit-and-forget Stream.


> For my current project, all I need to be able to do is zip up a single
> file, so I need the writing part.  Thanks for the offer, though.  If
> anything changes and I find I need more of what you've got ready and
> solid, I'll let you know.

It's currently "complete", and *apparently* working, but I haven't made any use
of the writer-side in other projects yet, nor tested it against more than a
couple of independent decoders.  I'll probably be confident enough of it to
"publish" it on my website in a couple of weeks.  (But then -- as a hobbyist --
I'm *allowed* to make totally unreasonable predictions of delivery dates, *and*
to overrun such dates by huge margins.  A freedom of which I often avail
myself....)

    -- chris

Chris,

> The Zip file handling itself isn't a wrapper, its done directly in
Smalltalk --
> after looking for ages for a free Zip file library that wasn't totally
> file-oriented, I gave up and wrote my own.  The only difficult parts were
the
> compression (which is handled very nicely for me by zlib) and creating a
> half-decent object model of such a weird format -- and having a handy DLL
to
> wrap wouldn't have helped with that.  And, of course, the
> compressing/decompressing Stream interface to zlib is all in Smalltalk --
the
> zlib API itself is not something I'd want to use "raw" in an application,
so
> that needs a fair bit of wrapping before it can be used as (mostly) just a
> fit-and-forget Stream.

This sounds great.  We are suffering a slight embarrasment of riches with
respect to wrappers, but any wrapper with stream support beats mine, and is
greatly appreciated.  I have a few loose methods (#asZCompressedBuffer,
etc.)  that you are welcome to include in your package, or I can always keep
them in an "adapter package" of my own.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,

> This sounds great.  We are suffering a slight embarrasment of riches with
> respect to wrappers

Of zlib, yes.  Besides your stuff, there's a wrapper of an ActiveX zlib (or was
it Zip?) component somewhere (sorry, I've forgotten where -- I didn't look at
it because I don't like using ActiveX components unless I *have* to), and STS
includes a (very limited) wrapper too.

I wanted real *incremental* streams that wouldn't necessarily involve holding
all the data in memory at one time.  (I have in the past needed to deal with
GBytes of data on a routine basis, and that leaves a mark on your thinking)  I
also wanted access to the more general facilites of zlib, such as 'raw' and
'gzip' compession formats.  ('raw' is used in Zip files, 'gzip' is often used
in HTTP)

> I have a few loose methods (#asZCompressedBuffer,
> etc.)  that you are welcome to include in your package,

I've already got a few similar loose methods, thanks.  In fact I may remove
them before I publish, since they are really just examples of how to use
streams, and -- as such -- I'm not sure they earn their keep as *loose*
methods.  I mean, how much value does:

============
    ByteArray>>compressed
        ^ (DeflaterWriteStream forBinaryOn: ByteArray writeStream)
              nextPutAll: self;
              contents.
============

really add ? ;-)

    -- chris

Randy,

> I looked briefly at WebStart when you first announced it.  Very cool.
> I have a question related to your zlib wrapper though.
>
> I need to be able to call some zlib/minizip stuff from a Dolphin app
> (other than what you wrapped) and am not quite sure of the best way
> to go about it.
>
> I think I can take what you've done and manually add in the other
> APIs I need.  However, I'm not sure if that's the best way to do it.

Actually, Blair quickly knocked up the ZLib wrapper for me. Apparently
he did it manually (i.e. without creating the IDL) because the number
of functions we needed for the demo was so small. He did point out,
though, that if he was going to wrap the entire library then he'd use
the IDL method. So, unfortunately, we haven't got any IDL we can share
with you :(
 
> I've read the stuff on the Wiki about using IDL to generate a type
> library that you can then use with the TypeLibraryAnalyzer, but am
> still not completely clear on how to do that.

I assume you've seen this page:

http://www.object-arts.co.uk/wiki/html/Dolphin/CreatingTLBfromaCheaderFi
le.htm

If you have any specific questions then post them up here and we'll try
to help.

> I'm assuming that there are no licensing/copyright restrictions on
> taking (my enhancement of) that package and incorporating it into my
> application.  Is that correct?

That's correct, use it how you wish.

Best regards,

Andy Bower
Dolphin Support
www.object-arts.com

Chris,

> Of zlib, yes.  Besides your stuff, there's a wrapper of an ActiveX zlib (or was
> it Zip?) component somewhere (sorry, I've forgotten where -- I didn't look at
> it because I don't like using ActiveX components unless I *have* to),

No argument there.  Well, there is the ease with which the type library
analyzer writes everything.  The down sides are speed, (in many cases)
reliability, and ease of installation.


 > and STS
> includes a (very limited) wrapper too.

I didn't know about that one.  Perhaps it's time we all pooled our
resources???


> I wanted real *incremental* streams that wouldn't necessarily involve holding
> all the data in memory at one time.  

Thanks for doing this!  It was on my "I really should someday" list, but
  I could never justify taking time away from the "I really needed to
last week" list :)



Fair enough, but I have many uses of #asZCopmpressedBuffer, largely to
compensate for the fact that I never took the time to wrap stream
compression, but they exist just the same.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Andy Bower wrote:
>
> Actually, Blair quickly knocked up the ZLib wrapper for me. Apparently
> he did it manually (i.e. without creating the IDL) because the number
> of functions we needed for the demo was so small. He did point out,
> though, that if he was going to wrap the entire library then he'd use
> the IDL method. So, unfortunately, we haven't got any IDL we can share
> with you :(
>  

No problem.  I can add wrappers for the functions I need pretty easily,
I think (now that I've looked at it more closely).

Yes, this is the page I was thinking of.

>
>>I'm assuming that there are no licensing/copyright restrictions on
>>taking (my enhancement of) that package and incorporating it into my
>>application.  Is that correct?
>
>
> That's correct, use it how you wish.
>

Are you planning to make it part of the base eventually (or even as a
downloadable add-on)?  If so, I'll be happy to contribute my additions
back when I'm done.

Thanks for the help,
Randy
--
Randy Coulman
NOTE: Reply-to: address is spam-guarded.  Reassemble the following to
reply directly:
rcoulman at charter dot net