[GSOC2012] Hupa evolution

[Luis Slocker]

hello, as I have in the issue,
https://issues.apache.org/jira/browse/HUPA-85?focusedCommentId=13238288&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13238288

I'm Luis R Slocker a final year postgraduate student from University of
Alcalá de Henares in Madrid, Spain. I am really interested in this project
for the GSoC of this year.

I find it interesting GWT technology as a powerful tool for developing
applications in the cloud, and I would like to extend my knowledge in this
area.
I always wanted to initiate me into the open source community and help with
humble contributions, and this seems perfect for me.

Then stay at your disposal for anything

Thanks a lot!
-- 
Correo de Luis R. Slocker

Re: [GSOC2012] Hupa evolution

[Manuel Carrasco Moñino]

Hello Luis,

Please feel free to ask whatever questions you had in order to
understand James, Hupa and its internals so as you could write a good
proposal to apply in the gsoc site.

I suggest that you can start downloading hupa code, compile and run
it. I have committed recently some changes (compillation fixes,
autodeploy bundle) so as you should not have any problem following the
readme file.
Once you know what the application does, you could start importing the
project modules in eclipse so as you could play with it in dev-mode
(you need to install m2eclipse and google plugins).
Although it is not mandatory you can try to install and run james
server to easily play with users and domains in local (I recomend to
download the last release).

and... good luck

- Manolo

On Tue, Mar 27, 2012 at 5:58 PM, Luis Slocker  wrote:
> hello, as I have in the issue,
> https://issues.apache.org/jira/browse/HUPA-85?focusedCommentId=13238288&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13238288
>
> I'm Luis R Slocker a final year postgraduate student from University of
> Alcalá de Henares in Madrid, Spain. I am really interested in this project
> for the GSoC of this year.
>
> I find it interesting GWT technology as a powerful tool for developing
> applications in the cloud, and I would like to extend my knowledge in this
> area.
> I always wanted to initiate me into the open source community and help with
> humble contributions, and this seems perfect for me.
>
> Then stay at your disposal for anything
>
> Thanks a lot!
> --
> Correo de Luis R. Slocker

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: [GSOC2012] Hupa evolution

[Luis Slocker]

Hi!

Many thanks for the advice Manolo, I will try to download the Hupa
code, compile, runand play with it.
Also I will try to test locally with James.

- Luis Slocker



2012/3/27 Manuel Carrasco Moñino 
>
> Hello Luis,
>
> Please feel free to ask whatever questions you had in order to
> understand James, Hupa and its internals so as you could write a good
> proposal to apply in the gsoc site.
>
> I suggest that you can start downloading hupa code, compile and run
> it. I have committed recently some changes (compillation fixes,
> autodeploy bundle) so as you should not have any problem following the
> readme file.
> Once you know what the application does, you could start importing the
> project modules in eclipse so as you could play with it in dev-mode
> (you need to install m2eclipse and google plugins).
> Although it is not mandatory you can try to install and run james
> server to easily play with users and domains in local (I recomend to
> download the last release).
>
> and... good luck
>
> - Manolo
>
> On Tue, Mar 27, 2012 at 5:58 PM, Luis Slocker  wrote:
> > hello, as I have in the issue,
> > https://issues.apache.org/jira/browse/HUPA-85?focusedCommentId=13238288&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13238288
> >
> > I'm Luis R Slocker a final year postgraduate student from University of
> > Alcalá de Henares in Madrid, Spain. I am really interested in this project
> > for the GSoC of this year.
> >
> > I find it interesting GWT technology as a powerful tool for developing
> > applications in the cloud, and I would like to extend my knowledge in this
> > area.
> > I always wanted to initiate me into the open source community and help with
> > humble contributions, and this seems perfect for me.
> >
> > Then stay at your disposal for anything
> >
> > Thanks a lot!
> > --
> > Correo de Luis R. Slocker
>
> -
> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> For additional commands, e-mail: server-dev-h...@james.apache.org
>



--
Correo de Luis R. Slocker

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: [GSOC2012] Hupa evolution

[Manuel Carrasco Moñino]

Hi Echo

I'm CCing the mailing list because other developers could be
interested in these questions.

Proly you can not login into gmail because of either cacerts issues or
you have not enabled imap in your gmail account.

Yesterday, I committed a fix to the default config.properties removing
the 'TrustStore' line so as hupa can use the default java cacerts
file.
If you are using openjdk, you should check that cacerts file is complete.

There are several MVP articles, the one you say is a good start point.
There are different approaches of how implement MVP, hupa is using
gwt-presenter which is similar to the stuff in gwt-2.4 so the idea is
to replace it with gwt-2.4 although we could consider other nice
libraries like mvp4g or gwtp. I recomend to you to read everything you
find in order to write a good proposal.

gwt-dispatcher is used in client and server sides because it is the
framework used to comunicate both sides (this is the reason why you
can see it in many modules). We used it instead of RPC in order to use
the command pattern and facilitate testing of remote procedures in the
jvm. This library is not very used nowadays because people uses the
new RequestFactory stuff. The evolution of gwt-dispatcher is in the
gwtp library.

Although RequestFactory is though to be used with ddbb entities, I
think we can consider our objects (emails, folders, etc) like entities
and take advantage of this pattern. Anyway, you could consider other
library like gwtp if it simplifies the code or the developing of new
features in hupa.

Gin is the only way to have injection in client side. Gin syntax is
the same than Guice and you have to use both to test client presenters
and code in the jvm. Note that one of the main goals in MVP is to test
in the jvm client code, so we need a way to decouple presenters, etc
and inject the necessary stuff to test them in the jvm.

We use gwt-dnd because it was the only available library those days.
It is necessary to move messages to folders. Now gwt has dnd support
although Cell widgets do not support it, may be we had to use
gwtquery-dnd etc. when we replace the message celltable.

gwtquery brings the simplicity of jquery to gwt, specially when
dealing with dom elements or html content, note that it doesn't need
jquery at all. I think gquery can help to display messages (clean
them, resize, etc). I maintain this library so feel free to ask me any
question you had about it.

All of these new features you suggest are welcome. Note that hupa does
not have any ddbb in server side, we are storing stuff in a hidden
message in the imap server, it is experimental, so maybe you could
consider to add a ddbb to handle this info (we use derby in james
server as the default one).

The project is big and it is difficult to estimate the effort for each
thing. But I think your schedule could be a good start point.


Cheers
- Manolo


On Thu, Mar 29, 2012 at 3:43 PM, echo  wrote:
> Hi, Manuel Carrasco
>
> Hupa is an Rich IMAP-based Webmail application written in GWT, but there is
> no release delivered yet
>
> We propose that gsoc student/s take the actual Hupa code and 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 Status
> - Hupa has been entirely written in java to be coherent with the
> language used in the James project.
>
> The Hupa has been checked out and deployed successfully on my
> ArchLinux+openjdk6+eclipse，even though I could not login with my gmail
> account and password which can access http://hupa.alcala.org. Maybe it need
> config the .hupa/config.properties, I think.
>
> - 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.
>
> I also found some examples or instructions on GWT's own MVP architectrue at
> here, it can be as a reference in my opinion, can it?
> It is found that gwt-dispatch is used in more places than the others, since
> almost every maven module(sever, client, share, etc.) needs it. So I believe
> it will take more time to change it by Command Pattern(RequestFactory as
> below) than the others.
> Acutally I have no idea about "Gin + Guice: for dependency injection." wh

Re: [GSOC2012] Hupa evolution

[echo]

Hi, Manolo
My "[GSOC2012] Hupa evolution" proposal has been updated in

   http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/echo/1.


Could you give me some advices about it? If it looks Ok, I am gonna to 
cope with some beginning stuff. If not, however, I will have to change 
something through your suggests.

Many thanks for your consideration.

-Echo


On 03/30/2012 06:08 PM, Manuel Carrasco Moñino wrote:

Hi Echo

I'm CCing the mailing list because other developers could be
interested in these questions.

Proly you can not login into gmail because of either cacerts issues or
you have not enabled imap in your gmail account.

Yesterday, I committed a fix to the default config.properties removing
the 'TrustStore' line so as hupa can use the default java cacerts
file.
If you are using openjdk, you should check that cacerts file is complete.

There are several MVP articles, the one you say is a good start point.
There are different approaches of how implement MVP, hupa is using
gwt-presenter which is similar to the stuff in gwt-2.4 so the idea is
to replace it with gwt-2.4 although we could consider other nice
libraries like mvp4g or gwtp. I recomend to you to read everything you
find in order to write a good proposal.

gwt-dispatcher is used in client and server sides because it is the
framework used to comunicate both sides (this is the reason why you
can see it in many modules). We used it instead of RPC in order to use
the command pattern and facilitate testing of remote procedures in the
jvm. This library is not very used nowadays because people uses the
new RequestFactory stuff. The evolution of gwt-dispatcher is in the
gwtp library.

