Hello Jean-Marc
2013/2/28 Jean-Marc Borer <jmbo...@gmail.com> > Jörg, I am new to this list and project. I have actively contributed > to VFS especially to the HTTP and Webdav parts. When I file an issue > or a request for improvement, I also publish a patch. > > Nice that you've joined us! > Where can I find the information if my patch will be > accepted/integrated in which version and when it is planned to be > released, etc? > commons does not provide road maps for components. Usually when some one starts to work on a new release he will go through all the open issues and decide which can be included in the release (for example new features can not be included in bugfix releases). Committers will review your patch and give you feedback about it. If a patch matches all requirements your patch will be included in the latest trunk and you can be sure that it will be included in the next release. This maybe unsatisfying if you need the functionality you provided with your patches, but please remember that commons (like every other ASF project) is a volunteer based community. People are reviewing patches and working on the source code in their free time. This is, why we can't make promises on release dates. VFS has received some attention from committers and users lately to a new release in the next time is likely. Regards, Benedikt > > Cheers, > > Jean-Marc > > On Wed, Feb 27, 2013 at 12:28 PM, Jörg Schaible > <joerg.schai...@scalaris.com> wrote: > > Hi, > > > > Jörg Schaible wrote: > > > >> Hello guys, > >> > >> the current implementation of the UserAuthenticationData only allows us > to > >> keep character arrays as values for the user authentication. However, > for > >> FTPS or SFTP (maybe more - HTTPS, WebDAVS) we may also have to use > private > >> keys or client-side certificates. Unfortunately I cannot keep those in > the > >> UserAuthenticationData. > >> > >> This results in half-baked solutions like provided in the patch of > VFS-283 > >> where the passphase is delivered with the "standard" mechanism, but the > >> key data is individually set and on top of it a private > UserAuthenticator > >> implementation that tries to overcome the limits of the > >> UserAuthenticationData. > >> > >> Therefore I'd like to apply my proposed changes in VFS-466, where I keep > >> binary compatibility, but have to deprecate the old getter/setter in > favor > >> of new ones dealing with arbitrary data (defined by the enhanced inner > >> Type). > >> > >> WDYT? > > > > I reverted this for now. There are too many implications and its probably > > not the best time to start a refactoring near a new release. It might be > > better to think about the complete UserAuthenticator concept for 3.0. > > > > Sorry for the noise, > > Jörg > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
