[jsword-devel] jsword-devel Digest, Vol 47, Issue 11

Joe Walker joe at getahead.org
Sun Apr 20 23:30:57 MST 2008


On Sun, Apr 20, 2008 at 9:54 PM, DM Smith <dmsmith555 at yahoo.com> wrote:

>
> On Apr 20, 2008, at 8:01 AM, Yiguang Hu wrote:
>
> > DM,
> > Yes. It makes perfect sense to refactor the
> > getOSISString method with one more parameter like
> > startCount instead of making another one.
> >
> > I think it is useful to make "total" available for
> > client. So that user may know the significance of the
> > key word from the numerical statistics.
>
> I added both. I did not give them much of a test. But it compiles and
> it looks like it should work :)
>
> >
> > Regarding paging, looks like we do need some way such
> > as cache to avoiding repeating the process of
> > searching/count total etc for the same
> > key/locale/book, when we start to take into account of
> > performance.
>
> I'm not a terribly familiar with servlets, nor with DWR. I know we can
> cache on the client side, which will minimize trips to the server.
> These trips are the most costly. I don't think that we can have state
> in DwrBridge, or at least I am not sure of whether it persists and if
> so, then whether or how it is shared.
>
> The key is relatively lightweight. Each book translates the string
> reference into a key by parsing it. What it references does not have
> to actually exist in the book. Doing operations on a key can be
> expensive, such as getting the number of verses in a reference.
> Caching "total" on the client makes lots of sense.


If DwrBridge was an interface then you could have 2 implementations, one a
proxy that included a cache, and the other that did the lookup directly.

Joe.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.crosswire.org/pipermail/jsword-devel/attachments/20080421/d7476d75/attachment.html 


More information about the jsword-devel mailing list