Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Sending email with attachments
141 views
Skip to first unread message
Patricia Shanahan
Oct 2, 2012, 1:49:04 AM10/2/12
to
I am writing a data collection application. It needs to run on as many
tablets and laptops as possible, so I'm writing it in HTML and
JavaScript. Although I cannot ask end users to buy a particular device,
I can ask them to install an up to date browser.
The ultimate destination of the data is a spreadsheet on a workstation
controlled by the person doing the data entry, or one of their associates.
The ideal, from my end users' point of view, would be a button they
could click that would send an e-mail to an address they enter with the
data attached in .csv format. I do understand that e-mail would not be
the best way of getting the data to a web server, but that is not the
objective. Forwarding the data from my web site to a user-specified
e-mail address would require anti-spam precautions, and be generally
undesirable.
I've done web searches, and the closest I've been able to get is to fold
the data into a mailto URL as the message body, not an attachment. I
would be length limited by the Internet Explorer 2083 char URL limit,
and I think I would also have to quote URL special characters.
Another option is to just display the data and invite the user to
select and copy. The data could then be pasted into the body of an
e-mail, or into a text file in an editor window. I believe that would
work, but involves more end user busy work than is ideal.
I am very new to JavaScript, so I'm really hoping there is a better way
of doing this that I have just not found.
Thanks for any ideas or pointers to web sites I should read.
Patricia
tablets and laptops as possible, so I'm writing it in HTML and
JavaScript. Although I cannot ask end users to buy a particular device,
I can ask them to install an up to date browser.
The ultimate destination of the data is a spreadsheet on a workstation
controlled by the person doing the data entry, or one of their associates.
The ideal, from my end users' point of view, would be a button they
could click that would send an e-mail to an address they enter with the
data attached in .csv format. I do understand that e-mail would not be
the best way of getting the data to a web server, but that is not the
objective. Forwarding the data from my web site to a user-specified
e-mail address would require anti-spam precautions, and be generally
undesirable.
I've done web searches, and the closest I've been able to get is to fold
the data into a mailto URL as the message body, not an attachment. I
would be length limited by the Internet Explorer 2083 char URL limit,
and I think I would also have to quote URL special characters.
Another option is to just display the data and invite the user to
select and copy. The data could then be pasted into the body of an
e-mail, or into a text file in an editor window. I believe that would
work, but involves more end user busy work than is ideal.
I am very new to JavaScript, so I'm really hoping there is a better way
of doing this that I have just not found.
Thanks for any ideas or pointers to web sites I should read.
Patricia
Scott Sauyet
Oct 2, 2012, 7:20:27 AM10/2/12
to
Patricia Shanahan wrote:
> I am writing a data collection application. It needs to run on as many
> tablets and laptops as possible, so I'm writing it in HTML and
> JavaScript. Although I cannot ask end users to buy a particular device,
> I can ask them to install an up to date browser.
>
> The ultimate destination of the data is a spreadsheet on a workstation
> controlled by the person doing the data entry, or one of their associates.
>
> The ideal, from my end users' point of view, would be a button they
> could click that would send an e-mail to an address they enter with the
> data attached in .csv format. [ ... ]
> I am writing a data collection application. It needs to run on as many
> tablets and laptops as possible, so I'm writing it in HTML and
> JavaScript. Although I cannot ask end users to buy a particular device,
> I can ask them to install an up to date browser.
>
> The ultimate destination of the data is a spreadsheet on a workstation
> controlled by the person doing the data entry, or one of their associates.
>
> The ideal, from my end users' point of view, would be a button they
> could click that would send an e-mail to an address they enter with the
I don't understand why you would choose email for this rather than a
web download. Are the browsers working disconnected from the server
serving that content? Is the server extremely limited? If neither of
these is true, then you should be able to send the data to the server
to send back as a downloadable file. That seems the most flexible
solution. Does your infrastructure prevent this?
-- Scott
Scott Sauyet
Oct 2, 2012, 8:16:39 AM10/2/12
to
this post:
<news:QvydnWGOxc8p0N_W...@posted.isomediainc>
Google archived this thread at
<https://groups.google.com/group/comp.lang.javascript/
browse_thread/thread/fbf0f310811f30b7/3b751ce8a7107c61>
-- Scott
Patricia Shanahan
Oct 2, 2012, 10:03:50 AM10/2/12
to
transmission.
If there were a non-browser programming language and run time
environment that ran on all target devices, including iPad, I would be
writing an application in that language. The only reason for configuring
the application as a web site is the number of possible collection
devices that have browsers with JavaScript.
The data is not my data and is none of my business. Different people
will be doing the data collection, for different projects, in different
organizations. Each project will belong to some researcher who will
typically use a workstation behind a firewall to consolidate and process
the data and prepare reports based on it.
I would like to get the data as directly as possible from the data
collection device to that workstation. The end users are expert
spreadsheet users, so they know what to do with a .csv attachment, but
are not web developers and do not necessarily control a web server. My
lead user suggested e-mail as his ideal data delivery method.
Some of the data collection will have to be done offline. I'm looking at
marking pages and JavaScript files for offline use, but would like to
also offer the application in the form of a zip file that can be
downloaded and extracted on a collection device, and used locally. I
plan to store the data in the browser's local memory until the user has
network access. Transferring data collected by local pages to my web
site gets into cross-domain access issues.
Patricia
Patricia Shanahan
Oct 2, 2012, 10:10:34 AM10/2/12
to
getting the data to the web site serving the pages, not to an e-mail
inbox on a workstation outside that domain, my objective. I recognize
that there may be ways of forwarding the data, but I would prefer to
avoid that if there is any way of doing so.
Patricia
Scott Sauyet
Oct 2, 2012, 1:50:36 PM10/2/12
to
able to do what you would like. Client-side Javascript has no
capability to email. `mailto:` links are just ways to launch external
email programs, and there is no way that I know of to add attachments
to those emails.
I wish I had better news for you. Best of luck,
-- Scott
Scott Sauyet
Oct 2, 2012, 1:57:00 PM10/2/12
to
Patricia Shanahan wrote:
> Scott Sauyet wrote:
>> Scott Sauyet wrote:
>>> Patricia Shanahan wrote:
>>>> [ ... ]
> Scott Sauyet wrote:
>> Scott Sauyet wrote:
>>> Patricia Shanahan wrote:
>>>> The ultimate destination of the data is a spreadsheet on a workstation
>>>> controlled by the person doing the data entry, or one of their associates.
>
>>>> The ideal, from my end users' point of view, would be a button they
>>>> could click that would send an e-mail to an address they enter with the
>>>> data attached in .csv format. [ ... ]
>
>>> I don't understand why you would choose email for this rather than a
>>> web download. Are the browsers working disconnected from the server
>>> serving that content? Is the server extremely limited? If neither of
>>> these is true, then you should be able to send the data to the server
>>> to send back as a downloadable file. That seems the most flexible
>>> solution. Does your infrastructure prevent this?
>
>> I posted a proof of concept of this technique in a thread started by
>> this post:
>
>> <news:QvydnWGOxc8p0N_W...@posted.isomediainc>
>
>> Google archived this thread at
>
>> <https://groups.google.com/group/comp.lang.javascript/
>> browse_thread/thread/fbf0f310811f30b7/3b751ce8a7107c61>
>
> I've looked at the thread. If I understand it correctly, it is about
> getting the data to the web site serving the pages, not to an e-mail
> inbox on a workstation outside that domain, my objective. I recognize
> that there may be ways of forwarding the data, but I would prefer to
> avoid that if there is any way of doing so.
You are correct. This is an example of how you can do web downloads
>>>> controlled by the person doing the data entry, or one of their associates.
>
>>>> The ideal, from my end users' point of view, would be a button they
>>>> could click that would send an e-mail to an address they enter with the
>>>> data attached in .csv format. [ ... ]
>
>>> I don't understand why you would choose email for this rather than a
>>> web download. Are the browsers working disconnected from the server
>>> serving that content? Is the server extremely limited? If neither of
>>> these is true, then you should be able to send the data to the server
>>> to send back as a downloadable file. That seems the most flexible
>>> solution. Does your infrastructure prevent this?
>
>> I posted a proof of concept of this technique in a thread started by
>> this post:
>
>> <news:QvydnWGOxc8p0N_W...@posted.isomediainc>
>
>> Google archived this thread at
>
>> <https://groups.google.com/group/comp.lang.javascript/
>> browse_thread/thread/fbf0f310811f30b7/3b751ce8a7107c61>
>
> I've looked at the thread. If I understand it correctly, it is about
> getting the data to the web site serving the pages, not to an e-mail
> inbox on a workstation outside that domain, my objective. I recognize
> that there may be ways of forwarding the data, but I would prefer to
> avoid that if there is any way of doing so.
from client-side code with a minimally cooperative server, not how to
do any email. It will not work at all in an off-line environment, and
it does require that the users trust the server not to do anything
more with the data than to return it as a download.
I wish I had a suggestion that might help with your original problem,
but I don't know of anything. My best suggestion would be to write
something that you could compile for each of your target
environments. If you want client-side Javascript, you might try
something that supplies its UI over HTTP and then launch a browser
pointing to a local host, but even then you would need to write that
host in something that you could deploy natively to your target
machines. Sorry.
-- Scott
Patricia Shanahan
Oct 2, 2012, 2:16:38 PM10/2/12
to
On 10/2/2012 10:50 AM, Scott Sauyet wrote:
> Patricia Shanahan wrote:
...
> Patricia Shanahan wrote:
>> If there were a non-browser programming language and run time
>> environment that ran on all target devices, including iPad, I would be
>> writing an application in that language. The only reason for configuring
>> the application as a web site is the number of possible collection
>> devices that have browsers with JavaScript.
>
> I see. I did misunderstand the problem. I don't think you will be
> able to do what you would like. Client-side Javascript has no
> capability to email. `mailto:` links are just ways to launch external
> email programs, and there is no way that I know of to add attachments
> to those emails.
>
> I wish I had better news for you. Best of luck,
Thanks. Even a negative result is very helpful. I would otherwise have
>> environment that ran on all target devices, including iPad, I would be
>> writing an application in that language. The only reason for configuring
>> the application as a web site is the number of possible collection
>> devices that have browsers with JavaScript.
>
> I see. I did misunderstand the problem. I don't think you will be
> able to do what you would like. Client-side Javascript has no
> capability to email. `mailto:` links are just ways to launch external
> email programs, and there is no way that I know of to add attachments
> to those emails.
>
> I wish I had better news for you. Best of luck,
spent a lot of time web searching and experimenting looking for
something that does not exist. It is relatively easy to find how to do
something that can be done in an unfamiliar language. Being sure
something cannot be done is much harder.
I do have a fall-back position that would have to be used to in some
situations. I plan to provide a way to display the data in a text area,
ideally already selected, so that the user can copy it to the clipboard.
Once it is in the clipboard it can be pasted into an e-mail, Google docs
text file, text file on a thumb drive etc. etc.
I have to support that anyway for devices that do not have an e-mail
client, and for confidential data that should not be sent over the
Internet in unencrypted form.
Patricia
dann...@gmail.com
Oct 2, 2012, 3:15:00 PM10/2/12
to
js or html cannot send an e-mail as an engine from the browser, true, however a mail-server on the server side can do the sending, if the webpage just provides the FORM with a method say method="post" and can also take file(s) <input type="file" ...> input to be send over on with enctype="multipar/form-data" in the FORM. The only thing needed for all that will be the mail-server service on the server side and the script to process it.
<form action="SPREADSHEET_SENDER.pl" method="POST" enctype="multipart/form-data">
<input type="file" name="data-collection">
.....
</form>
Danny
<form action="SPREADSHEET_SENDER.pl" method="POST" enctype="multipart/form-data">
<input type="file" name="data-collection">
.....
</form>
Danny
Tom de Neef
Oct 2, 2012, 3:28:58 PM10/2/12
to
"Patricia Shanahan" <pa...@acm.org> wrote:
>>> I am writing a data collection application. It needs to run on as many
>>> tablets and laptops as possible, so I'm writing it in HTML and
>>> JavaScript. Although I cannot ask end users to buy a particular device,
>>> I can ask them to install an up to date browser.
>>>
>>> I am writing a data collection application. It needs to run on as many
>>> tablets and laptops as possible, so I'm writing it in HTML and
>>> JavaScript. Although I cannot ask end users to buy a particular device,
>>> I can ask them to install an up to date browser.
>>>
>>> The ideal, from my end users' point of view, would be a button they
>>> could click that would send an e-mail to an address they enter with the
>>> data attached in .csv format. [ ... ]
>>
>>> could click that would send an e-mail to an address they enter with the
>>> data attached in .csv format. [ ... ]
>>
> If there were a non-browser programming language and run time
> environment that ran on all target devices, including iPad, I would be
> writing an application in that language. The only reason for configuring
> the application as a web site is the number of possible collection
> devices that have browsers with JavaScript.
>
> environment that ran on all target devices, including iPad, I would be
> writing an application in that language. The only reason for configuring
> the application as a web site is the number of possible collection
> devices that have browsers with JavaScript.
>
> I would like to get the data as directly as possible from the data
> collection device to that workstation. The end users are expert
> spreadsheet users, so they know what to do with a .csv attachment, but
> are not web developers and do not necessarily control a web server. My
> lead user suggested e-mail as his ideal data delivery method.
Forgive if I got it wrong: data is collected on devices with internet access
> collection device to that workstation. The end users are expert
> spreadsheet users, so they know what to do with a .csv attachment, but
> are not web developers and do not necessarily control a web server. My
> lead user suggested e-mail as his ideal data delivery method.
and browser support.
This data is in the form of tables or files and needs to be sent to someone
with an email account, where the account depends on the device/data under
consideration. You would like to get it there 'as direct as possible'.
Suppose you had a web server. The person operating the collection device
surfs to its URL. He gets a webpage with two selection 'fields': one to
indicate where the data is (when it is a file) or to copy it into a text
field (when it is a table). The other to select the email address of the
target person. Any pre-processing (like getting the data in the right
format) could be done by script on the page.
'Submit' could then result in an (encrypted) upload to the server, where the
data is attached to an email which the server sends to the target.
Would that meet your requirements? It would be easy to implement.
Tom
Patricia Shanahan
Oct 2, 2012, 3:59:55 PM10/2/12
to
On 10/2/2012 12:28 PM, Tom de Neef wrote:
> "Patricia Shanahan" <pa...@acm.org> wrote:
>>>> I am writing a data collection application. It needs to run on as many
>>>> tablets and laptops as possible, so I'm writing it in HTML and
>>>> JavaScript. Although I cannot ask end users to buy a particular device,
>>>> I can ask them to install an up to date browser.
>>>>
>>>> The ideal, from my end users' point of view, would be a button they
>>>> could click that would send an e-mail to an address they enter with the
>>>> data attached in .csv format. [ ... ]
>>>
>> If there were a non-browser programming language and run time
>> environment that ran on all target devices, including iPad, I would be
>> writing an application in that language. The only reason for configuring
>> the application as a web site is the number of possible collection
>> devices that have browsers with JavaScript.
>>
>> I would like to get the data as directly as possible from the data
>> collection device to that workstation. The end users are expert
>> spreadsheet users, so they know what to do with a .csv attachment, but
>> are not web developers and do not necessarily control a web server. My
>> lead user suggested e-mail as his ideal data delivery method.
>
> Forgive if I got it wrong: data is collected on devices with internet access
> and browser support.
> This data is in the form of tables or files and needs to be sent to someone
> with an email account, where the account depends on the device/data under
> consideration. You would like to get it there 'as direct as possible'.
Typically, the data will be in the browser's local storage, where I can
> "Patricia Shanahan" <pa...@acm.org> wrote:
>>>> I am writing a data collection application. It needs to run on as many
>>>> tablets and laptops as possible, so I'm writing it in HTML and
>>>> JavaScript. Although I cannot ask end users to buy a particular device,
>>>> I can ask them to install an up to date browser.
>>>>
>>>> The ideal, from my end users' point of view, would be a button they
>>>> could click that would send an e-mail to an address they enter with the
>>>> data attached in .csv format. [ ... ]
>>>
>> If there were a non-browser programming language and run time
>> environment that ran on all target devices, including iPad, I would be
>> writing an application in that language. The only reason for configuring
>> the application as a web site is the number of possible collection
>> devices that have browsers with JavaScript.
>>
>> I would like to get the data as directly as possible from the data
>> collection device to that workstation. The end users are expert
>> spreadsheet users, so they know what to do with a .csv attachment, but
>> are not web developers and do not necessarily control a web server. My
>> lead user suggested e-mail as his ideal data delivery method.
>
> Forgive if I got it wrong: data is collected on devices with internet access
> and browser support.
> This data is in the form of tables or files and needs to be sent to someone
> with an email account, where the account depends on the device/data under
> consideration. You would like to get it there 'as direct as possible'.
put it from client-side JavaScript. However, the main point is that the
data will be somewhere accessible to my client side code.
>
> Suppose you had a web server. The person operating the collection device
> surfs to its URL. He gets a webpage with two selection 'fields': one to
> indicate where the data is (when it is a file) or to copy it into a text
> field (when it is a table). The other to select the email address of the
> target person. Any pre-processing (like getting the data in the right
> format) could be done by script on the page.
> 'Submit' could then result in an (encrypted) upload to the server, where the
> data is attached to an email which the server sends to the target.
> Would that meet your requirements? It would be easy to implement.
forwarding engine?
Patricia
Thomas 'PointedEars' Lahn
Oct 2, 2012, 4:26:18 PM10/2/12
to
Patricia Shanahan wrote:
> I am writing a data collection application. It needs to run on as many
> tablets and laptops as possible, so I'm writing it in HTML and
> JavaScript. Although I cannot ask end users to buy a particular device,
> I can ask them to install an up to date browser.
>
> The ultimate destination of the data is a spreadsheet on a workstation
> controlled by the person doing the data entry, or one of their associates.
>
> The ideal, from my end users' point of view, would be a button they
> could click that would send an e-mail to an address they enter with the
> data attached in .csv format.
You cannot do that client-side, so you will have to do it server-side. That
> I am writing a data collection application. It needs to run on as many
> tablets and laptops as possible, so I'm writing it in HTML and
> JavaScript. Although I cannot ask end users to buy a particular device,
> I can ask them to install an up to date browser.
>
> The ultimate destination of the data is a spreadsheet on a workstation
> controlled by the person doing the data entry, or one of their associates.
>
> The ideal, from my end users' point of view, would be a button they
> could click that would send an e-mail to an address they enter with the
> data attached in .csv format.
is, have a server-side application compile the .csv and send the e-mail.
Usually that would be the same server-side application that generated the
client-side application in the first place.
> I do understand that e-mail would not be the best way of getting the data
> to a web server, but that is not the objective. Forwarding the data from
> my web site to a user-specified e-mail address would require anti-spam
> precautions, and be generally undesirable.
before they can use that function (see also [OWASP]).
Only shifting the load from the server to the client is not a solution. In
fact, it has the potential to make matters worse. Client computers
(including mobile devices) are usually much less protected, thus more easily
compromised, than servers.
> I've done web searches, and the closest I've been able to get is to fold
> the data into a mailto URL as the message body, not an attachment.
part message, following a delimiter line, own header and usually a Base64-
encoded message-part body (see [RFC2046]); so, in theory, it could work.
But I would not recommend it for production. In fact, security measures
might prevent it.
> I would be length limited by the Internet Explorer 2083 char URL limit,
> and I think I would also have to quote URL special characters.
`data:'. [SO] There might be one for `mailto:' as well. However, a
suitable MUA will need to be installed and configured at the client for this
to work, which you should not make a requirement.
> Another option is to just display the data and invite the user to
> select and copy. The data could then be pasted into the body of an
> e-mail, or into a text file in an editor window. I believe that would
> work, but involves more end user busy work than is ideal.
> I am very new to JavaScript, so I'm really hoping there is a better way
> of doing this that I have just not found.
cannot be done using an ECMAScript implementation server-side.
HTH
PointedEars
___________
[OWASP]
The Open Web Application Security Project: Authentication Cheet Sheet.
(updated: 2012-09-28)
<https://www.owasp.org/index.php/Authentication_Cheat_Sheet>
[RFC2046]
Freed, N., Borenstein, N.: Multipurpose Internet Mail Extensions (MIME) Part
Two: Media Types. November 1996. <http://tools.ietf.org/html/rfc2046>
[SO]
StackOverflow: What is the maximum length of a URL? (updated: 2012-07-12)
<http://stackoverflow.com/a/417184/855543>
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
Patricia Shanahan
Oct 3, 2012, 3:04:46 PM10/3/12
to
Thomas 'PointedEars' Lahn wrote:
> Patricia Shanahan wrote:
>
...
> Patricia Shanahan wrote:
>
...
> Technically, an e-mail attachment is a part of the message body of a multi-
> part message, following a delimiter line, own header and usually a Base64-
> encoded message-part body (see [RFC2046]); so, in theory, it could work.
> But I would not recommend it for production. In fact, security measures
> might prevent it.
...
> part message, following a delimiter line, own header and usually a Base64-
> encoded message-part body (see [RFC2046]); so, in theory, it could work.
> But I would not recommend it for production. In fact, security measures
> might prevent it.
It does sound worth investigating.
>
>> Another option is to just display the data and invite the user to
>> select and copy. The data could then be pasted into the body of an
>> e-mail, or into a text file in an editor window. I believe that would
>> work, but involves more end user busy work than is ideal.
>
> Yes, in a Web application you should make best use of the *Web* first.
>
I'm writing an application that happens to be implemented in HTML and
JavaScript, and use a browser as the run time. If iPad had a suitable
Java runtime, and a less inconvenient development process, it would have
been a Java application. Because of the choice of languages, one way of
deploying it is to use HTTP to get the files from some server. For other
combinations of situation and device, it may be better to download the
application to the client file system.
Patricia
Dr J R Stockton
Oct 3, 2012, 2:49:32 PM10/3/12
to
In comp.lang.javascript message <JqadnXQNAdXTHffNnZ2dnUVZ_qSdnZ2d@earthl
ink.com>, Mon, 1 Oct 2012 22:49:04, Patricia Shanahan <pa...@acm.org>
posted:
>I am writing a data collection application. It needs to run on as many
>tablets and laptops as possible, so I'm writing it in HTML and
>JavaScript. Although I cannot ask end users to buy a particular device,
>I can ask them to install an up to date browser.
> ...
I see no reason why you should not offer more than one method.
You can display the data, and the address, etc., and invite the user to
copy'n'paste into their ordinary E-mail system. Ensure that the data
fits in 72 characters per line, with newlines between, and uses only
7-bit characters, and has a data delimiter before and after, and it
should be possible to extract it reliably from a received E-mail. That
should all be easy for you to arrange.
You can then develop some other method, perhaps using code on the server
to forward the message; and once it is working you can allow users to do
that instead.
Some users might refer E-mail, as giving them a record of what was sent
when in a "filing system" that they already have.
But, as "someone new to JavaScript", your first thought should be to
find a confederate who already knows the language. Advertise in your
village magazine; look for scripted web pages that are local to your
town; employ a local firm who knows about such things, or whatever.
Remember that the fact that any idiot can start writing JavaScript
inevitably means that a large number of them have done so.
Read the newsgroup FAQ.
--
(c) John Stockton, nr London UK Reply address via Home Page.
news:comp.lang.javascript FAQ <http://www.jibbering.com/faq/index.html>.
<http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
ink.com>, Mon, 1 Oct 2012 22:49:04, Patricia Shanahan <pa...@acm.org>
posted:
>I am writing a data collection application. It needs to run on as many
>tablets and laptops as possible, so I'm writing it in HTML and
>JavaScript. Although I cannot ask end users to buy a particular device,
>I can ask them to install an up to date browser.
I see no reason why you should not offer more than one method.
You can display the data, and the address, etc., and invite the user to
copy'n'paste into their ordinary E-mail system. Ensure that the data
fits in 72 characters per line, with newlines between, and uses only
7-bit characters, and has a data delimiter before and after, and it
should be possible to extract it reliably from a received E-mail. That
should all be easy for you to arrange.
You can then develop some other method, perhaps using code on the server
to forward the message; and once it is working you can allow users to do
that instead.
Some users might refer E-mail, as giving them a record of what was sent
when in a "filing system" that they already have.
But, as "someone new to JavaScript", your first thought should be to
find a confederate who already knows the language. Advertise in your
village magazine; look for scripted web pages that are local to your
town; employ a local firm who knows about such things, or whatever.
Remember that the fact that any idiot can start writing JavaScript
inevitably means that a large number of them have done so.
Read the newsgroup FAQ.
--
(c) John Stockton, nr London UK Reply address via Home Page.
news:comp.lang.javascript FAQ <http://www.jibbering.com/faq/index.html>.
<http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
Eli the Bearded
Oct 3, 2012, 7:08:07 PM10/3/12
to
In comp.lang.javascript,
get mangled in email often, so not making whitespace significant
will help to reliably extract the message. (Or make all whitespace
interchangable: one newline is as good as two spaces, etc.)
Really the simple way to do this, is format the data however you
want, then apply the standard base64 encoding to it, and add headers.
The message will look a lot like a raw mail attachment, or a PGP
encypted block, or a SSL certificate, or ...
Elijah
------
the space issue sometimes came up with uuencode
Dr J R Stockton <repl...@merlyn.demon.co.uk.invalid> wrote:
> You can display the data, and the address, etc., and invite the user to
> copy'n'paste into their ordinary E-mail system. Ensure that the data
> fits in 72 characters per line, with newlines between, and uses only
> 7-bit characters, and has a data delimiter before and after, and it
> should be possible to extract it reliably from a received E-mail. That
> should all be easy for you to arrange.
If the poster does go down that route, be aware that whitespace
> You can display the data, and the address, etc., and invite the user to
> copy'n'paste into their ordinary E-mail system. Ensure that the data
> fits in 72 characters per line, with newlines between, and uses only
> 7-bit characters, and has a data delimiter before and after, and it
> should be possible to extract it reliably from a received E-mail. That
> should all be easy for you to arrange.
get mangled in email often, so not making whitespace significant
will help to reliably extract the message. (Or make all whitespace
interchangable: one newline is as good as two spaces, etc.)
Really the simple way to do this, is format the data however you
want, then apply the standard base64 encoding to it, and add headers.
The message will look a lot like a raw mail attachment, or a PGP
encypted block, or a SSL certificate, or ...
Elijah
------
the space issue sometimes came up with uuencode
Patricia Shanahan
Oct 3, 2012, 9:43:15 PM10/3/12
to
Dr J R Stockton wrote:
...
programming, or to learning programming languages, just to JavaScript. I
have over 30 years professional programming experience and a doctorate
in computer science. I have studied many programming languages, starting
with Fortran in 1967.
Usually, when I decide a program I want to write should be in a language
I don't already know my first thought is to get reading and writing. I
read books, tutorials, specifications, newsgroups, newsgroup FAQs, and
existing code. I write short practice programs, starting with the
basics, but after a couple of weeks of learning JavaScript I'm on to
experimenting with some of the difficulties I need to solve.
Is JavaScript especially difficult to learn?
It does combine a lot of features, but I have not yet encountered a
completely new feature, as distinct from variations on ideas I already
understand. Even the browser incompatibility issue reminds me of the
state of Fortran in the early 1980's.
Patricia
...
> But, as "someone new to JavaScript", your first thought should be to
> find a confederate who already knows the language. Advertise in your
> village magazine; look for scripted web pages that are local to your
> town; employ a local firm who knows about such things, or whatever.
I think "new to JavaScript" may have been ambiguous. I am not new to
> find a confederate who already knows the language. Advertise in your
> village magazine; look for scripted web pages that are local to your
> town; employ a local firm who knows about such things, or whatever.
programming, or to learning programming languages, just to JavaScript. I
have over 30 years professional programming experience and a doctorate
in computer science. I have studied many programming languages, starting
with Fortran in 1967.
Usually, when I decide a program I want to write should be in a language
I don't already know my first thought is to get reading and writing. I
read books, tutorials, specifications, newsgroups, newsgroup FAQs, and
existing code. I write short practice programs, starting with the
basics, but after a couple of weeks of learning JavaScript I'm on to
experimenting with some of the difficulties I need to solve.
Is JavaScript especially difficult to learn?
It does combine a lot of features, but I have not yet encountered a
completely new feature, as distinct from variations on ideas I already
understand. Even the browser incompatibility issue reminds me of the
state of Fortran in the early 1980's.
Patricia
Patricia Shanahan
Oct 3, 2012, 9:46:15 PM10/3/12
to
The data is spreadsheet-like, and needs to end up in a spreadsheet, so
csv is the obvious text format, but newlines are significant. Breaking a
long line into two shorter lines would create two spreadsheet rows where
there should be one.
Patricia
Scott Sauyet
Oct 3, 2012, 10:42:05 PM10/3/12
to
Patricia Shanahan wrote:
> The data is spreadsheet-like, and needs to end up in a spreadsheet, so
> csv is the obvious text format, but newlines are significant. Breaking a
> long line into two shorter lines would create two spreadsheet rows where
> there should be one.
For this and other similar reasons, the body of an email is almost
> The data is spreadsheet-like, and needs to end up in a spreadsheet, so
> csv is the obvious text format, but newlines are significant. Breaking a
> long line into two shorter lines would create two spreadsheet rows where
> there should be one.
certainly a terrible transport medium for the data you describe. You
could use email attachments, but as already discussed, that probably
won't be possible with client-side Javascript.
-- Scott
Scott Sauyet
Oct 3, 2012, 10:54:58 PM10/3/12
to
Patricia Shanahan wrote:
> I think "new to JavaScript" may have been ambiguous. I am not new to
> programming, or to learning programming languages, just to JavaScript. I
> have over 30 years professional programming experience and a doctorate
> in computer science. I have studied many programming languages, starting
> with Fortran in 1967.
>
> [ ... ]
> I think "new to JavaScript" may have been ambiguous. I am not new to
> programming, or to learning programming languages, just to JavaScript. I
> have over 30 years professional programming experience and a doctorate
> in computer science. I have studied many programming languages, starting
> with Fortran in 1967.
>
>
> Is JavaScript especially difficult to learn?
No it is not. There are difficulties in browser-scripting because of
> Is JavaScript especially difficult to learn?
the incompatibilities, but there is nothing particularly challenging
about the language. But, if you're familiar with C-style languages,
it's easy to expect this one to act more like those than it does just
because of syntactic similarity.
Assuming you have experience with a language that has functional
aspect, whether pure functional like ML or Haskell, or ones that have
major functional techniques like LISP or Scheme, then you should be
able to quickly grasp a big part of how the language differs from ones
like Java or C#. The only other really unusual major aspect of the
language is is prototypal inheritance.
-- Scott
Patricia Shanahan
Oct 5, 2012, 9:07:25 PM10/5/12
to
Thomas 'PointedEars' Lahn wrote:
> Patricia Shanahan wrote:
..
> Patricia Shanahan wrote:
..
>> I've done web searches, and the closest I've been able to get is to fold
>> the data into a mailto URL as the message body, not an attachment.
>
> Technically, an e-mail attachment is a part of the message body of a multi-
> part message, following a delimiter line, own header and usually a Base64-
> encoded message-part body (see [RFC2046]); so, in theory, it could work.
> But I would not recommend it for production. In fact, security measures
> might prevent it.
I've done some more web searches and experiments. Unfortunately, the
>> the data into a mailto URL as the message body, not an attachment.
>
> Technically, an e-mail attachment is a part of the message body of a multi-
> part message, following a delimiter line, own header and usually a Base64-
> encoded message-part body (see [RFC2046]); so, in theory, it could work.
> But I would not recommend it for production. In fact, security measures
> might prevent it.
comment about security measures seems to be correct.
RFC 6068, "The 'mailto' URI Scheme" says "Only a limited set of header
fields such as Subject and Keywords, as well as Body, are believed to be
both safe and useful in the general case."
I've tested with Firefox as browser and Thunderbird as mail client. The
content type header in the message as delivered is "text/plain;
charset=ISO-8859-1; format=flowed" regardless of my attempts to specify
a multi-part content type in the URI.
Patricia
Thomas 'PointedEars' Lahn
Oct 6, 2012, 2:48:23 AM10/6/12
to
Patricia Shanahan wrote:
> RFC 6068, "The 'mailto' URI Scheme" says "Only a limited set of header
> fields such as Subject and Keywords, as well as Body, are believed to be
> both safe and useful in the general case."
>
> I've tested with Firefox as browser and Thunderbird as mail client. The
> content type header in the message as delivered is "text/plain;
> charset=ISO-8859-1; format=flowed" regardless of my attempts to specify
> a multi-part content type in the URI.
I had not considered the requirement for the main `Content-Type' header
> RFC 6068, "The 'mailto' URI Scheme" says "Only a limited set of header
> fields such as Subject and Keywords, as well as Body, are believed to be
> both safe and useful in the general case."
>
> I've tested with Firefox as browser and Thunderbird as mail client. The
> content type header in the message as delivered is "text/plain;
> charset=ISO-8859-1; format=flowed" regardless of my attempts to specify
> a multi-part content type in the URI.
field of multi-part messages.
The question remains why it would be acceptable to send the data over the
Internet via e-mail to an SMTP server, but not over the Internet to an HTTP
server.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
Patricia Shanahan
Oct 6, 2012, 3:29:48 PM10/6/12
to
Thomas 'PointedEars' Lahn wrote:
...
SMTP server, and any SMTP server, without special configuration, can
forward e-mail to some mailbox that can be accessed from the workstation
where that particular data set will be processed.
On the other hand, organizations using the software are unlikely to have
an HTTP server set up with the right scripts. Typically, the department
that might use the software I'm writing will not have the sort of
control over a server that it takes to install new scripts on it.
I could install scripts in my personal domain, but I don't think users
would want their data to go through my domain.
Patricia
...
> The question remains why it would be acceptable to send the data over the
> Internet via e-mail to an SMTP server, but not over the Internet to an HTTP
> server.
The difference is that most tablets already have access to an existing
> Internet via e-mail to an SMTP server, but not over the Internet to an HTTP
> server.
SMTP server, and any SMTP server, without special configuration, can
forward e-mail to some mailbox that can be accessed from the workstation
where that particular data set will be processed.
On the other hand, organizations using the software are unlikely to have
an HTTP server set up with the right scripts. Typically, the department
that might use the software I'm writing will not have the sort of
control over a server that it takes to install new scripts on it.
I could install scripts in my personal domain, but I don't think users
would want their data to go through my domain.
Patricia
Thomas 'PointedEars' Lahn
Oct 6, 2012, 3:49:37 PM10/6/12
to
Patricia Shanahan wrote:
ACK. Alternative approaches can be suggested if you describe your problem
in more detail:
<http://www.catb.org/~esr/faqs/smart-questions.html#beprecise>
PointedEars
--
Sometimes, what you learn is wrong. If those wrong ideas are close to the
root of the knowledge tree you build on a particular subject, pruning the
bad branches can sometimes cause the whole tree to collapse.
-- Mike Duffy in cljs, <news:Xns9FB6521286...@94.75.214.39>
in more detail:
<http://www.catb.org/~esr/faqs/smart-questions.html#beprecise>
PointedEars
--
Sometimes, what you learn is wrong. If those wrong ideas are close to the
root of the knowledge tree you build on a particular subject, pruning the
bad branches can sometimes cause the whole tree to collapse.
-- Mike Duffy in cljs, <news:Xns9FB6521286...@94.75.214.39>
Patricia Shanahan
Oct 7, 2012, 3:13:43 AM10/7/12
to
Thomas 'PointedEars' Lahn wrote:
> Patricia Shanahan wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> The question remains why it would be acceptable to send the data over the
>>> Internet via e-mail to an SMTP server, but not over the Internet to an
>>> HTTP server.
>> The difference is that most tablets already have access to an existing
>> SMTP server, and any SMTP server, without special configuration, can
>> forward e-mail to some mailbox that can be accessed from the workstation
>> where that particular data set will be processed.
>>
>> On the other hand, organizations using the software are unlikely to have
>> an HTTP server set up with the right scripts. Typically, the department
>> that might use the software I'm writing will not have the sort of
>> control over a server that it takes to install new scripts on it.
>>
>> I could install scripts in my personal domain, but I don't think users
>> would want their data to go through my domain.
>
> ACK. Alternative approaches can be suggested if you describe your problem
> in more detail:
>
> <http://www.catb.org/~esr/faqs/smart-questions.html#beprecise>
I cannot describe my current project in public until it is further
> Patricia Shanahan wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> The question remains why it would be acceptable to send the data over the
>>> Internet via e-mail to an SMTP server, but not over the Internet to an
>>> HTTP server.
>> The difference is that most tablets already have access to an existing
>> SMTP server, and any SMTP server, without special configuration, can
>> forward e-mail to some mailbox that can be accessed from the workstation
>> where that particular data set will be processed.
>>
>> On the other hand, organizations using the software are unlikely to have
>> an HTTP server set up with the right scripts. Typically, the department
>> that might use the software I'm writing will not have the sort of
>> control over a server that it takes to install new scripts on it.
>>
>> I could install scripts in my personal domain, but I don't think users
>> would want their data to go through my domain.
>
> ACK. Alternative approaches can be suggested if you describe your problem
> in more detail:
>
> <http://www.catb.org/~esr/faqs/smart-questions.html#beprecise>
along. I'm not asking for general help with my program design. That's my
problem.
I just wanted to check whether a specific user requirement could be met
using only HTML and JavaScript, after I had failed to find a solution by
reading books, web searching, thinking, and experiments. As I indicated
in my first article, I was fully aware of server based solutions, but
they are not appropriate for my application.
I've got the answer to my question - I can only send text in an e-mail -
so I'm on to working with that answer.
I don't think it is a big enough problem to make me change strategy from
HTML + JavaScript to installable application implementations for each
major group of environments.
Thanks for your help,
Patricia
Stefan Weiss
Oct 7, 2012, 6:46:58 AM10/7/12
to
On 2012-10-06 21:29, Patricia Shanahan wrote:
> I could install scripts in my personal domain, but I don't think users
> would want their data to go through my domain.
They're already trusting your app to handle their data properly, so why
> I could install scripts in my personal domain, but I don't think users
> would want their data to go through my domain.
would they worry about the forwarding server? In the usual case, the
script doing the web-to-mail forwarding will be a very simple affair.
You can make it available as an open source download for those who do
have a server, and provide forwarding on own server as a (free?) service.
I think sending attachments by email with JS alone (from an HTML
document in a browser) is a lost cause, especially if it has to work on
as many clients as possible. It's not that the language is too limited,
the problem is that browsers don't usually expose that kind of
functionality to scripts (and for good reason).
Even Java applets can't send emails to random SMTP servers. In theory,
they'd be powerful enough (for example with JavaMail, or by just opening
a socket and speaking SMTP directly), but the default security
restrictions will prevent them from connecting to anything but the
originating host.
From what I understand about your project, you have two options: the
HTML+JS approach you described plus a server-side component, or you bite
the bullet and build native apps for each target platform. You could
still do most of the layout/navigation parts in HTML+JS, but your app
will have to handle the email part.
- stefan
Thomas 'PointedEars' Lahn
Oct 7, 2012, 8:28:53 AM10/7/12
to
Patricia Shanahan wrote:
> I cannot describe my current project in public until it is further
> along.
You do not have to tell names in order to go into details.
> I cannot describe my current project in public until it is further
> along.
> I'm not asking for general help with my program design.
> That's my problem.
ISTM that your problem is that despite all your research you have made
premature exclusions based on premature assessment based on limited
experience. Describing the context of the problem in more detail to many
people will most certainly show whether your exclusions actually have been
premature.
> I just wanted to check whether a specific user requirement could be met
> using only HTML and JavaScript, after I had failed to find a solution by
> reading books, web searching, thinking, and experiments. As I indicated
> in my first article, I was fully aware of server based solutions, but
> they are not appropriate for my application.
>
> I've got the answer to my question - I can only send text in an e-mail -
> so I'm on to working with that answer.
asked if there was a better way. Due to your limited experience with
client-side scripting, that initial assessment might have been wrong.
> I don't think it is a big enough problem to make me change strategy from
> HTML + JavaScript to installable application implementations for each
> major group of environments.
> Thanks for your help,
You are welcome.
PointedEars
--
> If you get a bunch of authors […] that state the same "best practices"
> in any programming language, then you can bet who is wrong or right...
Not with javascript. Nonsense propagates like wildfire in this field.
-- Richard Cornford, comp.lang.javascript, 2011-11-14
Thomas 'PointedEars' Lahn
Oct 7, 2012, 12:55:51 PM10/7/12
to
Stefan Weiss wrote:
> On 2012-10-06 21:29, Patricia Shanahan wrote:
>> I could install scripts in my personal domain, but I don't think users
>> would want their data to go through my domain.
>
> They're already trusting your app to handle their data properly, so why
> would they worry about the forwarding server? In the usual case, the
> script doing the web-to-mail forwarding will be a very simple affair.
> You can make it available as an open source download for those who do
> have a server, and provide forwarding on own server as a (free?) service.
She has explained that her users and the organizations they belong to are
> On 2012-10-06 21:29, Patricia Shanahan wrote:
>> I could install scripts in my personal domain, but I don't think users
>> would want their data to go through my domain.
>
> They're already trusting your app to handle their data properly, so why
> would they worry about the forwarding server? In the usual case, the
> script doing the web-to-mail forwarding will be a very simple affair.
> You can make it available as an open source download for those who do
> have a server, and provide forwarding on own server as a (free?) service.
usually neither willing nor capable of running a server-side script.
> I think sending attachments by email with JS alone (from an HTML
> document in a browser) is a lost cause, especially if it has to work on
> as many clients as possible. It's not that the language is too limited,
> the problem is that browsers don't usually expose that kind of
> functionality to scripts (and for good reason).
is installed and configured on the same system, does not support code of the
form
window.location = "mailto:foo@bar?subject=baz&body=bla";
And as for mobile devices which are the primary concern here, I have found
that to work in various browsers and with various e-mail apps both on iOS
4.2.1 and Android 4.0.3 both with `http:' and (on Android, the equivalent
of) `file:'. I would be surprised if it did not work elsewhere, such as
newer OS versions and on Windows Mobile. (There are other mobile OSes, but
the application requirements can reasonably state that they are not actively
supported, given the current and projected combined market share of the
aforementioned ones).
The actual limitation here is twofold: URI length and e-mail client. If the
data can be encoded so that it fits within about 447 octets in the worst
case – scheme (7) + address (20) + subject (9 + 20) + body (6 + 447) =
MSHTML maximum (509) – for a stream of ASCII characters without control
characters except perhaps CR and LF, and if there is an e-mail client
installed and configured on the same system, then this can be done using a
plain-text e-mail. For the desktop system where the e-mail is being
retrieved to later can provide the data decoding service.
Testcase: <http://PointedEars.de/scripts/test/dom/mailto>
> Even Java applets can't send emails to random SMTP servers. In theory,
> they'd be powerful enough (for example with JavaMail, or by just opening
> a socket and speaking SMTP directly), but the default security
> restrictions will prevent them from connecting to anything but the
> originating host.
> From what I understand about your project, you have two options: the
> HTML+JS approach you described plus a server-side component, or you bite
> the bullet and build native apps for each target platform. You could
> still do most of the layout/navigation parts in HTML+JS, but your app
> will have to handle the email part.
PointedEars
--
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300...@news.demon.co.uk> (2004)
Stefan Weiss
Oct 7, 2012, 2:06:09 PM10/7/12
to
On 2012-10-07 18:55, Thomas 'PointedEars' Lahn wrote:
> Is that so? I have not found a single Web browser that, if an e-mail client
> is installed and configured on the same system, does not support code of the
> form
>
> window.location = "mailto:foo@bar?subject=baz&body=bla";
I said "sending *attachments* by email" (and so does the subject).
I have not found a single web browser that could do that (haven't
actually searched for one, either, to be honest).
Even in the simple case with no attachments, all the browser does is
invoke a handler application which has been registered for "mailto:"
links. Some products have a mail client bundled with the browser, but
the principle is the same. Without suitable host objects, there's simply
no way we can use JS to send multipart emails from a browser. The best
we can do is build a mailto URI, and as you said, that's very limited.
Probably too limited to be practical for spreadsheet data, but since
Patricia's project is secret, who knows.
In theory, mobile apps could provide these host objects to their
scripts, but why bother - just send the mail from the native part of the
app.
- stefan
> Stefan Weiss wrote:
>> I think sending attachments by email with JS alone (from an HTML
>> document in a browser) is a lost cause, especially if it has to work on
>> as many clients as possible. [...]
>> I think sending attachments by email with JS alone (from an HTML
>> document in a browser) is a lost cause, especially if it has to work on
> Is that so? I have not found a single Web browser that, if an e-mail client
> is installed and configured on the same system, does not support code of the
> form
>
> window.location = "mailto:foo@bar?subject=baz&body=bla";
I have not found a single web browser that could do that (haven't
actually searched for one, either, to be honest).
Even in the simple case with no attachments, all the browser does is
invoke a handler application which has been registered for "mailto:"
links. Some products have a mail client bundled with the browser, but
the principle is the same. Without suitable host objects, there's simply
no way we can use JS to send multipart emails from a browser. The best
we can do is build a mailto URI, and as you said, that's very limited.
Probably too limited to be practical for spreadsheet data, but since
Patricia's project is secret, who knows.
In theory, mobile apps could provide these host objects to their
scripts, but why bother - just send the mail from the native part of the
app.
- stefan
Patricia Shanahan
Oct 7, 2012, 2:54:26 PM10/7/12
to
Stefan Weiss wrote:
> On 2012-10-06 21:29, Patricia Shanahan wrote:
>> I could install scripts in my personal domain, but I don't think users
>> would want their data to go through my domain.
...
> On 2012-10-06 21:29, Patricia Shanahan wrote:
>> I could install scripts in my personal domain, but I don't think users
>> would want their data to go through my domain.
> Even Java applets can't send emails to random SMTP servers. In theory,
> they'd be powerful enough (for example with JavaMail, or by just opening
> a socket and speaking SMTP directly), but the default security
> restrictions will prevent them from connecting to anything but the
> originating host.
If I went with Java I would make it an application, not an applet. The
> they'd be powerful enough (for example with JavaMail, or by just opening
> a socket and speaking SMTP directly), but the default security
> restrictions will prevent them from connecting to anything but the
> originating host.
only reason for involving the browser is to get portability to iPad,
which is not Java friendly and seems to be positively hostile to
volunteer developers who don't own a Mac.
>
> From what I understand about your project, you have two options: the
> HTML+JS approach you described plus a server-side component, or you bite
> the bullet and build native apps for each target platform. You could
> still do most of the layout/navigation parts in HTML+JS, but your app
> will have to handle the email part.
data in the body of a message sent through a mailto URI. The downsides
are that I don't get the automatic transfer of the data from mail to
spreadsheet, and browsers have various URI length limits. I also have to
be very careful about line lengths.
I also have to provide some non-Internet transfer such as pasting the
data into a text editor. Some data may be too confidential to send
unencrypted over the Internet.
Patricia
Thomas 'PointedEars' Lahn
Oct 7, 2012, 4:12:48 PM10/7/12
to
Stefan Weiss wrote:
> On 2012-10-07 18:55, Thomas 'PointedEars' Lahn wrote:
>> Stefan Weiss wrote:
>>> I think sending attachments by email with JS alone (from an HTML
>>> document in a browser) is a lost cause, especially if it has to work on
>>> as many clients as possible. [...]
>>
>> Is that so? I have not found a single Web browser that, if an e-mail
>> client is installed and configured on the same system, does not support
>> code of the form
>>
>> window.location = "mailto:foo@bar?subject=baz&body=bla";
>
> I said "sending *attachments* by email" (and so does the subject).
ACK. But if you read the whole thread you will observe that this is only
> On 2012-10-07 18:55, Thomas 'PointedEars' Lahn wrote:
>> Stefan Weiss wrote:
>>> I think sending attachments by email with JS alone (from an HTML
>>> document in a browser) is a lost cause, especially if it has to work on
>>> as many clients as possible. [...]
>>
>> Is that so? I have not found a single Web browser that, if an e-mail
>> client is installed and configured on the same system, does not support
>> code of the form
>>
>> window.location = "mailto:foo@bar?subject=baz&body=bla";
>
> I said "sending *attachments* by email" (and so does the subject).
one part of the problem/question. Insofar the Subject was not well-chosen
either.
> I have not found a single web browser that could do that (haven't
> actually searched for one, either, to be honest).
`multipart/mixed; boundary="…"' as required per RFC 2046 does not work in
"Chromium 21.0.1180.89 Built on Debian wheezy/sid, running on Debian 6.0.6
(154005)" with Icedove 10.0.7. As a result, there is no attachment.
Because other header fields can be set in this environment, this suggests
that setting the Content-Type header field does not work in WebCore-based
browsers at all, which covers most mobile browsers today.
> Even in the simple case with no attachments, all the browser does is
> invoke a handler application which has been registered for "mailto:"
I am aware of that. I am also aware that many, if it not all, modern mobile
operating systems provide a built-in e-mail client that is designed to work
with the equally built-in Web browser.
> In theory, mobile apps could provide these host objects to their
> scripts, but why bother
> just send the mail from the native part of the app.
using a local Web application (via file:// and equivalents) is not having to
install another application and adding the requirements, and granting it the
permissions, that come along with that.
Patricia Shanahan
Oct 7, 2012, 7:43:07 PM10/7/12
to
Thomas 'PointedEars' Lahn wrote:
...
...
> Actually, you have presented e-mail as the ideal solution, and you have
> asked if there was a better way. Due to your limited experience with
> client-side scripting, that initial assessment might have been wrong.
...
> asked if there was a better way. Due to your limited experience with
> client-side scripting, that initial assessment might have been wrong.
Ah, I see the misunderstanding.
My primary question, reflected in the subject, was whether it is
possible to send e-mail with attachments from JavaScript. My own
research and experiments had suggest "No", but, recognizing my limited
experience with the language, I wanted to check my answer. My original
analysis was indeed correct, which is reassuring though disappointing.
Secondarily, I am also interested in alternative suggestions for a very
specific issue, getting tabular data I have in JavaScript data
structures in a browser on e.g. a tablet into a spreadsheet on a
workstation without transferring it through a specially set up server.
The server script approach is obvious, is discussed in many web pages I
have read, and is inappropriate for my situation.
Even if you distrust my judgment on the need to avoid server set-up, if
you are interested in the secondary question you can, if you like, think
of it as a hypothetical. Suppose a JS+HTML application were to exist
that had tabular data in JavaScript data structures, and needed to
transfer it to a spreadsheet on a workstation without using any special
server set-up. What would be the best ways to do it?
The simplest and most general solution I have thought of is to display
the data as CSV text, so that the user can select and copy it to the
clipboard. From there, they can do all sorts of things with it, subject
only to device limitations, including pasting it into the body of an
e-mail, or, pasting it into a text editor window and saving it, as a
.csv file, on a thumb drive.
Patricia
Patricia Shanahan
Oct 7, 2012, 8:09:36 PM10/7/12
to
Stefan Weiss wrote:
> On 2012-10-06 21:29, Patricia Shanahan wrote:
...
> On 2012-10-06 21:29, Patricia Shanahan wrote:
> From what I understand about your project, you have two options: the
> HTML+JS approach you described plus a server-side component, or you bite
> the bullet and build native apps for each target platform. You could
> still do most of the layout/navigation parts in HTML+JS, but your app
> will have to handle the email part.
...
> HTML+JS approach you described plus a server-side component, or you bite
> the bullet and build native apps for each target platform. You could
> still do most of the layout/navigation parts in HTML+JS, but your app
> will have to handle the email part.
The small native application idea is an interesting possibility. Java
might be a good choice of language for most devices. The same .jar files
would work on all devices with a JVM. It looks as though the Android API
includes javax.mail, so very similar source code could be compiled to
provide the Andriod application.
Once it works, if it turns out to be useful but needs iPad support, I
would bite the bullet, get over my admittedly unfair prejudice against
Macs based on the way they were in the 1980's, and buy a Mac to do iPad
development. In this approach, the piece that would need to be rewritten
would be small and simple.
Patricia
Thomas 'PointedEars' Lahn
Oct 7, 2012, 9:26:15 PM10/7/12
to
Patricia Shanahan wrote:
> […] Suppose a JS+HTML application were to exist that had tabular data in
In addition to the already discussed solutions, with client-side scripting
data can be collected and stored locally on the mobile device, with cookies
or DOM Storage (DOM Storage works best with file:// equivalents, non-trivial
data structures and larger amounts of data). It can be transferred from
that storage to a common data base (not necessarily: database) or *perhaps*
(I have not tried that yet) accessed from the workstation directly, when
both the mobile device and the workstation are within the same network again
or are otherwise connected to each other (cloud storage comes to mind; I
have not tried that yet either, but as long as it supports HTTP access that
could be feasible).
I have updated my testcase to show how Local Storage works on mobile devices
both with http:// and file:// equivalents
<http://PointedEars.de/scripts/test/dom/mailto>
But a Thick Client Web application (in an HTML document in a Web browser) is
capable of displaying those spreadsheets and charts by itself, so
transferring the data might not be necessary in the first place.
> The simplest and most general solution I have thought of is to display
> the data as CSV text, so that the user can select and copy it to the
> clipboard. From there, they can do all sorts of things with it, subject
> only to device limitations, including pasting it into the body of an
> e-mail, or, pasting it into a text editor window and saving it, as a
> .csv file, on a thumb drive.
That is another option. You can also generate and process JSON or XML, with
the additional advantage of transferring more structured information.
> […] Suppose a JS+HTML application were to exist that had tabular data in
> JavaScript data structures, and needed to transfer it to a spreadsheet on
> a workstation without using any special server set-up. What would be the
> best ways to do it?
That depends.
> a workstation without using any special server set-up. What would be the
> best ways to do it?
In addition to the already discussed solutions, with client-side scripting
data can be collected and stored locally on the mobile device, with cookies
or DOM Storage (DOM Storage works best with file:// equivalents, non-trivial
data structures and larger amounts of data). It can be transferred from
that storage to a common data base (not necessarily: database) or *perhaps*
(I have not tried that yet) accessed from the workstation directly, when
both the mobile device and the workstation are within the same network again
or are otherwise connected to each other (cloud storage comes to mind; I
have not tried that yet either, but as long as it supports HTTP access that
could be feasible).
I have updated my testcase to show how Local Storage works on mobile devices
both with http:// and file:// equivalents
<http://PointedEars.de/scripts/test/dom/mailto>
But a Thick Client Web application (in an HTML document in a Web browser) is
capable of displaying those spreadsheets and charts by itself, so
transferring the data might not be necessary in the first place.
> The simplest and most general solution I have thought of is to display
> the data as CSV text, so that the user can select and copy it to the
> clipboard. From there, they can do all sorts of things with it, subject
> only to device limitations, including pasting it into the body of an
> e-mail, or, pasting it into a text editor window and saving it, as a
> .csv file, on a thumb drive.
the additional advantage of transferring more structured information.
Patricia Shanahan
Oct 8, 2012, 2:18:39 AM10/8/12
to
Thomas 'PointedEars' Lahn wrote:
> Patricia Shanahan wrote:
>
>> […] Suppose a JS+HTML application were to exist that had tabular data in
>> JavaScript data structures, and needed to transfer it to a spreadsheet on
>> a workstation without using any special server set-up. What would be the
>> best ways to do it?
>
> That depends.
>
> In addition to the already discussed solutions, with client-side scripting
> data can be collected and stored locally on the mobile device, with cookies
> or DOM Storage (DOM Storage works best with file:// equivalents, non-trivial
> data structures and larger amounts of data). It can be transferred from
> that storage to a common data base (not necessarily: database) or *perhaps*
> (I have not tried that yet) accessed from the workstation directly, when
> both the mobile device and the workstation are within the same network again
> or are otherwise connected to each other (cloud storage comes to mind; I
> have not tried that yet either, but as long as it supports HTTP access that
> could be feasible).
I am certainly going to need storage for offline operation. In some
> Patricia Shanahan wrote:
>
>> […] Suppose a JS+HTML application were to exist that had tabular data in
>> JavaScript data structures, and needed to transfer it to a spreadsheet on
>> a workstation without using any special server set-up. What would be the
>> best ways to do it?
>
> That depends.
>
> In addition to the already discussed solutions, with client-side scripting
> data can be collected and stored locally on the mobile device, with cookies
> or DOM Storage (DOM Storage works best with file:// equivalents, non-trivial
> data structures and larger amounts of data). It can be transferred from
> that storage to a common data base (not necessarily: database) or *perhaps*
> (I have not tried that yet) accessed from the workstation directly, when
> both the mobile device and the workstation are within the same network again
> or are otherwise connected to each other (cloud storage comes to mind; I
> have not tried that yet either, but as long as it supports HTTP access that
> could be feasible).
cases, the data collection will happen offline, but the transfer of the
data to the workstation will be done in a WiFi Internet environment.
DOM storage seemed to me to be far more practical for a data table than
cookies.
I want to minimize the risk of data loss in case of e.g. the browser
being closed, so I plan to write data to DOM storage as I go along,
rather than waiting to the end of the observing session.
I'm planning to use JSON to turn individual observation records
into strings for storage. I'm currently planning to use the string
version of an integer sequence number, concatenated with a session
identifier, as the storage key.
> I have updated my testcase to show how Local Storage works on mobile devices
> both with http:// and file:// equivalents
> <http://PointedEars.de/scripts/test/dom/mailto>
from reading about it, but a worked example is often helpful.
>
> But a Thick Client Web application (in an HTML document in a Web browser) is
> capable of displaying those spreadsheets and charts by itself, so
> transferring the data might not be necessary in the first place.
other devices, and will be analyzed and reorganized, before ending up
summarized in graphs and tables in a scientific paper.
I've seen my lead user's office. He has an iPad, but he also has a
Windows workstation, and when he wanted to email me some of the result
files for a project, he used the workstation.
>
>> The simplest and most general solution I have thought of is to display
>> the data as CSV text, so that the user can select and copy it to the
>> clipboard. From there, they can do all sorts of things with it, subject
>> only to device limitations, including pasting it into the body of an
>> e-mail, or, pasting it into a text editor window and saving it, as a
>> .csv file, on a thumb drive.
>
> That is another option. You can also generate and process JSON or XML, with
> the additional advantage of transferring more structured information.
can read. XML is a possibility - I've used it several times in other
projects - but can Excel read JSON? CSV seems to be the most familiar to
the end users.
Patricia
Patricia Shanahan
Oct 8, 2012, 4:46:40 AM10/8/12
to
Patricia Shanahan wrote:
...
data into a Google Drive document, then save as text with a .csv
extension on the workstation.
I've used this to move data from the clipboard on an iPhone to a Windows
laptop. When the Firefox download manager reported completion, I just
clicked the file name in its window, and Excel came up with the correct
data.
Patricia
...
> The simplest and most general solution I have thought of is to display
> the data as CSV text, so that the user can select and copy it to the
> clipboard. From there, they can do all sorts of things with it, subject
> only to device limitations, including pasting it into the body of an
> e-mail, or, pasting it into a text editor window and saving it, as a
> .csv file, on a thumb drive.
I've found a particularly convenient variation on this idea - paste the
> the data as CSV text, so that the user can select and copy it to the
> clipboard. From there, they can do all sorts of things with it, subject
> only to device limitations, including pasting it into the body of an
> e-mail, or, pasting it into a text editor window and saving it, as a
> .csv file, on a thumb drive.
data into a Google Drive document, then save as text with a .csv
extension on the workstation.
I've used this to move data from the clipboard on an iPhone to a Windows
laptop. When the Firefox download manager reported completion, I just
clicked the file name in its window, and Excel came up with the correct
data.
Patricia
Thomas 'PointedEars' Lahn
Oct 8, 2012, 5:13:34 AM10/8/12
to
Patricia Shanahan wrote:
> Thomas 'PointedEars' Lahn wrote:
>> Patricia Shanahan wrote:
>>> […] Suppose a JS+HTML application were to exist that had tabular data in
>>> JavaScript data structures, and needed to transfer it to a spreadsheet
>>> on a workstation without using any special server set-up. What would be
>>> the best ways to do it?
>>
>> That depends.
>>
>> [Possibilities: DOM Storage, cloud storage]
> Thomas 'PointedEars' Lahn wrote:
>> Patricia Shanahan wrote:
>>> […] Suppose a JS+HTML application were to exist that had tabular data in
>>> JavaScript data structures, and needed to transfer it to a spreadsheet
>>> on a workstation without using any special server set-up. What would be
>>> the best ways to do it?
>>
>> That depends.
>>
>
> I am certainly going to need storage for offline operation. In some
> cases, the data collection will happen offline, but the transfer of the
> data to the workstation will be done in a WiFi Internet environment.
>
> DOM storage seemed to me to be far more practical for a data table than
> cookies.
The curious thing is that, contrary to my expectations, DOM Storage [1]
> I am certainly going to need storage for offline operation. In some
> cases, the data collection will happen offline, but the transfer of the
> data to the workstation will be done in a WiFi Internet environment.
>
> DOM storage seemed to me to be far more practical for a data table than
> cookies.
(about to be standardized as Web Storage [2]) also only allows you to store
string values. That is, the main advantage of Web storage over cookies is
that you can store more information there than in cookies (> 4 KiB).
If you want to store/retrieved structured data to/from Web Storage, you
still have to serialize/unserialize it. Which is a bit disappointing. One
would have expected the following to be possible in 21st century browser
scripting:
window.localStorage.setItem("foo", {bar: 42});
/* Object */
var item = window.localStorage.getItem("foo");
/* Number */
var bar = item.bar;
But you have to do:
window.localStorage.setItem("foo_bar", "42");
/* Number */
var bar = +window.localStorage.getItem("foo_bar");
or
window.localStorage.setItem("foo", JSON.stringify({bar: 42});
/* Object */
var item = JSON.parse(window.localStorage.getItem("foo"));
/* Number */
var bar = item.bar;
So you are probably about to write your own wrapper for Web Storage [3].
> I want to minimize the risk of data loss in case of e.g. the browser
> being closed, so I plan to write data to DOM storage as I go along,
> rather than waiting to the end of the observing session.
> I'm planning to use JSON to turn individual observation records
> into strings for storage.
> I'm currently planning to use the string version of an integer sequence
> number, concatenated with a session identifier, as the storage key.
would want to retrieve the data regardless of the session you are in (or are
you considering an application for several users on the same device? In that
case the session identifier should be the user ID). ISTM to be more
important that you use a proper prefix so that data from your application
separates itself from that of other applications.
>> But a Thick Client Web application (in an HTML document in a Web browser)
>> is capable of displaying those spreadsheets and charts by itself, so
>> transferring the data might not be necessary in the first place.
>
> The data from one device may have to be combined with data collected on
> other devices, and will be analyzed and reorganized, before ending up
> summarized in graphs and tables in a scientific paper.
>
> I've seen my lead user's office. He has an iPad, but he also has a
> Windows workstation, and when he wanted to email me some of the result
> files for a project, he used the workstation.
>>> The simplest and most general solution I have thought of is to display
>>> the data as CSV text, so that the user can select and copy it to the
>>> clipboard. From there, they can do all sorts of things with it, subject
>>> only to device limitations, including pasting it into the body of an
>>> e-mail, or, pasting it into a text editor window and saving it, as a
>>> .csv file, on a thumb drive.
>> That is another option. You can also generate and process JSON or XML,
>> with the additional advantage of transferring more structured
>> information.
>
> It does have to be a format that spreadsheet programs, especially Excel,
> can read. XML is a possibility - I've used it several times in other
> projects -
Spreadsheet (.xlsx) are XML-based, XML might be your best option with regard
to compatibility. However, it also has the greatest overhead of all formats
mentioned so far.
> but can Excel read JSON?
more.
> CSV seems to be the most familiar to the end users.
processing the code on the workstation that was generated by it on the
mobile device here.
PointedEars
___________
[1] <https://developer.mozilla.org/en-US/docs/DOM/Storage>
[2] <http://www.w3.org/TR/webstorage/>
[3] <http://stackoverflow.com/questions/2010892/storing-objects-in-html5-
localstorage>
[4] <http://www.w3.org/TR/html5/webappapis.html#events>
[5] <https://developer.mozilla.org/en-US/docs/HTML/HTML5>
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
Erwin Moller
Oct 8, 2012, 6:01:44 AM10/8/12
to
On 10/8/2012 10:46 AM, Patricia Shanahan wrote:
> Patricia Shanahan wrote:
<snip>
> I've found a particularly convenient variation on this idea - paste the
> data into a Google Drive document, then save as text with a .csv
> extension on the workstation.
>
> I've used this to move data from the clipboard on an iPhone to a Windows
> laptop. When the Firefox download manager reported completion, I just
> clicked the file name in its window, and Excel came up with the correct
> data.
>
> Patricia
I followed this thread with interest, but now I wonder:
Why is it acceptable to move the data into the "Google cloud", but not
acceptable to use your own webserver as intermediate?
Regards,
Erwin Moller
--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens
> Patricia Shanahan wrote:
<snip>
> I've found a particularly convenient variation on this idea - paste the
> data into a Google Drive document, then save as text with a .csv
> extension on the workstation.
>
> I've used this to move data from the clipboard on an iPhone to a Windows
> laptop. When the Firefox download manager reported completion, I just
> clicked the file name in its window, and Excel came up with the correct
> data.
>
> Patricia
Why is it acceptable to move the data into the "Google cloud", but not
acceptable to use your own webserver as intermediate?
Regards,
Erwin Moller
--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens
Thomas 'PointedEars' Lahn
Oct 8, 2012, 7:10:34 AM10/8/12
to
Patricia Shanahan wrote:
> Stefan Weiss wrote:
>> On 2012-10-06 21:29, Patricia Shanahan wrote:
>> From what I understand about your project, you have two options: the
>> HTML+JS approach you described plus a server-side component, or you bite
>> the bullet and build native apps for each target platform. You could
>> still do most of the layout/navigation parts in HTML+JS, but your app
>> will have to handle the email part.
>> [...]
>
> The small native application idea is an interesting possibility. […]
> Stefan Weiss wrote:
>> On 2012-10-06 21:29, Patricia Shanahan wrote:
>> From what I understand about your project, you have two options: the
>> HTML+JS approach you described plus a server-side component, or you bite
>> the bullet and build native apps for each target platform. You could
>> still do most of the layout/navigation parts in HTML+JS, but your app
>> will have to handle the email part.
>> [...]
>
> Once it works, if it turns out to be useful but needs iPad support, I
> would bite the bullet, get over my admittedly unfair prejudice against
> Macs based on the way they were in the 1980's, and buy a Mac to do iPad
> development. In this approach, the piece that would need to be rewritten
> would be small and simple.
You might also want to look into <http://phonegap.com/>. (This is not a
> would bite the bullet, get over my admittedly unfair prejudice against
> Macs based on the way they were in the 1980's, and buy a Mac to do iPad
> development. In this approach, the piece that would need to be rewritten
> would be small and simple.
recommendation, nor one against it.)
Daniel Pitts
Oct 8, 2012, 11:38:50 AM10/8/12
to
On 10/7/12 5:09 PM, Patricia Shanahan wrote:
> Once it works, if it turns out to be useful but needs iPad support, I
> would bite the bullet, get over my admittedly unfair prejudice against
> Macs based on the way they were in the 1980's, and buy a Mac to do iPad
> development.
I have to say, as someone who grew up on PC's, I found the switch to
> Once it works, if it turns out to be useful but needs iPad support, I
> would bite the bullet, get over my admittedly unfair prejudice against
> Macs based on the way they were in the 1980's, and buy a Mac to do iPad
> development.
modern Macs to be not just easy, but actually improved my productivity.
The first thing I noticed was, I used my thumb for more keyboard
short-cuts, rather than extending my pinky to press ctrl. This makes a
subtle but notable improvement in my efficiency. For the record, I'm
using a MacBook Pro from 2010.
There are other niceties as well. Most of them are small but cumulative.
I do like the fact that its BSD based, and I have a familiar bash
shell. If you judged *any* brand by how they were built in the 80's,
you'd be missing out on a whole lot :-)
Gene Wirchenko
Oct 8, 2012, 12:28:29 PM10/8/12
to
On Mon, 08 Oct 2012 09:46:40 +0100, Patricia Shanahan <pa...@acm.org>
wrote:
[snip]
>I've used this to move data from the clipboard on an iPhone to a Windows
>laptop. When the Firefox download manager reported completion, I just
>clicked the file name in its window, and Excel came up with the correct
>data.
Excel has a nasty habit of adjusting things. Be careful that
something like this does not happen to you:
http://catless.ncl.ac.uk/Risks/24.19.html#subj6.1
Sincerely,
Gene Wirchenko
wrote:
[snip]
>I've used this to move data from the clipboard on an iPhone to a Windows
>laptop. When the Firefox download manager reported completion, I just
>clicked the file name in its window, and Excel came up with the correct
>data.
something like this does not happen to you:
http://catless.ncl.ac.uk/Risks/24.19.html#subj6.1
Sincerely,
Gene Wirchenko
Patricia Shanahan
Oct 8, 2012, 1:34:01 PM10/8/12
to
a spreadsheet now, but doing it automatically increases the risk of a
Do-What-I-Think-You-Should-Mean change not being noticed.
Patricia
Patricia Shanahan
Oct 8, 2012, 1:57:36 PM10/8/12
to
Thomas 'PointedEars' Lahn wrote:
> Patricia Shanahan wrote:
...
> Patricia Shanahan wrote:
>> DOM storage seemed to me to be far more practical for a data table than
>> cookies.
...
>> cookies.
> So you are probably about to write your own wrapper for Web Storage [3].
I generally prefer to put a wrapper between the main application logic
and the actual I/O, unless the I/O API does it for me. It tends to
increase code reuse and simplify ports to different environments.
In this case, I don't have much choice. I need something like a stack of
objects, with ability to iterate over all objects in the stack. I'm
getting a map from string to string. If I let that mismatch spread into
the body of the code it would be an unmaintainable mess.
...
>> I'm currently planning to use the string version of an integer sequence
>> number, concatenated with a session identifier, as the storage key.
>
> A session identifier does not appear to me to be of much use here, for you
> would want to retrieve the data regardless of the session you are in (or are
> you considering an application for several users on the same device? In that
> case the session identifier should be the user ID). ISTM to be more
> important that you use a proper prefix so that data from your application
> separates itself from that of other applications.
I do need to keep sessions separate. They may be for different projects,
>> number, concatenated with a session identifier, as the storage key.
>
> A session identifier does not appear to me to be of much use here, for you
> would want to retrieve the data regardless of the session you are in (or are
> you considering an application for several users on the same device? In that
> case the session identifier should be the user ID). ISTM to be more
> important that you use a proper prefix so that data from your application
> separates itself from that of other applications.
and belong in different spreadsheets, even if collected by the same
user. I am planning to use a dedicated sub-domain to isolate the web
pages for this, but I need to deal with the case of downloading, so you
are right about also needing an application prefix.
>> It does have to be a format that spreadsheet programs, especially Excel,
>> can read. XML is a possibility - I've used it several times in other
>> projects -
>
> Yes, given that OpenDocument Spreadsheet (.ods, .fods) and Office Open XML
> Spreadsheet (.xlsx) are XML-based, XML might be your best option with regard
> to compatibility. However, it also has the greatest overhead of all formats
> mentioned so far.
for now, on direct mail, I'm not sure compactness is that important, but
I'm also unsure that the increased structure of XML brings any real
benefit in this context. Of course, I may implement one initially, and
add the other as an option if I get demand for it.
>> CSV seems to be the most familiar to the end users.
>
> I was thinking more along the lines of having the same application
> processing the code on the workstation that was generated by it on the
> mobile device here.
would be easy. Any code that only needs to run on the workstation can be
a Java application.
...
> [1] <https://developer.mozilla.org/en-US/docs/DOM/Storage>
> [2] <http://www.w3.org/TR/webstorage/>
> [3] <http://stackoverflow.com/questions/2010892/storing-objects-in-html5-
> localstorage>
> [4] <http://www.w3.org/TR/html5/webappapis.html#events>
> [5] <https://developer.mozilla.org/en-US/docs/HTML/HTML5>
Thanks for the links. I'll add them to my reading list.
> [2] <http://www.w3.org/TR/webstorage/>
> [3] <http://stackoverflow.com/questions/2010892/storing-objects-in-html5-
> localstorage>
> [4] <http://www.w3.org/TR/html5/webappapis.html#events>
> [5] <https://developer.mozilla.org/en-US/docs/HTML/HTML5>
Patricia
Patricia Shanahan
Oct 8, 2012, 2:16:27 PM10/8/12
to
Erwin Moller wrote:
> On 10/8/2012 10:46 AM, Patricia Shanahan wrote:
>> Patricia Shanahan wrote:
>
> <snip>
>
>> I've found a particularly convenient variation on this idea - paste the
>> data into a Google Drive document, then save as text with a .csv
>> extension on the workstation.
>>
>> I've used this to move data from the clipboard on an iPhone to a Windows
>> laptop. When the Firefox download manager reported completion, I just
>> clicked the file name in its window, and Excel came up with the correct
>> data.
>>
>> Patricia
>
> I followed this thread with interest, but now I wonder:
> Why is it acceptable to move the data into the "Google cloud", but not
> acceptable to use your own webserver as intermediate?
Part of the problem is that I don't have a web server, I have a domain
> On 10/8/2012 10:46 AM, Patricia Shanahan wrote:
>> Patricia Shanahan wrote:
>
> <snip>
>
>> I've found a particularly convenient variation on this idea - paste the
>> data into a Google Drive document, then save as text with a .csv
>> extension on the workstation.
>>
>> I've used this to move data from the clipboard on an iPhone to a Windows
>> laptop. When the Firefox download manager reported completion, I just
>> clicked the file name in its window, and Excel came up with the correct
>> data.
>>
>> Patricia
>
> I followed this thread with interest, but now I wonder:
> Why is it acceptable to move the data into the "Google cloud", but not
> acceptable to use your own webserver as intermediate?
hosting account, including Perl and PHP script hosting. It is not backed
up, which does not matter for my current use. I am also not particularly
concerned about security - the material I upload is all stuff I want
other people to see.
I can't make any promises about reliability, because I don't control the
server.
Also, being sure of getting the right data to the right place may
require accounts and passwords. Many potential users may be unwilling to
open an additional account to use the application, but already have
Google Docs accounts.
Patricia
Patricia Shanahan
Oct 8, 2012, 2:20:04 PM10/8/12
to
Thomas 'PointedEars' Lahn wrote:
> Patricia Shanahan wrote:
> Patricia Shanahan wrote:
...
>> The small native application idea is an interesting possibility. […]
>> Once it works, if it turns out to be useful but needs iPad support, I
>> would bite the bullet, get over my admittedly unfair prejudice against
>> Macs based on the way they were in the 1980's, and buy a Mac to do iPad
>> development. In this approach, the piece that would need to be rewritten
>> would be small and simple.
>
> You might also want to look into <http://phonegap.com/>. (This is not a
> recommendation, nor one against it.)
Thanks. I'll look into it and make my own decision on whether to use it.
>> The small native application idea is an interesting possibility. […]
>> Once it works, if it turns out to be useful but needs iPad support, I
>> would bite the bullet, get over my admittedly unfair prejudice against
>> Macs based on the way they were in the 1980's, and buy a Mac to do iPad
>> development. In this approach, the piece that would need to be rewritten
>> would be small and simple.
>
> You might also want to look into <http://phonegap.com/>. (This is not a
> recommendation, nor one against it.)
Patricia
0 new messages