Although RequestFactory is though to be used with ddbb entities, I
think we can consider our objects (emails, folders, etc) like entities
and take advantage of this pattern. Anyway, you could consider other
library like gwtp if it simplifies the code or the developing of new
features in hupa.

Gin is the only way to have injection in client side. Gin syntax is
the same than Guice and you have to use both to test client presenters
and code in the jvm. Note that one of the main goals in MVP is to test
in the jvm client code, so we need a way to decouple presenters, etc
and inject the necessary stuff to test them in the jvm.

We use gwt-dnd because it was the only available library those days.
It is necessary to move messages to folders. Now gwt has dnd support
although Cell widgets do not support it, may be we had to use
gwtquery-dnd etc. when we replace the message celltable.

gwtquery brings the simplicity of jquery to gwt, specially when
dealing with dom elements or html content, note that it doesn't need
jquery at all. I think gquery can help to display messages (clean
them, resize, etc). I maintain this library so feel free to ask me any
question you had about it.

All of these new features you suggest are welcome. Note that hupa does
not have any ddbb in server side, we are storing stuff in a hidden
message in the imap server, it is experimental, so maybe you could
consider to add a ddbb to handle this info (we use derby in james
server as the default one).

The project is big and it is difficult to estimate the effort for each
thing. But I think your schedule could be a good start point.


Cheers
- Manolo


On Thu, Mar 29, 2012 at 3:43 PM, echo  wrote:

Hi, Manuel Carrasco

Hupa is an Rich IMAP-based Webmail application written in GWT, but there is
no release delivered yet

We propose that gsoc student/s take the actual Hupa code and 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 Status
 - Hupa has been entirely written in java to be coherent with the
language used in the James project.

The Hupa has been checked out and deployed successfully on my
ArchLinux+openjdk6+eclipse，even though I could not login with my gmail
account and password which can access http://hupa.alcala.org. Maybe it need
config the .hupa/config.properties, I think.

 - 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.

I also found some examples or instructions on GWT

Re: [GSOC2012] Hupa evolution

[Manuel Carrasco Moñino]

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

On Thu, Apr 5, 2012 at 1:01 PM, echo  wrote:
> Hi, Manolo
> My "[GSOC2012] Hupa evolution" proposal has been updated in
>
> http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/echo/1.
>
> Could you give me some advices about it? If it looks Ok, I am gonna to cope
> with some beginning stuff. If not, however, I will have to change something
> through your suggests.
> Many thanks for your consideration.
>
> -Echo
>
>
>
> On 03/30/2012 06:08 PM, Manuel Carrasco Moñino wrote:
>
> Hi Echo
>
> I'm CCing the mailing list because other developers could be
> interested in these questions.
>
> Proly you can not login into gmail because of either cacerts issues or
> you have not enabled imap in your gmail account.
>
> Yesterday, I committed a fix to the default config.properties removing
> the 'TrustStore' line so as hupa can use the default java cacerts
> file.
> If you are using openjdk, you should check that cacerts file is complete.
>
> There are several MVP articles, the one you say is a good start point.
> There are different approaches of how implement MVP, hupa is using
> gwt-presenter which is similar to the stuff in gwt-2.4 so the idea is
> to replace it with gwt-2.4 although we could consider other nice
> libraries like mvp4g or gwtp. I recomend to you to read everything you
> find in order to write a good proposal.
>
> gwt-dispatcher is used in client and server sides because it is the
> framework used to comunicate both sides (this is the reason why you
> can see it in many modules). We used it instead of RPC in order to use
> the command pattern and facilitate testing of remote procedures in the
> jvm. This library is not very used nowadays because people uses the
> new RequestFactory stuff. The evolution of gwt-dispatcher is in the
> gwtp library.
>
> Although RequestFactory is though to be used with ddbb entities, I
> think we can consider our objects (emails, folders, etc) like entities
> and take advantage of this pattern. Anyway, you could consider other
> library like gwtp if it simplifies the code or the developing of new
> features in hupa.
>
> Gin is the only way to have injection in client side. Gin syntax is
> the same than Guice and you have to use both to test client presenters
> and code in the jvm. Note that one of the main goals in MVP is to test
> in the jvm client code, so we need a way to decouple presenters, etc
> and inject the necessary stuff to test them in the jvm.
>
> We use gwt-dnd because it was the only available library those days.
> It is necessary to move messages to folders. Now gwt has dnd support
> although Cell widgets do not support it, may be we had to use
> gwtquery-dnd etc. when we replace the message celltable.
>
> gwtquery brings the simplicity of jquery to gwt, specially when
> dealing with dom elements or html content, note that it doesn't need
> jquery at all. I think gquery can help to display messages (clean
> them, resize, etc). I maintain this library so feel free to ask me any
> question you had about it.
>
> All of these new features you suggest are welcome. Note that hupa does
> not have any ddbb in server side, we are storing stuff in a hidden
> message in the imap server, it is experimental, so maybe you could
> consider to add a ddbb to handle this info (we use derby in james
> server as the default one).
>
> The project is big and it is difficult to estimate the effort for each
> thing. But I think your schedule could be a good start point.
>
>
> Cheers
> - Manolo
>
>
> On Thu, Mar 29, 2012 at 3:43 PM, echo  wrote:
>
> Hi, Manuel Carrasco
>
> Hupa is an Rich IMAP-based Webmail application written in GWT, but there is
> no release delivered yet
>
> We propose that gsoc student/s take the actual Hupa code and 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 Status
> - Hupa has been entirely written in java to be coherent with the
> language used in the James project.
>
> The Hupa has been checked out and deployed successfully on my
> ArchLinux+openjdk6+eclipse，even though I could not login with my gmail
> account and password which can access http://hupa.alcala.org. Maybe it need
> config the .hupa/conf

Re: [GSOC2012] Hupa evolution

[echo]

  
  
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 :)





  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
  

Re: [GSOC2012] Hupa evolution

[Manuel Carrasco Moñino]

Hello Echo.

It sounds good to me.
Keep me informed about your progress, and modify your proposal or write
comments with your thoughts and details in the gsoc melange site as well.

Cheers
- Manolo


On Wed, Apr 11, 2012 at 5:48 PM, echo  wrote:

