cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: [GSOC][CXF-2736] Proposal for "Simple and lightweight Atom HTML-based browser for CXF logs"
Date Mon, 19 Apr 2010 15:01:00 GMT
Hi Tomasz

On Mon, Apr 19, 2010 at 10:13 AM, Tomasz Oponowicz <> wrote:

> Hi Sergey,
> Thanks for your replay and sorry for my delay. I've been offline for a
> while. I add more comments below.

no problems at all, please feel free to reply whenever you have some time

> On Fri, Apr 16, 2010 at 4:25 PM, Sergey Beryozkin <>
> 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?

I guess I'd for cookies then and we can move to a better solution once we
can see browsers starting to adopt HTML5 and its local storage feature in

This actually raises another question. How will our 'browser' get started ?
I actually haven't even thought about it. Perhaps in the back of my mind
I've been assuming it will be indeed our own simple implementation (basic
Swing application with HTML-aware panels) - this could be one option after
all. If we went this route then a user could've started a browser using
"java -jar ...". But I'm not insisting, let just keep this option in mind.

But using an existing browser can be much simpler and may be it is the best
option indeed. So the question is then how a user will go to the initial

At the moment, one way for a user to subscribe to all existing CXF
AtomPullServer endpoints is to go to a CXF /services page and select the
links to AtomPullServer endpoints, the links will be there if a user has
chosen to make them visible, by configuring individual AtomPullServer
endpoints. So I thought that perhaps we could also have a link from the
/services page to an Atom Service document describing all the AtomPullServer
endpoints currently visible/available. Or may be we can have it available at
say /services/logs. Having such a document would let our browser to see an
uptodate view/list of the existing log feeds.

So one reliable way to 'restore' the previous subscriptions after either a
browser or a container hosting the feeds has been restarted is for a user to
copy the links from a /services page or direct a browser to /services/logs,
when it becomes available. It is a primitive option but it will work.

However, it is still not clear how a user will go to the initial browser
page. After talking aloud here I'm just coming to the conclusion that may be
rt/management-web should have another CXF JAXRS endpoint which will act as
the browser bootstrapping/storage point.

So this endpoints is registered at the well known '/services/logs' address
and when a user selects say http://host:8080/services/logs, our initial page
is served by this 'browser' endpoint. A user then subscribes to individual
log feeds and possibly gets authenticated and views the logs. Here, a user
can subscribe as suggested above, by copying the feed links from the
/services page or copying the link to the atom services document. (In the
future, a browser, after getting a link from a user to the /services page,
may be abe to parse the resulting page and offer a choice of feed links to a
user using some drop down list...).

Now, when a browser exits, we can let user (initially) restore the
subscriptions the same way as those subscriptions were made originally, by
copying the links, etc. Perhaps, in the typical application, there would be
just a couple of such links. Or we can try storing the subscriptions by
having a browser posting a final request to the 'backing' endpoint, or may
be just use the cookies if it what the user asks for.

Not sure if we can avoid creating a 'browser' CXF JAXRS endpoint. Seems like
the simplest but viable option.

what do you think ?

thanks, Sergey

> [1]
> --
> Best Regards,
> Tomasz Oponowicz

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message