[comp.mail.elm] Compressed folders

mike@MARIA.WUSTL.EDU (03/21/91)

Has anyone worked with some way for elm to save/handle compressed folders?

Mike

(mike@maria.wustl.edu)

lou@isc.intel.com (Lou Poehlitz) (03/22/91)

mike@MARIA.WUSTL.EDU writes:


>Has anyone worked with some way for elm to save/handle compressed folders?

>Mike

>(mike@maria.wustl.edu)

No good way exists to do this now.

This is something that would be really helpful.

What I suggest is an elmrc option that allows per folder configuration.

The format could be something like:

folderconfig = "folder1,sort_order,read_program,save_program:\
               folder2,sort_order,read_program,save_program:"

If a folder was not mentioned in folderconfig, it would be treated
like a standard folder, default sort_order, etc.

For a compressed folder, the config would look like

folderconfig = "bigfolder, rev_received, uncompress, compress"

The details would need to worked out.  One might want to allow
other per folder configuration items.

I wish I had time to code it, it would be a great feature for 2.4.

rob@mtdiablo.Concord.CA.US (Rob Bernardo) (03/24/91)

lou@isc.intel.com (Lou Poehlitz) wrote:
>What I suggest is an elmrc option that allows per folder configuration.
>
>The format could be something like:
>
>folderconfig = "folder1,sort_order,read_program,save_program:\
>               folder2,sort_order,read_program,save_program:"
...
>For a compressed folder, the config would look like
>
>folderconfig = "bigfolder, rev_received, uncompress, compress"

One major complication lies with the 'c' command to change folders.
Before it leaves the current folder, it checks for the existence
of the folder to specified. Since some read/save program pairs deal
with suffixed file names (e.g. uncompress/compress deal with .Z),
elm would have to have the name of the folder before the read_program
is applied as well as the name of the folder after the read_program is
applied in order to deal with it.
-- 
Rob Bernardo					Mt. Diablo Software Solutions
email: rob@mtdiablo.Concord.CA.US		phone: (415) 827-4301

chris@vision.uucp (Chris Davies) (03/26/91)

