[sword-devel] Making Import Easier

Tue Apr 7 01:00:39 MST 2009

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.hellings at gmail.com> wrote:
>
>> From: Greg Hellings <greg.hellings at gmail.com>
>> Subject: [sword-devel] Making Import Easier
>> To: "SWORD Developers' Collaboration Forum" <sword-devel at 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 at 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 at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page