Hi, James, Thanks for the comments!
I may not get your points, as my understanding, the documents (in SGML format, or html format, or any formats could be handled by Lucene) are parsed and processed in an off-line manner, which would not run on the server. And then the indexes database is deployed on server (ideally would be opensolaris.org or opensolaris.com), and exports webservices interface for public access. Then the client utility (in java) accesses the webservices interface, to send user's queries and get the result. I think the architecture and the interactions between components are clear. And the one pager is actually for integrating the client utility to opensolaris, while we described the whole picture to present more backgrounds, sorry that we did not make that clearly. Regards, James Carlson ??: > Yong Young Sun writes: > >> The purpose of this project (Command Assistant) is to provide >> an easy access to OpenSolaris documentations manpages and javadoc >> in the context of specific command usage to users. >> > > This doesn't appear to me to be either simple to describe, nor does > the split between client and server or the relationship to the SGML > DTD used by Solaris documentation have an obvious architectural > impact. Are you sure that it's suitable as a fast-track? > > http://sac.sfbay/arc/ARC-FastTrack.html > >
