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.
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 <sberyoz...@gmail.com> wrote: > Hi Tomasz > > On Mon, Apr 19, 2010 at 10:13 AM, Tomasz Oponowicz < > tomasz.oponow...@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 <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. >> > > 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
