Subject: Re: OT: [what about a. sun ?]
From: a sun (asun@cobalt.com)
Date: Thu Aug 10 2000 - 18:26:10 EDT
Which does beg the question again - since Cobalt distributes netatalk with
their Cobalt servers, what, if any, is the difference in the distributions?
I hope someone knows (Adrian definitely should) since I kinda wanna avoid
having to buy a Cobalt server and then return it under some pretense (if
they have a money back guarantee) just to find out (grin)
hi,
you could just buy a qube because of the coolness factor. in any case,
i believe that i've put out repeated requests for more active netatalk
development. it's a bit odd to have all of the excitement occur while
i've been away on vacation. all of the changes that i make to netatalk
show up in the next snapshot that i put out. right now, there are only
a few differences between my own development tree and pre39.
fyi, i was planning on fixing up the codepage support before making an
"official" new release. it's currently disabled because i wanted to
change the format to handle multibyte characters and deal with generic
character mappings. unfortunately, i've been swamped with job-related
activities. in terms of longer-term netatalk development, here's how
i've thought things would go:
make an asun2.2.0 (final asun2.1.4-preXX) + fixes branch
split into a new development branch
i would really like to see the sourceforge netatalk site as the
latter. a separate development branch would allow pretty sweeping
changes. these might include the following:
1) easier configuration and support for more platforms
2) both user/group sys admin capabilities. note: i didn't
integrate the current patch on group admin because
of the security implications.
3) fix the permissions problems. doing this will actually
make proper user/group sys admin support almost trivial to
do.
4) enable appledouble v2 and finish the db support. we'll
need to provide an api to samba to improve interoperability.
5) integrate with samba's idea of locking. this has some
license issues to work out. ideally, we can get the samba
folks to put out an api that netatalk links against.
6) any other inter-operability issues that arise
7) provide apple-style printer authentication. i have stubs
in the uam code to deal with that, and some patches for
this already exist.
8) start on an afpclient.
9) more user authentication modules. i'd like to see kerberos
and openpgp uams.
10) work on making netatalk future-AFP ready. #4 actually goes
a long way towards doing this. however, we will probably
need to change to an appledouble next-gen to handle 64-bit
filesystems correctly. we'll need to spec this one out,
but it should be pretty simple. we basically have two
options:
a) change to an incompatible header format with space
for 64-bit offsets.
b) add an extended header tag that allows us to
specify 64-bit information.
i'm leaning toward b) as the way of maintaining some
backwards compatibility although both of these options
would still need a version number bump.
-a
This archive was generated by hypermail 2b28 : Wed Jan 17 2001 - 14:31:56 EST