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

[Matthew Talbert]

> 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).

Well, the modules could be those installed via the package manager, or
the system could be setup for write permissions for /usr/share/sword
for a group of users. On Windows, the shared location is by default
writable by all users. Obviously this is a "power-user" feature, but
we aim to be a power-user sort of program.

>> 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.

The point is, in something like a mobile device, the modules may very
well need to be stored on a removable storage card. There's no way to
cover all the locations someone might need to put modules in.

> 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".

Except that even in these apps, you don't expect them to share the
same data. I don't know much about the iphone file system, but I'd be
a little surprised if you were allowed to access data put there by
another app.

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

As I said above, every device could be different. On one device, they
might need to be in one location, on another they might need to be
stored on a storage card, or even have some in both places.

>> 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?

It's no problem. I've specifically set up my module collection the way
it is, and if the new SWORD app can't handle dealing with multiple
locations, then I won't use it!

> 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.

My point is not that you need a large set of locations, but that it
gets increasingly difficult to define these locations in the library
to suit all platforms. I suggest you read the previously mentioned
discussion on this to see the difficulties we face on different
platforms.

> 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?

Now you're taking this way farther than anything I said. I believe
that most of the installmgr stuff works well (I'm talking about the
library, not the installmgr program). There are just a few things that
could use improvement. I would do them myself if I could get someone
to say that they would definitely be included. There are three things
specifically that I would like to see:

1. HTTP support. This is planned.
2. Allow specifying the location of where to install modules. This is
quite simple and I could easily do it, if it would get applied. I've
mentioned this before with no response.
3. Allow installing a zipped module. That is, the library would unzip
it itself and install it somewhere. This would be useful for all of
the frontends I think, and it's best to handle it in SWORD, because it
already has the necessary functionality to do this (very similar to
the untar capability). I've offered before to help with this, or code
something up, but got no response, so I assumed that it wasn't wanted
in the library.

> 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.

That has never been my intention, or the intention of any at Xiphos.
If there are reasons why our app and others duplicate functionality,
it is not caused by not wanting to share back to sword.

Again, this discussion is re-covering some of the same issues already
discussed at length previously.

Matthew