Request for Comment.
A feature for the 0.91 release and going forwards.
The idea is for inkscape to have a way to alert our users about some goings on in the inkscape world 'in app'. This is needed because many users either download the app and fail to upgrade after that, or are not aware of anything beyond the app download. And for users who get inkscape through their package manager and are thus cut off from us.
An xml file would be made generated (and cached) on inkscape.org which would be controllable by the inkscape board by vote. It would contain a list of translated alert 'items' specific for an inkscape released version, each one would contain:
- unique id (int) - A subject (translated-text) - A body (translated-text) - A link (url) - Start Date (iso date) - Expire Date (iso date) - Importance (int)
This file would be downloaded every so often and cached locally. (default one month between updates). Stored in ~/.cache/inkscape/alerts-${inkscape-version}-${lang}.xml
When the app has been opened for a certain delayed time (default 3 seconds) it will check for alerts never shown before by id. It will then filter out any outside of the date range start-expire.
It will then check the user's preference for alerts (Developer-Notice(0), Community-Update(5), Important(10), Critical(15), Never(20)) and if >= display the alert[1] saving the fact it has displayed this alert-id.
[1] http://inkscape.org/en/gallery/item/704/
The importance might be reflected in an icon displayed. The user might be alerted by default to go to inkscape.org to register (and also check their alert settings if they never want to be disturbed)
Your thoughts on this proposal are needed.
Best Regards, Martin Owens
On Tue, Oct 14, 2014, at 01:26 PM, Martin Owens wrote:
Request for Comment.
An xml file would be made generated (and cached) on inkscape.org which would be controllable by the inkscape board by vote. It would contain a list of translated alert 'items' specific for an inkscape released version, each one would contain:
[SNIP]
Off hand that sounds like the an RSS feed or some basic web service. We probably want to see which standards and conventions we could use to get it implemented.
On Tue, Oct 14, 2014 at 04:26:16PM -0400, Martin Owens wrote:
Request for Comment.
A feature for the 0.91 release and going forwards.
The idea is for inkscape to have a way to alert our users about some goings on in the inkscape world 'in app'. This is needed because many users either download the app and fail to upgrade after that, or are not aware of anything beyond the app download. And for users who get inkscape through their package manager and are thus cut off from us.
An xml file would be made generated (and cached) on inkscape.org which would be controllable by the inkscape board by vote. It would contain a list of translated alert 'items' specific for an inkscape released version, each one would contain:
- unique id (int)
- A subject (translated-text)
- A body (translated-text)
- A link (url)
- Start Date (iso date)
- Expire Date (iso date)
- Importance (int)
This file would be downloaded every so often and cached locally. (default one month between updates). Stored in ~/.cache/inkscape/alerts-${inkscape-version}-${lang}.xml
When the app has been opened for a certain delayed time (default 3 seconds) it will check for alerts never shown before by id. It will then filter out any outside of the date range start-expire.
It will then check the user's preference for alerts (Developer-Notice(0), Community-Update(5), Important(10), Critical(15), Never(20)) and if >= display the alert[1] saving the fact it has displayed this alert-id.
[1] http://inkscape.org/en/gallery/item/704/
The importance might be reflected in an icon displayed. The user might be alerted by default to go to inkscape.org to register (and also check their alert settings if they never want to be disturbed)
Your thoughts on this proposal are needed.
Some thoughts based on IRC discussions:
* For IT security admin, we'll want to have a configure flag to enable/disable this feature. Enabled by default.
* It should be an opt-in service. On first usage the user should explicitly specify that they want the notifications. Might be slick to present this choice via the notification system, but just an ordinary dialog box would probably be fine too.
* We'll want the ability to categorize feeds so that users can switch them on or off according to their preferences. So for instance, one feed would be just about updates, a second feed brings updates on community events of interest, a third feed is Tips & Tricks, etc.
* We may want to think more about a DTD for the XML format
* A risk we'll need to design for is if someone spoofed our DNS to a different IP address and fed a malicious XML. How can we design it to be robust against this type of attack? E.g. ensure that nothing in the XML is interpreted or executed code, and that buffers can't be overrun, etc.
* We should probably brainstorm the full scope of use cases. If it turns out that we'd mostly only use this for update notifications, perhaps there's a simpler way of doing that? In that case we might look to firefox, vlc, chrome, and/or other applications that already do this.
* For update notifications, users will expect that once they acknowledge the message, it should smoothly proceed to download and installation of the new version with no more than 1-2 more button clicks required.
Bryce
Best Regards, Martin Owens
Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Tue, Oct 14, 2014, at 03:19 PM, Bryce Harrington wrote:
- We may want to think more about a DTD for the XML format
Eeeek!!!
DTDs are soooo last century. XML Schema and/or RelaxNG are probably the items to consider. However... leveraging an existing standard such as some of the RSS ones might be best.
On Tue, Oct 14, 2014 at 03:25:46PM -0700, Jon A. Cruz wrote:
On Tue, Oct 14, 2014, at 03:19 PM, Bryce Harrington wrote:
- We may want to think more about a DTD for the XML format
Eeeek!!!
DTDs are soooo last century. XML Schema and/or RelaxNG are probably the items to consider. However... leveraging an existing standard such as some of the RSS ones might be best.
Ahem, you were the one that brought it up! ;-)
"<JonCruz> everytime some software reads an XML doc, it might be looking to the web for the DTD"
But yea, reusing RSS maybe makes sense. I think martin has a few extra fields beyond what's in RSS though.
-- Jon A. Cruz jon@...18...
Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Tue, Oct 14, 2014, at 03:53 PM, Bryce Harrington wrote:
On Tue, Oct 14, 2014 at 03:25:46PM -0700, Jon A. Cruz wrote:
On Tue, Oct 14, 2014, at 03:19 PM, Bryce Harrington wrote:
- We may want to think more about a DTD for the XML format
Eeeek!!!
DTDs are soooo last century. XML Schema and/or RelaxNG are probably the items to consider. However... leveraging an existing standard such as some of the RSS ones might be best.
Ahem, you were the one that brought it up! ;-)
"<JonCruz> everytime some software reads an XML doc, it might be looking to the web for the DTD"
But yea, reusing RSS maybe makes sense. I think martin has a few extra fields beyond what's in RSS though.
Actually... incorrect RSS implementations are the poster child for this. They were supposed to use the URI as just an identifier, but instead treated it as a live web resource. Thus when the one site stopped hosting the RSS DTD at a given spot, readers died left and right.
:-)
On Tue, 2014-10-14 at 15:19 -0700, Bryce Harrington wrote:
- It should be an opt-in service. On first usage the user should explicitly specify that they want the notifications. Might be slick to present this choice via the notification system, but just an ordinary dialog box would probably be fine too.
So the idea would be to have it enabled, then because every notification allows you to turn it off, have the first-run notifier act as the opt-in/out. I'd prefer it that way so people can specify which types they want or just say no thanks to them all without just pressing 'continue' and thus no thanks. (if that makes sense)
- We'll want the ability to categorize feeds so that users can switch them on or off according to their preferences. So for instance, one feed would be just about updates, a second feed brings updates on community events of interest, a third feed is Tips & Tricks, etc.
Sounds good. Didn't want to over think it, but it makes sense to have these for the preferences.
- For update notifications, users will expect that once they acknowledge the message, it should smoothly proceed to download and installation of the new version with no more than 1-2 more button clicks required.
Tricky, we can't do automatic installs (it's a hydra of a thing) but a solid link to a download page is certainly doable.
Martin,
participants (3)
-
Bryce Harrington -
Jon A. Cruz -
Martin Owens