Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: pass (athena.apache.org: domain of sberyozkin@gmail.com
 designates 209.85.218.209 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=T8op3pYLWsbQlMD/hv96QeXvlVYfKEpaNM0Nc+8frcwL+6qtkCYzqMYjvzGPPPZjwe
         VZM7XSVm121+k1BqylX4S66d9eGPsDXpEbs4cYtRL9wpDf5Ac+ceqeJ5Fs7Pysds5P4Y
         dOo7r/7D5HzCS1+VHADC9JygTqkRN4M3Pb7wc=
MIME-Version: 1.0
In-Reply-To: <q2v21d47e311004211527w3a4dfdb1h537416e393d3354a@mail.gmail.com>
References: <21d47e311003301540o6d56e135kec5b046654cc9809@mail.gmail.com>
	 <602da591003310515w73d458b2l965d26c498fb1f66@mail.gmail.com>
	 <t2i21d47e311004020218i9c0a3c2fxf2540251e9f5d828@mail.gmail.com>
	 <q2w602da591004020840q3e866bfdr719716217c2e66c6@mail.gmail.com>
	 <x2w21d47e311004031033m4e68797bie3c823de8741e8c9@mail.gmail.com>
	 <o2z602da591004160725y61e4fe39mbf69217c0ec874fa@mail.gmail.com>
	 <q2y21d47e311004190213i84c2cbaerc8c22f4d1a381ffb@mail.gmail.com>
	 <t2n602da591004190801s4884010fra1499ecefb3c41fd@mail.gmail.com>
	 <q2v21d47e311004211527w3a4dfdb1h537416e393d3354a@mail.gmail.com>
Date: Thu, 22 Apr 2010 14:10:25 +0100
Message-ID: <n2t602da591004220610q5049d6dal7b7d09218bcc1a78@mail.gmail.com>
Subject: Re: [GSOC][CXF-2736] Proposal for "Simple and lightweight Atom
	HTML-based browser for CXF logs"
From: Sergey Beryozkin <sberyozkin@gmail.com>
To: dev@cxf.apache.org
Content-Type: multipart/alternative; boundary=001485f45046b771720484d308f7

--001485f45046b771720484d308f7
Content-Type: text/plain; charset=ISO-8859-1

Hi Tomasz

On Wed, Apr 21, 2010 at 11:27 PM, Tomasz Oponowicz <
tomasz.oponowicz@gmail.com> wrote:

> Hi Segey,
>
> I gather all our ideas in one place and create "concept overview"
> document [1]. I think "Centralized structure without logs server"
> concept is what we are looking for. However if there will be enough
> time I can extend implementation to "Centralized structure with logs
> server" concept. Of course some of presented function are not
> implemented. Please let me know what are you thinking about this.
>
>
Indeed, at the moment I'm thinking of us starting from something similar to
"Centralized structure without logs server", it is quite close but not
exactly what I've had in mind.

First, I'd propose that we do not deal with AtomPushBeans at the moment,
just  to make things simpler. The idea behind AtomPushBeans is to push
events immediately to an Atom aware sink/feed and they will likely play
their part in your project too at some later stage, if you'll have time
left, or mat be even after it completes :-).

But at the moment lets start from the assumption that CXF endpoints which
are logging, AtomPullServers which are collecting the log events, and the
"Application1" (as in your diagram) which acts as a browser endpoint are all
collocated in one server. And no AtomPushBeans just yet. Also, IMHO it would
be more precise if the connection between "Application1" and AtomPullServer
was represented by a dotted line directed toward AtomPullServer, meaining
that the browser "Application1" is not really managing or controls
AtomPullServer but kind of depends on them.

Here are so more details which I hope can clarify what I mean.

The relationship between AtomPullServer and CXF endpoints is not one to one.
Users can have one feed matching a single CXF endpoint (logs) or a single
AtomPullServer can be configured such that it collects the log events from
multiple CXF endpoints.
As far as our browser app is concerned, we don't know about the relationship
between AtomPullServer and CXF endpoints.

The browser application/endpoint will get available say at
http://localhost:8080/services/logs and when a users targets this URI he/she
will be presented with an initial page and then a user will be able to
subscribe to individual feeds whose addresses a user will find about from
the http://localhost:8080/services page or through some other channels.

If it is not the first time when a user goes to
http://localhost:8080/services/logs then this user may get presented with
the list of feeds(one or more AtomPullServer endpoint addresses) persisted
in the local storage by "Application1", provided those endpoints 'survived'
the restart. So the only role "Application1" plays is presenting a user with
the initial/starting page, and possibly persisting the subscriptions
somehow, etc.

I hope that going this direction will help you focus better on the actual
browser application. And then once it is all working nicely, we can continue
with introducing AtomPushBeans into the picture and targeting more advanced
deployment scenarious

thanks, Sergey


Before I prepare detailed documentation (with use cases, sequence
> diagram etc.) I must where are we going.
>
> [1] http://wiki.apache.org/general/cxf-logs-browser-concept-overview
>
> On Mon, Apr 19, 2010 at 5:01 PM, Sergey Beryozkin <sberyozkin@gmail.com>
> wrote:
> > Hi Tomasz
> >
> > On Mon, Apr 19, 2010 at 10:13 AM, Tomasz Oponowicz <
> > tomasz.oponowicz@gmail.com> 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 <sberyozkin@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.
> >>
> >
> > Excellent.
> >
> >
> >>
> >> > 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
> > particular.
> >
> > 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
> > page.
> >
> > 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] http://apirocks.com/html5/html5.html#slide7
> >>
> >> --
> >> Best Regards,
> >> Tomasz Oponowicz
> >>
> >
>
>
>
> --
> Pozdrawiam,
> Tomasz Oponowicz
>

--001485f45046b771720484d308f7--