'Client side Event bus'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       rhq-devel
Subject:    Client side Event bus
From:       jkremser () redhat ! com (Jiri Kremser)
Date:       2012-10-09 11:28:48
Message-ID: 148681962.4271077.1349782128959.JavaMail.root () redhat ! com
[Download RAW message or body]

The increase of footprint holds also for compressed and/or unobfuscated JS (bellow is \
the sizes of the whole directory war/org.rhq.enterprise.gui.coregui.CoreGUI, \
including *.gwt.rpc ie GWT serialization policy files).

current | current-obf | current-obf-gz  x  errai | errai-obf | errai-obf-gz
----------------------------------------------------------------------
40.8      12.3            3.0               62.7     55.8       4.6

The largest file (.cache.html) has 752 kB gzipped and obfuscated for errai it is 1.5 \
MB.

> Is there not any way to reduce this?
I don't think so, but theoretically, we can use the code splitting from pure GWT \
https://developers.google.com/web-toolkit/doc/latest/DevGuideCodeSplitting, but I am \
not sure if it works with SmartGWT. SmartGWT library modules located in \
war/org.rhq.enterprise.gui.coregui.CoreGUI/sc/modules are very large as well:  \
ISC_Grids.js 747 kB ISC_Core.js 696 kB
ISC_Forms.js 629 kB
...
the whole directory = 7.5 megs
Here the SmartGWT JS libraries are not obfuscated even if the project is compiled \
with OBF flag, so here we could make some improvements. I haven't found anything \
about this though.

> Can you push the branch so we can check it out?
pushed to jkremser/errai-integration

JK

----- Original Message -----
From: "mike thompson" <mithomps at redhat.com>
To: rhq-devel at lists.fedorahosted.org
Sent: Tuesday, October 9, 2012 5:43:21 AM
Subject: Re: Client side Event bus

Jirka this is good research,

The transparent eventing between client and server is a very desirable behavior \
(especially via CDI). Pub/sub via javascript client(GWT) to java backend would \
definitely enhance the user experience as notifications and other pushes would become \
available on instantaneously.

I'm quite surprised by the large footprint (64% increase) as we already have the \
largest javascript application I have ever seen. I'm assuming these figures are \
uncompressed. What is the gzipped number?  [ I know that we are around 700kb gzipped \
and obfuscated; we pay a high price for stack traces.]  Is there not any way to \
reduce this? Why is the reason this is so large (especially when smartgwt wraps \
native javascript libs? Maybe the Errai guys can address this as it directly effects \
their/our technology. Out of curiosity what is the GWT OBF size? And the last \
question: Can you push the branch so we can check it out?

On Oct 5, 2012, at 6:11 AM, Jiri Kremser <jkremser at redhat.com> wrote:

> Hi, 
> I was playing with Errai lately and I was able to integrate it with RHQ, here are \
> my 2 cents. 
> what we would get:
> ------------------
> * CDI, once the migration to as7 is ready, there will be same technology used on \
> back-end and front-end. CDI events supports loosely coupled components removing the \
> direct dependencies and DI itself may allow for easier testing. 
> * Server push, errai bus allows for sending the events "across the wire" from \
> client side to server side and vice-versa. This could significantly improve the \
> responsiveness of UI (instead of manual polling by pressing the refresh button). \
>                 Following Ajax push technologies are supported by Errai:
> -short/long polling
> -web socket: netty (side channeling)
> as7.1.2 (experimental)
> Technology should be autoselected considering the fallbacks if not supported.
> 
> * they are going to support super dev mode
> 
> * from version 2.1 they want to support a subset of JPA utilizing the browser's \
> local storage. In theory it could be used for storing user prefs on client with the \
> same code as now serves for storing it on the server side. Depending on how large \
> subset it is. 
> * they provide their own solution for building the UI, I haven't looked how much it \
> is compatible with SmartGWT though. 
> 
> what we would lose:
> -------------------------------------
> * the footprint is bigger: 
> -Server side libs: (current x Errai) 15.9 MB x 24.9 MB (63% increase)
> -JS (1 locale, 1 browser): 40.8 MB x 63.6 MB (64% increase)
> 
> * compile time (1 locale, 1 browser, 4 worker threads on my tp520): ~2:05s x ~1:35s \
> (31% increase) 
> * -xmx=1024M is not enough for GWT compiler, 2048M works ok
> 
> 
> To sum it up, I am +1 on integrating it, but it is a big step and there could be \
> some performance issues. Please respond with your thoughts. Unfortunately, SmartGWT \
> doesn't allow for code splitting, at least for the SmartGWT library itself, and \
> there is one big file with all the javascript code making the users accessing from \
> mobile devices unhappy. (RHQ Pocket solves this for tablets.) 
> 
> JK
> 
> ----- Original Message -----
> From: "Lukas Krejci" <lkrejci at redhat.com>
> To: rhq-devel at lists.fedorahosted.org
> Sent: Tuesday, July 31, 2012 10:15:51 PM
> Subject: Re: Server side Event bus
> 
> While polling, etc. are nice concepts that are quite easy to grasp and 
> implement, I'd very much like to see some sophisticated event bus solution 
> employed in RHQ (spanning the server and clients).
> 
> We might not see the possibilities or use cases right now but tying ourselves 
> to a more "primitive" technology (that, after all, the event buses build upon) 
> would later require us to invest much more time into refactoring/restructuring 
> the code.
> 
> We already discussed the deficiencies of our GUI, which we ran into by choosing 
> an obsolete development model (GWT pushes the MVP style of development but we 
> chose swing-like approach, even though we knew about its scalability 
> problems). Let's try and pick carefully this time.
> 
> 
> On Tuesday, July 31, 2012 15:45:15 John Mazzitelli wrote:
> > > Nothing really specific ; it could even be a part of the UI that just
> > > polls some generic API every second and then informs other parts in the
> > > UI.
> > 
> > This is how I implemented that fast prototype I did with the UI messages
> > coming from the agent. Used polling.
> > > Perhaps GWT or SmartGWT also offers something similar out of the box
> > 
> > There is the concept of a GWT timer. Just something that gets triggered
> > after N milliseconds. You can implement a simple polling mechanism using
> > that and have it continually poll the server. This is what Errai helps with
> > - IIUC, Errai avoids the need to continually poll, since it involves
> > pushing from server to gwt client. But we don't currently integrate with
> > Errai as we all know. _______________________________________________
> > rhq-devel mailing list
> > rhq-devel at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel

_______________________________________________
rhq-devel mailing list
rhq-devel at lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel

[prev in list] [next in list] [prev in thread] [next in thread] 