[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