[jsword-devel] Building on Bible Desktop: BibleBlogs.Net
Don Brown
donald.brown at gmail.com
Tue Jan 17 11:33:01 MST 2006
On 1/17/06, DM Smith <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.
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?
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.
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'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. 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.
Don
>
> > Look forward to your feedback and ideas.
> >
> > Don
> >
> > [1] http://www.bibleblogs.net
> > [2] http://www.bibleblogs.net/study
> > [3] http://www.rollerweblogger.org/page/project
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > 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/20060117/911df183/attachment.html
More information about the jsword-devel
mailing list