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

DM Smith dmsmith555 at yahoo.com
Sat Dec 9 06:41:29 MST 2006


I'll see about setting up a jsword-rcp Eclipse project and get the  
permissions wide open. We can use this to collaborate.

On Dec 9, 2006, at 1:44 AM, Zhaojun Li wrote:

> My last post before I fall asleep :)
>
> Let us do not worry code efficency or naming standard and such and  
> such. At least we have a start point. We can always refactor and  
> tune the apis later.
>
> Right now, the most import thing is to get started.
>
> God Bless!
>
> On 12/9/06, P. R. B. <dysbiote at yahoo.com> wrote:
> Hi Zhaojun,
>
> I'll work on making the jsword plugin available this weekend. In  
> general, I had two purposes when writing the plugin: to use RCP  
> classes in place of JSword classes whenever I felt it was  
> appropriate (e.g. preferring IProgressMonitor over JSword Job and  
> RCP extension points over properties files), and expose only the  
> essential packages to the clients.
>
> Don't worry about me being burned out. =) Most of that had to do  
> with trying to write the thing myself in a short period of time  
> through long nights, and making the project self-serving / ego- 
> driven rather than God-serving. That's my confession. I think  
> there's a lot we can do with it together if we're patient.
>
> As to your previous e-mail: Having multiple GUIs may be a good  
> idea. One of the strengths of BibleDesktop is its smaller footprint  
> and compatibility. The desktop application I wrote is focused on  
> functionality / usability (e.g. listing the commentaries and  
> dictionaries that reference a highlighted verse) at the cost of  
> depending on the RCP framework and being fairly CPU intensive for  
> some operations. There'd be less concern about applications having  
> overlapping functionality or overlapping target audience if we keep  
> the GUIs in separate niches, yet we'd still be pushing to keep the  
> core flexible and simple.
>
> Be sure to keep all of this in your prayers. If we keep God at the  
> center of this, I believe He'll lead us to something good.
>
> Good night, all.
> -Phillip
>
>
> ----- Original Message ----
> From: Zhaojun Li < lzj369 at gmail.com>
> To: J-Sword Developers Mailing List <jsword-devel at crosswire.org>
> Sent: Friday, December 8, 2006 11:51:59 PM
> Subject: Re: [jsword-devel] feather request: book downloading and  
> index generating api
>
> Philip,
>
> I don't konw OSGi good enough either. However, guys in the street  
> tell me it is cool.
>
> I think a standard ant build to create a plugin jar is good enough  
> for now. With your effort, I think we are in a good position now.   
> Since you are burned out, :) , I can take over your GUI and  
> maintain mine too. After all, it is not very hard for this part.
>
> Since you did the migration already, Could you share your changes?  
> I mean overview, why and how.
>
> On 12/9/06, P. R. B. < dysbiote at yahoo.com> wrote:
> Another thing to consider is to put the JSword and Common code into  
> a basic OSGi bundle / RCP plugin jar and have BibleDesktop run an  
> OSGi framework implementation (something like Apache Felix). The  
> Crosswire jars would stay independent of RCP, yet RCP developers  
> could treat the jars as standard plugins. Some abstraction classes  
> would still need to be made to the JSword/Common code for RCP'rs,  
> to reduce the conflicts that Zhaojun and I ran into.
>
> I don't know enough about OSGi to say what other pros and cons  
> there are.
>
> As for making BibleDesktop a standard GUI RCP: Yes, you'd be  
> dependent on SWT.
>
> Any other thoughts? It seems like we've got some good ideas  
> floating around.
>
> ----- Original Message ----
> From: David < lzj369 at gmail.com>
> To: J-Sword Developers Mailing List <jsword-devel at crosswire.org >
> Sent: Friday, December 8, 2006 10:50:14 PM
> Subject: Re: [jsword-devel] feather request: book downloading and  
> index generating api
>
> The main advantage for RCP that it hides the low level details from  
> business logic. A big plus is cross platform is piece of cake. We  
> can click several times to make it run on almost every platform  
> like linux, windows,mac ,ppc, you name it. It is native code call  
> from java layer, thus very fast.
> The biggest challenge is the size.
>
>  The default size is like 9mb.
>
> Another advantage is update: RCP has built-in update site support.  
> It even supports anatomical update! even scheduled update!
>
> Plus, it is de facto standard for JAVA IDE now. and IBM is behind it.
>
> as far as BD gui, it is hard to tell because it depends. My  
> experince tells me that it is very easy to mimic the current gui  
> with two views. Installation view can be done , I have it done  
> already, it can be shared. The other part is main gui: it should be  
> a Form base with a broswer GUI or two.
> The preference can be done by using RCP built-in preference api. It  
> is very simple. I can share my code by providing a simple tutorial.
>
> BTW, all code are open sourced.
>
> I have different opinion about the classloader. Yes, jsword's class  
> loader creates an issue for RCP. However, I do not think removing  
> it is a good idea. We can add addition classes or addition methods  
> to jword (Jsword, and common) to solve this issue. Maybe is is time  
> to create an standard eclipse plugin. I can offer help on this one.
> Next week I will release all the code to a place so everyone can  
> share and modify.  The GUI like a clone of WEBSOWRD on  crosswire.com
>
> In Christ,
>
> Zhaojun
> On 12/8/06, DM Smith <dmsmith555 at yahoo.com> wrote:
> Zhaojun and Phillip,
>
> I think there is enough interest that it would be good to meld all  
> this into one effort.
>
> Phillip, I'm sorry you have burned out. Perhaps if we had  
> collaborated we could have shared the load.
>
> Please help me understand the advantages and disadvantages of going  
> to RCP for JSword and Common. And what impact it would have on the  
> BibleDesktop GUI. How portable is RCP? Will it run on all platforms  
> that Java runs? Or is it limited like SWT?
>
> I've done a bunch of reading, but have been focusing on adding  
> behavior to what we have. So I have not really experimented too much.
>
> In Him
>  	DM
>
> On Dec 8, 2006, at 9:17 PM, P. R. B. wrote:
>
>> Hi gang,
>>
>> I ran into the same problem with RCP. I ultimately turned the core  
>> JSword libraries (common and jsword -- the parts I was after) into  
>> an RCP plug-in that could accommodate the RCP Job class and use  
>> plug-ins to extend the installer, filter, and driver (RCP needs to  
>> manage class loaders itself, so the class utilities and property  
>> files were removed). The key to changing the job code, for me, was  
>> to replace JSword-Job calls  with IProgressMonitor calls, and  
>> making all calls run in the caller's thread. The IProgressMonitor  
>> interface serves essentially the same purpose and the JSword Job  
>> class, so the change was fairly straight-forward.
>>
>> I have an example of the changes that I made at the bottom of this  
>> e-mail.
>>
>> Off-topic: I hit project burn-out with this endeavor a few weeks  
>> back and the fate of the code is undecided (I take project burn- 
>> out pretty hard). The JSword plug-in is functional and the RCP  
>> application is 100% working. If anyone wants to play with it or is  
>> interested in helping me resurrect the thing back to life, please  
>> let me know.
>>
>> Thanks,
>> -Phillip
>>
>> -- 
>>
>> Example changes to convert JSword Job code to use IProgressMonitor  
>> (for non-RCP'rs, IProgressMonitor and IStatus are part of the  
>> Eclipse/RCP core API):
>>
>> Installer interface:
>>     IStatus install(IProgressMonitor monitor, Book book);
>>
>> HttpSwordInstaller class:
>>     public IStatus install(IProgressMonitor monitor, Book book){
>>         // Is the book already installed? Then nothing to do.
>>         if (Books.installed().getBook(book.getName()) != null)
>>         {
>>             monitor.beginTask(Msg.INSTALLING.toString(book.getName 
>> ()), 1);
>>             monitor.worked(1);
>>             monitor.done();
>>             return Status.OK_STATUS;
>>         }
>>
>>         final SwordBookMetaData sbmd = (SwordBookMetaData)  
>> book.getBookMetaData();
>>         try
>>         {
>>             // the task has as many steps to perform as there are  
>> parts to the download
>>             monitor.beginTask(Msg.INSTALLING.toString(book.getName 
>> ()), (getSize(book) / 4096) + 1);
>>             monitor.subTask(Msg.JOB_INIT.toString());
>>
>>             URL temp = NetUtil.getTemporaryURL("swd",  
>> ZIP_SUFFIX); //$NON-NLS-1$
>>
>>             // download the book. Each chunk downloaded  
>> contributes to the monitor's work.
>>             download(monitor, directory + '/' + PACKAGE_DIR,  
>> sbmd.getInitials() + ZIP_SUFFIX, temp);
>>
>>             // Once the unzipping is started, we need to continue
>>             File dldir = SwordBookPath.getDownloadDir();
>>             if (!monitor.isCanceled())
>>             {
>>                 monitor.subTask (Msg.JOB_CONFIG.toString());
>>                 IOUtil.unpackZip(NetUtil.getAsFile(temp), dldir);
>>                 SwordBookDriver.registerNewBook(sbmd, dldir);
>>             }
>>
>>         }
>>         catch (Exception ex)
>>         {
>>             Reporter.informUser(this, ex);
>>             return new Status(IStatus.ERROR,  
>> JswordActivator.PLUGIN_ID, 0, Msg.UNKNOWN_ERROR.toString(), ex);
>>         }
>>         finally
>>         {
>>             monitor.done();
>>         }
>>
>>         return Status.OK_STATUS;
>>
>>
>> ----- Original Message ----
>> From: David < lzj369 at gmail.com>
>> To: J-Sword Developers Mailing List < jsword-devel at crosswire.org>
>> Sent: Friday, December 8, 2006 10:26:01 AM
>> Subject: Re: [jsword-devel] feather request: book downloading and  
>> index generating api
>>
>> 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
>>
>> _______________________________________________
>> jsword-devel mailing list
>> jsword-devel at crosswire.org
>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>>
>>
>> Check out the all-new Yahoo! Mail beta - Fire up a more powerful  
>> email and get things done faster.
>> _______________________________________________
>> 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
>
>
>
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel
>
>
> Access over 1 million songs - Yahoo! Music Unlimited.
>
> _______________________________________________
> 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
>
>
> Any questions? Get answers on any topic at Yahoo! Answers. Try it now.
>
> _______________________________________________
> 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/20061209/7bf48967/attachment-0001.html 


More information about the jsword-devel mailing list