I missed this thread because of being in hospital after a mountain bike accident. I'm now recovered but there are still a few older mails which I have not yet read. During my recuperation I subscribed at home but there are a few mails which fell into the hole between, which I'm just getting round to reading.
Dilwyn's message here broaches the question of _exe files. There is however a more controversial aspect: What about direct execution of exe files? It could be really useful but opens up the Pandora's box of virus propagation. What do you think? On the question of pre-viewing mails before down loading (comes later in the thread). This is built into the POP protocol but seems to be a seldom used feature. My little demo program in the SOQL package could easily be extended to provide such a feature but I'm still busy with PPP and I don't think anybody is using it much at the moment as PPP access is almost universally required. Jon. -----Original Message----- From: Dilwyn Jones [mailto:[EMAIL PROTECTED]] Sent: Monday, April 22, 2002 9:05 PM To: [EMAIL PROTECTED] Subject: Re: [ql-users] QeyMail question... >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
