Re: [dict-beta] RFC - 2229: Suggestions for Update

Hi,

> There is no reason to do this, because utf-8 should be used
> by both DICT client and server. It is enough to support several languages
> on a single DICT server.

  I know. But suppose I have some dictionaries on my server in several
languages, how do I give option to the client to look in dictionaries
in a specific language?

  You may say that the client should select the appropriate database.
But what if I am looking for a German term (just learning German), and
I don't know which dictionary... how would I do that? Would I need to
selected all German databases?

   Infact, this very point gives me another idea - searching for a
word in locale L1 but want to have the meaning in locale L2. Take the
same example - I've just started to learn German and I found a word,
say, "amor". German dictionary will explain it in German words, but
what I am looking for is the English word "love".

   Is this facility available in current specs? Or is there some kind
of workaround?

   Also, here's another possibility that came to my mind -- I am
looking for a medical term, in German and you are looking for a
medical term in French. Should the server have two different databases
like "de_DE_Medical" and "fr_FR_Medical"? Or does it make more sense
to first select the locale and then select the Medical database?

   If you go my way... I have a very efficient implementation of the
database and its search methods.


> The only problem with UTF-8 I see is that
> it is not possible to implement the search strategy which
> whould work like 'prefix' strategy but

   It can be. I think it's more of an implementation issue than a
protocol restriction. One can do it. Yes, but if the locale / language
itself is not defined, you cannot expect sorting.

  
>  GV>  - Defining output formats (support for XML format besides
>  GV>  current plain text)
> See paragraph 3.10.1 for OPTION MIME command.

   Seen it. Thought about it. Worked on it.
   I just wanted to give a default XML-output format. Nothing much.
Defining output format does not mean option to support more format.
It's like defining how plain text output from server should look like.

>  GV>  - Extensions to the current method of defining and matching words
>  GV> (with support for references to other words in same or other
>  GV> dictionaries)
> References are a part of definition.
> Its structure is not considered
> by DICT protocol (except optional MIME header).

   I would impress upon -- it should be a separate part on itself
rather than being part of definition. It becomes easy to separate them
out from definition when listing references.

  Just to give an idea, look at
http://dictionary.reference.com/search?q=dictionary

  You'll notice all references at the end of the page, after all
definitions. How does the client handle it? I think there should be
enough space created by the server for the client to play. :-)

>  GV>  - Support to list full dictionary-words
> MATCH <DB> prefix ""

   Yikes. Should have struck. Ok... one down! ;-)

>  GV>  - Updates to the current URL form.
> What exactly?

   Not much. Support to recognize the protocol version, multiple words
and multiple strategies. Not sure if the last two are already there.
And also support locales and charsets.

   My new form looks something like:

   dict:userinfo@host:port/version/locale/charset/database/word
   dict:userinfo@host:port/version/locale/charset/database/part/strategy

   Removing all colons and using more widely acceptible character -
"/", make it look prettier as well. :-)

> 
>  GV>  - Updates to how the interaction happens (esp the initial server
>  GV> response,
> See section 3.1 in RFC

   Seen it. One question -- the initial response it:

   text capabilities msg-id.

   Where does capabilities start and text end? I want the initial
response to just contain the protocol version and msg-id, optionally
followed by server name and other details (generic text at the end).

>  GV> getting capabilities
> A list of capabilities are enclosed in <>.
> See section 3.1

   Oops! I missed the "<>" characters.

   But still, I would like to separate them out. Just for example,
SMTP server responds with its capabilities once you issue and EHLO
command. :D

>  GV>, server info,
> See section 3.5.4 for SHOW SERVER command

    Gotcha. One more down.

>  GV> supported charsets,
>  GV> available locales etc)

   What charsets can the server understand and what locales are
available with the server. Of course, they do not come into picture if
you don't allow my previous recommendations, on charset and locales,
to be enforced. :D

   Just for announcement - I've already started work on implementation
of the new commands in the DICT server that I am implementing. :-)

   I am all alone - with two hands - not to mention my office hours
make a killing... will take some time to come out with even pre-alpha.
:(

   But if I gather enough moss, things may speed up!

-- 
Cheers,
Gaurav Vaish
http://www.mastergaurav.org
http://mastergaurav.blogspot.com
--------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

_____________________________________________________________________
Website META Language (WML)                         http://thewml.org
User Support Mailing List                        [email protected]
Automated List Manager                            [email protected]