the objects
directly, rather going through SWMgr?
Best regards,
Tobias
From: Troy A. Griffitts
Sent: Montag, 30. September 2019 16:29
To: SWORD Developers' Collaboration Forum
Subject: Re: [sword-devel] Determining the repository a SWModule belongs to
Hi Tobias,
Yes, thank you for all this. We c
module uplpad
>
> Sent from my mobile. Please forgive shortness, typos and weird autocorrects.
>
> Original Message --------
> Subject: Re: [sword-devel] Determining the repository a SWModule belongs to
> From: "Troy A. Griffitts"
> To: SWORD Developers' Collab
Less onerous , but of course also less accurate, we could introduce a conf entry which could be automatically applied during module uplpadSent from my mobile. Please forgive shortness, typos and weird autocorrects. Original Message Subject: Re: [sword-devel] Determining the reposito
Hi Tobias,
Yes, thank you for all this. We certainly could optimize SWMgr c-tor for large
repos. My guess is that the creation of every SWModule for large repos is
taking the time. Many impls of SWModule check their data files on c-tor. SWMgr
also adds all the filters to each SWModule. All of th
Hi,
in my Sword backend (node-sword-interface) I've now implemented a new
method isModuleAvailableInRepo:
bool isModuleAvailableInRepo(std::string moduleName, std::string
repoName="all");
This method avoids the creation of a SWMgr instance (which is slow for
large repos), but just quick
To correct what I wrote earlier ...
It seems to be the construction of SWMgr that takes some time, in my
case InstallSource::getMgr().
The actual iteration over the ModMap is fast.
Best regards,
Tobias
Quoting cont...@tklein.info:
Hi,
For now I'm thinking to store this information (Reposit
Hi,
For now I'm thinking to store this information (Repository of a
module) in my own application-level persistence layer.
However, I'm still wondering about the performance of
InstallMgr::getModuleStatus.
It's not a big issue on current desktop PCs with fast SSDs. On my
Windows tablet, t
Hi Troy!
I guess InstallMgr could add a line into the .conf when installing:
InstalledFrom, but that could be a side load, a local repo, another
SWORD application install on a local lan, or one of our remote
sources which might not still host the module.
That would be helpful!
I have 2 u
Hi Tobias. There is some feature in InstallMgr which returns the status of a
module as: not installed, installed but an update is available, installed and
up to date. I know this isn't what you want, but was as far as we wanted to go
with defining module info. I guess InstallMgr could add a line
Ok. In this case (if there are potentially multiple source repo's for
one given module) could a list be returned?
This is quite common for 1:n relationships in databases as well ...
Best regards,
Tobias
Quoting Greg Hellings :
Currently the engine does not intentionally preserve any informat
Currently the engine does not intentionally preserve any information about
where a module comes from. This is why, for a single installer, it cannot
handle having parallel installs of the same module from different sources
(e.g. you can't have both CrossWire KJV and your own homegrown KJV in
parall
11 matches
Mail list logo
