Le 9 août 06 à 11:30, Günther Noack a écrit :
Hi!
As some of you have probably noticed, I recently added local
dictionary support to DictionaryReader. DictionaryReader currently
installs a copy of the Jargon file along with it in the application
resources.
The used file format is the same file format used by the dict
server from dict.org, so it's compatible to the dictionaries you
can retrieve for the dict server.
Now I wonder how I'm going to get the dictionaries when the
application is launched. The resource-solution is okay for the
Jargon file, but other dictionaries may have other licenses. I
certainly don't want to get involved with licensing issues. ;-)
What are the usual licenses of other dictionaries. Do you know a page
where such dictionary license are listed and avaible for reading?
The constraints I keep in mind are:
A) I probably want to have icons for the dictionaries later.
Bundles would be perfect for that, but if this is not acceptable,
the icons can also be stored in the main application. (There don't
seem to be more than 20 appropriate dictionaries in the public
domain.)
Are most of dictionaries provided with a dedicated icon? How is the
icon provided/packaged usually? Is there a usual location?
B) The dict server can read from gzipped dictionaries, while
DictionaryReader can't do that unless there's a gzip-transparent
implementation for FileHandle. So DictionaryReader will probably
need to gunzip and save its dictionaries to a local folder in any
case.
You may have a class that decorates NSFileHandle and takes care of
gzip translation.
Here are the solutions I came up with:
1) Bundling dictionaries in bundles or something similar while
providing a tool to convert dictionaries to those bundles.
+ Licensing is no problem
- A lot of work for each user
I think this single point disqualifies this solution (unless it can
be worked out to the point it is handled behind the scene and
transparently)
- Is is possible to create bundles without code?
Yes, with NSFileWrapper class which is used to handle document bundle
like .rtfd. For NSBundle, I don't know. You could need a dummy
principal class but that's no big deal.
+ Icons can be packaged along with the dictionary
+ Dictionaries wouldn't need to be unzipped.
To me, having to unzip dictionary isn't a problem at all since Étoilé
requires zlib (LuceneKit currently uses it and support for zip files
will be provided by default in the environment)
2) Searching the system for installed Dict-style dictionaries.
(Most distributions provide a dict-file package that accompanies
the dict server.)
+ Licensing is no problem
+ Dictionaries are system-wide
- Either on-the-fly-unzipping or copying to home directory needed.
(Not yet solved)
You can cache an unzipped copy in Library/Caches
- Users will need to install the dictionary package, which ofter
depends on the installation of the dict.org server (at least on
FreeBSD)
- Icons aren't packaged with the dictionaries
I'm not convinced by the need of icon representations for
dictionaries. Are they pretty? ;-) Or really meaningfull most of the
time?
3) Hard-coding the FTP URLs to the dict.org dictionaries into
DictionaryReader and making them fetchable from the GUI
You can provide default URL values and let the user tweak them in a
preferences panel. By tweaking, I mean fixing the dictionary URL if
it isn't valid anymore.
It would be great if dict.org would maintain a simple page where all
dictionary URLs are kept up-to-date and stored in a easily parsable
way. We could ask them about this possibility.
In this case 3), dictionaries should probably be installed in Library/
Application Support/DictionaryReader
+ Licensing is no problem
+ Easy for users
- Icons aren't packaged with the dictionaries
- no system-wide dictionary installation
- dict.org needs to provide the dictionaries via HTTP, too. (IIRC
there's no FTP support in Foundation/GS-Base)
Basic FTP may be added easily in GNUstep or Étoilé (I think such code
already exists outside). Otherwise relying on 'ftp' command or a
small library could be a solution. I think we are going to provide
some form of FTP support by default.
4) Fetching and installing dictionaries as part of the build process.
- Licensing issues just *moved* to the time when Etoile is shipped
in binary form. :-/
+ Easy to use
+ "Bundles" (see above) can be used
That's going to make Étoilé a lot more heavy, taking in account they
are a huge number of dictionaries available, no?
I don't think providing all of them out of the box is a good idea.
It's better to give the user the opportunity to install the
dictionaries they want. Though providing a default set of five or ten
dictionary is surely a good deal.
I'm in favor of a basic set of dictionaries with the possibility to
extend it by relying on solution 2) and 3) … solution 3) would be the
last fallback, always working.
Here is my take on this issue :-)
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