>  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 :)
>
>
> [image: 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
>
>

Re: [GSOC2012] Hupa evolution

[Ioan Eugen Stan]

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-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: [GSOC2012] Hupa evolution

[Dhrubo]

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 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
> For additional commands, e-mail: 
> server-dev-help@james.apache.**org
>
>


-- 
Kind Regards... Dhrubo

Re: [GSOC2012] Hupa evolution

[Manuel Carrasco Moñino]

-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  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  >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-unsubscr...@james.apache.org>
> > For additional commands, e-mail: server-dev-help@james.apache.**org<
> server-dev-h...@james.apache.org>
> >
> >
>
>
> --
> Kind Regards... Dhrubo
>
> 
>

Re: [GSOC2012] Hupa evolution

[Dhrubo]

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
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  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  > >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-unsubscr...@james.apache.org>
> > > For additional commands, e-mail: server-dev-help@james.apache.**org<
> > server-dev-h...@james.apache.org>
> > >
> > >
> >
> >
> > --
> > Kind Regards... Dhrubo
> >
> > 
> >
>



-- 
Kind Regards... Dhrubo

Re: [GSOC2012] Hupa evolution

[Dhrubo]

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  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  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 > > >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-unsubscr...@james.apache.org>
>> > > For additional commands, e-mail: server-dev-help@james.apache.**org<
>> > server-dev-h...@james.apache.org>
>> > >
>> > >
>> >
>> >
>> > --
>> > Kind Regards... Dhrubo
>> >
>> > 
>> >
>>
>
>
>
> --
> Kind Regards... Dhrubo
>
> 
>



-- 
Kind Regards... Dhrubo

Re: [GSOC2012] Hupa evolution

[Manuel Carrasco Moñino]

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  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  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  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-unsubscr...@james.apache.org>
> >> > > For additional commands, e-mail: server-dev-help@james.apache.
> **org<
> >> > server-dev-h...@james.apache.org>
> >> > >
> >> > >
> >> >
> >> >
> >> > --
> >> > Kind Regards... Dhrubo
> >> >
> >> > 
> >> >
> >>
> >
> >
> >
> > --
> > Kind Regards... Dhrubo
> >
> > 
> >
>
>
>
>

Re: [GSOC2012] Hupa evolution

[Dhrubo]

Manolo -
Primefaces Mailbox template ---
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/

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

This can be further extended with Spring and Ant style configuration.


On Wed, Apr 18, 2012 at 3:37 PM, Manuel Carrasco Moñino
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  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  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 
> 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 readin

Re: [GSOC2012] Hupa evolution

[Ioan Eugen Stan]

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 :
> Manolo -
> Primefaces Mailbox template ---
> 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/
>
> 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
>
> This can be further extended with Spring and Ant style configuration.
>
>
> On Wed, Apr 18, 2012 at 3:37 PM, Manuel Carrasco Moñino
> 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  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  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 
>> 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
>> > >> > t

Re: [GSOC2012] Hupa evolution

[Manuel Carrasco Moñino]

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 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 :
> > Manolo -
> > Primefaces Mailbox template ---
> > 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/
> >
> > 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
> >
> > This can be further extended with Spring and Ant style configuration.
> >
> >
> > On Wed, Apr 18, 2012 at 3:37 PM, Manuel Carrasco Moñino
> > 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  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 
> 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 
> >> 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.

Re: [GSOC2012] Hupa evolution

[Manuel Carrasco Moñino]

Dhrubo,

More helpful info about gwt.

On Wed, Apr 18, 2012 at 12:24 PM, Dhrubo  wrote:

> Manolo -
> Primefaces Mailbox template ---
> http://www.primefaces.org/showcase-labs/ui/layoutMailbox.jsf
>

Gwt guys have an example of a Mail application as a start-point as well (we
did not use it at the beginning of hupa though)
 http://gwt.google.com/samples/Mail/Mail.html


>
> 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/
>
> They also have their entire showcase online.
>

Gwt show-case (it is fully customizable using just a well documented css
api)
http://gwt.google.com/samples/Showcase/Showcase.html#!CwCellList

Of course, out of the core there are several widgets, suites and libs
available.


>
> 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
>
> This can be further extended with Spring and Ant style configuration.
>

Hupa already is packaged with jetty, so it could be run in any desktop with
java, using a browser or even xul.

Hupa works out-of-the-box in mobile devices (try access with a mobile or
tablet to the demmoing instances), and because gwt is pure js, it should be
easy to convert in a mobile native app using phonegap (now apache cordova).

- Manolo



>
>
> On Wed, Apr 18, 2012 at 3:37 PM, Manuel Carrasco Moñino
> 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  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 
> 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 
> > 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.
> > > >>

Re: [GSOC2012] Hupa evolution

[Eric Charles]

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 Stanwrote:


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:

Manolo -
Primefaces Mailbox template ---
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/

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

This can be further extended with Spring and Ant style configuration.


On Wed, Apr 18, 2012 at 3:37 PM, Manuel Carrasco Moñino
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  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

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

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

t

Re: [GSOC2012] Hupa evolution

[Dhrubo]

Looks good!!!

On Thu, Apr 19, 2012 at 9:20 AM, Eric Charles  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**
>> 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**:
>>>
 Manolo -
 Primefaces Mailbox template ---
 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/

 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

 This can be further extended with Spring and Ant style configuration.


 On Wed, Apr 18, 2012 at 3:37 PM, Manuel Carrasco Moñino
 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
>  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
>>
> 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:

Re: [GSOC2012] Hupa evolution

[Manuel Carrasco Moñino]

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  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
>> g

Re: [GSOC2012] Hupa evolution

[Eric Charles]

Hi Manolo,

Thx a lot for the detailed information.

- On the decoupling: I like gwt-dispatch, but was thinking to still 
further decouple stuff in separate module independent of any http/gwt/...


- Direct access to james mailbox will be killer, but efficient imap 
client service is still needed for non-james users (I have in my 
bookmarks 
https://github.com/dhanji/sitebricks/tree/master/sitebricks-mail which 
support oauth2...)


- mailbox-imap would be a cool module :)

- About the client side, I work since 5 months on a GWT project and I 
made stuff I couldn't have done with any other web technology, so you 
won't have to convince a prayer ;). We now use also separate module for 
client, shared and server, but important, we put our business logic in 
other modules agnostic from any presentation.


Thx again,

Eric

On 04/19/2012 09:48 AM, Manuel Carrasco Moñino wrote:

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, edi

Re: [GSOC2012] Hupa evolution

[Eric Charles]

After all, if we develop mailbox-imap, we could have Hupa using the 
mailbox-api to a local james or any remote server.


Prolly the user and domain stuff could go in a separate hupa module 
(separation of concerns).


That would be cool,

Eric

On 04/19/2012 10:38 AM, Eric Charles wrote:

Hi Manolo,

Thx a lot for the detailed information.

- On the decoupling: I like gwt-dispatch, but was thinking to still
further decouple stuff in separate module independent of any http/gwt/...

- Direct access to james mailbox will be killer, but efficient imap
client service is still needed for non-james users (I have in my
bookmarks
https://github.com/dhanji/sitebricks/tree/master/sitebricks-mail which
support oauth2...)

- mailbox-imap would be a cool module :)

- About the client side, I work since 5 months on a GWT project and I
made stuff I couldn't have done with any other web technology, so you
won't have to convince a prayer ;). We now use also separate module for
client, shared and server, but important, we put our business logic in
other modules agnostic from any presentation.

Thx again,

Eric

On 04/19/2012 09:48 AM, Manuel Carrasco Moñino wrote:

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 we

Re: [GSOC2012] Hupa evolution

[Manuel Carrasco Moñino]

On Thu, Apr 19, 2012 at 10:54 AM, Eric Charles
wrote:

> After all, if we develop mailbox-imap, we could have Hupa using the
> mailbox-api to a local james or any remote server.
>

Yep, this is the point, I think with that is not necessary to maintain imap
code in hupa server side, although we need to have a james server doing
that work, also we can use james storage to cache copies of the messages.


>
> Prolly the user and domain stuff could go in a separate hupa module
> (separation of concerns).
>

agree


>
> That would be cool,
>
> Eric
>
>
> On 04/19/2012 10:38 AM, Eric Charles wrote:
>
>> Hi Manolo,
>>
>> Thx a lot for the detailed information.
>>
>> - On the decoupling: I like gwt-dispatch, but was thinking to still
>> further decouple stuff in separate module independent of any http/gwt/...
>>
>> - Direct access to james mailbox will be killer, but efficient imap
>> client service is still needed for non-james users (I have in my
>> bookmarks
>> https://github.com/dhanji/**sitebricks/tree/master/**sitebricks-mailwhich
>> support oauth2...)
>>
>> - mailbox-imap would be a cool module :)
>>
>> - About the client side, I work since 5 months on a GWT project and I
>> made stuff I couldn't have done with any other web technology, so you
>> won't have to convince a prayer ;). We now use also separate module for
>> client, shared and server, but important, we put our business logic in
>> other modules agnostic from any presentation.
>>
>> Thx again,
>>
>> Eric
>>
>> On 04/19/2012 09:48 AM, Manuel Carrasco Moñino wrote:
>>
>>> 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

Re: [GSOC2012] Hupa evolution

[Eric Charles]

On 04/19/2012 10:58 AM, Manuel Carrasco Moñino wrote:

On Thu, Apr 19, 2012 at 10:54 AM, Eric Charles
wrote:


After all, if we develop mailbox-imap, we could have Hupa using the
mailbox-api to a local james or any remote server.



Yep, this is the point, I think with that is not necessary to maintain imap
code in hupa server side, although we need to have a james server doing
that work, also we can use james storage to cache copies of the messages.



Yep, it will be mailbox-imap responsibility to interact to the external 
servers (ideally with a performant nio client, not the oracle one), and 
cache in memory (we even have mailbox-memory) and/or storage for Hupa.






Prolly the user and domain stuff could go in a separate hupa module
(separation of concerns).



agree




That would be cool,

Eric


On 04/19/2012 10:38 AM, Eric Charles wrote:


Hi Manolo,

Thx a lot for the detailed information.

- On the decoupling: I like gwt-dispatch, but was thinking to still
further decouple stuff in separate module independent of any http/gwt/...

- Direct access to james mailbox will be killer, but efficient imap
client service is still needed for non-james users (I have in my
bookmarks
https://github.com/dhanji/**sitebricks/tree/master/**sitebricks-mailwhich
support oauth2...)

- mailbox-imap would be a cool module :)

- About the client side, I work since 5 months on a GWT project and I
made stuff I couldn't have done with any other web technology, so you
won't have to convince a prayer ;). We now use also separate module for
client, shared and server, but important, we put our business logic in
other modules agnostic from any presentation.

Thx again,

Eric

On 04/19/2012 09:48 AM, Manuel Carrasco Moñino wrote:


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 

Re: [GSOC2012] Hupa evolution

[Luis Slocker]

Great!, Manolo, thank you very much.

This new contribution is serving me a lot to get to understand the
architecture of Hupa, and to know where they fit the pieces of this
interesting puzzle.

2012/4/19 Manuel Carrasco Moñino 

> 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  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 librari

Re: [GSOC2012] Hupa evolution

[echo]

I am sorry for not contacting with this channel, because my grandma got the
lung cancer and passed away the other day. I am too sad to do anything
until now.
However, I pick up my spirits to continue the project and my life. Pls
believe in me.
Thank you.

