I’ve been looking into the use of eBay from an Eclipse RCP. The good news is that it works; at least, I’ve had some success. eBay provides a site for developers where you can get a software developer’s kit (SDK) that includes almost everything you need (more complete examples would be nice) including documentation, examples, and Java libraries. The libraries are Apache Axis-generated web services code (generated from a provided WSDL file). In addition to the SDK, eBay provides a “development sandbox” which is an complete “fake” eBay that works exactly like the “real” eBay with the exception that all the users and auction items are completely bogus (i.e. no articles or money changes hands). The idea is that you can test against the sandbox without losing too much sleep over mistakes. You can access the sandbox from your favourite web browser just as easily as you access the real site. However, to access the sandbox using the web services API, you need to register. When you register, you are given a set of credentials that you need to use with every eBay API call.

One curious thing that I’ve run into is the way that you login to eBay from an RCP application. In short… you don’t. While it is possible to provide a user name and password, it’s not supported by most calls. The SDK documentation states:

“As of the version 361 release, the use of a user name and password to authenticate the requester of a call is deprecated for most calls. Most calls that attempt user authentication with a user name and password will fail with an error. Applications must use authentication tokens for the authentication of these calls.”

To do just about anything interesting, you need to get a token. You can get a token in two ways and both require web access. If you’re building a web application, you need to redirect the user to an eBay-provided web page which will take care of user authentication and then redirect the user back to your site with the token embedded in the request (which you can then extract and use on your own API calls). If you’re building an RCP application, you still need to send the user to the eBay website to generate a token, but then you must use the APIs to query for the token. It’s all a little weird, but it makes sense (at least at some level). Although I haven’t found it explicitly stated (yet), it seems that the good people at eBay don’t want third party vendors to have access to their user’s eBay passwords (once you have the token, you can get the user name). eBay is just protecting itself: I imagine that it would only take a few malicious vendors hijacking user login information to taint eBay’s generally good reputation.

Unfortunately, while the documentation does seem to be pretty complete in explaining what needs to be done, I haven’t been able to find any really good examples. What you’re supposed to do is something along the following lines:

• Determine a “unique authentication identifier” for your application (called an “runame”). The runame is determined using an API call to eBay.
• Create a “special id” (sid) that is unique. The documentation recommends using a Universally Unique Identifier (UUID); Java 5 includes a java.util.UUID class to generate these (there are other implementations that will work with Java 1.4.x).
• Open a browser and direct the user to the eBay login site with the runame and sid included as parameters.
• To sign in to the sandbox, the URL looks like this:
  https://signin.sandbox.ebay.com/ws/eBayISAPI.dll?SignIn&runame=XXX&sid=XXX
• When the user is done, you make an API call (FetchTokenCall) with the runame and sid as parameters to retrieve the token.

Once you have the token, you’re in business. In the process of logging in, the eBay site attempts to make sure that the user is aware of the inherent risks of using your software and makes them agree that they are indeed comfortable with the risk before actually creating the token.

In an Eclipse RCP, this is relatively straightforward to use (if not a little odd and painful from the user’s perspective):

• Open a browser that points to the login URL
• Open a modal dialog box with an “Ok” and “Cancel” button
• When the user clicks “Ok”, go and get the token. Once you have the token, you’re away!
• When the user clicks “Cancel”, bail out.

I’ve almost got it all working. The documentation says that in order to actually get the token, you need to provide the application’s user id and password in the call. I haven’t quite sorted out which user id and password that is. And, I can’t seem to find any help. Has anybody out there sorted this out yet?

When I do get this working, I’ll post some sample code.

On September 15th/2005, I wrote about the WebTools Project (WTP) and some issues that I encountered while trying to create a client for a web service in a plug-in. It turns out that this support is in-plan for version 1.0.

In a response to bug #109625, Chris Brealey wrote:

