Changes
Jump to navigation
Jump to search
Line 25:
Line 25: − + + Line 53:
Line 54: − + − + − +
no edit summary
* Using email provider APIs like [https://developers.google.com/gmail/api/quickstart/js Gmail API]. This is a viable alternative, as it involves Oauth, which solves the user credentials problem, but with the disadvantage of tying the user to a specific
* Using email provider APIs like [https://developers.google.com/gmail/api/quickstart/js Gmail API]. This is a viable alternative, as it involves Oauth, which solves the user credentials problem, but with the disadvantage of tying the user to a specific
= Generating Body Text From Locally Stored User Data =
= Locally Stored User Data for Dynamic Email Generation =
To create ease of use for the generating the mail bodys, the site can store persistent reusable user data on the client machine using some feature enabling this.
To create ease of use for the generating the mail bodys, the site can store persistent reusable user data on the client machine using some feature enabling this.
= Data access considerations =
= Data access considerations =
* Except for SOLID, there seems to be no easy way to transfer locally saved content from one browser or computer to another.
This means it would be useful to give the user the option to convert anonymous client data into server backed registration data, or rather, just use SOLID.
* Except for SOLID, there seems to be no easy way to transfer locally saved content from one browser or computer to another. This means it would be useful to give the user the option to convert anonymous client data into server backed registration data, or rather, just use SOLID.
* As our predicted volume of used data fields will probably stay in double digits, asynch or synch requests should not make a big difference in performance, however, in general it is good practice not accessing any local data until it is to be read or wrote. Also good practice to read local data into RAM/some js object once it is necessary, and use it from there then on, and only touching the local copy of data when writing into it.
* As our predicted volume of used data fields will probably stay in double digits, asynch or synch requests should not make a big difference in performance, however, in general it is good practice not accessing any local data until it is to be read or wrote. Also good practice to read local data into RAM/some js object once it is necessary, and use it from there then on, only touching the local copy of data when writing into it.