Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #16308 > unrolled thread

Sending email with attachments

Back to article view | Back to comp.lang.javascript

Contents

  Sending email with attachments Patricia Shanahan <pats@acm.org> - 2012-10-01 22:49 -0700
    Re: Sending email with attachments Scott Sauyet <scott.sauyet@gmail.com> - 2012-10-02 04:20 -0700
      Re: Sending email with attachments Scott Sauyet <scott.sauyet@gmail.com> - 2012-10-02 05:16 -0700
        Re: Sending email with attachments Patricia Shanahan <pats@acm.org> - 2012-10-02 07:10 -0700
          Re: Sending email with attachments Scott Sauyet <scott.sauyet@gmail.com> - 2012-10-02 10:57 -0700
      Re: Sending email with attachments Patricia Shanahan <pats@acm.org> - 2012-10-02 07:03 -0700
        Re: Sending email with attachments Scott Sauyet <scott.sauyet@gmail.com> - 2012-10-02 10:50 -0700
          Re: Sending email with attachments Patricia Shanahan <pats@acm.org> - 2012-10-02 11:16 -0700
            Re: Sending email with attachments dann90038@gmail.com - 2012-10-02 12:15 -0700
        Re: Sending email with attachments "Tom de Neef" <tdeneef@qolor.nl> - 2012-10-02 21:28 +0200
          Re: Sending email with attachments Patricia Shanahan <pats@acm.org> - 2012-10-02 12:59 -0700
    Re: Sending email with attachments Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-02 22:26 +0200
      Re: Sending email with attachments Patricia Shanahan <pats@acm.org> - 2012-10-03 20:04 +0100
      Re: Sending email with attachments Patricia Shanahan <pats@acm.org> - 2012-10-06 02:07 +0100
        Re: Sending email with attachments Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-06 08:48 +0200
          Re: Sending email with attachments Patricia Shanahan <pats@acm.org> - 2012-10-06 20:29 +0100
            Re: Sending email with attachments Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-06 21:49 +0200
              Re: Sending email with attachments Patricia Shanahan <pats@acm.org> - 2012-10-07 08:13 +0100
                Re: Sending email with attachments Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-07 14:28 +0200
                  Re: Sending email with attachments Patricia Shanahan <pats@acm.org> - 2012-10-08 00:43 +0100
                    Re: Sending email with attachments Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-08 03:26 +0200
                      Re: Sending email with attachments Patricia Shanahan <pats@acm.org> - 2012-10-08 07:18 +0100
                        Re: Sending email with attachments Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-08 11:13 +0200
                          Re: Sending email with attachments Patricia Shanahan <pats@acm.org> - 2012-10-08 18:57 +0100
                    Re: Sending email with attachments Patricia Shanahan <pats@acm.org> - 2012-10-08 09:46 +0100
                      Re: Sending email with attachments Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-10-08 12:01 +0200
                        Re: Sending email with attachments Patricia Shanahan <pats@acm.org> - 2012-10-08 19:16 +0100
                      Re: Sending email with attachments Gene Wirchenko <genew@ocis.net> - 2012-10-08 09:28 -0700
                        Re: Sending email with attachments Patricia Shanahan <pats@acm.org> - 2012-10-08 18:34 +0100
            Re: Sending email with attachments Stefan Weiss <krewecherl@gmail.com> - 2012-10-07 12:46 +0200
              Re: Sending email with attachments Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-07 18:55 +0200
                Re: Sending email with attachments Stefan Weiss <krewecherl@gmail.com> - 2012-10-07 20:06 +0200
                  Re: Sending email with attachments Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-07 22:12 +0200
              Re: Sending email with attachments Patricia Shanahan <pats@acm.org> - 2012-10-07 19:54 +0100
              Re: Sending email with attachments Patricia Shanahan <pats@acm.org> - 2012-10-08 01:09 +0100
                Re: Sending email with attachments Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-08 13:10 +0200
                  Re: Sending email with attachments Patricia Shanahan <pats@acm.org> - 2012-10-08 19:20 +0100
                OT: Mac vs PC for development  (Was: Sending email with attachments) Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-10-08 08:38 -0700
    Re: Sending email with attachments Dr J R Stockton <reply1240@merlyn.demon.co.uk.invalid> - 2012-10-03 19:49 +0100
      Re: Sending email with attachments Eli the Bearded <*@eli.users.panix.com> - 2012-10-03 23:08 +0000
        Re: Sending email with attachments Patricia Shanahan <pats@acm.org> - 2012-10-04 02:46 +0100
          Re: Sending email with attachments Scott Sauyet <scott.sauyet@gmail.com> - 2012-10-03 19:42 -0700
      Re: Sending email with attachments Patricia Shanahan <pats@acm.org> - 2012-10-04 02:43 +0100
        Re: Sending email with attachments Scott Sauyet <scott.sauyet@gmail.com> - 2012-10-03 19:54 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#16458

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 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.


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:Xns9FB6521286DB8invalidcom@94.75.214.39>