On Thu, Apr 19, 2012 at 10:58 PM, Luis Slocker wrote:

> Great!, Manolo, thank you very much.
>
> This new contribution is serving me a lot to get to understand the
> architecture of Hupa, and to know where they fit the pieces of this
> interesting puzzle.
>
> 2012/4/19 Manuel Carrasco Moñino 
>
> > 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 

Re: [GSOC2012] Hupa evolution

[Eric Charles]

Hi echo,
My sincerest condolences for your grandmother.
All the best,
Eric


On 04/21/2012 02:57 AM, echo wrote:

I am sorry for not contacting with this channel, because my grandma got the
lung cancer and passed away the other day. I am too sad to do anything
until now.
However, I pick up my spirits to continue the project and my life. Pls
believe in me.
Thank you.

On Thu, Apr 19, 2012 at 10:58 PM, Luis Slockerwrote:


Great!, Manolo, thank you very much.

This new contribution is serving me a lot to get to understand the
architecture of Hupa, and to know where they fit the pieces of this
interesting puzzle.

2012/4/19 Manuel Carrasco Moñino


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,

Re: [GSOC2012] Hupa evolution

[Manuel Carrasco Moñino]

Hi echo I'm very sorry for the death of your granny.
Don't worry about not contacting us for this while, we understand each
contributor circunstances.

As you can see in this thread we just have shared opinions about the status
and future of hupa and advantages/disadvantages about different
technologies, don't hesitate to participate with your ideas as well.

Related with gsoc, we would know if you are selected in the course of the
next days, I wish you good luck.

- Manolo

On Sat, Apr 21, 2012 at 7:31 AM, Eric Charles  wrote:

> Hi echo,
> My sincerest condolences for your grandmother.
> All the best,
> Eric
>
>
>
> On 04/21/2012 02:57 AM, echo wrote:
>
>> I am sorry for not contacting with this channel, because my grandma got
>> the
>> lung cancer and passed away the other day. I am too sad to do anything
>> until now.
>> However, I pick up my spirits to continue the project and my life. Pls
>> believe in me.
>> Thank you.
>>
>> On Thu, Apr 19, 2012 at 10:58 PM, Luis Slocker**
>> wrote:
>>
>>  Great!, Manolo, thank you very much.
>>>
>>> This new contribution is serving me a lot to get to understand the
>>> architecture of Hupa, and to know where they fit the pieces of this
>>> interesting puzzle.
>>>
>>> 2012/4/19 Manuel Carrasco Moñino
>>>
>>>  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.- 

Re: [GSOC2012] Hupa evolution implementing chat

[Tejaswini Kurakula]

Hello Manolo,
I think we should integrate the google chat in HUPA evolution for which we
would have to create a XMPP rich client which can do the following :
1. Send invitation to chat
2. Chat presence and status
3.Provide a chat status
4. Sending and receiving chat messages.
At the abckend wew ould be using the XMPP server provided by Google Talk .
Let me know your thoughts on it .
Tejaswini

Re: [GSOC2012] Hupa evolution implementing chat

[Manuel Carrasco Moñino]

So we would need that a Hupa user have a gmail account, right?

I think Hupa is thought to interact with any imap server, and specially
with  James, have you consider the option to implement the chat using Hupa
server side instead of google's ?

Cheers
- Manolo

On Thu, Apr 12, 2012 at 7:39 AM, Tejaswini Kurakula <
tejaswinikurak...@gmail.com> wrote:

> Hello Manolo,
> I think we should integrate the google chat in HUPA evolution for which we
> would have to create a XMPP rich client which can do the following :
> 1. Send invitation to chat
> 2. Chat presence and status
> 3.Provide a chat status
> 4. Sending and receiving chat messages.
> At the abckend wew ould be using the XMPP server provided by Google Talk .
> Let me know your thoughts on it .
> Tejaswini
>

Re: [GSOC2012] Hupa evolution implementing chat

[Dhrubo]

I think chat is an initial distraction. One can look to integrate with
Apache XMPP server - Apache VYSPER.
It can also be a pluggable module that integrates with any XMPP compliant
server

BR ...dhrubo

On Thu, Apr 12, 2012 at 11:35 AM, Manuel Carrasco Moñino
wrote:

> So we would need that a Hupa user have a gmail account, right?
>
> I think Hupa is thought to interact with any imap server, and specially
> with  James, have you consider the option to implement the chat using Hupa
> server side instead of google's ?
>
> Cheers
> - Manolo
>
> On Thu, Apr 12, 2012 at 7:39 AM, Tejaswini Kurakula <
> tejaswinikurak...@gmail.com> wrote:
>
> > Hello Manolo,
> > I think we should integrate the google chat in HUPA evolution for which
> we
> > would have to create a XMPP rich client which can do the following :
> > 1. Send invitation to chat
> > 2. Chat presence and status
> > 3.Provide a chat status
> > 4. Sending and receiving chat messages.
> > At the abckend wew ould be using the XMPP server provided by Google Talk
> .
> > Let me know your thoughts on it .
> > Tejaswini
> >
>



-- 
Kind Regards... Dhrubo

Re: [GSOC2012] Hupa evolution implementing chat

[Tejaswini Kurakula]

Hi manuel ,
I was also thinking of implementing the video mail with the help of
JMF(java media framework ) where we record the audio and video and send the
avi file directly to the user .
Also can you  please guide me , which one should i go for
1. Chat Application
2. Video Mail
I am fine with both .
Tejaswinin

On Thu, Apr 12, 2012 at 11:35 AM, Manuel Carrasco Moñino
wrote:

> So we would need that a Hupa user have a gmail account, right?
>
> I think Hupa is thought to interact with any imap server, and specially
> with  James, have you consider the option to implement the chat using Hupa
> server side instead of google's ?
>
> Cheers
> - Manolo
>
>
> On Thu, Apr 12, 2012 at 7:39 AM, Tejaswini Kurakula <
> tejaswinikurak...@gmail.com> wrote:
>
>> Hello Manolo,
>> I think we should integrate the google chat in HUPA evolution for which
>> we would have to create a XMPP rich client which can do the following :
>> 1. Send invitation to chat
>> 2. Chat presence and status
>> 3.Provide a chat status
>> 4. Sending and receiving chat messages.
>> At the abckend wew ould be using the XMPP server provided by Google Talk .
>> Let me know your thoughts on it .
>> Tejaswini
>>
>
>

Re: [GSOC2012] Hupa evolution implementing chat

[Manuel Carrasco Moñino]

To me instant chat is more necessary than video mail.

- Manolo

On Thu, Apr 12, 2012 at 8:34 AM, Tejaswini Kurakula <
tejaswinikurak...@gmail.com> wrote:

> Hi manuel ,
> I was also thinking of implementing the video mail with the help of
> JMF(java media framework ) where we record the audio and video and send the
> avi file directly to the user .
> Also can you  please guide me , which one should i go for
> 1. Chat Application
> 2. Video Mail
> I am fine with both .
> Tejaswinin
>
> On Thu, Apr 12, 2012 at 11:35 AM, Manuel Carrasco Moñino <
> man...@apache.org> wrote:
>
>> So we would need that a Hupa user have a gmail account, right?
>>
>> I think Hupa is thought to interact with any imap server, and specially
>> with  James, have you consider the option to implement the chat using Hupa
>> server side instead of google's ?
>>
>> Cheers
>> - Manolo
>>
>>
>> On Thu, Apr 12, 2012 at 7:39 AM, Tejaswini Kurakula <
>> tejaswinikurak...@gmail.com> wrote:
>>
>>> Hello Manolo,
>>> I think we should integrate the google chat in HUPA evolution for which
>>> we would have to create a XMPP rich client which can do the following :
>>> 1. Send invitation to chat
>>> 2. Chat presence and status
>>> 3.Provide a chat status
>>> 4. Sending and receiving chat messages.
>>> At the abckend wew ould be using the XMPP server provided by Google Talk
>>> .
>>> Let me know your thoughts on it .
>>> Tejaswini
>>>
>>
>>
>

Re: [GSOC2012] Hupa evolution implementing chat

[Dhrubo]

Manuel/Tejaswini - my 2 cents  both would be great :)

On Thu, Apr 12, 2012 at 12:04 PM, Tejaswini Kurakula <
tejaswinikurak...@gmail.com> wrote:

