zrzm0111@helpdesk.rus.uni-stuttgart.de (MUFTI) (02/12/91)
Hi ! What about a discussion about Fileformats in future comp.sys.acorn ? On Acorn Archimedes there are many Archiving and uuencode/uudecode-Programms. I am not sure, that all are compatible (e.g. is Spark 1.0 compatible to Spark 2.11 ?). What about using standart archiving and uudecodeing programs ? Do you know the feeling: I have 10 Dearchiveing und uudecoding programs but I need the 11. ? Here are what I think, that this archiving and uudecodeing programs sould be: 1) Public-domain in De- and en-coding. (so everyone can post in a legal way) 2) Compress the Data effectiv (low costs) 3) produce readable code (then it can be transmitted without errors) 4) compatible to MSDOS- and/or UNIX- standarts (so you can decode the files on the Networkcomputer (which are most no Archimedes) and some network-servers ,twice standarts are always good) 5) archiving a hole directory-structure. so long J. Scheurich
dhmyrdal@lise.unit.no (Dag H}kon Myrdal) (02/12/91)
In article <1991Feb12.141244.29483@rusmv1.rus.uni-stuttgart.de> zrzm0111@helpdesk.rus.uni-stuttgart.de (MUFTI) writes: >Hi ! > >What about a discussion about Fileformats in future comp.sys.acorn ? >On Acorn Archimedes there are many Archiving and uuencode/uudecode-Programms. >I am not sure, that all are compatible (e.g. is Spark 1.0 compatible to >Spark 2.11 ?). >What about using standart archiving and uudecodeing programs ? >Do you know the feeling: I have 10 Dearchiveing und uudecoding programs but >I need the 11. ? > >Here are what I think, that this archiving and uudecodeing programs sould >be: > >1) Public-domain in De- and en-coding. (so everyone can post in a legal way) > >2) Compress the Data effectiv (low costs) > >3) produce readable code (then it can be transmitted without errors) > >4) compatible to MSDOS- and/or UNIX- standarts (so you can decode the files > on the Networkcomputer (which are most no Archimedes) and some network-servers > ,twice standarts are always good) > >5) archiving a hole directory-structure. > >so long >J. Scheurich Newsgroups: comp.sys.acorn Subject: Re: what about a discussion about standart fileformats when posting to comp.sys.binaries in future ? Summary: Expires: References: <1991Feb12.141244.29483@rusmv1.rus.uni-stuttgart.de> Sender: Followup-To: Distribution: Organization: University of Trondheim In article <1991Feb12.141244.29483@rusmv1.rus.uni-stuttgart.de> zrzm0111@helpdesk.rus.uni-stuttgart.de (MUFTI) writes: >Hi ! > >What about a discussion about Fileformats in future comp.sys.acorn ? [....]~ >so long >J. Scheurich All very good, but you forget the things that have made !Spark and the dearchiver !SparkPlug popular: 1- Ease of use; can be used from within deskktop, without any hassle 2- both compression AND uuencoding in ONE program, making it possible to have reasonable small, "pure ASCII" files 3- Most important: you don't have to set the filetypes; this file-info is stored within the archive... The third thing is also the one that has caused problems regarding the use of !Spark... David Pilling has chosen a way of coding directory-structures and filetypes that is *not* compatible with standard 'arc'. But surely, someone should be able to do that a better way??? How about storing filetypes the same way as one uses the opposite way for extensions? To store a filetype in a archive, you could save the filetype as the last part of the filename, having an option on the archimedes side on whether to treat the files as archimedes or 'standard' files.. Also, how does Fil's !Submit program develop? Is it ready for use? --Dag
pcolmer@acorn.co.uk (Philip Colmer) (02/13/91)
In article <1991Feb12.153527.27416@ugle.unit.no> dhmyrdal@lise.unit.no (Dag H}kon Myrdal) writes: > [Stuff about pros and cons and requirements of file encoding deleted] > >The third thing is also the one that has caused problems regarding >the use of !Spark... David Pilling has chosen a way of coding >directory-structures and filetypes that is *not* compatible >with standard 'arc'. But surely, someone should be able to >do that a better way??? How about storing filetypes the >same way as one uses the opposite way for extensions? To store >a filetype in a archive, you could save the filetype as the >last part of the filename, having an option on the archimedes side >on whether to treat the files as archimedes or 'standard' files.. My !Submit/!Extract, which use Frank Lancaster's port of tar, get around this problem by holding a script file in the archive which goes around setting the load & exec addresses afterwards :-). Cheap, cheerful and it works. It means that the tar files are then fully UNIX compatible. >Also, how does Fil's !Submit program develop? Is it ready for >use? I haven't done ANYTHING to it since the last release. I was intending to make the necessary changes to make it work with the latest version of tar, and also to include some of the suggestions that people of made. Personally, I feel it is BETTER than !Spark as far as posting large binaries goes, because it copes with people dropping multiple articles on it. With !Spark, you need to cut all the headers and footers out first. However, I won't spend any time progressing this project unless people want it and are going to adopt it in favour of Spark. It simply isn't worth my time. Incidentally, I would suggest that once we *have* got comp.binaries.acorn, a copy of !SparkPlug (or whatever extractor is required) is posted regularly (about once a month). This solves the major problem straight away - the availability of the required extractor. Of course, it needs to be posted in a form that can be extracted ... --Fil. ------------------------------------------------------------------------------ Hi, I'm Pisces. I just dive right in ...