> > 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