> Hi manuel ,
> I was also thinking of implementing the video mail with the help of
> JMF(java media framework ) where we record the audio and video and send the
> avi file directly to the user .
> Also can you  please guide me , which one should i go for
> 1. Chat Application
> 2. Video Mail
> I am fine with both .
> Tejaswinin
>
> On Thu, Apr 12, 2012 at 11:35 AM, Manuel Carrasco Moñino
> wrote:
>
> > So we would need that a Hupa user have a gmail account, right?
> >
> > I think Hupa is thought to interact with any imap server, and specially
> > with  James, have you consider the option to implement the chat using
> Hupa
> > server side instead of google's ?
> >
> > Cheers
> > - Manolo
> >
> >
> > On Thu, Apr 12, 2012 at 7:39 AM, Tejaswini Kurakula <
> > tejaswinikurak...@gmail.com> wrote:
> >
> >> Hello Manolo,
> >> I think we should integrate the google chat in HUPA evolution for which
> >> we would have to create a XMPP rich client which can do the following :
> >> 1. Send invitation to chat
> >> 2. Chat presence and status
> >> 3.Provide a chat status
> >> 4. Sending and receiving chat messages.
> >> At the abckend wew ould be using the XMPP server provided by Google
> Talk .
> >> Let me know your thoughts on it .
> >> Tejaswini
> >>
> >
> >
>



-- 
Kind Regards... Dhrubo

Re: [GSOC2012] Hupa evolution implementing chat

[Manuel Carrasco Moñino]

Agree, we should integrate with an apache XMPP product to eat our own dog
food.

We should have in mind that we have to use the same auth database and if
possible everything should work out-of-the-box.



On Thu, Apr 12, 2012 at 8:20 AM, Dhrubo  wrote:

> I think chat is an initial distraction. One can look to integrate with
> Apache XMPP server - Apache VYSPER.
> It can also be a pluggable module that integrates with any XMPP compliant
> server
>
> BR ...dhrubo
>
> On Thu, Apr 12, 2012 at 11:35 AM, Manuel Carrasco Moñino
> wrote:
>
> > So we would need that a Hupa user have a gmail account, right?
> >
> > I think Hupa is thought to interact with any imap server, and specially
> > with  James, have you consider the option to implement the chat using
> Hupa
> > server side instead of google's ?
> >
> > Cheers
> > - Manolo
> >
> > On Thu, Apr 12, 2012 at 7:39 AM, Tejaswini Kurakula <
> > tejaswinikurak...@gmail.com> wrote:
> >
> > > Hello Manolo,
> > > I think we should integrate the google chat in HUPA evolution for which
> > we
> > > would have to create a XMPP rich client which can do the following :
> > > 1. Send invitation to chat
> > > 2. Chat presence and status
> > > 3.Provide a chat status
> > > 4. Sending and receiving chat messages.
> > > At the abckend wew ould be using the XMPP server provided by Google
> Talk
> > .
> > > Let me know your thoughts on it .
> > > Tejaswini
> > >
> >
>
>
>
> --
> Kind Regards... Dhrubo
>
> 
>

Re: [GSOC2012] Hupa evolution implementing chat

[Dhrubo]

We can make it a little more work as James is on Spring - so HUPA can use
Spring Integration for easy integration with XMPP server and LDAP like auth
repository. Thats also possible with Spring.

On Thu, Apr 12, 2012 at 12:15 PM, Manuel Carrasco Moñino
wrote:

> Agree, we should integrate with an apache XMPP product to eat our own dog
> food.
>
> We should have in mind that we have to use the same auth database and if
> possible everything should work out-of-the-box.
>
>
>
> On Thu, Apr 12, 2012 at 8:20 AM, Dhrubo  wrote:
>
> > I think chat is an initial distraction. One can look to integrate with
> > Apache XMPP server - Apache VYSPER.
> > It can also be a pluggable module that integrates with any XMPP compliant
> > server
> >
> > BR ...dhrubo
> >
> > On Thu, Apr 12, 2012 at 11:35 AM, Manuel Carrasco Moñino
> > wrote:
> >
> > > So we would need that a Hupa user have a gmail account, right?
> > >
> > > I think Hupa is thought to interact with any imap server, and specially
> > > with  James, have you consider the option to implement the chat using
> > Hupa
> > > server side instead of google's ?
> > >
> > > Cheers
> > > - Manolo
> > >
> > > On Thu, Apr 12, 2012 at 7:39 AM, Tejaswini Kurakula <
> > > tejaswinikurak...@gmail.com> wrote:
> > >
> > > > Hello Manolo,
> > > > I think we should integrate the google chat in HUPA evolution for
> which
> > > we
> > > > would have to create a XMPP rich client which can do the following :
> > > > 1. Send invitation to chat
> > > > 2. Chat presence and status
> > > > 3.Provide a chat status
> > > > 4. Sending and receiving chat messages.
> > > > At the abckend wew ould be using the XMPP server provided by Google
> > Talk
> > > .
> > > > Let me know your thoughts on it .
> > > > Tejaswini
> > > >
> > >
> >
> >
> >
> > --
> > Kind Regards... Dhrubo
> >
> > 
> >
>



-- 
Kind Regards... Dhrubo

Re: [GSOC2012] Hupa evolution implementing chat

[Manuel Carrasco Moñino]

Hupa does not consume any auth nor ldap system, since it delegates to the
imap protocol authentication, so the username/password pair provided by the
user is passed to the imap server to get a session.
Gmail supports oauth via imap though, i do not know if there are more imap
servers supporting that but i dont think so.

I would know more detail about how would be that integration with spring
and xmpp.



On Thu, Apr 12, 2012 at 8:53 AM, Dhrubo  wrote:

> We can make it a little more work as James is on Spring - so HUPA can use
> Spring Integration for easy integration with XMPP server and LDAP like auth
> repository. Thats also possible with Spring.
>
> On Thu, Apr 12, 2012 at 12:15 PM, Manuel Carrasco Moñino
> wrote:
>
> > Agree, we should integrate with an apache XMPP product to eat our own dog
> > food.
> >
> > We should have in mind that we have to use the same auth database and if
> > possible everything should work out-of-the-box.
> >
> >
> >
> > On Thu, Apr 12, 2012 at 8:20 AM, Dhrubo  wrote:
> >
> > > I think chat is an initial distraction. One can look to integrate with
> > > Apache XMPP server - Apache VYSPER.
> > > It can also be a pluggable module that integrates with any XMPP
> compliant
> > > server
> > >
> > > BR ...dhrubo
> > >
> > > On Thu, Apr 12, 2012 at 11:35 AM, Manuel Carrasco Moñino
> > > wrote:
> > >
> > > > So we would need that a Hupa user have a gmail account, right?
> > > >
> > > > I think Hupa is thought to interact with any imap server, and
> specially
> > > > with  James, have you consider the option to implement the chat using
> > > Hupa
> > > > server side instead of google's ?
> > > >
> > > > Cheers
> > > > - Manolo
> > > >
> > > > On Thu, Apr 12, 2012 at 7:39 AM, Tejaswini Kurakula <
> > > > tejaswinikurak...@gmail.com> wrote:
> > > >
> > > > > Hello Manolo,
> > > > > I think we should integrate the google chat in HUPA evolution for
> > which
> > > > we
> > > > > would have to create a XMPP rich client which can do the following
> :
> > > > > 1. Send invitation to chat
> > > > > 2. Chat presence and status
> > > > > 3.Provide a chat status
> > > > > 4. Sending and receiving chat messages.
> > > > > At the abckend wew ould be using the XMPP server provided by Google
> > > Talk
> > > > .
> > > > > Let me know your thoughts on it .
> > > > > Tejaswini
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Kind Regards... Dhrubo
> > >
> > > 
> > >
> >
>
>
>
> --
> Kind Regards... Dhrubo
>
> 
>

Re: [GSOC2012] Hupa evolution implementing chat

[Bernd Fondermann]

Hi,

On Thu, Apr 12, 2012 at 07:39, Tejaswini Kurakula
 wrote:
> Hello Manolo,
> I think we should integrate the google chat in HUPA evolution for which we
> would have to create a XMPP rich client which can do the following :
> 1. Send invitation to chat
> 2. Chat presence and status
> 3.Provide a chat status
> 4. Sending and receiving chat messages.
> At the abckend wew ould be using the XMPP server provided by Google Talk .
> Let me know your thoughts on it .
> Tejaswini

I think having XMPP chat in Hipa is generally a great idea.

However, I think (i.e. I guess I know) that implementing a XMPP client
is a GSoC project completely on it's own.
It's a totally separate protocol and technologies from email and James
(XMPP, BOSH).

Being an inactive James comitter and the initial developer and
committer of the XMPP server Apache Vysper, I'd be happy to help out
with any issues you might run into.
Vysper server can be easily embedded into any Spring setup and doesn't
require it's own separate process/JVM.

  Bernd

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: [GSOC2012] Hupa evolution implementing chat

[Tejaswini Kurakula]

Hi ,
So now we should concentrate on creating a xmpp client for  Apache Xmpp
server ?
tejaswini

On Thu, Apr 12, 2012 at 12:39 PM, Bernd Fondermann <
bernd.fonderm...@googlemail.com> wrote:

