What's next for Samba ?

[tridge at samba.org]

Jerry,

 > ok.  Couple of things.  I don't really want to start extending the
 > life of 3.0.  If we want to backport then let's have a 3.1
 > and backport to that.  Backporting to a release branch tends to
 > destabilize code.

yep

 > Second there is an issue of time.  Can samba4 be ready by
 > next fall?   Do people even want to shoot for a release
 > next fall?

Can we stick to months instead of US-centric terms like "fall". I'm
guessing you mean around September next year? (thanks to LukeH and
Vance for translating for me) :-)

If so, then I think we could get Samba4 ready by then, but it would be
a pretty hectic time between now and then. It really depends how much
time key people can put into it.

 > Finally, if we focus on Samba4 alone, argueably a good move
 > for future code maintaince, it seems that we will be ignoring
 > new features. 

not completely. For example, by moving to the new RPC infrastructure
we should be about to expand our feature base for being a domain
controller much faster. We also will get a few important features:

 * the ability to multiplex requests, which is very important for
   terminal server performance

 * the ability to support things like streams, which are in Samba4 but
   not Samba3

 * the ability to support all 4 timestamps on a file, which the Samba4
   NTVFS can do but Samba3 can't. (of course, we need a backend to
   hold it, presumably using extended attributes on posix).

 > Rather will be reimplementing a lot of stuff we can do now.  I know
 > there's new, cool stuff there, but I think you understand what I'm
 > saying....

yes, there will be a period when we are mostly re-implementing stuff,
but it shouldn't be seen as wasted time. We will also be fixing large
numbers of bugs and building something that will save us lots of time
in the future.

You also need to take into account the fact that with the more modular
nature of Samba4 we should be treading on each others toes
less. Someone can write the POSIX backend without touching the core
code in smbd. We know this is possible, because the CIFS backend is
basically complete[*] and fully functional, so we know that it is
possible to write a complete backend. That means that unlike Samba3 we
should be able to parallelise our work more, with one group working
towards the new POSIX backend without constantly having their API
changed by people working on other sections of the code. That why I
chose "complete" APIs for the interfaces rather than picking a subset
API.

Cheers, Tridge

[*] There are a couple of missing pieces in the CIFS backend, but not
    much