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.
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 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. 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 On Sat, Apr 3, 2010 at 6:33 PM, Tomasz Oponowicz <tomasz.oponow...@gmail.com > wrote: > Hi Sergey, > > Thanks for your comments. > > I have updated my proposal (at ASF wiki and GSOC 2010 website) with > respect to your comments. > > > I'm not sure if we can come up with production-quality default > > implementation, perhaps a file-based ReadWriteLogStorage can be provided > > OTB, but there's no way we can have a default ReadableOnlyStorage, > perhaps > > the abstract helper only, given that users's code can log into external > > files using log4j, jul, sl4j, using various formats. > > I agree that production-quality default implementation of > ReadWriteLogStorage or ReadableLogStorage interface could be > problematic. Removed this requirement from my proposal. However I > noted about abstract helper dedicated for ReadWriteLogStorage and > ReadableLogStorage interface. > > > IMHO using links as opposed to buttons will be better (for browsing to > > first/last/etc feeds) > > Fixed. > > > The browser should offer users an option to do the search > > It is great idea to use FIQL query. I have updated my proposal and > noted about custom filtering requirement (by phrase, event log, date > range etc) using FIQL to build queries. > > Best Regards, > Tomasz Oponowicz >
