CompressedFilename
Locked
 
|
hi. I wonder if somebody has the following animal:
a wrapper on Filename to the purpose that clients would not know whether they were working with a compressed file or not. Parcel>>> loadFrom: aSource where aSource is aFilename. a usage: Parcel loadFrom: 'myParcel.pcl' asCompressedFilename this animal i.e. the compressedFilename would provide a Filename interface but would be able to handle using a compressed file as its source. It probably entails building a CompressedFileConnection. in the example above the Parcel class is unaware that it is using a compressed file. The code calling above of course does but that is good enough. Filename could of course be extended to use a convention where certain extensions entail creating CompressedFilename(s)but that would be icing. My immediate need is to load parcel files that have been compressed using VW's compression classes however I do envision doing more of this aside from Parcel loading so I don't want to just equip Parcel with said capabilities. It seems to be a generic need so perhaps its available somewhere or somebody has something we clean up and put in the repository. thanks -- Charles A. Monteiro |
|
|
In my application I can save application files as plain ASCII or
compressed depending on settings. I did not want to introduce new file extensions so I worked around this as follow: when I need to read my app. data from file I have a method like: getTheStreamOnFile: fname | readStream input readStreamX | input := fname asFilename readStream binary. [readStreamX := OS.ZLib.GZipReadStream on: input. readStream := readStreamX text] on: Error do: [:ex | input close. readStream := fname asFilename readStream lineEndAuto]. ^readStream Gzip reads a file header and then raises an exception the file was not written by my application with the Gzip enabled. It is not very elegant solution but it seem to work so far. Note to the Gzip authors: it would be much more useful if GZipReadStream would raise something like GzipBadHeaderError and not just generic Error --Mark Charles A. Monteiro wrote: > hi. I wonder if somebody has the following animal: > > a wrapper on Filename to the purpose that clients would not know > whether they were working with a compressed file or not. > > Parcel>>> > loadFrom: aSource > > where aSource is aFilename. > > a usage: > > Parcel loadFrom: 'myParcel.pcl' asCompressedFilename > > this animal i.e. the compressedFilename would provide a Filename > interface but would be able to handle using a compressed file as its > source. It probably entails building a CompressedFileConnection. > > in the example above the Parcel class is unaware that it is using a > compressed file. The code calling above of course does but that is good > enough. Filename could of course be extended to use a convention where > certain extensions entail creating CompressedFilename(s)but that would > be icing. > > My immediate need is to load parcel files that have been compressed > using VW's compression classes however I do envision doing more of this > aside from Parcel loading so I don't want to just equip Parcel with > said capabilities. > > It seems to be a generic need so perhaps its available somewhere or > somebody has something we clean up and put in the repository. > > thanks > > |
|
|
I want the transparency.
Take what Windows XP does as an example. One can decide that a certain folder should be set to "compress contents". Applications are unaware that the files are compressed and do nothing special to load them, Windows just does the uncompressing upon the file open request and provides the stream to the uncompressed content -- I assume. But wait, that's my answer why don't I do that? Well, because that does not really help me if I am network launching my app and especially across a VPN. I need the content to come uncompressed to my app i.e. I need to minimize the download times to the clients. Perhaps, I'm wrong if on a Windows network maybe Windows is smart enough to download the files still compressed and do the uncompression on the client. However, that still does not help since although our front-end clients are on Windows PCs our clients are moving to using Linux for file serving as well via Samba. Therefore I need/want a service layer to take care of these issues for me. Whether I use a compressed file or perhaps even an encrypted file these should not be the concerns of my business app. Anyhow, I guess the answer is this animal has not been previously built. -Charles On Thu, 23 Feb 2006 16:40:05 -0500, Mark Pirogovsky <[hidden email]> wrote: > In my application I can save application files as plain ASCII or > compressed depending on settings. > > I did not want to introduce new file extensions so I worked around this > as follow: > > when I need to read my app. data from file I have a method like: > > getTheStreamOnFile: fname > > | readStream input readStreamX | > input := fname asFilename readStream binary. > > [readStreamX := OS.ZLib.GZipReadStream on: input. > readStream := readStreamX text] > on: Error > do: > [:ex | > input close. > readStream := fname asFilename readStream lineEndAuto]. > ^readStream > > > Gzip reads a file header and then raises an exception the file was not > written by my application with the Gzip enabled. > > It is not very elegant solution but it seem to work so far. > > > Note to the Gzip authors: it would be much more useful if GZipReadStream > would raise something like GzipBadHeaderError and not just generic Error > > > --Mark > > > Charles A. Monteiro wrote: > >> hi. I wonder if somebody has the following animal: >> a wrapper on Filename to the purpose that clients would not know >> whether they were working with a compressed file or not. >> Parcel>>> >> loadFrom: aSource >> where aSource is aFilename. >> a usage: >> Parcel loadFrom: 'myParcel.pcl' asCompressedFilename >> this animal i.e. the compressedFilename would provide a Filename >> interface but would be able to handle using a compressed file as its >> source. It probably entails building a CompressedFileConnection. >> in the example above the Parcel class is unaware that it is using a >> compressed file. The code calling above of course does but that is >> good enough. Filename could of course be extended to use a convention >> where certain extensions entail creating CompressedFilename(s)but that >> would be icing. >> My immediate need is to load parcel files that have been compressed >> using VW's compression classes however I do envision doing more of >> this aside from Parcel loading so I don't want to just equip Parcel >> with said capabilities. >> It seems to be a generic need so perhaps its available somewhere or >> somebody has something we clean up and put in the repository. >> thanks >> -- Charles A. Monteiro |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |