On Thu, 2015-09-03 at 03:55 -0700, David Haslam wrote: > cf. Long module names such as SpaRV2009ebib could be a problem for > some mobile apps with small screens, unless perhaps the front-end > makes better use of Abbreviation.
The eBible repo represents such a big amount of new modules that most frontends will need to give thought to some changes. Using Abbreviation is a beneficial change and will be encouraged (without being forced) by my proposal. > > e.g. In PocketSword on my iPhone 5, one of my own modules I installed > is > named FreMartin1707. > It's OK for selecting, but gets shown as "FreMa.." while being read. Abbreviation would solve that or at least produce "Marti.." As you are unlikely to have two Marti... open at any time (you said selection works), the fact that there are two modules (are there?) called FreMartin and FreMartinebib is not going to cause much harm to you or anyone else - less than if they started to mess with each other indeces or datapaths. > If adding namespace to module names was to go forward, we'd still > need to > ensure that users who have already installed some eBible modules > (before > such a change) are adequately catered for. No. the eBible repository is currently nowhere advertised. People who use it, know they are testing things and need to live with breakage. What we need is to be up and running in a fashion which will not break _once_ the repo is part of the automatic repolist refresher. At that moment we will need to consider it "live" and not mess about with it anymore. > So then, would you require that the conf file for SpaRV2009ebib > should > include Obsoletes=SpaRV2009 ? No. See above. Or, yes, but not as part of the namespace solution, but as part of a secondary de-duplication effort where we agree between us who is going to run with which module. If Kahunapule is going to take the SpaRV2009 forward + we drop ours then, yes, he can obsolete ours, but the beauty of having the namespace will mean, that nothing will break even prior to us having addressed the duplications. At the moment things do break because there is too much to address at the same time. Using my proposal would - without code changes allow all of us a breather and the repo to go online. A different solution would be to add Repository info to the installmgr and let it handle different repos in a non-conflicting fashion - but this would mean significant work and little likelihood to filter through anytime soon to the frontends. It would solve nothing for users of old frontends. FWIW, we have not even started to take down modules in CrossWire Wycliffe - and that is all our problem, not Kahunapule's. I am dreading it. If you feel brave, please have a start to take note which one should be taken down (some are not in Kahunapule's) > But this takes us back to the collisions problem, as it could > obsolete a CrossWire module rather than the earlier eBible module. Indeed, and hence my proposal to decouple things. Part of the proposal is of course my firm conviction that ModuleName is and should be seen as an _internal_ ModuleID and not really as a human readable name - at least that should be our general direction. Peter _______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
