Thanks Karl, this is brilliant!
Karl Kleinpaste wrote:
This brings a couple problems. First, we have the necessity of the
interaction: Does the user allow this to occur? If the user
declines --
for now, or forever -- then we are left with an application that
still
must provide bookmark storage. That means that we must create 2
retrieval
methods for bookmarks, and that complexifies the bookmark subsystem
in the
application.
Would this be required? I would think that every application stores
its
folders of internal settings +/- may provide a import/export/sync
capability. Does this need to be amalgamated functionality? I would
not
think so.
The result is that, regardless of whether network-sync'able
bookmarks ever
get implemented, every application must still provide its own
method for
doing so locally. That will be OS-, language-, toolkit-, and
filesystem-dependent, thus usually not portable. I'm simply not yet
excited about having to expand this in Xiphos, because the value
gained
from doing so likely won't offset the anguish of its development.
But why do I say that? Because sometimes we have warped ideas of
what's
important. Generally speaking, we are often not like our users.
In a related discussion in the Xiphos devel list, it was pointed
out that
we as developers sometimes have an odd perspective about
interoperability,
because we keep multiple applications installed in order to test our
features and our modules, and so we think "everyone" must want
"everything" to work together. On its face...um, yeah, sure, and
while
we're at it, we love baseball, motherhood, and apple pie, too. In
reality, how many Joe Averages are there, who particularly care
whether
bookmarks can be sync'd among Xiphos, BPBible, BibleTime,
PocketSword,
Bible Desktop, and BibleCS? Do you (does anyone) actually do
remotely the
same kind of study in 2 different applications? Do you care
whether your
tightly-managed bookmarks in Xiphos are directly usable in
PocketSword,
which doesn't yet provide bookmark titles, has no hierarchy, and no
multi-
verse support? For facially similar applications (say, Xiphos and
BibleTime, or BPBible and BibleCS, or...pick any pair), does Joe
Average
actually use 2 such applications, so that sync rises to the level of
interest, or in fact does he look over a couple of the available
possibilities, and then come down in favor of using just one?
Can we even claim to know? If so, how?
A prime, on-point example: Since the Dawn Of Net.Time, there has
been code
in GnomeSword/Xiphos to import BibleTime bookmarks. But the code
to do so
was so unsupported that it simply stopped working well over a year
ago,
when BT left behind its KDE specificity.
Part of the reason is probably general direction of user mobility.
People move Windows->Apple or Windows-> Linux, but after a bit of
messing around, few move Gnome->KDE or vice versa.
Xiphos uses the exact same bookmark storage format as BT.
Is it not also the same format as BibleCS? I think so.
I didn't know that until this time. I didn't know because I had
never had
cause to want BT bookmarks in the first place, because Xiphos is my
application of choice, and I do my study in Xiphos, where my
bookmarks are
extensive, featureful, titled, commented. Apparently, Terry simply
inhaled BT's format whole when he first implemented them for
GnomeSword.
_In practice_ no one cares about that beneficial compatibility,
even when
compatibility comes literally for free.
See above. KDE to Gnome (or back) is not a common move in established
users. Last time I used KDE is 8 years ago.
The practical use case for bookmark sync is undoubtedly desktop -vs-
handheld device, and not for different applications that run in the
same
(physical) environment, that is, desktops. And so where we would be
concerned with sync is between, say, Xiphos and PocketSword...whose
respective metaphors for bookmarks are virtually unrelated. What
will
"sync bookmarks from Xiphos to PocketSword" mean, when my titles, my
hierarchy, and my multi-verse references will simply vanish during
the
operation? Would I ever want to sync back the other way? No, never,
because too much information would be lost.
I would think that this is the main place where syncing has a role to
play. And the order of the day is clearly for mobile application
developers to become equally featureful as desktop frontends.
Now please let me generalize and extrapolate: This in turn makes me
wonder
about baseline capability, and what "should" be part of any Sword
application. Certainly there are obvious qualifiers on which we
would
agree about the bottommost bare minimums: Show selected Bible text,
generally on a per-chapter basis; provide for module installation;
provide
search somehow; provide commentaries along with or alongside Bible
text;
support UTF-8 to get correct display. We could create a list of
those
kinds of real bare minimums. (We wouldn't /entirely/ agree on the
list,
of course. But we could probably come close.)
How far beyond these bare minimums should we expect any (all) apps
to go?
We had some time ago a debate of what we would consider a "fully
featured frontend" - and large part of this was what was considered
necessary functionality.
In essence it meant that every module could be displayed fully in all
its features and then some. The canon and versification problematic
has
of course thrown a major spanner into the works, making at this moment
exactly none of the frontends truly "fully featured". But that aside,
the debate took place about a year and a half or so ago around my
revamp
of the website and discussions which applications may
I'm asking because, when I think about some of the capability that
we've
brought to Xiphos in the last couple years, I realize that a lot of
it has
no analogue or counterpart in any other Sword application.
Again, the feature comparison page on the wiki was meant to create
some
impetus towards standardisation and mutual convergence. I think it
has.
One of the really fascinating outcomes (for me at least) was how
during
compiling the comparison lists slowly a picture emerged of
applications
developing in parallel and ignorance of each other, calling
essentially
the same feature different names
Along comes Jane Random, who desperately wants Critical Feature XYZ
in her
Bible study application. She hears about The Sword Project, finds an
application, tries it out, and sees that XYZ isn't there. And so she
concludes erroneously that The Sword Project isn't worth her time,
and
worst of all, she tells her friends about her search for XYZ and
how The
Sword Project didn't measure up.
I think part of the answer would be to move the comparison page out of
teh wiki into the general website and link + refer to it from various
frontends. At the moment it is meant mostly for developers.
And to think that we have PR problems on our best days...
As to those Critical Features:
beyond complete module support this is for me: user content, image
support, rtol, syncable bookmarking + commenting (sometimes called
tagging), text comparison (see jsword), decent parallel display,
integration of commentary in parallel views (see jsword), zip install,
Peter
_______________________________________________
sword-devel mailing list: [email protected]
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
