i18n question.

Kenichi Okuyama okuyamak at dd.iij4u.or.jp
Tue Mar 9 12:15:24 GMT 2004

Dear Simo, Tridge, and all,

>>>>> "Simo" == Simo Sorce <simo.sorce at xsec.it> writes:
Simo> What I really meant was that by implementing a samba3 module people can
Simo> have it sloooowly working right now.

Well... I believe we need little more work than that.

I've looked at samba4 tree of CVS, which I believe Tridge have given
us a chance of code.
# Correct me if I'm looking at wrong thing.

I feel we need little more interface than what we have now.

The following list are unpriotized, so it's mixture of nice to haves
and should haves, and "Don't know how it should be".

1) Currently, README document says we are recieving windows style
   file name, but it would be nice if we can have 'unix' style
   file name ( I mean, '\' converted to '/' ).

2) We need what 'unix charset' are we recieving.
   I believe it would be nice if this information is being passed
   by API, and not looking at status structure.. so that we do
   not need to re-compile modules everytime internal format changes.
   # Some manager love this idea.. Though I feel that's simply
   # lack of some understanding...

   I wonder if we should have it per string, or prepare some
   interface function for this purpose...
   ( do 'unix charset' change dinamically? I mean,
     do modules get reloaded when smb.conf is re-read?
     Or should we have 're-setting unix charset' interface for
     this purpose... ).

3) I think it would be nice if we could have options per [homes],
   and somehow knowing which [homes] we're in, or some number
   we've generated on initialization, be passed.

   I mean having modules per very small change of conversion table
   isn't nice idea ( Even for CP932, we made more local format
   like HEX, CAPS, etc.. ). With this parameter, we'll be able to 
   know which to choose.

   Parsing parameter should be job of modules. We only need
   some pointer we've generated.

I'm sure Monyo and Shiro will have different opinion, as well as
other Japanese developer.
# They might find a way to solve all the threes above, and
# as result, we might not wish for any change ...

It would be very nice if we can hear opinion from those other than
Japanese too, like Korian, Chinese and other language working groups.

By the way, I've already seen some unique request which seems to fit
very well against NTVFS modules.

  The person wanted to REJECT filename containing any character
  that's causing trouble with compatibility of CP932.

  He/She also wanted to reject file starting with '-' or '()${}'

  It might be better to have such filter as NTVFS modules....
  #Multi-layered NTVFS modules?

So let us take time. I believe it does worth.

Simo> Another thing that will break for sure are all getpw* calls so the
Simo> system _need_ to be in utf8 (if you use utf8 as the default charset) and
Simo> only some secondary disk can be in a different charset with samba3+vfs
Simo> after all ...


What you're saying is, that if /etc/passwd contains EUC character as
username, we have to use EUC as 'unix charset'? Even if filesystem
is managed in UTF-8? We have to have pass modules for converting
EUC->UTF8 against all the file IO?

That sounds sad.. Though I have never heard of unix system allowing
EUC nor CP932 as username... But there might be.

Also, there might be for case of Korian, or Chinese.

Maybe we should have some modules for that purpose, independent of
filesystem module layer.  So that if filesystem is UTF8, then we can
have UTF-8 as 'unix charset', and take time on handling username,
which does not happen as often as file IO.

Let's call this module PASSWORD modules for now.

If we could have PASSWORD modules, we can do something like this:

   On unix, we have user name managed in ASCII, but on Windows, we
   have username in Kanji(Unicode). By having mapping table, now
   user can use Kanji(Unicode) as username, and can access to unix
   system which only can handle ASCII username.

I have no idea whether this idea worth implementing... But I'm sure
someone will come up with idea of using this modules...

Any opinion?
Kenichi Okuyama

More information about the samba-technical mailing list