<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">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 class="Apple-tab-span" style="white-space:pre">        </span>DM</div><div><br><div><div>On Jun 3, 2013, at 8:46 AM, Chris Burrell &lt;<a href="mailto:chris@burrell.me.uk">chris@burrell.me.uk</a>&gt; wrote:</div><br class="Apple-interchange-newline"><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 style="">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 style=""><br></div><div style="">Chris</div><div style=""><br></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On 3 June 2013 13:42, DM Smith <span dir="ltr">&lt;<a href="mailto:dmsmith@crosswire.org" target="_blank">dmsmith@crosswire.org</a>&gt;</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>
&nbsp; &nbsp; &nbsp; &nbsp; DM Smith<br>
_______________________________________________<br>
jsword-devel mailing list<br>
<a href="mailto:jsword-devel@crosswire.org">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">jsword-devel@crosswire.org</a><br>http://www.crosswire.org/mailman/listinfo/jsword-devel<br></blockquote></div><br></div></body></html>