[toc] | [prev] | [next] | [standalone]

#16461

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
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>

I'll read your code with interest. I think I understand DOM storage,
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.

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 - but can Excel read JSON? CSV seems to be the most familiar to
the end users.

Patricia

[toc] | [prev] | [next] | [standalone]

#16463

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]
> 
> 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] 
(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.

Good idea.  Events [4, 5] will come in handy there.
 
> I'm planning to use JSON to turn individual observation records
> into strings for storage.

So you have noticed :)

> 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.
 
>> 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.

Fair enough.

>>> 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 - 

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.

> but can Excel read JSON?

I think that native support is very unlikely.  See <http://json.org/> for 
more.

> 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.


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

[toc] | [prev] | [next] | [standalone]

#16479

Thomas 'PointedEars' Lahn wrote:
> Patricia Shanahan wrote:
...
>> DOM storage seemed to me to be far more practical for a data table than
>> 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,
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.

And .csv seems to be the most compact. Now that I've given up, at least
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.

I may decide to do some post-processing on the workstation, but that
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.

Patricia

[toc] | [prev] | [next] | [standalone]

#16462

Patricia Shanahan wrote:
...
> 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
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

[toc] | [prev] | [next] | [standalone]

#16464

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

[toc] | [prev] | [next] | [standalone]

#16481

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
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

[toc] | [prev] | [next] | [standalone]

#16477

On Mon, 08 Oct 2012 09:46:40 +0100, Patricia Shanahan <pats@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

[toc] | [prev] | [next] | [standalone]

#16478

Gene Wirchenko wrote:
> On Mon, 08 Oct 2012 09:46:40 +0100, Patricia Shanahan <pats@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
> 

Thanks for the pointer. Generally, the data is being manually entered in
a spreadsheet now, but doing it automatically increases the risk of a
Do-What-I-Think-You-Should-Mean change not being noticed.

Patricia

[toc] | [prev] | [next] | [standalone]

#16444

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.

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

[toc] | [prev] | [next] | [standalone]

#16449

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 
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 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";

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.

You do not have to send the e-mail from the browser.

> 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.

Neither one may be necessary.


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$8300dec7@news.demon.co.uk> (2004)

[toc] | [prev] | [next] | [standalone]

#16451

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).

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

[toc] | [prev] | [next] | [standalone]

#16454

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 
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).

Setting the Content-Type header field of the generated message to 
`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:"
> links. […]

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

It would be interesting to find out and very useful.

> just send the mail from the native part of the app.

That is assuming that there is an app in the first place.  One reason for 
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.


PointedEars
-- 
var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
)  // Plone, register_function.js:16

[toc] | [prev] | [next] | [standalone]

#16452

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.
...
> 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
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.

There is a third option of abandoning sending attachments. I can put
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

[toc] | [prev] | [next] | [standalone]

#16457

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. 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

[toc] | [prev] | [next] | [standalone]

#16465

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. […]
> 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.)


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

[toc] | [prev] | [next] | [standalone]

#16482

Thomas 'PointedEars' Lahn 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.

Patricia

[toc] | [prev] | [next] | [standalone]

#16474 — OT: Mac vs PC for development (Was: Sending email with attachments)

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 
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 :-)

[toc] | [prev] | [next] | [standalone]

#16364

In comp.lang.javascript message <JqadnXQNAdXTHffNnZ2dnUVZ_qSdnZ2d@earthl
ink.com>, Mon, 1 Oct 2012 22:49:04, Patricia Shanahan <pats@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.

[toc] | [prev] | [next] | [standalone]

#16368

In comp.lang.javascript,
Dr J R Stockton  <reply1240@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
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

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web