[jsword-devel] feather request: book downloading and index generating api

[David]

Hi, DM,
If you just want to migrate to SWT, I personally think it does not worth it.
SWT just another set of API, like SWING.  However, if you want to migrate to
NETBEAN RCP or Eclipse RCP, I will applause your effort. (The application
size will be increased by 6-9MB).  For Eclipse RCP, the work is just create
veiws and call jword api.

The work I am doing is based on Eclipse RCP. Jsword is a base part of it.
The plan is to build a p2p system that can enable blog , forum sharing, of
course file sharing(  JXTA.)  next year.  It will be a set of plugins.

Right now, I am rewriting the system to look like exactly what is on web
sword interface. After all, people are familar with web interface.  I ,
however did a websword plugin with tomcat embedded(yes, a server on user's
desktop).  It is cool. However, due to other considerations, I put it on
hold.

Since you are interest, I will put the source code to Google code next
week.  I tried sourceforge, still does not get approved.  An alternative is
I put the code temporily into jwsord SVN, so you can look at it. Again, next
week. :)



On 12/8/06, DM Smith <dmsmith555 at yahoo.com> wrote:
>
> We hope to migrate the UI to SWT. So I am very interested in your RCP
> work. Is there a place where I can see what you have done. If possible,
> I'd like to minimize your pain of re-integrating the JSword as it changes.
>
> David wrote:
> > Eclipse RCP platform has its own threading api. Use can choose the job
> > run on backgroud or foreground. I maybe need to double check why the
> > process failed. (I believe it is because of threading)
> > For book installation, I added two mirror methods to do downloading
> > and copying.  It works fine. The only issue is the api and package
> > keep changing and I have to compare every time there is a new release
> > and merge the code.
> >
> > For indexing, I have not made it to work correctly.  I will study the
> > code next week. The basic idea is kick off a background job and call
> > jsword api to generate index. No thread for indexing itself is needed.
> >
> > For Web sword, the book installation is on server side. Never mind.
> > It will not be used for end users. I put it on hold because I have
> > several othe plugins need to be done soon.
> >
> > Zhaojun
> >
> > On 12/8/06, *DM Smith* <dmsmith555 at yahoo.com
> > <mailto:dmsmith555 at yahoo.com>> wrote:
> >
> >     David wrote:
> >     > Hi, DM and fellow developers,
> >     >
> >     > I am developing web sword(90% done, pure j2ee implementation, will
> >     > help web hosting) and sword on eclipse RCP.  Issues were raised up
> >     > when I try to integrate install book and generate indices. The
> code
> >     > now has job api build in and also has the reporter to
> >     communicate with
> >     > user UI.
> >     >
> >     > In order to accelerate the acceptance of jword library,  the api
> for
> >     > downloading books and api for index processing need to seperated
> >     from
> >     > Job api.
> >     I'm not sure I understand the problem.
> >
> >     The index api (org.crosswire.jsword.index) is independent of the
> >     Job and
> >     Reporter apis. The Lucene implementation is not.
> >     Likewise for the install api ( org.crosswire.jsword.index) and the
> >     sword
> >     implementation.
> >
> >     Both the Job api and the Reporter api are listener based. If there
> >     is no
> >     listener for Job events or Reporter events, then those are not
> heard.
> >     Any listener of your choosing can be provided or not provided. It
> >     is up
> >     to you.
> >
> >     The purpose of the Job and Reporter apis is to provide asynchronous
> >     communication of a potentially background task thread. For
> >     example, you
> >     will notice in BibleDesktop that you can download and/or index
> >     more than
> >     one Book at a time. Each download and index is on its own thread
> >     and it
> >     communicates back to BibleDesktop asynchronously of its progress
> >     or any
> >     problems that are encountered.
> >
> >     In a web environment asynchronous communication of long-lived
> >     threads on
> >     the server may prove to be a challenge, but it should be possible.
> >
> >
> >     _______________________________________________
> >     jsword-devel mailing list
> >     jsword-devel at crosswire.org <mailto:jsword-devel at crosswire.org>
> >     http://www.crosswire.org/mailman/listinfo/jsword-devel
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > jsword-devel mailing list
> > jsword-devel at crosswire.org
> > http://www.crosswire.org/mailman/listinfo/jsword-devel
> >
>
>
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.crosswire.org/pipermail/jsword-devel/attachments/20061208/fdb7668c/attachment-0001.html