[sword-devel] More installmgr woes... (need for export SWORD_PATH=~/.sword )

Jonathan Marsden jmarsden at fastmail.fm
Thu Sep 3 15:14:42 MST 2009


Matthew Talbert wrote:

>> So Xiphos now prompts for root privs when needed, so it can write
>> shared modules to /usr/share/sword/ ? Nice, I'll have to try it
>> out!

> No, it only tests to see if the user has permissions to install 
> there. If they do, then it is offered as an option. If not, it is not
> selectable for an install location. It would be nice to integrate 
> PolicyKit support to elevate privileges, but that hasn't been done.

OK.  Without that, it's not clear to me how usable a central shared 
location really is -- either you have to run your big GUI app as root to 
install modules  to it (awkward, and potentially dangerous), or you make 
the shared location writeable by everyone (and risk accidental 
deletions), or you expect users to know enough to make the central 
location writeable by e.g. all users in group swordadmin but readable by 
all users, or something... (more than many users will know how to do).

Sounds like a spec for the whole "central shared module location" thing 
needs to be written, and then any needed SWORD API changes defined, and 
then code written to implement that definition :)

> SWORD is at use on several platforms where interoperability isn't a
> concern.

Yet.  App developers should not assume they will never have any 
competition, except perhaps on a totally closed platform.

> Besides that, most users aren't even aware that there is more
> than one application available. Obviously the situation is different
> with the people on this list, but the average user doesn't need 10
> different programs reading the same modules.

The average user might well try out a few programs, before settling on 
the one he prefers!  I'd think that is a very common situation on any 
"general purpose PC" platform, and it *could* easily become a common 
case on embedded devices in future.  Look at how many different 99cent 
iPhone apps there are in the app store, that do the exact same thing... 
users seem to like choice.  Even on those small little devices where you 
are saying "interoperability isn't a concern".

>> Libraries are about abstracting away unnecessary details, so when 
>> they can do so, IMO they should do so. To keep things somewhat
>> sane, and avoid accidents, the library could only permit installing
>> modules to SWORD data locations that it knows already exist and are
>> writeable, or some similar small set of locations. Writing out 
>> SWORD modules to any random path at all is not really what SWORD
>> (and SWORD apps) should be doing, IMO.

> Again, there are many cases where that isn't true, such as a
> handheld/mobile device.

You want people writing SWORD modules to random locations on a 
handheld/mobile?  Why?  Isn't a small set of locations sufficient?

Either a device is intended for a single user, in which case I suspect 
99% of end users will be fine with just one module data area, or it is a 
new device I that have not yet seen (multi-user smartphones with 
per-user profiles, maybe ... not sure how popular it would be to have to 
log in to your phone in order to use it)?  In either case I don't see 
the need for writing modules to random data locations.

> It really isn't true for desktop apps either.
> I'd like to be able to install modules in several different locations,
> for different purposes and have Xiphos manage them all. I don't really
> care whether all the other apps can find the modules or not.

I think that's short sighted; what if someone creates the mythical 
alphaomega SWORD application that is just so much better than any 
current SWORD app you want to switch to it,or at least try it out and 
see what features from it you might want to add to xiphos? :)  What if 
you decide you'd like to try a new web based app for remote access to 
your large and growing module collection, for when you are away from 
your desktop machine?

Besides, nothing I wrote above prevents any of this... a "small set of 
locations" does not mean "exactly one or two".  So in what way is what I 
wrote above (in the paragraph starting with 'Libraries are') "not true"? 
  I don't see any obvious falsehood there.

If you mean something closer to "desktop apps are so special that they 
don't *need* to use libraries like SWORD at all", well, OK, you *could* 
re-implement all the code, if you so chose.  But why waste effort?  And 
the same reasoning applies to the details of SWORD module management; 
why duplicate effort when all or most SWORD apps need some way or other 
to manage modules, and most will have similar requirements in that area?

In an open source world, it is in principle (IMO) somewhat selfish to 
put code into a single app that really should be in a library for others 
to re-use.  OK as a demo, or a short term hack because your patch was 
rejected, maybe, but in principle selfish as a long term approach.

Jonathan



More information about the sword-devel mailing list