> Hi,
>
> On Thu, Apr 12, 2012 at 07:39, Tejaswini Kurakula
>  wrote:
> > Hello Manolo,
> > I think we should integrate the google chat in HUPA evolution for which
> we
> > would have to create a XMPP rich client which can do the following :
> > 1. Send invitation to chat
> > 2. Chat presence and status
> > 3.Provide a chat status
> > 4. Sending and receiving chat messages.
> > At the abckend wew ould be using the XMPP server provided by Google Talk
> .
> > Let me know your thoughts on it .
> > Tejaswini
>
> I think having XMPP chat in Hipa is generally a great idea.
>
> However, I think (i.e. I guess I know) that implementing a XMPP client
> is a GSoC project completely on it's own.
> It's a totally separate protocol and technologies from email and James
> (XMPP, BOSH).
>
> Being an inactive James comitter and the initial developer and
> committer of the XMPP server Apache Vysper, I'd be happy to help out
> with any issues you might run into.
> Vysper server can be easily embedded into any Spring setup and doesn't
> require it's own separate process/JVM.
>
>  Bernd
>
> -
> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> For additional commands, e-mail: server-dev-h...@james.apache.org
>
>

Re: [GSOC2012] Hupa evolution implementing chat

[Ioan Eugen Stan]

Pe 12.04.2012 10:31, Tejaswini Kurakula a scris:

Hi ,
So now we should concentrate on creating a xmpp client for  Apache Xmpp
server ?
tejaswini


Implementing a protocol client is not trivial, especially for a complex 
one like chat. You would be better off using an existing library and 
integrate it with Hupa. You're best start would be [1].


Use an existing (Java, Javascript) client library that implements the 
protocol and issue calls to the server based on client actions (login, 
logout, send message). Render the responses to the client.


Ideally Hupa should save as little state as possible on the server side. 
The client should try to maintain it's own state.


I would also like to see chat integration in Hupa. Good luck.

[1] http://xmpp.org/xmpp-software/libraries/

p.s. I really hope we get a project around Hupa. Manolo, I will 
co-mentor so count me in.


--
Ioan Eugen Stan
http://ieugen.blogspot.com

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: [GSOC2012] Hupa evolution implementing chat

[Tejaswini Kurakula]

Hi ,
I have gone through the list mentioned here -->
http://xmpp.org/xmpp-software/clients/. We can make use of any one of the
client library. Do we finalize that we would be using the Apache Vysper as
a imap server? Then we should find a suitable client library for it .
p.s I have my semester exams coming up all month long till may 15th , so
wont be able to contrubute till then . Please let me know if its ok .
I would love to implement this feature .
Tejaswini

On Thu, Apr 12, 2012 at 6:33 PM, Ioan Eugen Stan wrote:

> Pe 12.04.2012 10:31, Tejaswini Kurakula a scris:
>
>  Hi ,
>> So now we should concentrate on creating a xmpp client for  Apache Xmpp
>> server ?
>> tejaswini
>>
>
> Implementing a protocol client is not trivial, especially for a complex
> one like chat. You would be better off using an existing library and
> integrate it with Hupa. You're best start would be [1].
>
> Use an existing (Java, Javascript) client library that implements the
> protocol and issue calls to the server based on client actions (login,
> logout, send message). Render the responses to the client.
>
> Ideally Hupa should save as little state as possible on the server side.
> The client should try to maintain it's own state.
>
> I would also like to see chat integration in Hupa. Good luck.
>
> [1] 
> http://xmpp.org/xmpp-software/**libraries/
>
> p.s. I really hope we get a project around Hupa. Manolo, I will co-mentor
> so count me in.
>
> --
> Ioan Eugen Stan
> http://ieugen.blogspot.com
>
>
> --**--**-
> To unsubscribe, e-mail: 
> server-dev-unsubscribe@james.**apache.org
> For additional commands, e-mail: 
> server-dev-help@james.apache.**org
>
>

[jira] [Created] (HUPA-85) [GSOC2012] Hupa evolution

[Created]

[GSOC2012] Hupa evolution
-

 Key: HUPA-85
 URL: https://issues.apache.org/jira/browse/HUPA-85
 Project: JAMES Hupa
  Issue Type: New Feature
Reporter: Manuel Carrasco Moñino
Assignee: Norman Maurer


Hupa is an Rich IMAP-based Webmail application written in GWT,  but there is no 
release delivered yet

We propose that gsoc student/s take the actual Hupa code and 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 Status
- 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.

** Hupa roadmap
   - Replace out-of-date dependencies with GWT-2.4.0 stuff
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 
- Performance
Use gQuery in client side to enhance message view, specially to parse 
html messages and remove dangerous tags, instead of expensive parsing in server 
side
Implement Server cache and client storage
- New features
Contact management.
Authentication: Oauth
Message filters, User signature, User settings, Message sorting and 
labeling.
Theming

** Student skills: Java, Gwt, Web (Js, Html, Css)
** Dificulty: medium
** Mentor: Manuel Carrasco 



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Assigned] (HUPA-85) [GSOC2012] Hupa evolution

[Assigned]

 [ 
https://issues.apache.org/jira/browse/HUPA-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manuel Carrasco Moñino reassigned HUPA-85:
--

Assignee: Manuel Carrasco Moñino  (was: Norman Maurer)

> [GSOC2012] Hupa evolution
> -
>
> Key: HUPA-85
> URL: https://issues.apache.org/jira/browse/HUPA-85
> Project: JAMES Hupa
>  Issue Type: New Feature
>Reporter: Manuel Carrasco Moñino
>Assignee: Manuel Carrasco Moñino
>  Labels: gsoc2012, mentor
>
> Hupa is an Rich IMAP-based Webmail application written in GWT,  but there is 
> no release delivered yet
> We propose that gsoc student/s take the actual Hupa code and 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 Status
> - 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.
> ** Hupa roadmap
>- Replace out-of-date dependencies with GWT-2.4.0 stuff
> 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 
> - Performance
> Use gQuery in client side to enhance message view, specially to parse 
> html messages and remove dangerous tags, instead of expensive parsing in 
> server side
> Implement Server cache and client storage
> - New features
> Contact management.
> Authentication: Oauth
> Message filters, User signature, User settings, Message sorting and 
> labeling.
> Theming
> ** Student skills: Java, Gwt, Web (Js, Html, Css)
> ** Dificulty: medium
> ** Mentor: Manuel Carrasco 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (HUPA-85) [GSOC2012] Hupa evolution

[Commented]

[ 
https://issues.apache.org/jira/browse/HUPA-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13237983#comment-13237983
 ] 

Manuel Carrasco Moñino commented on HUPA-85:


This presentation is a good start-point to know what james, hupa and gwt are: 

http://www.slideshare.net/dodotis/apache-jameshupa-gw

> [GSOC2012] Hupa evolution
> -
>
> Key: HUPA-85
> URL: https://issues.apache.org/jira/browse/HUPA-85
> Project: JAMES Hupa
>  Issue Type: New Feature
>Reporter: Manuel Carrasco Moñino
>Assignee: Manuel Carrasco Moñino
>  Labels: gsoc2012, mentor
>
> Hupa is an Rich IMAP-based Webmail application written in GWT,  but there is 
> no release delivered yet
> We propose that gsoc student/s take the actual Hupa code and 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 Status
> - 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.
> ** Hupa roadmap
>- Replace out-of-date dependencies with GWT-2.4.0 stuff
> 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 
> - Performance
> Use gQuery in client side to enhance message view, specially to parse 
> html messages and remove dangerous tags, instead of expensive parsing in 
> server side
> Implement Server cache and client storage
> - New features
> Contact management.
> Authentication: Oauth
> Message filters, User signature, User settings, Message sorting and 
> labeling.
> Theming
> ** Student skills: Java, Gwt, Web (Js, Html, Css)
> ** Dificulty: medium
> ** Mentor: Manuel Carrasco 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Updated] (HUPA-85) [GSOC2012] Hupa evolution

