<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: scripting GNOME</title>
	<atom:link href="http://blogs.gnome.org/otte/2008/09/09/scripting-gnome/feed/" rel="self" type="application/rss+xml" />
	<link>http://blogs.gnome.org/otte/2008/09/09/scripting-gnome/</link>
	<description>Just another GNOME Blogs weblog</description>
	<lastBuildDate>Fri, 20 Nov 2009 09:10:00 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.6</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: otte</title>
		<link>http://blogs.gnome.org/otte/2008/09/09/scripting-gnome/comment-page-1/#comment-755</link>
		<dc:creator>otte</dc:creator>
		<pubDate>Wed, 10 Sep 2008 06:15:32 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/otte/2008/09/09/scripting-gnome/#comment-755</guid>
		<description>Janne, I&#039;m talking about the second thing (and I do believe sripts should be able to RemoveSong). What I&#039;m talking about is getting people without an SVN account and without review to submit code, because frankly, I often can&#039;t be bothered to write bug reports and discuss about a feature I want in an app. Especially if it gets rejected later, even though I know a bunch of people who like it.

Chris, I think Kross is more on one level with gobject-introspection. And (just like gobject-introspection) it doesn&#039;t look like it tackles security at all.</description>
		<content:encoded><![CDATA[<p>Janne, I&#8217;m talking about the second thing (and I do believe sripts should be able to RemoveSong). What I&#8217;m talking about is getting people without an SVN account and without review to submit code, because frankly, I often can&#8217;t be bothered to write bug reports and discuss about a feature I want in an app. Especially if it gets rejected later, even though I know a bunch of people who like it.</p>
<p>Chris, I think Kross is more on one level with gobject-introspection. And (just like gobject-introspection) it doesn&#8217;t look like it tackles security at all.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chris Parker</title>
		<link>http://blogs.gnome.org/otte/2008/09/09/scripting-gnome/comment-page-1/#comment-754</link>
		<dc:creator>Chris Parker</dc:creator>
		<pubDate>Tue, 09 Sep 2008 17:52:50 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/otte/2008/09/09/scripting-gnome/#comment-754</guid>
		<description>What about something like Kross?

http://techbase.kde.org/Development/Tutorials/Kross-Tutorial</description>
		<content:encoded><![CDATA[<p>What about something like Kross?</p>
<p><a href="http://techbase.kde.org/Development/Tutorials/Kross-Tutorial" rel="nofollow">http://techbase.kde.org/Development/Tutorials/Kross-Tutorial</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Janne</title>
		<link>http://blogs.gnome.org/otte/2008/09/09/scripting-gnome/comment-page-1/#comment-753</link>
		<dc:creator>Janne</dc:creator>
		<pubDate>Tue, 09 Sep 2008 12:48:00 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/otte/2008/09/09/scripting-gnome/#comment-753</guid>
		<description>Aren&#039;t you mixing the idea of scripting applications a la Applescript or Bash on one hand; and implementing applications by means of scripting on top of a base implementation on the other? 

What most people are talking about is the second thing, not the first, and security is basically a non-issue since the scripting layer needs full, unhindered access to every nook and cranny of the base layer (having RemoveSong not be avaialbe to scripting would be like not allowing the Emacs lisp engine access to delete-word).</description>
		<content:encoded><![CDATA[<p>Aren&#8217;t you mixing the idea of scripting applications a la Applescript or Bash on one hand; and implementing applications by means of scripting on top of a base implementation on the other? </p>
<p>What most people are talking about is the second thing, not the first, and security is basically a non-issue since the scripting layer needs full, unhindered access to every nook and cranny of the base layer (having RemoveSong not be avaialbe to scripting would be like not allowing the Emacs lisp engine access to delete-word).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Sam Thursfield</title>
		<link>http://blogs.gnome.org/otte/2008/09/09/scripting-gnome/comment-page-1/#comment-752</link>
		<dc:creator>Sam Thursfield</dc:creator>
		<pubDate>Tue, 09 Sep 2008 12:36:56 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/otte/2008/09/09/scripting-gnome/#comment-752</guid>
		<description>I&#039;m quite happy with RemoveSong() being exposed, /as long as the script is reversible/. If I run a script and it deletes all my songs, my first thought is to undo, and if this works I have no complains.</description>
		<content:encoded><![CDATA[<p>I&#8217;m quite happy with RemoveSong() being exposed, /as long as the script is reversible/. If I run a script and it deletes all my songs, my first thought is to undo, and if this works I have no complains.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
