Someone once asked me why we break up things between ui plug-ins and core plug-ins. My theory was that we could eventually swap out the ui with something else. I didn't really believe that at the time, and I'm not sure how well architected our CDT plug-ins are to allow that, but it sounded good.
So as I begin my journey down the road of web-based IDE's it really struck me that this was the time to swap out the UI. My theory goes like this. Google are the experts at creating web applications (and you may disagree with that, but stick with me). They have a framework for building them called the Google Web Tooklit, GWT, which allows you to program your UI in Java which then gets compiled into JavaScript. And, they have a really cool RPC mechanism, again all in Java, that overlays Servlets. Hey, Equinox plus Jetty gives you Servlets. Why not swap out the Eclipse UI code with a GWT implementation that talks to our Core code using Servlets?
A big thanks goes out to Ian Bull who reminded me of the example project he created last year that shows how to use GWT with Equinox OSGi. I have extended that a little to call into the Eclipse workbench, right now calling Platform.getOS(). This is the start of my prototype web-based IDE using GWT as a front end to the Eclipse IDE Core parts. And I am pumped the deeper I get into it. Feel free to follow along as I check my prototype into http://github.com/dschaefer/w-ide. Feel free to fork that and join in the fun. (BWT, I need to show you the cool way I'm using git, stay tuned).
As Ian says, "GWT + OSGi is a great platform!" And I am starting to see why. It really is. So much so that it confirms my earlier conjecture that Equinox would be a great addition to Chrome OS and I hope Eclipse people are talking to Google people about that. Wouldn't it be cool to see Equinox serving up local server pages, presenting a p2 install web UI to download and install bundles into your favorite mobile device. Yes, it would be cool.
Of course, there is also RAP which allows you to "single source" your UIs and just run the Eclipse UI over the web. Like GWT not everything is possible with RAP but the joy of simply runing your desktop app UI in a browser after a bit of tweaking is quite remarkable. The RAP team has also been doing e4 integration.
ReplyDeleteAs Jeff mentioned, you should look at the RAP platform. You can think of RAP as a different SWT platform. When SWT calls out to GTK or Win32 it has native C calls, when it calls out to RAP it has "native" javascript calls.
ReplyDeleteThe advantage of this is that you get a single programming model between Eclipse on the Desktop and Eclipse on the Web. You also get access to the Jobs framework, workbench actions, extension registry, etc...
RAP and GWT take different views at similar problems. The RAP team has also talked about how they can leverage the GWT work too.
You will get hit very fast by something we addressed in e4 - you are expecting that the Eclipse-Platform-Code is prepared to get used by multiple users which is not the case because of all those singletons. Instead of using the 3.x stream you'd much better of with e4 because it has not statics, singletons at all and even better the the code split between UI/Logic is very clear.
ReplyDeleteThis sounds a bit like what the e4 guys did with Bespin? You might want to take a look at that.
ReplyDeleteI am concerned that all of these comments from Eclipse insiders are basically saying "don't do that". I hope they aren't seeing GWT as competing technology to Eclipse. Or that Google competes with Eclipse. I have absolutely no ties to Google, but given a choice, I'd put my money on them in this area, if I had to, which I guess I am. Ignoring them would be like ignoring Microsoft in the 90's.
ReplyDeleteJeff and Ian B, I don't want to single source the UI. Cramming a desktop app into a browser sounds wrong to me. The end goal is to fit this into Google Wave. That certainly will require different work flows especially with an eye one REST.
Tom, agreed. I had thought of that. And, yes, getting rid of singletons is a good start. I also think that is probably over simplifying things. Essentially you need the Resources plug-in to be multi-session aware. I'm not sure that's in the e4 plans, or why that couldn't be done on the 3.x base.
And I have looked at Bespin. Or I was except it told me that my IE browser didn't support the needed Canvas markup. Hopefully there's something new there that the e4 guys have uncovered. Any web-based effort needs a good editor and Bespin is a good start at that. For now I'll be looking at how the GWT RichTextEditor does it's magic for things like keyword coloring.
I was certainly not saying that Google competes with Eclipse, nor was I saying "don't do that". I have worked with GWT and Equinox, and as I said, it's a great technology.
ReplyDeleteI was simply pointing out that you may get some advantage of single sourcing with RAP. I don't think you should "cram the desktop in the browser". But there is advantages to using programming models / paradigms (and widget toolkits) that you are familiar with.
[For example, why learn a new technology when you want a list... what's wrong with a list Viewer and content provider?]
Also, the RAP team is looking at how they can integrate with GWT. I don't tihnk RAP and GWT compete, they bring different (complementary) angles to the Ajax world.
if you follow my work I'm a big fan of GWT giving you access to enabling Eclipse-UI technologies like Eclipse-Databinding for GWT and in the last few evenings I worked on a Qooxdoo-GWT-wrapper.
ReplyDeleteI think you are over simplifying things because I don't think you are going to be happy with only the resource stuff because an IDE is made of much more than that.
How do you promote selection changes? How do you promote parse errors? How do you promote dirty states? An IDE is made up many different parts who communicate together to give you what you get today from the Eclipse-Platform. As you said you only want to replace the UI through something different but this also means that all the logic in the back needs to multi-instance aware.
I have no clue about the Resource because if never really taken a look but because RAP is already working with it I guess it's working already today because every Workbench-Instance has it's own but I could be very wrong here.
I'm in favor of RAP over GWT. I have extensive experience with both to know that it's an apples vs. oranges comparison.
ReplyDeleteThe equivalent of GWT is RWT, the part of RAP that implements the SWT API using the Qooxdoo JavaScript framework. It's like comparing the Eclipse RCP to Swing.
Also in GWT you have all the presentation logic on the client side in JavaScript, whereas RWT sends only the widget structure and state changes to the client. It is more network intensive, but it feels the right way.
An added benefit: a RAP application should be ported fairly easily to e4.
Doug,
ReplyDeleteFrom one Eclipse insider to another Eclipse insider - 'lighten up' :-). People are just trying to be helpful and give you pointers that might give you ideas.
I think it is great you are using GWT and doing this work. We need more people experimenting, innovating and pushing the future of Eclipse.
In fact what excites me about e4 is that it attempts to make make it easier for people to integrate different user interfaces, like GWT, with the platform services. I hope we see lots of new innovative ways for creating IDEs and tools.
Thanks Ian S. Yes, time to lighten up. Funny how this all started by stating my fear that e4 will not be accepted by the CDT community, which has since been confirmed. The response to that has made me very defensive lately, which is too bad.
ReplyDeleteBut anyway, time for me to stop talking and time to show some code. As I said, I'm pretty excited about this GWT-base IDE thing and am going continue working on that to show what I mean.
One last thing, though. Tom, I have a little experience building IDEs, and yes, I over simplifying things. But, I'm not a fan of writing long blog entries ;). More on this when I have something real to show.
My personal experience with p2 (and Eclipse updates in general) is that it performs _well_ below par and it is an extremely unfriendly update platform.
ReplyDeleteI may be wrong here, don't know the internals and it may well be the best piece of software ever devised: as a user, I despise it.
In its present form, I see it highly unlikely anyone at Google would consider it for inclusion in Chrome OS (if internal complaints about Eclipse updates are anything to go by :-)