<div dir="ltr">I agree with the below, in that they are basically things that are changeable (fonts) by user preference, or at least entered by the user (CipherKey). But for static reference data, that never changes nor is changeable, I would prefer to download this.<div>
<br></div><div style>Perhaps an addition to the sidecar is to allow a frontend to specify a hook in the installation process. For example, STEP can expose "install a module".</div><div style><br></div><div style>
JSword then takes that, install the module, and then calls any registered post-installation routines. In this case, perhaps it could go to the Tyndale Server to download stuff that is useful for STEP (although I think it would be useful for others too).</div>
<div style><br></div><div style>In other words, a customizable post-process. In particular, it would be nice to re-use the download functionality in JSword to download those sidecars from other servers</div><div style><br>
</div><div style>Would that work?</div><div style>Chris</div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 3 June 2013 14:05, DM Smith <span dir="ltr"><<a href="mailto:dmsmith@crosswire.org" target="_blank">dmsmith@crosswire.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">No it would not be automatic with the download of the module. It would be a separate module file to download. Hopefully, it would be opaque to front-ends. But right now the download process is not quite opaque.<div>
<br></div><div>To have it cached on the server would mean that we'd need to build a server process to cache such sidecar information. Or it would have to be a manual process. There's a bunch more that would need to be done to make it a meaningful process. But something is better than nothing.</div>
<div><br></div><div>The current need is to have the CipherKey stored on the user's local machine but not in the conf. If we add a sharing mechanism, ala SWORD (any respsitory is a module source) or Xiphos (any module can be zipped up for distribution), then the cipher should not be included. The same is true for all per user settings.</div>
<div><br></div><div>In Him,</div><div><span style="white-space:pre-wrap"> </span>DM</div><div><br><div><div class="im"><div>On Jun 3, 2013, at 8:46 AM, Chris Burrell <<a href="mailto:chris@burrell.me.uk" target="_blank">chris@burrell.me.uk</a>> wrote:</div>
<br></div><div><div class="h5"><blockquote type="cite"><div dir="ltr">I like the idea, if as you say, it will be cached on the server. If we can have the sidecar downloaded at the same time, that would be good.<div><br></div>
<div>But I guess if we're going to do that, then I'm not sure I understand why we don't also do this in the .conf file.</div>
<div><br></div><div>But so long as the installation of the module means that sidecar information comes with it, then that solves all of my problems.</div><div><br></div><div>Chris</div><div><br></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On 3 June 2013 13:42, DM Smith <span dir="ltr"><<a href="mailto:dmsmith@crosswire.org" target="_blank">dmsmith@crosswire.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I've been mulling over whether we need to have a sidecar for a module's conf. A sidecar would be just like a module's conf and would be merged into the internal/core representation of the conf. If there's a conflict/duplicate, the sidecar would win.<br>
<br>
Today, we store the CiperKey in the module's conf.<br>
<br>
We also have a mechanism in Bible Desktop to store user preference for Font and some notion of position and size of various windows, so that the user can return to a last known state. I'm pretty certain that per user settings should be a separate consideration. Maybe a second level sidecar for this?<br>
<br>
I think the sidecar would be used by a front-end to store what it needs to know about a module that is not easy to discover.<br>
<br>
Examples,<br>
Introductions: Does a module have introductions. STEP has a use case for this.<br>
Books: Which books are present/missing.<br>
Chapters: Which chapters in a book are missing/present.<br>
...<br>
<br>
We've got a caching mechanism for low powered devices (i.e. AndBible has pre-built indices on the CrossWire Server). Maybe we could do the same for such info.<br>
<br>
Way back when we had an argument for "download size". It was finally added to the conf, but it took forever. Having a sidecar sidesteps such arguments. (We should still have the discussion).<br>
<br>
In Him,<br>
DM Smith<br>
_______________________________________________<br>
jsword-devel mailing list<br>
<a href="mailto:jsword-devel@crosswire.org" target="_blank">jsword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/jsword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/jsword-devel</a><br>
</blockquote></div><br></div>
_______________________________________________<br>jsword-devel mailing list<br><a href="mailto:jsword-devel@crosswire.org" target="_blank">jsword-devel@crosswire.org</a><br><a href="http://www.crosswire.org/mailman/listinfo/jsword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/jsword-devel</a><br>
</blockquote></div></div></div><br></div></div></blockquote></div><br></div>