WTP 1.0 will allow you to generate Apache Axis clients to normal Java projects, which should include plug-in projects. Whether via “project facets” or some other more basic mechanism*, the tools will insure the necessary jars are available on the build path of the project so that your generated Axis client code compiles.

Chris goes on to talk about some work they’re doing to make it possible to use an arbitrary version of Apache Axis as well. If this is an issue that you care about, please take a look at bug #109625 and post your comments.

BTW: There is a milestone build (1.0M8) available for WTP.

At the Eclipse Foundation, we tend to eat our own dog food. Foundation employees use Eclipse itself to generate content for the website (I can’t speak for individual project teams, but I’m pretty sure that most of them do as well). In particular, we use PHPEclipse to create and edit most of the content (which makes pretty heavy use of PHP). I’ve just recently started using the 1.1.7 version which prereqs the web tools project. All-in-all, it’s pretty cool stuff.

One of the neater features of PHPEclipse is integration with XAMPP. XAMPP is a distribution of several open source products including Apache HTTP Server with PHP support and MySQL; it’s a one-click (more or less) install of a collection of key products for testing web applications. Essentially, you configure the Apache installation within XAMPP to have its DocumentRoot point at your workspace and Apache will serve up whatever you’ve got saved there. PHPEclipse provides a view with a browser that automatically updates whenever you save a PHP file you’re editing. It also works for HTML files. It’s not quite a WYSIWYG editor, but it’s the next best thing (you edit in HTML and the view shows you what it’s going to look like). You can even test database interaction by configuring MySQL.

PHPEclipse even provides some handy buttons in the toolbar to start and stop the XAMPP package with a single click.

There is an unfortunate security hole in setting this up. By configuring Apache to serve content from your Eclipse workspace, you are essentially making public anything you have loaded there. It might make sense to keep a separate workspace (or perhaps a separate directory with the web projects) for your web content. On the plus side, Apache is by default configured not to serve up directory listings so anybody who wants to peek at your workspace contents is not going to have a super easy time of it. I’ve been toying with sorting out how to prevent Apache from serving content to anybody but localhost; I’m pretty sure this is possible, but have never tried to make it happen.

Anyway, the combination of PHPEclipse, Web Tools, and XAMPP is pretty cool.

Yesterday, I wrote about the ability to drop URLs onto an SWT component. I’ll pause for a couple of minutes while you go back and review it…

