Well... After a few days of reading TED's code, I've began taking a look at how we could create him a web UI.

There are 2 ways that I would approach this:

Create a GWT (Google Web Toolkit) version
I've put some time into putting together a GWT version of the TED UI, which so far looks pretty close to the actual Swing version. I will look into posting some screen shots later tonight.

An issue with this is that for every feature that requires a UI change to the Swing version, we need one for the GWT UI as well. This is a bit of a PITA. However, it presents the option for people to deploy TED as a standard web application, and would likely require only dropping a jar file into their web container.

Deploy the Swing app with Java Web Start (JNLP)
This would eliminate the need to have to update both UI implementations. Although I haven't looked into this yet for TED, but I've done this on other projects before.

With the options out of the way, let's take a look at the work that will be involved, as I see it.

1) As stated before, there is a lot of work to be done to separate the current UI from the core logic of TED. An engine of sorts?

2) Need to decide if TED will be provided in two flavors (web or Swing) with each running an Instance of TED's core, or if both UIs are usable at the same time with both instances communicating with a central TED core process/service. I think this decision needs to be made rather quickly as it will certainly have an impact on the UI separation/daemon tasks.

Comments?

If I look from a user perspective, I would expect the web ui to be reachable with a browser and accessible without too much configuration.

A good example is the web ui of uTorrent. To enable it, you simple check a checkbox in uTorrents preferences panel. You can set a port if you want to. Then, uTorrent is reachable via every browser by simply opening something like http://mediacenter:8080/gui/

I have no clue how they implemented it, but as a user there is very little to know and configure. It seems to run in the same process as uTorrent itself, you still have that running somewhere in the background. No clue if they seperated the ui from the core..

Looking forward to the screen shots


That would indeed by a PITA but I don't see any big UI changes coming up. The basic functionality of ted has been pretty much the same and adding a text field and check box once in a while shouldn't be too hard (I hope).


I don't understand By deploying as a standard web application you mean to open in a browser? And what does dropping a jar file into a web container actually do?


And what would be the disadvantage of this approach?


What kind of engine are we talking about here? Some kind of interface which you can call either by the web or swing UI?


I would vote for the second option. One ted with two different interfaces. To me it would seem most logical that if you change something in ted this change is also visible in the other UI.

I would say that uTorrent uses Jetty web server. It is very light weight and can be embedded into an application with minimal configuration (more required to make it secure). Jetty is Java based as well.

We could do the same sort of thing with Ted as uTorrent WebUI. I'm not exactly sure yet, but I would think that you would have to use RMI or SOAP to comunicate b/w Ted and our WebUI.

Sorry -- jar = war. Dropping a war into the webapps folder of a web container (i.e Tomcat) the war is exploded and the application is now considered deployed/active.



Headless ted is kind of like an engine, where the application logic is executed within a loop in a templated fashion.

Would that mean that you'll have two instances running? One core and one web deployed one?


A daemon sort to say?

I like the approach roel mentioned. I think for the user that will be the one easiest to understand and use. I don't know if you have any experience with Jetty? If you don't and it will cost you a lot of extra work we might want to consider using another solution. But on the other hand it's of course always fun to learn something new

Yep... I've used Jetty quite a bit actually, and wouldn't be too hard to implement something like uTorrent does (as roel had stated).

Jetty can be embedded in the Swing application, and configured to be turned on and off as the user sees fit. The tricly bit is sharing the same Ted core, hence the architecture questions I've been posting.

How does the web application running in Jetty, communicate with the CORE started by the Swing UI? A shared web service? Can both access the same static object? RMI (Remote Method Invocation)?

I've got to pick an approach and move forward.

I'd personally choose something like embedded jetty and your favourite web ui on top (GWT, YUI, dojo, etc). That way the code is still running on the server, and communication is easy(er).

Also you can more easily add a 'mobile' version of the site, to see updates from your handheld devices.

I mentioned this site to you personally, but I'll post it here so I don't forget. You could also check out
AjaxSwing. Available under a GPL and might get us 95% of the way there.

I think integrating the webserver into ted is a good idea, to minimize user effort.

I made a list of things you might want to (and not want to) offer in the web ui, defining the API for web services. I'll post that later today if I'm at home.

Also: please note that several users requested ted to be used as a windows media center / boxee / whatever plugin. Whatever we make here, it should offer some kind of webservice for those kind of tools.

So the webserver will be hosting a (public) webservice (for 3rd party integration) and a web ui to access ted.

I will draw and post some kind of UML version of what I think could be the design for the ui/core split with API extension.

Maybe you could do the same so we can see if we are on the same page about this?

Again, forgive my ignorance but what is a shared web service? (As you probably have understood by now I've little experience with programming for web application ).

What I envision here is that you've one core running and you can decide yourself if you want to start the web UI or the Swing UI (or both at the same time). As both UIs only have to read the state of the (static?) core and display it on the screen it should not be a problem that you've two interfaces running right?

If RMI is the way to do this then that would be fine by me.

A shared webservice offers an API that can be used by a number of external tools, like a web UI, a media center plugin, an iphone app, whatever. All those tools can post messages to ted and recieve response, mostly in some kind of XML format.

I think I would have two views running at the same time on one ted core. A swing UI view and an API view.
That API view offers the webservice which in turn can be used by 3rd party tools (and our own web ui).

yep, as Roel said.


Kenny, I got ted running under AjaxSwing. A lot of the custom UI components were broken, and I found it a little slow. As for the broken UI widgets, we would have to write classes for the AjaxSwing framework to render them correctly and to handle web events correctly, ect... I was hoping that it would eliminate having to write code for both. Didn't feel right... but that's my opinion I guess.


I'm making some good progress with a GWT version right now, so, unless there are any objections, I will continue with it. Hopefully I'll be able to get it integrated with maven soon and put into trunk, so people can have an initial look.

No objections, so please continue

If you've something to show (screenhots?) I'm always interested in having a look at them.

I can get some screenshots posted tonight. I know I said it before, but this time I promise!

As for progress... I've been working on the main screen and the add show functionality for the past little while. Right now it is using dummy data and not asking the backend files for their data.

The issue I've been dealing with over the past couple of days is pearing down the datastructure (domain) objects. i.e. TedSerie, StandardStructure, ect... These classes should be simple POJO objects, but some contain date formatting ect... Also, when using objects client side, GWT does not support 100% of the Java classes at the moment, so the dependencies have to be moved out. For example java.util.Calendar. Simple POJOs are a must.

GWT server side code can use any libraries you want. All client-side java code gets compiled into JavaScript code.

The lack of unit tests make this really time consuming as I want to make sure that any changes do not break ted in any way.


BTW, if you were wondering why I chose to use GWT instead of other web frameworks, heres my top 3 reasons that helped me decide:
1) Writing GWT code is VERY similar to SWING, so it would be easy for you guys to pick up and add too.
2) Client code can be tested using JUnit.
3) AJAX is simple with GWT.

Right now, the "Add Show" dialog for the WebUI is grabbing the show list from the server. This was easy b/c the SimpleTedSerie datastructure object is a POJO. This step has to be completed before I can continue on with connecting the web UI to the backend to get it's data.