>For example, I've recently learned of the difficulty of moving files >between machines. Headers are a wonderful thing. Would you prefer to have >zip file attachments that are MIME encoded, or a proprietary attachment >system that will allow you to transfer files with header info? (I would >open up the source of this to anyone wanting to write an FTP client too)
I don't know enough about the technicalities of what goes on in an email program to answer directly. What I would like is that zipped files come out of the user end just like they do from say Outlook Express - i.e. once saved I can unzip them on either my PC or QL system. If you go for a proprietary system, I presume it'd be something along the lines of my QH system - a small extra file or appended bytes in the encoded attachment containing just the lost job header (dataspace 4 bytes) so that one could SEXEC the file by using the dataspace information appended, equivalent of: SEXEC job_filename$,LEN(job_filename$),base_address,dataspace_bytes If the file type byte was also sent, it would also allow Relocatables (S-ROFF) files, or Type 2 files, to be sent. So 6 extra encoded bytes would send the minimum file header information with the file if it's not a zipped (or other archived) file. Alternatively, of course, it might not be too much extra work to send the full file header encoded with the file. Perhaps it could be encoded in such a way that if no job header is sent, it would default to decoding just like any other attachment in any email client. Inside a zip file of course, the job still has its header, it's only lost when unzipped to a DOS disk. Unzip it to a QL floppy or Qubide hard disk or QXL.WIN on a QXL using QL Unzip and header remains there. While I have no qualms with how the zip file is encoded (may be better to use same system as the rest of the world), it might be good to be able to attach QL executable jobs. >What kind of features not already in common use would give a QL email >client higher utility value? The ability to send a QL job or SROFF file unzipped I guess. And ability to show QL picture files (screens and pointer environment PICs) at the user end, or facility to call up a viewer program like pqiv or Photon or Photo-QL to do the picture display. Alternatively, facility to allow the email client to take use of FileInfo II filename associations if present. FI2 allows you to specify which program loads which type of file, e.g. _bas files sent to BASIC, _JPG files sent to Photon, _TXT files sent to your favourite editor, rather like Windows file associations. Not suggesting for one moment we let that word rule our lives, but... I have been longing for a QL email and internet access system for ages, but I do not use uQLx (currently the only QL platform with a finished TCP/IP system) - if I can help to Beta-test or whatever I'd be happy to try to help. -- Dilwyn Jones [EMAIL PROTECTED] http://www.soft.net.uk/dj/index.html