I found an entry in Bugzilla (bug #100095) that’s asking for the URLTransfer class to be made public. It seems that the functionality is under development. In the meantime, using the TextTransfer may be a good enough workaround depending on what you need to do (as long as you don’t require the ability to drag links off an Internet Explorer page). You’ll have t use some smarts to determine if it’s just a bunch of text being dropped, or if it’s a URL.

There are a bunch of other Transfer types that let you capture such things as dropped HTML and RTF text.

I was asked a question today about whether or not Eclipse RCP can integrate with Firefox. The short answer is “yes”. The longer answer is “what do you mean by ‘integrate’?”.

An RCP application can, for example, be the drop target of a link dragged off a browser. SWT code snippet #84 shows how you can build a drag and drop source and target. Firefox seems to do the drag part a little different from the way that Internet Explorer. With both, you can drag a link from the address bar. With Firefox, you can drag links from within the page content to the running example. However, with Internet Explorer this doesn’t work.

When a drop event occurs, its contents are potentially represented in multiple formats and the drop target can pick what formats it wants to accept. You specify the types to accept by providing a org.eclipse.swt.dnd.DropTarget with an array of org.eclipse.swt.dnd.Transfer instances (subclasses, actually); it is the transfer objects that are responsible for determining what types of objects can be dropped and ultimately for decoding the contents of the event data. Snippet #84 uses an org.eclipse.swt.dnd.TextTransfer instance which facilitates the dropping of text. Unfortunately, a drop from a link from Internet Explorer is not provided in the text format, so the drop is denied (it does work for drag events that originate from the address bar). You can figure out what types are loaded in the drop event by running snippet #83.

There is an org.eclipse.swt.dnd.HtmlTransfer which sounds promising, but doesn’t do the job (this is intended for the case when you drag and drop a chunk of HTML text). Even more promising is the org.eclipse.swt.dnd.URLTransfer class, but it also doesn’t appear to work (and is not actually visible outside the package anyway). I haven’t yet been able to find a transfer instance that does the job. Snippet #83 actually provides a custom implementation that looks promising; I may go that route. I’ll let you know how it works out. Whatever the case, even though it works, it doesn’t seem right to accept a URL in text format if you really are expecting a URL…

I’m going to play with this a little longer and then maybe open a bug report if it makes sense. I’m also going to see how this all works in Linux. More later.

If you’re using RCP or even Eclipse itself, you’re using SWT. So… who’s using SWT? Lots of folks are. Ian Skerrett gave some examples of folks using RCP (and SWT by extension) in an blog entry several months back.

If you’re using RCP/Eclipse, you’ve also been using Eclipse’s OSGi implementation. You can find out more about what Eclipse is doing with OSGi by visiting the Equinox project page.

[Updated Sept. 20/05 to fix misspelling of Ian’s last name. Yikes and apologies…]

I guess that the name “Rich Client Platform” should be a tip-off that applications built using RCP technology can extend beyond the desktop. Essentially… if you have a client, it seems that you should probably also have a server.

Last night, I started build a collection of views (with an underlying model, of course) that display the value of a handful of stocks I hold. I’m sure that this kind of functionality exists somewhere else, but I’m going through a period where pretty much everything I do is in Eclipse (that is, Eclipse has more-or-less become my desktop) and I wanted to display this sort of information on my desktop. Besides, I’ve been looking for reasonably interesting things to implement as RCP components. The calculation is not completely trivial (mostly trivial, but not completely): as a Canadian, I am interested in the value of these holdings in my national currency and all of my current holdings are valued in US dollars. It was with some excitement that I realized that there is potential here to make use of two different web services: one to obtain the current trading price of a stock, and one to obtain the current exchange rate.

From a web services point-of-view, this is pretty simple RPC stuff. No attachments. No security. No transactions. Dead simple stuff, really. I’m certainly not what I might consider a web services expert, but I assumed that it would be pretty easy to put together what I needed. I used Google to find a couple of service providers. I discovered the BindingPoint site which provides a searchable index of web services and even allows you to dynamically test web services. Like I said, I’m no expert in web services, but this seems like a pretty handy resource (anybody out there have any experiences–positive or negative–with BindingPoint?)

So, I obtained the WSDL for the web services and used the Web Tools (WTP) feature in Eclipse to build a web services client. I stumbled a little bit at the discovery that I needed to actually define an application server before I could generate a web service client; it seems odd to me that you need to have a server in order to define a client (but maybe that just shows how little I know about web services). Anyway, I installed Tomcat 5.5 and configured a server instance for it in the WTP preferences. After that, the generation of the client was a snap. With one hitch (okay, more of a cascading series of hitches)…

WTP generates client code into a web project only. That is, it only generates clients that run in the servlet container of an application server (which may be why a server must be defined). “No problem”, I thought as a I copied the generated package into a new plug-in project. “Big problem”, I thought as I watched the little red Xs appear. The generated code, it turns out, requires access to Apache Axis (if I had more experience with web services, I might have expected this). After a couple of minutes of poking around (and a little moping) I found an org.apache.axis plug-in which was included with WTP. “Great!”, I thought as I added this plug-in to my dependencies. “Rats!”, I muttered as I watched most–but not all–of the little red Xs disappear.

The org.apache.axis plug-in doesn’t export all the classes that the generated code uses. In particular, it doesn’t export the javax.xml.rpc, or javax.xml.namespace packages. I decided on a two-pronged assault on the problem: first, I created a new version of the org.apache.axis package and exported the required packages in it; second, I created a bug report asking for it to be changed. With the change in place, everything works perfectly.

I decided to generalize the problem a little in the bug report. What I’d really like to do is be able to generate a web service directly into a plug-in. If you’re curious, it’s bug #109625.

Strictly speaking, I haven’t actually turned this into an “RCP” application yet. However, my next step is to roll this little collection of plug-ins into another RCP project I have in the works.

[Updated on Sept. 20/05 to fix the title.]

Check out the SWT site for some screen shots of many of the widgets included with SWT. Be sure to take a look at the snippets page for help on using ‘em.

In my previous posting, I suggested that “scavenging, borrowing, and blatantly copy code” is the staple of modern software development; this is, of course, true. However, there are caveats to consider, both legal and technical.

Legally, you need to be aware of the license that governs the code you’re copying. If the license permits it, you’re good-to-go. In some cases, the license may ask for attribution; that is, the license may require that you include a comment in your code that indicates where you got it from and who owns the original work. Pay heed to the wording of the license, because there may be restrictions or requirements on "derivative works" (e.g. you may be legally obligated to release your derivative work under the same license).

From a technical point-of-view, wholesale duplication of code is something to avoid. I remember a demo for a new product I attended many years ago in which the demonstrator was showing us how easy the product was to extend. "All you have to do is copy this 800-line long method and change these two lines at the end. See how easy it is?". The presenter missed an important point. What happens when those original 800 lines get updated? By copying all that code, they had worked themselves into a dangerous support position. What might previously have been a single branch of code became two separate but mostly identical branches that both need to be maintained (i.e. when the original changes, so must the copy). And who knows… over time more branches might be added, amplifying the developing support nightmare. The moral is that wholesale duplication is rarely good.

As a general rule, if you find that you need to copy lots of code, then chances are a better solution might be to refactor the existing code to make it more easily extended. And chances are that before you refactor, you may be able to find another way do what you need to do without duplication (refactoring existing code is not always possible; check the license).

So what kind of copying is good? In my previous posting, I was attempting to allude to copying idioms out of existing code. Recently, I needed to build a table in SWT and couldn’t remember how to do it (my brain capacity is too limited for me to memorize such things). I used the search capabilities in Eclipse to find code that builds a table using org.eclipse.jface.viewers.TableViewer as a starting point (I do remember some things). After about a minute, I found an appropriate example, copied it, and changed it to do what I needed. In the end, the original code is barely recognizable.

For most of the code in Eclipse, this sort of copying is okay. However, at the end of the day, it’s always best to review the license before you copy.

In response to my Friday posting, RefuX said “Linux is cheap if your time is free”. This statement is, of course, absolutely correct. However a similar statement about the cost of your time can be made about operating systems that you have to pay for. The amount of time that I have spent troubleshooting Windows problems is staggering (I had to resolve a painful driver conflict a couple of weeks back). I think that it’s fair to suggest that the amount of money you pay for your operating system ends up being a relatively small part of the overall cost of ownership. Let me know if you think otherwise.

I’ve installed Eclipse many times. I love the fact that all I have to do is make sure that I have a JRE configured, unzip a file into a directory, and I’m good to go. It all just feels so clean; no files spread out all over the place. Very simple. It literally takes me about 10 minutes to get Eclipse up and running on a new system. I’ve been working on an RCP application (I’ll tell you all the details when I’m a little further along). Since Eclipse is itself an RCP application and comes with all of its own source, it’s a great source of help when you’re building an application. I’ve been able to put together some fantastic user interface elements in almost no time at all by scavenging, borrowing, and blatently copying code tha comes with the environment. This practice is, of course, a staple of modern software development and is strongly encouraged in "Contributing to Eclipse" by Erich Gamma and Kent Beck.

So… the cost of entry for Eclipse, both in terms of money and time is quite low.