[Updated]

 [ 
https://issues.apache.org/jira/browse/HUPA-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manuel Carrasco Moñino updated HUPA-85:
---

Description: 
Hupa is an Rich IMAP-based Webmail application written in GWT,  but there is no 
release delivered yet

We propose that gsoc student/s take the actual Hupa code and 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 Status
- 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.

** Hupa roadmap
   - Replace out-of-date dependencies with GWT-2.4.0 stuff
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 
- Performance
Use gQuery in client side to enhance message view, specially to parse 
html messages and remove dangerous tags, instead of expensive parsing in server 
side
Implement Server cache and client storage
- New features
Contact management.
Authentication: Oauth
Message filtering, grouping, sorting and labeling. 
User settings: name, emails, signature. 
Theming.

** Student skills: Java, Gwt, Web (Js, Html, Css)
** Dificulty: medium
** Mentor: Manuel Carrasco 



  was:
Hupa is an Rich IMAP-based Webmail application written in GWT,  but there is no 
release delivered yet

We propose that gsoc student/s take the actual Hupa code and 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 Status
- 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.

** Hupa roadmap
   - Replace out-of-date dependencies with GWT-2.4.0 stuff
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 
- Performance
Use gQuery in client side to enhance message view, specially to parse 
html messages and remove dangerous tags, instead of expensive parsing in server 
side
Implement Server cache and client storage
- New features
Contact management.
Authentication: Oauth
Message filters, User signature, User settings, Message sorting and 
labeling.
Theming

** Student skills: Java, Gwt, Web (Js, Html, Css)
** Dificulty: medium
** Mentor: Manuel Carrasco 




> [GSOC2012] Hupa evolution
> -
>
> Key: HUPA-85
> URL: https://issues.apache.org/jira/browse/HUPA-85
> Project: JAMES Hupa
>  Issue Type: New Feature
>Reporter: Manuel Carrasco Moñino
>Assignee: Manuel Carrasco Moñino
>  Labels: gsoc2012, mentor
>
> Hupa is an Rich IMAP-based Webmail application written in GWT, 

[jira] [Commented] (HUPA-85) [GSOC2012] Hupa evolution

[Commented]

[ 
https://issues.apache.org/jira/browse/HUPA-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13238171#comment-13238171
 ] 

Manuel Carrasco Moñino commented on HUPA-85:



I've setup a demo instance so as you can play with hupa and check its status.

It is configured in order to use gmail as an imap server, so you have to setup 
a gmail account and configure it enabling imap access. 

http://hupa.alcala.org
    
> [GSOC2012] Hupa evolution
> -
>
> Key: HUPA-85
> URL: https://issues.apache.org/jira/browse/HUPA-85
> Project: JAMES Hupa
>  Issue Type: New Feature
>Reporter: Manuel Carrasco Moñino
>Assignee: Manuel Carrasco Moñino
>  Labels: gsoc2012, mentor
>
> Hupa is an Rich IMAP-based Webmail application written in GWT,  but there is 
> no release delivered yet
> We propose that gsoc student/s take the actual Hupa code and 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 Status
> - 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.
> ** Hupa roadmap
>- Replace out-of-date dependencies with GWT-2.4.0 stuff
> 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 
> - Performance
> Use gQuery in client side to enhance message view, specially to parse 
> html messages and remove dangerous tags, instead of expensive parsing in 
> server side
> Implement Server cache and client storage
> - New features
> Contact management.
> Authentication: Oauth
> Message filtering, grouping, sorting and labeling. 
> User settings: name, emails, signature. 
> Theming.
> ** Student skills: Java, Gwt, Web (Js, Html, Css)
> ** Dificulty: medium
> ** Mentor: Manuel Carrasco 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (HUPA-85) [GSOC2012] Hupa evolution

[Luis Slocker (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/HUPA-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13238288#comment-13238288
 ] 

Luis Slocker commented on HUPA-85:
--

Hi,

I am Luis R. Slocker, a final year postgraduate student from University of 
Alcalá de Henares in Madrid, Spain. I am really interested in this project for 
the GSoC of this year.

I find it interesting GWT technology as a powerful tool for developing 
applications in the cloud, and I would like to extend my knowledge in this area.
I always wanted to initiate me into the open source community and help with 
humble contributions, and this seems perfect for me.

Then stay at your disposal for anything

Thanks! 

> [GSOC2012] Hupa evolution
> -
>
> Key: HUPA-85
> URL: https://issues.apache.org/jira/browse/HUPA-85
> Project: JAMES Hupa
>  Issue Type: New Feature
>Reporter: Manuel Carrasco Moñino
>Assignee: Manuel Carrasco Moñino
>  Labels: gsoc2012, mentor
>
> Hupa is an Rich IMAP-based Webmail application written in GWT,  but there is 
> no release delivered yet
> We propose that gsoc student/s take the actual Hupa code and 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 Status
> - 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.
> ** Hupa roadmap
>- Replace out-of-date dependencies with GWT-2.4.0 stuff
> 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 
> - Performance
> Use gQuery in client side to enhance message view, specially to parse 
> html messages and remove dangerous tags, instead of expensive parsing in 
> server side
> Implement Server cache and client storage
> - New features
> Contact management.
> Authentication: Oauth
> Message filtering, grouping, sorting and labeling. 
> User settings: name, emails, signature. 
> Theming.
> ** Student skills: Java, Gwt, Web (Js, Html, Css)
> ** Dificulty: medium
> ** Mentor: Manuel Carrasco 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (HUPA-85) [GSOC2012] Hupa evolution

[Commented]

[ 
https://issues.apache.org/jira/browse/HUPA-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13238836#comment-13238836
 ] 

Manuel Carrasco Moñino commented on HUPA-85:


Hi Luis, 

I'm glad that you are interested in the project. 
Please, could you send an email with your offer to the dev mailing list 
(server-dev@james.apache.org) so as other developers know this. 

Thank you
 
    
> [GSOC2012] Hupa evolution
> -
>
> Key: HUPA-85
> URL: https://issues.apache.org/jira/browse/HUPA-85
> Project: JAMES Hupa
>  Issue Type: New Feature
>Reporter: Manuel Carrasco Moñino
>Assignee: Manuel Carrasco Moñino
>  Labels: gsoc2012, mentor
>
> Hupa is an Rich IMAP-based Webmail application written in GWT,  but there is 
> no release delivered yet
> We propose that gsoc student/s take the actual Hupa code and 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 Status
> - 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.
> ** Hupa roadmap
>- Replace out-of-date dependencies with GWT-2.4.0 stuff
> 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 
> - Performance
> Use gQuery in client side to enhance message view, specially to parse 
> html messages and remove dangerous tags, instead of expensive parsing in 
> server side
> Implement Server cache and client storage
> - New features
> Contact management.
> Authentication: Oauth
> Message filtering, grouping, sorting and labeling. 
> User settings: name, emails, signature. 
> Theming.
> ** Student skills: Java, Gwt, Web (Js, Html, Css)
> ** Dificulty: medium
> ** Mentor: Manuel Carrasco 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (HUPA-85) [GSOC2012] Hupa evolution

[Thelge Tharindu Madushanka Peiris (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/HUPA-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13239640#comment-13239640
 ] 

Thelge Tharindu Madushanka Peiris  commented on HUPA-85:


 hi,

 I am Tharindu , first year undergraduate student from university of Colombo in 
Sri lanka , This is my very first Gsoc and I really interest this project, I 
think that  I can contribute it with my new ideas more than java or any 
other technical skills.  

> [GSOC2012] Hupa evolution
> -
>
> Key: HUPA-85
> URL: https://issues.apache.org/jira/browse/HUPA-85
> Project: JAMES Hupa
>  Issue Type: New Feature
>Reporter: Manuel Carrasco Moñino
>Assignee: Manuel Carrasco Moñino
>  Labels: gsoc2012, mentor
>
> Hupa is an Rich IMAP-based Webmail application written in GWT,  but there is 
> no release delivered yet
> We propose that gsoc student/s take the actual Hupa code and 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 Status
> - 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.
> ** Hupa roadmap
>- Replace out-of-date dependencies with GWT-2.4.0 stuff
> 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 
> - Performance
> Use gQuery in client side to enhance message view, specially to parse 
> html messages and remove dangerous tags, instead of expensive parsing in 
> server side
> Implement Server cache and client storage
> - New features
> Contact management.
> Authentication: Oauth
> Message filtering, grouping, sorting and labeling. 
> User settings: name, emails, signature. 
> Theming.
> ** Student skills: Java, Gwt, Web (Js, Html, Css)
> ** Dificulty: medium
> ** Mentor: Manuel Carrasco 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (HUPA-85) [GSOC2012] Hupa evolution

[Commented]

[ 
https://issues.apache.org/jira/browse/HUPA-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13239926#comment-13239926
 ] 

Manuel Carrasco Moñino commented on HUPA-85:


Hi Tharindu, 

Nice to see more people interested in contributing. 
Please could you send a message the developers mailing-list so as we can 
continue the conversation there?
You could indicate what are your skills and what those ideas are 

> [GSOC2012] Hupa evolution
> -
>
> Key: HUPA-85
> URL: https://issues.apache.org/jira/browse/HUPA-85
> Project: JAMES Hupa
>  Issue Type: New Feature
>Reporter: Manuel Carrasco Moñino
>Assignee: Manuel Carrasco Moñino
>  Labels: gsoc2012, mentor
>
> Hupa is an Rich IMAP-based Webmail application written in GWT,  but there is 
> no release delivered yet
> We propose that gsoc student/s take the actual Hupa code and 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 Status
> - 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.
> ** Hupa roadmap
>- Replace out-of-date dependencies with GWT-2.4.0 stuff
> 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 
> - Performance
> Use gQuery in client side to enhance message view, specially to parse 
> html messages and remove dangerous tags, instead of expensive parsing in 
> server side
> Implement Server cache and client storage
> - New features
> Contact management.
> Authentication: Oauth
> Message filtering, grouping, sorting and labeling. 
> User settings: name, emails, signature. 
> Theming.
> ** Student skills: Java, Gwt, Web (Js, Html, Css)
> ** Dificulty: medium
> ** Mentor: Manuel Carrasco 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Commented] (HUPA-85) [GSOC2012] Hupa evolution

[tejaswini kurakula (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/HUPA-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13245580#comment-13245580
 ] 

tejaswini kurakula commented on HUPA-85:


hi,

i have Replaced some of the out-of-date dependencies with GWT-2.4.0 stuff from 
the Hupa project manually before compiling it..it worked fine and got build 
successfully..

i understand that the GWT provides some poweful features for code generation 
that have enabled a meaningful subset of the GUICE features to be implemented 
in GWT and GIN features while applying some recipes to an existing application..

therefore, i want propose this as my project idea for GSoC 2012 and dug in deep 
to implement and make Hupa entirely compatible to the latest version of GWT...

Any kind of suggestions regarding the modification and implementation of it are 
greatly appreciated

Thank you,

Tejaswini kurakula



> [GSOC2012] Hupa evolution
> -
>
> Key: HUPA-85
> URL: https://issues.apache.org/jira/browse/HUPA-85
> Project: JAMES Hupa
>  Issue Type: New Feature
>Reporter: Manuel Carrasco Moñino
>Assignee: Manuel Carrasco Moñino
>  Labels: gsoc2012, mentor
>
> Hupa is an Rich IMAP-based Webmail application written in GWT,  but there is 
> no release delivered yet
> We propose that gsoc student/s take the actual Hupa code and 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 Status
> - 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.
> ** Hupa roadmap
>- Replace out-of-date dependencies with GWT-2.4.0 stuff
> 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 
> - Performance
> Use gQuery in client side to enhance message view, specially to parse 
> html messages and remove dangerous tags, instead of expensive parsing in 
> server side
> Implement Server cache and client storage
> - New features
> Contact management.
> Authentication: Oauth
> Message filtering, grouping, sorting and labeling. 
> User settings: name, emails, signature. 
> Theming.
> ** Student skills: Java, Gwt, Web (Js, Html, Css)
> ** Dificulty: medium
> ** Mentor: Manuel Carrasco 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Assigned] (HUPA-85) [GSOC2012] Hupa evolution

[Echo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HUPA-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Echo reassigned HUPA-85:


Assignee: Echo  (was: Manuel Carrasco Moñino)

> [GSOC2012] Hupa evolution
> -
>
> Key: HUPA-85
> URL: https://issues.apache.org/jira/browse/HUPA-85
> Project: JAMES Hupa
>  Issue Type: New Feature
>Reporter: Manuel Carrasco Moñino
>Assignee: Echo
>  Labels: gsoc2012, mentor
>
> Hupa is an Rich IMAP-based Webmail application written in GWT,  but there is 
> no release delivered yet
> We propose that gsoc student/s take the actual Hupa code and 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 Status
> - 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.
> ** Hupa roadmap
>- Replace out-of-date dependencies with GWT-2.4.0 stuff
> 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 
> - Performance
> Use gQuery in client side to enhance message view, specially to parse 
> html messages and remove dangerous tags, instead of expensive parsing in 
> server side
> Implement Server cache and client storage
> - New features
> Contact management.
> Authentication: Oauth
> Message filtering, grouping, sorting and labeling. 
> User settings: name, emails, signature. 
> Theming.
> ** Student skills: Java, Gwt, Web (Js, Html, Css)
> ** Dificulty: medium
> ** Mentor: Manuel Carrasco 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Closed] (HUPA-85) [GSOC2012] Hupa evolution

[echo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HUPA-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

echo closed HUPA-85.


Resolution: Not A Problem

It seems this issue should be able to closed since the GSoC 2012 had finished.

> [GSOC2012] Hupa evolution
> -
>
> Key: HUPA-85
> URL: https://issues.apache.org/jira/browse/HUPA-85
> Project: James Hupa
>  Issue Type: New Feature
>Reporter: Manuel Carrasco Moñino
>Assignee: echo
>  Labels: gsoc2012, mentor
>
> Hupa is an Rich IMAP-based Webmail application written in GWT,  but there is 
> no release delivered yet
> We propose that gsoc student/s take the actual Hupa code and 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 Status
> - 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.
> ** Hupa roadmap
>- Replace out-of-date dependencies with GWT-2.4.0 stuff
> 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 
> - Performance
> Use gQuery in client side to enhance message view, specially to parse 
> html messages and remove dangerous tags, instead of expensive parsing in 
> server side
> Implement Server cache and client storage
> - New features
> Contact management.
> Authentication: Oauth
> Message filtering, grouping, sorting and labeling. 
> User settings: name, emails, signature. 
> Theming.
> ** Student skills: Java, Gwt, Web (Js, Html, Css)
> ** Dificulty: medium
> ** Mentor: Manuel Carrasco 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Issue Comment Edited] (HUPA-85) [GSOC2012] Hupa evolution

[Issue Comment Edited]

[ 
https://issues.apache.org/jira/browse/HUPA-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13237983#comment-13237983
 ] 

Manuel Carrasco Moñino edited comment on HUPA-85 at 3/25/12 9:53 PM:
-



This presentation is a good start-point to know what james, hupa and gwt are: 

http://www.slideshare.net/dodotis/apache-jameshupa-gwt


  was (Author: manolo):
This presentation is a good start-point to know what james, hupa and gwt 
are: 

http://www.slideshare.net/dodotis/apache-jameshupa-gw
  
> [GSOC2012] Hupa evolution
> -
>
> Key: HUPA-85
> URL: https://issues.apache.org/jira/browse/HUPA-85
> Project: JAMES Hupa
>  Issue Type: New Feature
>Reporter: Manuel Carrasco Moñino
>Assignee: Manuel Carrasco Moñino
>  Labels: gsoc2012, mentor
>
> Hupa is an Rich IMAP-based Webmail application written in GWT,  but there is 
> no release delivered yet
> We propose that gsoc student/s take the actual Hupa code and 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 Status
> - 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.
> ** Hupa roadmap
>- Replace out-of-date dependencies with GWT-2.4.0 stuff
> 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 
> - Performance
> Use gQuery in client side to enhance message view, specially to parse 
> html messages and remove dangerous tags, instead of expensive parsing in 
> server side
> Implement Server cache and client storage
> - New features
> Contact management.
> Authentication: Oauth
> Message filters, User signature, User settings, Message sorting and 
> labeling.
> Theming
> ** Student skills: Java, Gwt, Web (Js, Html, Css)
> ** Dificulty: medium
> ** Mentor: Manuel Carrasco 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

[jira] [Issue Comment Edited] (HUPA-85) [GSOC2012] Hupa evolution

[Issue Comment Edited]

[ 
https://issues.apache.org/jira/browse/HUPA-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13239926#comment-13239926
 ] 

Manuel Carrasco Moñino edited comment on HUPA-85 at 3/27/12 8:47 PM:
-

Hi Tharindu, 

Nice to see more people interested in contributing. 
Please could you send a message the developers mailing-list so as we can 
continue the conversation there?
You could indicate what are your skills and what those ideas are. 

Thank you

  was (Author: manolo):
Hi Tharindu, 

Nice to see more people interested in contributing. 
Please could you send a message the developers mailing-list so as we can 
continue the conversation there?
You could indicate what are your skills and what those ideas are 
  
> [GSOC2012] Hupa evolution
> -
>
> Key: HUPA-85
> URL: https://issues.apache.org/jira/browse/HUPA-85
> Project: JAMES Hupa
>  Issue Type: New Feature
>Reporter: Manuel Carrasco Moñino
>Assignee: Manuel Carrasco Moñino
>  Labels: gsoc2012, mentor
>
> Hupa is an Rich IMAP-based Webmail application written in GWT,  but there is 
> no release delivered yet
> We propose that gsoc student/s take the actual Hupa code and 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 Status
> - 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.
> ** Hupa roadmap
>- Replace out-of-date dependencies with GWT-2.4.0 stuff
> 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 
> - Performance
> Use gQuery in client side to enhance message view, specially to parse 
> html messages and remove dangerous tags, instead of expensive parsing in 
> server side
> Implement Server cache and client storage
> - New features
> Contact management.
> Authentication: Oauth
> Message filtering, grouping, sorting and labeling. 
> User settings: name, emails, signature. 
> Theming.
> ** Student skills: Java, Gwt, Web (Js, Html, Css)
> ** Dificulty: medium
> ** Mentor: Manuel Carrasco 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org