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