[jsword-devel] feather request: book downloading and index generating api
DM Smith
dmsmith555 at yahoo.com
Sun Dec 10 18:27:46 MST 2006
The permissions on "incubator" are set up.
On Dec 10, 2006, at 3:10 PM, DM Smith wrote:
> Philip, Zhaojun, Gabriel and anyone else who wants to participate,
>
> I have set up a new area under svn called incubator. When its
> configured, it will be world writeable. The location is:
>
> www.crosswire.org/svn/jsword/trunk/incubator.
>
> The basic idea is that we set up Eclipse projects under it.
>
> In Him,
> DM
>
>
> On Dec 10, 2006, at 2:26 PM, Zhaojun Li wrote:
>
>> Philip,
>>
>> My guess is that your code still under the same license as the
>> standard jsword jar.
>>
>>
>>
>> On 12/10/06, Zhaojun Li < lzj369 at gmail.com> wrote:
>> Thanks Philip.
>>
>> I will look at your code soon. Let us us find a better way to
>> keep it sycronized with standard jsword jar and common.jar without
>> affecting the normal BD release.
>>
>>
>> On 12/10/06, P. R. B. <dysbiote at yahoo.com> wrote:
>> My JSword plugin code is available in the zip file linked below,
>> in " org.crosswire.jsword_src.jar". I have not retested the plugin
>> since changing it from an Eclipse 3.2 project to an Eclipse 3.1
>> project. I believe any runtime problems caused by this conversion
>> will show up right away and be fairly easy to correct, but it may
>> be worth mentioning anything you hit, for future reference. As a
>> reminder, I have not tested the search extensions or related code.
>>
>> The zip also contains plugin versions of the jars that JSword uses.
>>
>> http://paristano.org/public/jsword_plugins.zip
>>
>> Here's a link to a summary of changes that I made. I didn't list
>> the files that I deleted. You can determine that by
>> comparing the available files in the plugin with those in the
>> JSword and Common 1.0.4 jars.
>>
>> http://paristano.org/public/jsword_changes.txt
>>
>> -Phillip
>>
>> ----- Original Message ----
>> From: P. R. B. < dysbiote at yahoo.com>
>> To: J-Sword Developers Mailing List < jsword-devel at crosswire.org>
>> Sent: Saturday, December 9, 2006 12:34:05 AM
>> Subject: Re: [jsword-devel] feather request: book downloading and
>> index generating api
>>
>> 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
>>
>>
>> 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
>
> _______________________________________________
> 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/20061210/8b74b664/attachment-0001.html
More information about the jsword-devel
mailing list