Hi Sergey, Thanks for your replay and sorry for my delay. I've been offline for a while. I add more comments below.
On Fri, Apr 16, 2010 at 4:25 PM, Sergey Beryozkin <sberyoz...@gmail.com> wrote: > Hi Tomasz > > If you can, please experiment with RSSBandit Atom reader on Windows, I used > it when testing Atom logging feeds and I thought it was quite close to how > I'd expect the views be partitioned. > RSSBandit has exactly layout that I think about. For sure, the browser will be web application (based on AJAX, JavaScript, JQuery, CSS, XSLT technologies) - not standalone application (based on Swing technology). However I'm going to prepare draft documentation to the end of this month. Documentation will contain uses cases, data flow diagram and sample screenshots. > The left hand panel lists the individual CXF endpoint feeds, a user will > create new subscriptions by specifying atom pull server endpoint addresses > and provide the username/password if needed. Later on we can think of We should think about a way how to store an additional data (subscribed feeds, user credentials etc.). The most obvious solution - browser can store data in: - cookies - local storage (introduced by HTML 5 [1]). I would prefer "local storage", but it isn't supported by any Internet Explorer (only Safari, Firefox, Google Chrome and Opera support this). What you think about this? > introducing an Atom services document which will show all the current > collection of CXF log feeds, but this can be done later. > > The top-right one represents a current feed page for an individual CXF > endpoint log feed (selected by clicking on the left plane) and lists the > links to individual log entries and this is where I'd expect the links to > previous/next/etc pages to be located. Currently, AtomPullServer builds some > primitive HTML page (without the links, or may even with ?) internally which > represents the current feed page in HTML, so this page will need to be > improved to have the links added and the styles attached, perhaps by > introducing some CSS and XSLT resources. > > The bottom-right one represents a selected log entry (selected in the > current feed page above). Again, AtomPullServer creates a primitive HTML > page too for representing a selected entry. > > Another possible (optional) enhancement to consider (only if you have some > time left, really not critical) : this browser acts as the feed as well to > which CXF AtomPush loggers will push too. Here is the idea. By default the > browser will poll the individual feeds. The frequency may have to be quite > small, say every 30 secs or 60 secs or whatever the user selects to ensure a > user/admin sees the uptodate picture. Now, this might put some pressure on > the actual application servers where JAXWS/JAXRS endpoints doing the actual > logging are published. > > One simple approach to solve that issue is to simply have a separate > container running AtomPullServers only and the other container(s) (which > host application endpoints) relying on AtomPushBeans posting log entries > oneway to AtomPullServers - our browser will poll the latter one and some > very limited pressure will be applied on the application containers. > WebClientDeliverer utilized by AtomPushBeans will need to be updated > slightly to optionally add @Oneway headers to outgoing requests, if > configured so. > I understood everything. > Now another option is for a browser to have a small window which sits right > below the windows mentioned above and which simply outputs the latest log > entry titles (no content, just titles) using FIFO, without storing anything. > The idea is that the application server which uses AtomPullServers ( which > our browser keeps polling) also employs a Oneway AtomPushBean to post most > important events (ERROR/WARN, etc) to the master feed (which what our > browser acts as too in this case). This can let the browser poll the > endpoint say every 4-5 mins thus reducing the pressure on the container but > also indicate to a user (by displaying the event in this window) that the > feed page may need to be refreshed manually... > > As I said, it can be addressed later on... > > Finally AtomPullServer will need to be enhanced slightly to support > conditional GETS, but this is an easy one (so I hope :-)). > > thanks, Sergey > [1] http://apirocks.com/html5/html5.html#slide7 -- Best Regards, Tomasz Oponowicz
