Hi Eric,
Actually hupa has everything decoupled, this is the reason why we use MVP
and Command patterns.
Let me explain how hupa is designed, and why the imap latency your
realize.
- Server side
Everything in server-side is agnostic about the client-side (browser), we
use handlers for each service and they are very well unit tested. We
offer
those services via ajax, rigth now with a gwt-dispatch servlet,
although we
could easily add other servlets to allow rpc via ajax (json) for non-gwt
client applications.
The main problem now in the server side is that we are not doing imap
caching nor we access directly to the mailbox.
So each time a user interacts with the ui, hupa have to ask the
imap-server
and download headers or messages just in case (this is very expensive in
far-off imap servers like gmail, large inboxes or messages with
attachments).
I have in mind to use directly the james mailbox instead of imap, this
should increase considerably the performance like gmail does with
mailboxes.
Even we could have a mailbox implementation in James which could be an
imap/pop client (something like fetchmail) and it should be feasible that
a user in James could configure other mail sources (like gmail does)
There are many things to do in the server side though, think that we just
have coded a simple imap client so as we could develop faster the visual
part.
- Client side
It is gwt, so everything is converted into javascript resulting a pure
desktop-like app made with javascript which requests services via ajax to
the server. Note that we don't have any jsp parser not html generator.
The goal of using gwt is that instead of coding in javascript (jquery +
plugins + widgets etc) we code in Java, so as we can take advantage of
the
full java ecosystem: first we have a featured IDE (refactoring, coverage,
javadoc...), second a way to decouple code modules using libs and maven
dependencies, and finally we can use real patterns and object oriented
programing because of java.
The main pattern we use in client side is MVP (model-view-presenter) with
allows completely decouple the views from the client-application
logic, so
as we can mock the view and test every single method (including the ajax
dialog with the server).
With this pattern, testing does not need to start a servlet container
so as
we can run integration tests very fast.
Instead of using ajax json or xml, and because the server side is
java, we
use a special ajax serialization which comes with gwt, so as we can
use the
same objects in both server and client sides (here we use the command
pattern).
We have a set of very simple views styled with css, but we could enrich
them very easily either using css3 or replacing with more rich widgets
like
gxt, smartgwt, etc.
Of course, like you say, we could replace gwt by any other approach to
build a web application, in this case the only reusable part is the imap
client in the server part. But this is a very small part of the all the
Hupa code.
What we pretended with hupa is to develop a very rich desktop-like app to
run in the browser, the only way to do that is using profusely javascript
(apart from java applets, flash, etc). There are many technologies to do
that:
1.- codding javascript by hand (you have js libraries like jquery with
makes the work easier.
2.- using java and converting it to js using gwt-compiler (there is
also a
scala to js compiler)
3.- using frameworks like jsf-2, rails, grails, lift, etc which injects
javascript portions into html templates.
Based in my experience,
#1 You have full control over the generated js, but you need good
skills in
js (most people who uses js tend to copy pieces from here and there) and
deep knowledge of obfuscation and compression js tools to produce good
performance apps.
#2 There is a learning curve to understand well that your java code
wont be
run in a jvm but in a browser, but the IDE helps a lot and gwt-compiler
will take care of generating good quality js (optimized, reduced, etc).
#3 It's very good for traditional apps based on a page per view with some
kind of ajax to update, edit, etc. But when you want a
single-page-application, sooner than later you have to deal with
javascript.
I hope this clarifies a bit the architecture or Hupa.
- Manolo
On Thu, Apr 19, 2012 at 5:50 AM, Eric Charles<e...@apache.org> wrote:
Hupa should also focus to decouple the 'services' from the 'ui'.
If we have independent services for efficient IMAP mailbox read/write,
contact management, authentication/authorization..**. (name any), we
can:
1.- Focus on those libraries without the ui concern - for example, my
current experience with hupa is that the mailboxes reading sometimes
fails
due to (I think) latency,...
2.- Put any ui on top, GWT being the first developed, but any other one
could be further added.
Thx,
Eric
On 04/18/2012 05:20 PM, Manuel Carrasco Moñino wrote:
I've been taking a look to the demo, it looks pretty nice because of a
good
selection of css, I'll deep into the code when I had a while.
You can see Hupa in action in either servers:
http://hupa.alcala.org (it's a shared server I use, it could be down
sometimes)
http://james.zones.apache.org (it's a recent instance deployed in the
James jail server).
In order to use hupa you have to login with any gmail user
(previously you
have to enable imap in that user).
- Manolo
On Wed, Apr 18, 2012 at 3:44 PM, Ioan Eugen
Stan<stan.ieu...@gmail.com>**
wrote:
Hi Dhurbo, Manolo,
I think the developer doing the work should choose whatever platform
he is most comfortable with. Good code has to come out of his hands
and comfort aids that. Having both with be great (but most likely hard
to maintain in the long run).
As a user I would like to see something usable that looks nice. I
wouldn't care if it where implemented in a specific platform.
MyFaces mailbox demo looks very nice. I haven't checked Hupa demo (I
know Manolo has one installed, but I don't have a gmail test account
and I didn't see any SSL), maybe we should have a mocked HUPA install
like MyFaces one available online. I wonder what it will take to do
that?
My cents ;).
Cheers,
2012/4/18 Dhrubo<dhrubo.ka...@gmail.com>**:
Manolo -
Primefaces Mailbox template ---
http://www.primefaces.org/**showcase-labs/ui/**layoutMailbox.jsf<http://www.primefaces.org/showcase-labs/ui/layoutMailbox.jsf>
Its basic but good starting point. They have very rich component
suite
also
you can look into Primefaces extensions for more layouts and Rich
editor
support besides what is provided by Primefaces itself.
The extensions project is hosted here -
http://code.google.com/p/**primefaces-extensions/<http://code.google.com/p/primefaces-extensions/>
They also have their entire showcase online.
Slight deviation - following the principles of Zimbra we can easily
(hopefully) we can turn this webmail app into a desktop app like MS
OUTLOOK
or Thunderbird by embeding Jetty with Mozilla Prism (is it a dead
project i
guess) or some kind of XULRunner.
Also I am available for any consultancy or help on Primefaces, JSF 2,
Spring. I can also do lot of development as well provided I have a
commit
privilege on SVN :) . One big advantage I see using JSF 2 is
modular app
development. Please check this link -
https://community.jboss.org/**wiki/ModularWebAppsWithJSF2?_**sscc=t<https://community.jboss.org/wiki/ModularWebAppsWithJSF2?_sscc=t>
This can be further extended with Spring and Ant style configuration.
On Wed, Apr 18, 2012 at 3:37 PM, Manuel Carrasco Moñino
<man...@apache.org>wrote:
Dhrubo, Is there a site running the the webmail example of
primefaces?,
or
is there a way to download the .war file?, I'd like to take a look.
Thanks
- Manolo
On Wed, Apr 18, 2012 at 9:41 AM, Dhrubo<dhrubo.ka...@gmail.com>
wrote:
I do not intend to launch a debate on GWT v JSF 2. But JSF 2 is the
JEE
standard for UI and Primefaces comes with sample layout for webmail
which
may help you get started very fast.
On Wed, Apr 18, 2012 at 12:37 PM, Dhrubo<dhrubo.ka...@gmail.com>
wrote:
These days with JSF 2 frameworks like Primefaces et all we do not
really
need any js , ajax is out of the box and we need little html know
how
too.
Also they come with more than standard layouts and theme support.
James being an Apache product and Apache also develops JSF 2
imp, we
should use JSF 2 with easiest and huge set of components like in
Primefaces
which is excellent documented highly active community.
So my two cents
+1 Primefaces
-1 GWT
Please note I have no affiliation or neither work for Prime
Teknoloji
:)
On Wed, Apr 18, 2012 at 12:29 PM, Manuel Carrasco Moñino<
man...@apache.org> wrote:
-1 JSF2
+1 GWT
Like JSF2, GWT is a proved technology, open sourced, and apache-2
licensed.
GWT adds a set of benefices to James, mainly we continue being
java
centric
and we dont need serious javascript, ajax nor html skills to
understand
the
project, secondly we can deliver a product which is unit
tested and
javadoc-ed in all its components.
I don't want to expose the benefices of developing large rich
apps
with
gwt
vs hand-written js because there is a lot of literature along the
web.
- Manolo
On Fri, Apr 13, 2012 at 6:05 AM, Dhrubo<dhrubo.ka...@gmail.com>
wrote:
I think we should move to JSF 2 than GWT which is mostly
controlled
by
one
company.
Apache with its vision and endeavor for OSS we should use - JSF
2 -
Tomahawk (or Mojarra) + Primefaces
On Thu, Apr 12, 2012 at 6:37 PM, Ioan Eugen Stan<
stan.ieu...@gmail.com
wrote:
Pe 11.04.2012 18:48, echo a scris:
Hi Manolo
Very glad to see your reply. The reason why I want to choose
the
gwt-platform
was that it is more smoothly to update from current Hupa's
state(gwt-presenter).
However, I like the native one rather than gwtp since it will
import
the
other
resources. What I really want to do is to replace the MVP by
gwt
itself.
I was
just afraid whether I can complete the proposal before the
deadline
of
GSoC, so
I asked for you advices. If possible, I want to use the core
mvp
in
gwt
to
realize it. Over these days, I have been researching the Hupa
project
and
GWT
technology and later on I want to show you something I am
changing.
To the new features, I would like to implement as many
features,
that a
current
email client should have, as possible not only during the
GSoC
period,
but also
after that. And I am also keeping my eyes open on the Hupa's
JIRA,
where
some
wonderful ideas come out gradually. Sure I will give my deeper
discription after
my researching. I don't think it will be late.
Thanks a lot :)
Wish you a happy
Hi Echo
I've been reading your application and it looks right to me.
One thing I see is that you have selected gwt-platform
instead
of
the
core mvp in gwt but you don't say any reason about why you
prefer
the
first option.
Also I'd like a deeper description of how you pretend to
face
new
features, I mean components, persistence, customization etc.
Cheers
- Manolo
--
cheers,
echo
Hello Echo,
Sound good. I'm not familiar with GWT and I would like to know
more.
Good
luck with your research and send us the findings.
Cheers.
--
Ioan Eugen Stan
http://ieugen.blogspot.com
------------------------------****----------------------------**
--**---------
To unsubscribe, e-mail: server-dev-unsubscribe@james.****
apache.org
<
server-dev-unsubscribe@james.**apache.org<server-dev-unsubscr...@james.apache.org>
For additional commands, e-mail: server-dev-help@james.apache.
**org<
server-dev-help@james.apache.**org<server-dev-h...@james.apache.org>
--
Kind Regards... Dhrubo
<http://www.linkedin.com/in/**dhrubo<http://www.linkedin.com/in/dhrubo>
--
Kind Regards... Dhrubo
<http://www.linkedin.com/in/**dhrubo<http://www.linkedin.com/in/dhrubo>
--
Kind Regards... Dhrubo
<http://www.linkedin.com/in/**dhrubo<http://www.linkedin.com/in/dhrubo>
--
Kind Regards... Dhrubo
<http://www.linkedin.com/in/**dhrubo<http://www.linkedin.com/in/dhrubo>
--
Ioan Eugen Stan
http://ieugen.blogspot.com/
------------------------------**------------------------------**
---------
To unsubscribe, e-mail:
server-dev-unsubscribe@james.**apache.org<server-dev-unsubscr...@james.apache.org>
For additional commands, e-mail:
server-dev-help@james.apache.**org<server-dev-h...@james.apache.org>
--
eric | http://about.echarles.net | @echarles
------------------------------**------------------------------**---------
To unsubscribe, e-mail:
server-dev-unsubscribe@james.**apache.org<server-dev-unsubscr...@james.apache.org>
For additional commands, e-mail:
server-dev-help@james.apache.**org<server-dev-h...@james.apache.org>
