Short description: Hupa is an Rich IMAP-based Webmail application written in GWT, but there is no release delivered yet. This proposal's aim is to make it fully functional adding many features which are missing and removing out-of-dated dependencies in favor of the new stuff in the latest GWT version.
Hupa is an Rich IMAP-based Webmail application written in GWT, but there is no release delivered yet. This proposal's aim is to make it fully functional adding many features which are missing and removing out-of-dated dependencies in favor of the new stuff in the latest GWT version.
- Hupa has been entirely written in java to be coherent with the language used in the James project.
- Time ago, Hupa was a reference of a GWT MVP pattern application.
- Hupa MVP design is based of a set of libraries available for gwt a couple of years ago when Gwt-core didn't have support for MVP
- Gwt-presenter: for the MVP and EventBus patterns.
- Gwt-dispatch: for the Command pattern
- Gin + Guice: for dependency injection.
- Hupa was developed before GWT-2.0 was released, when LayoutPanels, uibinders, Cells, RF, etc. were not available.
- Although Hupa is using the last GWT release, it still depends on some unmaintained libraries because they have an equivalent feature in modern GWT.
- In summary, Hupa is a functional and well designed email client, ready to read, send and manage messages, but it lacks many of the nice features any email client nowadays has.
- Replace out-of-date dependencies with GWT-2.4.0 stuff (gwt-platform)
Replace gwt-dispatch by RequestFactory Replace gwt-presenter with the available stuff in GWT-2.4 Remove gwt-incubator dependency in favor of CellTable and CellTree Use LayoutPanels and DecoratorPanels of css workarounds Use Gwt DnD
- New features
Analysis of evolution
- Why replace gwt-dispatch by RequestFactory
- Why replace gwt-presenter with the available stuff in GWT-2.4
a)There are some problems with the current state of [gwt-presenter]:
- Presenter relationships: Child presenters are injected in parent which leads to tight coupling between your presenters. This also makes it harder to structure your application for certain scenarios.
- Lack of lazy loading: It does not have built in support for lazy loading of presenters/views, which means you have to to implement this in your application layer.
- Only singleton presenters: No support for non-singleton presenters which decreases the level of flexibility in your application design.
- Places implementation: Too much code to handle places (one class for each place, etc). Also, each request leads to quering each place if it is a match which can be a bottleneck.
- Code splitting: No support for code splitting.
b)Compare with gwt-presenter, the gwtp looks better:
- Loose coupling between presenters. There are no direct dependencies between parents and children. All communication takes place over the event bus and the child simply fires an event that a parent presenter reacts to. Want to change parent for a child? You change the event type being fired in the child..that's it. You can also reveal the child in different parents with this based on the context, for example token parameters. Parents annotate defined events with @ContentSlot where child presenters are injected when they fire that event.
- Lazy loading. gwt-platform introduces the concept of light-weight proxies. These proxies listen to events and instantiates your presenters on demand. Your presenter/view is therefore not created until the first request.
- Non-singleton presenters. Singleton presenters does not always make sense. Sometimes you want to re-use presenters in different contexts, and this is where PresenterWidgets come in handy.
- Code splitting. Code splitting could not possibly be easier. You simply annotate your proxy with @ProxyCodeSplit, and the initialization of the presenter is behind a code split point. Incredibly easy and powerful.
- Place management. Easier than ever. With three lines of code and no new classes, you have mapped your presenter to a place. The gwt-presenter problem with quering every place if it's a match is avoided as well.
- Search engine crawling: Integrated support for letting search engines crawl your GWT app.
- Integrated command pattern for RPC communication.
- For Performance
- GwtQuery dynamic selectors are, in most cases, faster or equal than any other library.
- GwtQuery performs better than its brother jQuery.
- Sizzle is faster than other libraries, this is the reason why gwtquery fall back js implementation is based on it.
- There are considerable differences between the performance of different browsers. The most significant is the behaviour of IE, although last changes introduced in IE8 are promising.
- Gecko browsers perform worst than browsers based on webkit, nevertheless the version used in FF-3.6 has many improvements.
- For New features
- Contact management.
- Authentication: Oauth.
- Message filtering, grouping, sorting and labeling.
- User settings: name, emails, signature.
- Theme improving.
- And Besides
- Remove gwt-incubator dependency in favor of CellTable and CellTree
- Use LayoutPanels instead of css workaround and use gwt-decorated panels
- Use gwt-dnd.
- [from now on] Be familiar with those that benefit the project development
- [Week 1~2] Replace gwt-dispatch by RequestFactory.
- [Week 3~4] Replace gwt-presenter with the available stuff in GWT-2.4 (gwt-platform)
Deliverable #1: the improved Hupa after replacing something.
- [Week 5] Remove gwt-incubator dependency in favor of CellTable and CellTree.
- [Week 6~7] Use LayoutPanels and DecoratorPanels of css workarounds, Use Gwt DnD
Deliverable #2: the improved Hupa with almost all GWT-2.4 owning
- [Week 8~9] Make several prototypes of new features(Contact management, Message filtering, grouping, sorting and labeling, etc.). And then try to commit to the mail list for quickly feedback.
- [Week 10~11] Develop Oauth and User settings, meanwhile update the feedback from Week8~9.
BTW, among all of above slots, if time be surplus, performance and theme will be considered.
Deliverable #3: the improved Hupa with some new features, even good performance and theme.
- [Week 12] suggested "pencils down" date.
- NOTE: I am going to take at least 4 days per week on the Hupa development, and constantly contact with the james mail lists.
Following and future work
Constantly get well in touch with hupa team to improve the ever-developed features and discuss every other stuff which can make Hupa more useful for human beings. For example, nice theme, good performance and so forth...
- General Information
- Open Source Development Experience
-  [GSOC2012] Hupa evolution - https://issues.apache.org/jira/browse/HUPA-85
-  Apache James/Hupa & GWT - http://www.slideshare.net/dodotis/apache-jameshupa-gwt
-  gwtquery - http://code.google.com/p/gwtquery/
-  Getting Started with RequestFactory - https://developers.google.com/web-toolkit/doc/latest/DevGuideRequestFactory
-  When should I use RequestFactory vs GWT-RPC? - http://stackoverflow.com/questions/4119867/when-should-i-use-requestfactory-vs-gwt-rpc
-  What is your favorite GWT MVP Framework? - http://www.linkedin.com/groups/What-is-your-favorite-GWT-129889.S.100344151
-  gwt-platform - http://code.google.com/p/gwt-platform/
-  mvp architecture - https://developers.google.com/web-toolkit/articles/mvp-architecture
-  Hello gwt-platform - http://borglin.net/gwt-project/?page_id=817
-  GWT 2.1.1 RequestFactory - http://tbroyer.posterous.com/gwt-211-requestfactory
-  GwtQuery CSS Selectors Performance - http://manolocarrasco.blogspot.com/2011/01/gwtquery-css-selectors-performance.html