Greg Hellings wrote:
This thread seems to be of the mind that perhaps the module should always be
zipped and not expanded on disk.
I believe that was Eeli's feeling. My feeling, and it sounds like the
feeling of several others is that the actual representation on the
server's end is less impo
On Fri, May 15, 2009 at 7:18 AM, DM Smith wrote:
>
> On May 15, 2009, at 4:28 AM, Manfred Bergmann wrote:
>
>>
>> Am 15.05.2009 um 05:38 schrieb Greg Hellings:
>>
>>> On Thu, May 14, 2009 at 11:29 PM, Matthew Talbert
>>> wrote:
>
> Does it require a difference (for the C++ front ends) to
Matthew Talbert wrote:
Xiphos can produce GenBook modules as well, or additional personal
commentaries. Of course, we provide a handy function inside Xiphos to
zip up any module :)
... And if this is generally useful for all frontends, why not put it
into the library? Or into a small command
On Fri, May 15, 2009 at 10:15 AM, Peter von Kaehne wrote:
> Eeli Kaikkonen wrote:
>> However, it already requires some
>> nous to create a module and put it to some file system location, so
>> zipping it and creating the (g)zipped file of the .conf files isn't a
>> large step. I wonder if there ex
Eeli Kaikkonen wrote:
> However, it already requires some
> nous to create a module and put it to some file system location, so
> zipping it and creating the (g)zipped file of the .conf files isn't a
> large step. I wonder if there exist such people who can create a sword
> module but can't zip it.
> Short term for SWORD, that is likely to remain an important difference.
> Long term, either a local repo just returns "OK, done, nothing changed"
> when asked to refresh, or you can rethink whether this is really needed...
If local sources were really handled as the others were, then a
refresh w
> Remote repositories have concepts like 'refresh from remote source' (apt-get
> update)
>
> Local repositories usually aren't 'entered' in a list by a user, though I
> suppose they could be if it was useful. Practically there is usually 1
> local source (a CD or USB drive) and the user can Browse
On May 15, 2009, at 4:29 AM, Peter von Kaehne wrote:
Eeli Kaikkonen wrote:
2. We need to support http.
3. We don't need to support the old, standard non-zipped directory
structure with http because it's not needed for backwards
compatibility.
I think Troy's argument is right for module li
On May 15, 2009, at 4:28 AM, Manfred Bergmann wrote:
Am 15.05.2009 um 05:38 schrieb Greg Hellings:
On Thu, May 14, 2009 at 11:29 PM, Matthew Talbert > wrote:
Does it require a difference (for the C++ front ends) to add
support
for FTP InstallMgr methods than it does for them to add a file:
Am 14.05.2009 um 10:59 schrieb Chris Little:
Once you've got 1.6.0 in your hands and working, take a look at the
new WLC module, based on WLC 4.10.
The big new feature *should* be the use of native versification:
Malachi will have 3 chapters, Nehemiah is the last book of the
Bible, the C
Peter von Kaehne wrote:
Eeli Kaikkonen wrote:
2. We need to support http.
3. We don't need to support the old, standard non-zipped directory
structure with http because it's not needed for backwards compatibility.
I think Troy's argument is right for module libraries, created by people
who do
Am 15.05.2009 um 06:58 schrieb Troy A. Griffitts:
To understand the design decisions for InstallMgr, you have to have
a basic understanding of the SWORD API:
Libraries of modules are exposed as SWMgr objects.
An SWMgr object can be easily created from a local path:
SWMgr localLibrary("/path
Eeli Kaikkonen wrote:
> 2. We need to support http.
>
> 3. We don't need to support the old, standard non-zipped directory
> structure with http because it's not needed for backwards compatibility.
I think Troy's argument is right for module libraries, created by people
who do not have much nous
Am 15.05.2009 um 05:38 schrieb Greg Hellings:
On Thu, May 14, 2009 at 11:29 PM, Matthew Talbert > wrote:
Does it require a difference (for the C++ front ends) to add support
for FTP InstallMgr methods than it does for them to add a file://
version? It seems that, if so, this is a problem with
Am 15.05.2009 um 05:11 schrieb Greg Hellings:
Is this a basic idea of how it could/should work? Or do we want it to
work with some internal inclusion of times when cURL isn't available
and we've had to fall back to ftplib? I think you'll fall into
problems there and, for any such system, it w
Troy A. Griffitts wrote:
On top of that, we may add what I've been labeling as CACHING /
OPTIMIZATION mechanisms to make downloading quicker, but these will
require the content providers be more savvy, possibly implement cron
jobs to zip up folders, etc. But these mechanisms will be optiona
Troy A. Griffitts wrote:
> There is a basic and practical difference between a local and a remote
> installation, however abstract you want to get.
>
> Remote repositories have concepts like 'refresh from remote source'
> (apt-get update)
Short term for SWORD, that is likely to remain an importa
Troy A. Griffitts wrote:
> Am I helping explain my reasoning?
Yes, I think you do.
Wrt HTTP repositories - this is a valid need. Our church has cheap
hosting space which uses its ftp server only to upload stuff for the
website. There is no anonymous ftp. Nor is there any way i know of of
making s
18 matches
Mail list logo
