<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.2" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: Sunshade 3.2.0 released</title>
	<link>http://simplygenius.com/geekblog/2007/02/24/sunshade-320-released/</link>
	<description>Matt Conway's blog - Keeping track of all my bits</description>
	<pubDate>Thu, 04 Dec 2008 21:05:48 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.2</generator>

	<item>
		<title>By: Steven Elliott</title>
		<link>http://simplygenius.com/geekblog/2007/02/24/sunshade-320-released/#comment-157</link>
		<author>Steven Elliott</author>
		<pubDate>Tue, 25 Mar 2008 04:16:24 +0000</pubDate>
		<guid>http://simplygenius.com/geekblog/2007/02/24/sunshade-320-released/#comment-157</guid>
		<description>I'm not sure if this is the best place for it, but I have some feedback on this, particularly the FileDrag plugin.

First, some background on where I'm coming from.  I'm also a developer who once wrote an Eclipse plugin.  I think I had a similar motivation - Eclipse lacks some functionality that I miss from my previous editor, Emacs (and so the name "Emacsish").  One of the things I miss about emacs is it's "emacsclient", which like "eclipseclient" can be used to trigger an existing Emacs instance to load a file from the command line.  I was thinking about writing something like this for Ecilpse, but you beat me to it.

Here are some of my thoughts about the FileDrag plugin:

1) Version 3.2.0 of eclipseclient-* does not seem to work with Eclipse 3.3 whereas latest CVS does.  Maybe part of the point your changes in latest CVS is to support Eclipse 3.3 in which case this does not surprise you.
2) I don't recall trying it in Eclipse 3.2, but drag and drop seems to be natively supported in Eclipse 3.3.  Specifically, if I drag something like "/etc/profile" in nautilus in Fedora 8 to Eclipse it works with or without the FileDrag plugin.  I set some breakpoints and it seems that the FileDrag code is not playing a role when the file is dragged over.  Maybe you want to try to detect the Eclipse version and disable the drag and drop functionality if it is Eclipse version 3.3 or later.
3) You enforce whether or not remote connections are allowed by checking if the remote address of the socket is the loopback address.  That approach is *probably* secure since if a remote host tried to forge its return IP address in the IP header the reply packets wouldn't route back to the remote host.  But it might just be simpler and more secure to bind to localhost instead of checking the remote address.
4) It would be nice if there was something more secure than accepting any local connection, but that's a harder problem to solve.  Some ideas:
  4a) The X cookie approach - Keep some secret piece of information in the user's home directory that is only readable by that user.  eclispeclient-* reads it and sends it to port 7400.  The FileDrag plugin verifies it.
  4b) Use named sockets on platforms that support it.  Permissions can be set on the named socket so only the user that started Eclipse is able to bind to it.  I don't know how this in done on Windows.

I might be willing to help with some of this, if you are interested.  Feel free to contact me.</description>
		<content:encoded><![CDATA[<p>I&#8217;m not sure if this is the best place for it, but I have some feedback on this, particularly the FileDrag plugin.</p>
<p>First, some background on where I&#8217;m coming from.  I&#8217;m also a developer who once wrote an Eclipse plugin.  I think I had a similar motivation - Eclipse lacks some functionality that I miss from my previous editor, Emacs (and so the name &#8220;Emacsish&#8221;).  One of the things I miss about emacs is it&#8217;s &#8220;emacsclient&#8221;, which like &#8220;eclipseclient&#8221; can be used to trigger an existing Emacs instance to load a file from the command line.  I was thinking about writing something like this for Ecilpse, but you beat me to it.</p>
<p>Here are some of my thoughts about the FileDrag plugin:</p>
<p>1) Version 3.2.0 of eclipseclient-* does not seem to work with Eclipse 3.3 whereas latest CVS does.  Maybe part of the point your changes in latest CVS is to support Eclipse 3.3 in which case this does not surprise you.<br />
2) I don&#8217;t recall trying it in Eclipse 3.2, but drag and drop seems to be natively supported in Eclipse 3.3.  Specifically, if I drag something like &#8220;/etc/profile&#8221; in nautilus in Fedora 8 to Eclipse it works with or without the FileDrag plugin.  I set some breakpoints and it seems that the FileDrag code is not playing a role when the file is dragged over.  Maybe you want to try to detect the Eclipse version and disable the drag and drop functionality if it is Eclipse version 3.3 or later.<br />
3) You enforce whether or not remote connections are allowed by checking if the remote address of the socket is the loopback address.  That approach is *probably* secure since if a remote host tried to forge its return IP address in the IP header the reply packets wouldn&#8217;t route back to the remote host.  But it might just be simpler and more secure to bind to localhost instead of checking the remote address.<br />
4) It would be nice if there was something more secure than accepting any local connection, but that&#8217;s a harder problem to solve.  Some ideas:<br />
  4a) The X cookie approach - Keep some secret piece of information in the user&#8217;s home directory that is only readable by that user.  eclispeclient-* reads it and sends it to port 7400.  The FileDrag plugin verifies it.<br />
  4b) Use named sockets on platforms that support it.  Permissions can be set on the named socket so only the user that started Eclipse is able to bind to it.  I don&#8217;t know how this in done on Windows.</p>
<p>I might be willing to help with some of this, if you are interested.  Feel free to contact me.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
