Am 06.04.2009 um 22:45 schrieb Mike Hart:
On this subject, why are ALL modules (especially beta mods)
compressed? Once upon a time, compression made the world of POTS
(telephone) based file transfer possible.. turning a 2 hour 5 meg
download into a 20 minute download made sense. Today with the
exception of very low end mobile devices, the need for compression
is zero, and the compression used by Sword is rather CPU intensive.
CPU speeds are driving what you can do with a given computer far
more often than disk space. It would make more sense to optimize the
compression for speed rather than maximum compression in cases where
it is required, and to eliminate it altogether where possible.
For final modules, it does make some sense to compress as a
discouragement to make changes to other's work. On beta modules
however, the ability to 'view the source' to troubleshoot is in the
hands of the few. Considering the number of works in beta (and the
trend is up), being able to do more end user troubleshooting is a
good idea.
I'm saying this in the hopes that an 'import' menu option outputs a
rawtext module, not a zipped file. Also, the companion 'compress'
option as a separate menu item should be accompanied by an
'uncompress.' (with the ability to lock out 'unmodifiable' or non-
beta modules.)
CPU speeds are not really the issue nowadays. It is more the size of
caches, bus, RAM and hard drive speeds.
And I still would encourage to compress data before I send it via
email instead of just sending it uncompressed. Not doing this costs
bandwidth. And all this costs money.
Depending on the source data compression can shrink by factor 2 or 3.
So having 5 instead of 10 mega bytes matters in my opinion.
Manfred
--- On Mon, 4/6/09, Greg Hellings <greg.helli...@gmail.com> wrote:
From: Greg Hellings <greg.helli...@gmail.com>
Subject: [sword-devel] Making Import Easier
To: "SWORD Developers' Collaboration Forum" <sword-devel@crosswire.org
>
Date: Monday, April 6, 2009, 4:19 PM
DM and others involved in the import process --
I was just chatting with Matthew Talbert about the process
of making
module import a much easier task than it is now.
Currently, most of
us are familiar with the process we go through when a new
person tries
to make a module. They often fall into one of a few
categories: they
can't find the utilities because they're not
packaged in their
distro's libsword package, they can't use a command
line comfortable,
they have trouble finding the Windows build of the
binaries, etc.
Obviously it's possible for the front-ends to have the
ability to
create new modules and module content -- they do it with
the Personal
commentary, and I believe that Xiphos even allows an
arbitrary number
of personal commentaries to be created. Wouldn't it be
nice if it was
easy for a module to be created programmatically from a GUI
interface?
Why shouldn't a front-end have the ability to be
pointed to a file on
the user's hard drive (or even remotely to a web-based
resource or any
other number of resources) and have them press a button and
voila!
their module appears (Handling the config file wouldn't
be terribly
more difficult than any other form-based fill-in. The
frontend could
even have predefined values if the developers wanted, etc)
in their
SWORD directories wherever they specify/have write
permissions.
Implementing this should come for almost free with a minor
change set
to the utilities/ directory. Currently, AFAIK, most of the
import
utilities are written in a single .cpp file per utility,
which
includes a main() function. If those utilities were
refactored so
that the option handling and file reading was in one file
and the
actual text processing and module writing were in a second
file, that
would allow those second files to be included directly into
the
library and be linked against by any front end. The front
end would
then be able to read the file from whatever source it wants
(local,
web, ftp, gopher, ocr, whatever) and feed it into the same
functions
that are used by the official import utilities. Then any
front end
who wants to play nice to the user like this would not have
to
reduplicate the efforts of the current utilities, nor would
they have
to hack the code out of the SWORD source and shoe horn it
directly
into their own application.
Am I actually near the mark? Would this be something that
could be
easily handled without being too much work (and, if it was
handled,
would it be used by any of the front ends?)? I think it
would be a
very user-friendly thing to have available, but it would
take work
from someone to refactor the utilities directory and also
from the
front end developers to build support for this into their
applications. I know I've been carrying the pumpkin
for mod2osis for
most of the recent work on it, and would be happy to make
these
changes to that program -- it wouldn't be the best one
to include in
this effort, since there's lots of work it still needs
to convert
non-OSIS original modules into its format well, but
it's the only such
utility that I'm closely familiar with.
Thoughts, comments, accusations?
--Greg
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
