[jsword-devel] jdom removal

Thu Sep 13 03:54:04 MST 2012

Hi Joe,

I agree with you in all aspects.  I might have been tempted to use an
object model for the same reason that Java developers like to use JDom
instead of SAX, DOM,.. but, as you say, would probably had performance and
memory issues.

My design was based on the standard JSword xslt approach which seems to be
the conventional approach for converting one xml format to another (OSIS
xml -> HTML)  if there are no other factors.  However, I used SAX instead
of xslt because it can provide a similar xml transformation service to
xslt, performs better, and there was no xslt parser in Android until
Android 2.2 and I didn't consider including an xslt parser library in the
app.

I always believed SAX would be faster but I recently found this comparison
of different XML parsing approaches on
Android<http://steveliles.github.com/comparing_methods_of_xml_parsing_in_android.html>
in
which SAX is shown to be *10 times faster* than other approaches,
specifically on Android devices.  A lot of Android users have slower phones
and one positive remark I often get relates to the performance of And Bible.

Martin

On 12 September 2012 11:52, Joe Walker <joe at eireneh.com> wrote:

>
> So, I wonder had a simple object model been available at the time, which
> would have been easier:
> 1. Create a SAX stream converter to change from OSIS/SAX to HTML/SAX
> 2. Create an object model converter to change from a simple lightweight
> OSIS model to an HTML DOM [1]
>
> My guess is that 2 would be easier to write and maintain, but that 1 would
> win in using less memory.
> Does this sound reasonable?
> Even if this is true, having done the hard work of 1, we don't have a
> strong case for 2 to help And Bible.
>
> Joe.
>
> [1] I'm not even sure that you can manipulate an HTML DOM in Java in
> Android, but I'm sure there must be some method of passing data to a
> WebView and then manipulating it.
>
> On 10 Sep 2012, at 12:22, Martin Denham <mjdenham at gmail.com> wrote:
>
> Hi Joe,
>
> And Bible does use html.  The main ui control which displays module text
> is a WebView which is essentially a cut-down version of Chrome.  So 2. (a
> lightweight object model) might not be required.
>
> And Bible had performance and memory problems at the start so I tried to:
>
>    1. replace the DOM with a verse-by-verse InputStream/Source to relieve
>    the app of multiple instances of a whole page being created in different
>    formats - to reduce memory use
>    2. use SAX instead of xslt, moving any required xml manipulation code
>    here from DOM handlers - to improve speed
>
> The Streaming in 1. was only partially successful as I could not stream
> the whole process and I only got as far as handling ztext osis modules..
>  The SAX 2. seemed to work pretty well.  The OSIS2HtmlSaxHandler still
> isn't as mature as the xslt I have seen but apart from being faster allows
> me to stay working in Java.
> The above and other small performance fixes allowed And Bible to be usable
> on my old G1.
>
> I could expand what I did although I haven't made any major changes to
> that code for a couple of years.  However, my approach was bottom-up and it
> could benefit from a top-down design based approach by somebody more
> familiar with JSword.
>
> Best regards
> Martin
>
> On 9 September 2012 08:50, Joe Walker <joe at eireneh.com> wrote:
>
>>
>> I've not looked at the AndBible source, but I was under the impression
>> that you were not using HTML as a view layer. If it's true that no-one uses
>> anything but HTML as a view layer then there isn't much call for 2.
>>
>> My logic behind 2 was - If your display is very simple, then the
>> rendering process goes - Read from disk, extract text from markup,
>> word-wrap and apply other trivial bits of formatting, draw to screen.
>>
>> Compare the process with SAX/OSIS->HTML: Read from disk, parse to create
>> event stream, inside XSTL engine, create internal DOM, apply transform from
>> XSTL stylesheet to create another external DOM, pass to HTML engine which
>> constructs render tree from second DOM and reads CSS stylesheet to create a
>> CSS object model, which informs the layout engine how to draw the render
>> tree, draw to screen.
>>
>> I'm emotionally attached to AndBible having contributed to it in some
>> small way, but for me what makes it *much* better than YouVersion is speed.
>> I have a hope of keeping up with a speaker and a chain of references with
>> AndBible and not with YouVersion.
>>
>> Joe.
>>
>>
>> On 8 Sep 2012, at 22:56, Martin Denham <mjdenham at gmail.com> wrote:
>>
>> So 1. would be an optimized version of what now exists which sounds good.
>>
>> But 2. would be a new interface, wouldn't it.  I can't think when it
>> would be used.  Might it not just add complexity.
>>
>> Martin
>>
>> On 5 September 2012 17:41, Joe Walker <joe at eireneh.com> wrote:
>>
>>>
>>> So I think I was arguing that there should be 2 ways to get data out [1]:
>>> 1. OSIS/SAX or (OSIS/StAX)
>>> 2. A lightweight object model
>>>
>>> The advantage of 1 is that it serialises to HTML well, and is lean on
>>> memory. It would be the job of the stream consumer to decide how to use up
>>> memory. The advantage of 2 would be simple fast access without any XML
>>> overhead.
>>> I would imagine that anyone using HTML as a layout system would pipe the
>>> SAX into an XSLT parser, and that anyone doing layout themselves would use
>>> the lightweight object model.
>>>
>>> Joe.
>>>
>>> [1] Actually I'm not sure that I'd got as far as saying how I thought it
>>> should be, more that I'd consistently got it wrong ;-)
>>>
>>>
>>> On 4 Sep 2012, at 15:32, DM Smith <dmsmith at crosswire.org> wrote:
>>>
>>> I don't see it that way. I like the transformation to OSIS as an
>>> intermediate form and then to HTML.
>>>
>>> The only problems I see are the creation of the DOM as objects. If SAX
>>> or StAX could be the interface, then we'd be able to have a lighter process.
>>>
>>> DM
>>>
>>> On Sep 4, 2012, at 5:15 AM, Joe Walker <joe at eireneh.com> wrote:
>>>
>>>
>>> Sigh - I think the document model in JSword is one of the things I most
>>> consistently got wrong. If I remember correctly we started with a standard
>>> API, then JAXB then JDOM.
>>> At the time XML seemed like The Future, however there seems to be more
>>> and more that argues against that vision for JSword:
>>> - Android display works around the JSword API to avoid XML
>>> - Swing uses the horribly broken JEditorPane (?) and its display is
>>> probably the worse for it
>>> - Even using XML for JSword on the web, which should be a sweet spot,
>>> has (had?) problems like getting reliable XSLT in browsers.
>>>
>>> We're going to need some sort of document object model, and given the
>>> existence of OSIS, some sort of ability to serialise it to XML makes some
>>> sense, but perhaps we should consider an object model that is somewhat
>>> closer to the storage model than the display model.
>>>
>>> Joe.
>>>
>>> On 3 Sep 2012, at 22:20, DM Smith <dmsmith at crosswire.org> wrote:
>>>
>>> Looks like from your notes that there is more opportunity than just
>>> replacing JDOM, but rather not building a DOM at all. Maybe you and Douglas
>>> can collaborate?
>>>
>>> In Him,
>>> DM
>>>
>>> On Sep 3, 2012, at 11:25 AM, Martin Denham <mjdenham at gmail.com> wrote:
>>>
>>> It would be good to remove JDOM.  When working on the first versions of
>>> And Bible I had to bypass the JDOM DOM creation to improve performance on
>>> low powered Android devices, but my simple workaround only worked for
>>> simple, well structured OSIS bibles.
>>>
>>> I made a few rough notes<http://code.google.com/p/and-bible/wiki/AmendmentsToJSwordForAndroid> on
>>> it at the time.
>>>
>>> I don't think Android includes a StAX library, but it does include a
>>> similar efficient XML Pull library and it would probably be possible to
>>> include a StAX library with And Bible.  I could do some investigation and
>>> experiments if this approach was seriously under consideration.
>>>
>>> Martin
>>>
>>> On 3 September 2012 15:35, Douglas Campos <qmx at qmx.me> wrote:
>>>
>>>> Howdy!
>>>>
>>>> I was talking with DM wrt removing jdom and using org.w3c.* APIs
>>>> instead (more portable, less deps), and he asked me to post it here :)
>>>>
>>>> Any objections? (I'm assuming I'll fix BD too)
>>>>
>>>> Blessings,
>>>> -- qmx
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>> _______________________________________________
>> 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
>
>
>
> _______________________________________________
> 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/20120913/e2df7517/attachment.html>