In some article (which doesn't seem to be on this system) mike@MARIA.WUSTL.EDU
writes:
>Has anyone worked with some way for elm to save/handle compressed folders?

There was some code posted a few months ago which allowed a program to read
and write compressed files through the same (sort of) interface as ordinary
files - ie fopen(), fclose()...  Perhaps elm could use this?

The author was Graham Toal <gtoal@ed.ac.uk>.  Newsgroup alt.sources.
Archive-name zlib.shr Article message-id <1422@tharr.UUCP> dated
15 Nov 90 00:59:40 GMT.

An extract from the file follows -
> This implementation supplies 'z' versions of fopen, fputc, feof and fclose
> to be used as direct substitutes for the originals; it would be cleaner
> and more transparent if the decompress filter were hidden under the
> real stdio procedures.  An extra call zfilter() is supplied to convert
> an already-opened stream into a z-stream: see the example at the end
> of this file.
> 
> If a file opened by zfopen() was not compressed, the files contents are
> still recovered correctly at the low expense of an extra procedure call
> per byte.  This makes the routines more generally usable - they can be
> left in production programs which can be speeded up in the field by
> compressing selected input files(*); also, files can be compressed or
> not selectively depending on whether the compression makes them
> smaller or not - code accessing the files does not need to know.

Chris
-- 
VISIONWARE LTD         | UK: chris@vision.uucp    JANET: chris%vision.uucp@ukc
57 Cardigan Lane       | US: chris@vware.mn.org   BANGNET: ...!ukc!vision!chris
LEEDS LS4 2LE, England | VOICE:  +44 532 788858   FAX:  +44 532 304676
-------------- "VisionWare:   The home of DOS/UNIX/X integration" -------------

lou@isc.intel.com (Lou Poehlitz) (03/26/91)

rob@mtdiablo.Concord.CA.US (Rob Bernardo) writes:

>lou@isc.intel.com (Lou Poehlitz) wrote:
>>What I suggest is an elmrc option that allows per folder configuration.
>>
>> text deleted
>>folderconfig = "bigfolder, rev_received, uncompress, compress"

>One major complication lies with the 'c' command to change folders.
>Before it leaves the current folder, it checks for the existence
>of the folder to specified. Since some read/save program pairs deal
>with suffixed file names (e.g. uncompress/compress deal with .Z),
>elm would have to have the name of the folder before the read_program
>is applied as well as the name of the folder after the read_program is
>applied in order to deal with it.

Yes, a good detail point.  It could be dealt with by having the folder
name substituted in for %s.

folderconf = "bigfolder,rev_received,cat %s | uncompress -c,cat %s | compress"

With the proper handling to fd's, I think this could work for having
encrypted folders also.

folderconf = "secret,mailbox_order, crypt < %s , crypt < %s"

The key would be to get the fd that the key is prompted for on mapped to the
terminal in elm.

gary@proa.sv.dg.com (Gary Bridgewater) (03/27/91)

In article <1210@intelisc.isc.intel.com> lou@isc.intel.com (Lou Poehlitz) writes:
>rob@mtdiablo.Concord.CA.US (Rob Bernardo) writes:
> [stuff about compressed and/or crypted folders]

What if the header and body had separate files?  The standard elm folder would
then be the header file with an index into whatever file contained the bodies.
It could have a format like:

    { body file path *OR* command to produce the body file as a stream from stdout}
    {<empty> *OR* command to put the body file back given the data on stdin}
    HEADER1
     byte offset of BODY1 {in ASCII} and size in bytes
    HEADER2
     byte offset of BODY2 and size in bytes
    ...

To keep somewhat of a backward compatibility the first line could also be
<empty> meaning that the body part was "inline" - or if we say that these
special first two line began with some special character then the current
folder format would be recognized by having a first line which did not begin
that way.


If nothing else, separate files would make Cing into a folder go a lot
quicker for BIG folders.
-- 
Gary Bridgewater, Data General Corporation, Sunnyvale California
gary@sv.dg.com or {amdahl,aeras,amdcad}!dgcad!gary
"I am a pizza.  I am a pizza.  ..."

rob@mtdiablo.Concord.CA.US (Rob Bernardo) (03/28/91)

lou@isc.intel.com (Lou Poehlitz) wrote:
>rob@mtdiablo.Concord.CA.US (Rob Bernardo) writes:
>
>>lou@isc.intel.com (Lou Poehlitz) wrote:
>>>What I suggest is an elmrc option that allows per folder configuration.
>>>
>>> text deleted
>>>folderconfig = "bigfolder, rev_received, uncompress, compress"
>
>>One major complication lies with the 'c' command to change folders.
>>Before it leaves the current folder, it checks for the existence
>>of the folder to specified. Since some read/save program pairs deal
>>with suffixed file names (e.g. uncompress/compress deal with .Z),
>>elm would have to have the name of the folder before the read_program
>>is applied as well as the name of the folder after the read_program is
>>applied in order to deal with it.
>
>Yes, a good detail point.  It could be dealt with by having the folder
>name substituted in for %s.
>
>folderconf = "bigfolder,rev_received,cat %s | uncompress -c,cat %s | compress"

That won't work either, btw.  Your example has compress and uncompress
outputting to stdout. What file is elm going to read then?
-- 
Rob Bernardo					Mt. Diablo Software Solutions
email: rob@mtdiablo.Concord.CA.US		phone: (415) 827-4301

ian@ukpoit.co.uk (Ian Spare) (03/29/91)

In article <1991Mar27.013510.15421@proa.sv.dg.com> gary@proa.sv.dg.com (Gary Bridgewater) writes:
>
>
>If nothing else, separate files would make Cing into a folder go a lot
>quicker for BIG folders.
>-- 

I see your point but I'm not sure I'd personally like that. I have cnews (
amongst others ) saving outbound articles and mails to an elm folder. This is
a useful thing to do , OK it's not the end of world if I can't but I do like
it and I'm sure others use that sort of thing.

Some sort of duplication may work though, I haven't tried this ( or even
thought it through !!! ;-) ) but the seperate index could be held duplicating 
the headers , the trick would be to construct that index if it wasn't there or
update it if a test established it was out of date,

Just a thought !! I think in general compressed folders is a good idea and
would help with my users who seem to keep every mail and news item in a 
folder !!

Cheers Ian
-- 
Ian Spare , iT , Barker Lane , CHESTERFIELD , DERBYS , S40 1DY , GREAT BRITAIN

   E-mail : ian@ukpoit.uucp - VOICE : +44 246 214296 - FAX : +44 246 214353