Should I turn them into JIRAs, so we can track them better? Bernd
On Mon, Apr 13, 2009 at 10:55, Ashish <[email protected]> wrote: >> >> this is a probably incomplete list of things to do to move Vysper over here. >> >> MOVE PROJECTS >> + ratify reception of code (MINA) (vote, pending) >> + ratify Vysper lab completion on Labs side (vote) >> + (optional) do additional steps as required to move from Labs to >> MINA, for example moving through Incubator >> >> IP CLEARANCE >> >> + check dependencies, NOTICE, LICENSE etc. >> >> INFRA >> + move LABS/Vysper JIRAs >> + move Vysper svn >> + move Vysper's cwiki pages >> >> CODE (after svn move) >> + adjust code to MINA conventions (headers etc.) >> + use maven for build >> >> KARMA >> + grant berndf committer karma for Vysper >> >> Anything else? > > One thing that can be done meanwhile is upload the XMPP compliance > report on wiki. > > I did saw the compliance package, and its really great way of > capturing Spec compliance. > We can do something similar for FtpServer and SSHD (typically for > project where we need RFC compliance). > > Meanwhile, as we wait for the Voting and other formalities to > complete, here are possible directions to work spend our energies > 1. Generic XML Codec - We can work towards making a generic XML Codec > and may be make it as part of MINA Core. In Vysper, we can reuse the > same. > > 2. Can think of some suitable place for Spec compliance package and > try to see possible use in other projects > > 3. Wiki is a definite candidate to be worked upon. > > 4. Can try to see the possible use of State Machine decoder, while > decoding XML or alternatively see how we extend and use a streaming > parser. > > 5. Some benchmarking shall be a good to have. We will be competing > with Openfire (hope have picked the right name), which again use MINA > for transport layer. > > Trying to understand the code a little more. > > thanks > ashish >
