Subject: Re: [netatalk-admins] Stuffit On Linux?
From: Chris Thorman (ct@ignitiondesign.com)
Date: Tue Sep 01 1998 - 17:54:48 EDT
At 5:55 AM -0700 9/1/98, Frank Morton wrote:
>Does anyone know of any linux software that can
>create or unarchive from or to a StuffIt file?
Hi Frank,
I have gone through this question a number of times with Aladdin. After a
few years of occasional pings from me on this issue, Eric Slosser from
Aladdin Engineering finally got back to me in early April of this year and
said they were thinking of making an SDK for Unix.
They polled me on what I thought about the process, and what I thought the
requirements should be. Naturally, I listed netatalk / AppleDouble
compatibility as high on the requirements list.
The entire conversation is included below for the record. I have not heard
anything from them since, but I'd guess they're working on it.
I'll CC Eric on this reply, and hope that he'll do a Reply All so those of
us on the list can get an update straight from him.
-c
------------ Message From Aladdin: -------------------------------------
Date: Wed, 1 Apr 1998 18:31:42 -0800
To: ct@ignitiondesign.com
From: Eric Slosser <slosser@aladdinsys.com>
Subject: Stuffit for Unix
Status:
Dear Chris,
Some time ago, you pinged Aladdin about support for Unix. I'm now
spearheading an effort to provide this, and want to know if you still are
interested, and if so, what your needs are.
Mind if I subject you to a little market research?
-what Unix are you using?
-any other Unix variants you think we should support?
-what form would be best for you?
-a library/API (If so, C, C++, or Java make a difference to you)?
-a pair of command line tools? (like 'unsit')
-what's your minimal/better/best feature set for this thing?
-do you wish to be able to create StuffIt format archives, or just
decompress them?
-Just want to decompress the whole archives, or be able to get a catalog
and decompress selectively?
-price?
-what other formats are you dealing with (zip, hqx, etc)?
-what tools do you use on them?
-would you find it helpful to have a single tool that could do them all?
//---------------------------------------------------------------
Eric Slosser (408) 761-6200
Director of Engineering Aladdin Systems, Inc.
------------ My Reply: -------------------------------------
At 6:31 PM -0800 4/1/98, Eric Slosser wrote:
>Dear Chris,
>
>Some time ago, you pinged Aladdin about support for Unix. I'm now
>spearheading an effort to provide this, and want to know if you still are
>interested, and if so, what your needs are.
Hi Eric,
Yes! I have two projects that need this support -- one on the
decompressing side, and one on the compressing side. (unsit is not helpful
because it only reads 1.5.1 files).
>
>Mind if I subject you to a little market research?
I'd be happy to reply........ see below...
>-what Unix are you using?
Linux and SunOS
>-any other Unix variants you think we should support?
I hate to say that I'm not very familiar with all the different variants.
However, the best thing would be to have as few requirements as possible;
use GNU make and GNU gcc, and use only POSIX-compliant library calls, etc,
if possible.
>-what form would be best for you?
> -a library/API (If so, C, C++, or Java make a difference to you)?
> -a pair of command line tools? (like 'unsit')
I library or API would be nice, especially because then a Perl loadable
module could be made that covered the API, making it accessible from Perl.
C/C++ would be a better implementation language than java, for many
reasons, including the fact that Java is slower, less stable, and less
widely available (at least as of today). I know of one important Linux
variant (Cobalt Microservers) that does not yet support the latest Java
Just-in-Time compiler, so I'd stick with C. You could always later add
Java cover routines that access the native interfaces, analagous to making
a Perl module that accesses the native libraries.
(Personally, both of my relevant projects are in Perl, but may eventually
have C and/or Java components as well, in the future).
However, a simple pair of command-line tools would be adequate for me in
both cases.
>-what's your minimal/better/best feature set for this thing?
The most important thing is that there needs to be a way to add/extract
items from in-memory buffers (in the case of an API) or from STDIN/STDOUT
(in the case of command-line items). I.e. the only options should NOT be
to take the data streams from files on disk, because many times this is
impractical. For example: I want to make an incoming-mail processor that
extracts .sit files (as MIME attachments), then, with the .SIT file in
memory, needs to be able to get a catalog of file contents, and then
extract data (and/or resource) forks into memory buffers, without ever
needing to create a file on disk.
The other most important thing :-) is that there needs to be full support
for Netatalk (the AppleShare implementation for Unix out of UMichigan).
Netatalk is a format where the resource data and other Mac-specific info
for a file called "Foo" is stored in a file called ./.AppleDouble/Foo --
this includes the resource fork, window position, and just a couple of
other variables.
But of course, there should be a way to extract and/or add those info-bits
(including the resource fork) separately from the API/command line tool,
for sites that still need to manipulate that info but may not be using
Netatalk per se.
>-do you wish to be able to create StuffIt format archives, or just
>decompress them?
Really, both would be ideal, as mentioned above. Let me explain a bit
about the application for which I want to CREATE archives, to show you how
compelling I think this is:
I have an image management application that resides on the same Unix server
as an AppleShare volume (using Netatalk). The users upload and download
and move files around from the Mac and/or Windows file sharing using
Netatalk and/or Samba. Then, there's a CGI-based interface that lets them
manipulate the files AND a whole slew of meta-data (project-tracking data)
about the files. They can retrieve the files in a number of ways,
including viewing them in the browser - but one of the most important ways
is via HTTP -- they can just click a link and the file instantly downloads.
Nettalk ships with a utility (see megatron) that my software uses to create
a .bin file on the fly for when the user wants to retrieve a single file --
the cool thing is, by using .bin, ALL of the mac info, including resource
forks, and custom icons, EVERYTHING, comes right onto the user's desktop.
Very very neat. One of the features of the system is that it lets users
build up "deliveries" -- sets of files, in a folder, that have been
selected using the query interface, and then added one at a time or in
groups -- almost like a shopping-cart application. What I then want to be
able to do is have the user just click a link and receive the delivery
folder on the fly, over the CGI interface -- but to do this, I need a
ubiquitous, Mac-aware, archive format (and SIT is the only one), that I can
create on-the-fly on Unix and then deliver as a data stream back to their
browser. So you can see why I am so eager for this.
>-Just want to decompress the whole archives, or be able to get a catalog
>and decompress selectively?
I'd say that selective decompression would be pretty important. Getting a
catalog is crucial -- even if selective decompression weren't provided, it
would be crucial to know which files were going to be (or were already)
decompressed.
>-price?
If I were advising you on this, I'd say: make the decompression free, and
make the compression free for non-commercial use, but have a fee for
commercial customers (say, $200?), and a higher fee for developers such as
myself that want to incorporate it into applications (say, $500?).
>-what other formats are you dealing with (zip, hqx, etc)?
>-what tools do you use on them?
Netatalk already comes with tools for hqx (which, as you know, only
compresses (or expands :-)) one file at a time). There are other Unix
tools for zip, and I already use those.
>-would you find it helpful to have a single tool that could do them all?
Yes, this would be helpful, but not strictly necessary. It would make your
tool more compelling as a product, if it were a universal can=opener the
way it is on the Mac, but since so many other tools are out there, you
could skip those features.
---------
One thing you didn't ask:
> Should there be a GUI version? If so, what GUI?
I don't have a feeling for this since I don't use any Unix GUIs. You may
wish to poll the Unix/Netatalk community with this question. I am on the
netatalk-admins list, and I think that the people there would love to be
asked their opinions on this matter if you think the answer would be
helpful.
My *educated hunch* is that there will be little interest in a Unix GUI
version because this appeals most to people who are using Mac files on Unix
-- and hence most of them are probably like me, using Mac for all GUI
stuff, and Unix for programming (via Telnet) only. I could be wrong,
though.
I am excited to hear that there's some movement on this. Please keep me in
the loop; I'd be happy to review the spec for you before implementation
begins, and to be a beta-tester.
-c
------------------------------------------------------------------------
Chris Thorman ct@ignitiondesign.com
Ignition, Inc. (415) 392-6244 x3
870 Market Street (415) 392-6245 fax
San Francisco, CA 94102 http://ignitiondesign.com
------------------------------------------------------------------------
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:33:13 EST