[wikireader]Suggestions for next steps on software

[David Reyes Samblas Martinez]

2009/10/30 Doug Jones <dj6mf at frombob.to>:
> Doug Jones wrote:
>> David Reyes Samblas Martinez wrote:
>>> Though on how the evolution of the soft of the wikireader must be, I
>>> have oredered the sugesstions by impact on functionality/easy to
>>> implement ratio, of course under a totally  non-hardcore developer and
>>> only-one-week user criteria.
>>> *First and prioritary,
>>> allow have multiple languages on same sdcard, I think a one easy
>>> approach is to have a selection menu on boot with the available
>>> languages on the sdcard (looking at the sufix of the pedia files
>>> "pedia_es", "pedia_de", "pedia_pt"..... ) present a bare text menu
>>> with the items, select,  and then operate as usual.
>>> More complex things like changing of language inside a topic or
>>> include non wikipedia content to  that menu using a config file can be
>>> implemented later on.
>>
>>
>> I notice that the current implementation fits within the old 8.3 DOS
>> file naming scheme (except that both upper case and lower case is used).
>>   Is this done to avoid the FAT patent issue?
>>
>> If so, then we need to devise a naming scheme that fits within that...
>> perhaps something like
>>
>> wwwwllnn.ext
>>
>>
>> where:
>>
>> wwww indicates which wiki
>>
>> ll   indicates which language
>>
>> nn   indicates which alphabetical section  (I assume the articles are
>> grouped according to first letter, 00 through 26 for A-Z and other
>> characters...   or is this wrong?)
>>
>>
>> Other alphabets have different numbers of letters, so do we sometimes
>> need more than two digits?
>>
>> And some languages don't use alphabets...   has somebody already worked
>> out a general scheme for breaking up the files, and is this documented
>> somewhere?
>>
>>
>> We have to break up the data into chunks somehow.  FAT has a 4GB file
>> limit, as I recall...
>
>
> Actually it seems a bit more complicated than this.
>
> The language designations used within Wikipedia are not just limited to
> two characters  --  these aren't just country codes.
>
> Most languages there are designated by a two-letter code, but some are
> three letters, and go all the way up to "simple" for simple English and
> "cbk-zam" for Chavacano de Zamboanga.
>
> Clearly we should be aiming for a system that can accommodate all
> available versions of Wikipedia, as well as those yet to be implemented.
>
>
> The current implementation uses a flat directory structure, with no
> subdirectories.  Is there some compelling reason for this?
>
> We could put each separate wiki into its own directory.  This would make
> it much easier to fit everything within the 8.3 naming scheme (assuming
> that this scheme really is a requirement).  It would also make it easier
> for the user to copy a new wiki onto the card;  they just have to copy
> one folder, instead of keeping track of dozens of files.
>
> This would also eliminate the need for a config file at the root that
> would need to be updated as wikis are added or removed.  Instead, the
> boot code scans the root, finds all the directories, looks inside each
> one for a short metadata file that contains the description for that
> wiki (in the appropriate language of course), and then uses that data to
> build the first menu that the user sees.
>
> _______________________________________________
> Openmoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
I like this approach, just remind that as far I see the code and by
comments of the devs, the kernel implements the bare just enough to
read files, so I think directories are not implemented at all that's
why all is on root directory so at least basic hierarchical filesystem
has to be implemented before we can do this solution. But directories
will easy the organization of pictures too