On Mon, Apr 13, 2009 at 10:55, Ashish <paliwalash...@gmail.com> 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.
Did you get it to work?? I never managed to run the ant apt task properly, I had to use the command line apt with lots of workarounds (Might be due to me using MaOSX or something). > I did saw the compliance package, and its really great way of > capturing Spec compliance. +1. If you put the generated HTML into the javadoc root, all the links should also work. > 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. +1. XMPP uses a subset of XML, so Vysper's current impl is sufficent for now. I think this is a worthwhile thing to do, and will definitively participate in the discussion, but I lack time and energie to help with coding. > 2. Can think of some suitable place for Spec compliance package and > try to see possible use in other projects +1 > 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. +1. All effort until now went into making it spec compliant (ongoing), no time into making it performant. To catch up with Openfire will be a lot of work (an understatement). I think at first we will run into simple obstacles. And yes, this is perhaps one of the most important todos. > Trying to understand the code a little more. Let me know where you need more explanation. Bernd
