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 >
