[jsword-devel] Building on Bible Desktop: BibleBlogs.Net

[DM Smith]

Don Brown wrote:
> On 1/17/06, *DM Smith* <dmsmith555 at yahoo.com 
> <mailto:dmsmith555 at yahoo.com>> wrote:
>
>     You will notice in our code that we code to interfaces. So there
>     probably should be a BlogEngine interface, perhaps others (e.g. Blog,
>     which defines a site and the user's access to it). We then provide
>     concrete implementations. In this case your code would be derived
>     from
>     the interface(s). Finally, we use a plug-in model to define a default
>     implementation and alternate implementations (though sometimes we
>     leave
>     the whole alternates until the point that we have a second
>     implementation) When there are alternate implementations, we would
>     provide options to pick a default from among the implementations.
>
>
> Ok, good, the blog client library - https://blogapps.dev.java.net/ -  
> I'm using already has these interfaces.  I'll look into how you 
> specify implementations.
Take a look at o.c.j.book.install.InstallManager.java (o.c.j = 
org.crosswire.jsword)
This uses InstallManager.properties and InstallFactory.properties to 
define the plugin.

Another example would be:
o.c.j.book.Books.java This uses BookDriver.properties to define the plugin.

Other property files which define plugins are:
o.c.b.display.BookDataDisplay.properties
o.c.b.book.install.SiteEditorFactory.properties
o.c.c.config.Choice.properties
o.c.c.config.swing.ConfigEditor.properties
o.c.c.config.swing.Field.properties
o.c.c.xml.Converter.properties
o.c.j.book.filter.Filter.properties
o.c.j.book.search.IndexManager.properties
o.c.j.book.search.Searcher.properties
o.c.j.book.search.SearchSyntax.properties


>
>     I would suggest a further abstraction JournalEngine would not
>     presuppose
>     a Web Journal and could be a private local journal. Journal would
>     define
>     a location for it and the user's access to it. But we can refactor to
>     this when the need arises.
>
>
> Sure, however I won't be able to work on this for a while, as I'm 
> currently trying to get this site up and running.  Would this be a 
> requirement before the code is imported or could we do a phased approach?
Phased. Refactoring is easy in Eclipse.
>
>     If this is something that should be a user preference as to
>     whether they
>     want to do any blogging, then there should be an option to show or
>     hide
>     it. If it is something that the user would like to do but might
>     want to
>     show/hide it quickly, then an entry in the view menu is
>     appropriate. And
>     by using a SplitPane, we could hide/show it like we do the Passage
>     Sidebar. 
>
>
> Yep, and this is already an option, Alt-J IIRC.  In addition, the 
> journal is shown using a splitpane so it can be hidden or resized as 
> desired.  I do plan to add this option to the config to have it 
> persisted.
Let me know if you need help. I am familiar with the plumbing required 
to get it done.
Once we have this in place we can do another release, 1.1.
>
>     This might sound like a lot, but it is pretty easy to do.
>     >  #2 - Continue as a separate project, forking code as needed.
>     >
>     > Since Bible Desktop is GPL, the code is available on the
>     > BibleBlogs.Net site [2], so option 1 is more about collaboration.
>     > Option 2 obviously necessitates me finding a new name, but it also
>     > might help encourage Bible Desktop's design to better accept plugins
>     > and extensions.
>     I think we should move to an OSGI plugin model. I always favor using
>     industry standards.
>     For 2.0 we will probably use RCP from Eclipse. A Blog would then be a
>     perspective....
>
>
> There are OSGI implementations for Swing, and in fact, there is a 
> great Swing framework discussion going on right now: 
> http://www.clientjava.com/blog/2006/01/14/1137282016137.html
>
> My concern about RCP, and I believe this has already been raised, is 
> how it affects WebStart.
I haven't looked into this, but in the tutorial I have it explains how 
to deliver an RCP application via WebStart. Since we don't update 
"stable" except for new releases, using WebStart is pretty much a one 
time download.
>   I'm a big fan of WebStart as we've used it in production 
> applications with good success.  I want to try to keep the download as 
> small as possible to encourage folks that aren't necessarily computer 
> savvy and may not have a blazing fast connection. 
Yeah, I agree. Part of our target audience has been and I hope that it 
remains: missionaries and schools with hand-me-down computers. These 
machines often have limited memory, ancient versions of the OS and 
intermittent dialup connections. (This describes the missionaries' 
situation my daughter saw when job-shadowing missionaries in Burkina 
Faso, Africa.)

My experiment with RCP has resulted in a much larger download. IIRC, 
about 8-10M.

We also have plans to do more significant things with Greek and Hebrew 
and the code to do that (icu4j.jar) is over 4M.

The question is, "At what point is it too big?"

At this time, the user has to be able to download Sun's JRE. So I 
suppose that we should stay smaller than that;)
> Otherwise, I really like RCP's framework and plugin support and think 
> moving to a flexible platform such as RPC would encourage all kinds of 
> new development.
The initial motivation behind looking at SWT was to provide a better 
rendering (e.g. native browser) and less work-arounds (e.g. SplitFrame). 
In looking at it, it became obvious that we would also use JFace.

The motivation to look at RCP was to use a framework that already 
implements much of what is in our post 1.0 wish list. And it provides a 
perfect framework for what you are trying to do.