[DISCUSS] Moving Vysper lab to MINA as a sub-product
Hi MINA folks, Currently I am developing a XMPP[1] server implementation at Apache Labs[2] called Vysper[3][4] (pronounced 'whisper'). This effort is going on on and off since 2006, but recently it gained track again and reached some critical internal milestones (regarding to level of functionality completed and persistence layer added). Unfortunately, I am the only contributor to the project until now. A few days ago at ACEU09 I spoke to Emmanuel and he had the idea of possibly making Vysper a sub-project of MINA. Thanks, Emmanuel! I gave this a few more thoughts and started to like the idea. So I'm starting a public discussion about it. The big advantages for Vysper in the MINA community would be: + strong protocol related community, + feel at home (Vysper uses MINA for IO), + ability to have a dedicated ML and make releases (eventually) + benefit from on-site MINA know-how The advantages for MINA could be: + add one more emerging protocol to the MINA roster + add one more MINA case to the project with specific interesting IO needs under high load (hint: Twitter), + look into optimizing support for non-line-oriented protocols + take Vysper (the software, not the project) as a possible experimental playground, since the IO layer should be relatively easy to change (for example changing it to MINA 1.x, 2.x, TRUNK). Any thoughts on this? Thanks, Bernd [1] http://en.wikipedia.org/wiki/XMPP [2] http://labs.apache.org [3] http://cwiki.apache.org/confluence/display/labs/vysper [4] http://svn.apache.org/repos/asf/labs/vysper/
Re: [DISCUSS] Moving Vysper lab to MINA as a sub-product
On Sat, Apr 11, 2009 at 00:54, Emmanuel Lecharny elecha...@apache.org wrote: Niklas Gustavsson wrote: On Fri, Apr 10, 2009 at 7:51 PM, Alex Karasulu akaras...@gmail.com wrote: On Fri, Apr 10, 2009 at 1:46 PM, Emmanuel Lecharny elecha...@apache.orgwrote: just before leaving, I think that the first step should be to move Vysper from labs to MINA sandbox. +1 Then a bit of IP clearance should be done (mainly checking if the jars are license compatible), +1 plus some degree of mavenization ugh. :-/ and headers cleaning would be necessary, You mean, adding @author The Apache Directory project? ;-) and last, not least, a general formating (using MINA code formatter) where can I get that from? I have some specific code formatting at some specific lines (where XMPP stanzas are built). I'd like to see what it does to them. Don't the folks over at labs do IP vetting? I think they do, but I agree that it might we worth rechecking after the project is moved to MINA. +1, although Labs is not excluded from doing IP clearance. There is nothing such as IP vetting in labs, IFAIK. However, as labs are reserved for committers, I guess that those who have a labs already know about this IP issue. However, looking at the Labs site, I found this description of lab project states: http://labs.apache.org/faq.html#q7 They seem to assume that projects go to the incubator after labs, rather directly to a project like MINA. I do not subscribe to the labs list, could someone who does confirm that we would be allowed to move the code directly to MINA? There have been different opinions on this. It has never been executed before. So this is the first try. If the code would have to go through Incubator (via an IP clearance vote) this wouldn't be a big thing, too. The Vysper code was developed alone by myself as a personal endeavour (Labs was not existing back then), and when the Lab was established, it was simply svn imported. All patches up to now where made by ASF committers, except for today's commit, contributed through a JIRA, by an GSoC applicant, committed by me. Bernd
Re: [VOTE] Vysper as MINA subproject
On Sun, Apr 12, 2009 at 10:32, Julien Vermillard jvermill...@archean.fr wrote: Hi guys, Bernd Fondermann has written a XMPP server based on MINA in Apache labs. As discussed earlier we all see interest in making Vysper a MINA sub-project, do let's vote : [X] +1 Yes, accept Vysper as a sub-project (happy but non-binding) Bernd
TODOs for moving Vysper
Hi, 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? Bernd
Re: [DISCUSS] Moving Vysper lab to MINA as a sub-product
On Sun, Apr 12, 2009 at 10:24, Niklas Gustavsson nik...@protocol7.com wrote: On Sat, Apr 11, 2009 at 10:51 PM, Bernd Fondermann bernd.fonderm...@googlemail.com wrote: plus some degree of mavenization ugh. :-/ We can probably help out with this :-) and headers cleaning would be necessary, You mean, adding @author The Apache Directory project? ;-) and last, not least, a general formating (using MINA code formatter) where can I get that from? I have some specific code formatting at some specific lines (where XMPP stanzas are built). I'd like to see what it does to them. Here's the documented guidelines for MINA: http://mina.apache.org/developer-guide.html There have been different opinions on this. It has never been executed before. So this is the first try. If the code would have to go through Incubator (via an IP clearance vote) this wouldn't be a big thing, too. Would you mind starting a discussion over a labs about this? I'll join the list and follow along. I'll do that as soon as possible. Bernd
Re: TODOs for moving Vysper
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
Re: TODOs for moving Vysper
On Tue, Apr 14, 2009 at 06:02, Ashish paliwalash...@gmail.com wrote: 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). Not yet, just browsing the code. will give it a shot 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. Don't worry about this, our community is very active. Check this out http://www.nabble.com/XML-Pull-Parser-based-XML-Decoder-implementation-td23022865.html Vysper has it's own naive pull parser implementation. See packages o.a.vysper.mina o.a.vysper.mina.codec o.a.vysper.xmpp.decoder o.a.vysper.xmpp.fragment No third party lib I looked at in 2007 worked for me. snip/ Trying to understand the code a little more. Let me know where you need more explanation. I did worked on XMPP, during a POC. Been through openser, Openfire. The number for specs on XMPP scared me away ;-) :-) Well, I can understand that. As soon as you take a closer look, though, that's actually an advantage of XMPP: Being very modular on the spec side, too. The RFCs are big, but the XEPs are usually pretty handy. Bernd
Re: TODOs for moving Vysper
Should I turn them into JIRAs, so we can track them better? Bernd 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. 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
Re: [DISCUSS] Moving Vysper lab to MINA as a sub-product
On Sun, Apr 12, 2009 at 10:24, Niklas Gustavsson nik...@protocol7.com wrote: On Sat, Apr 11, 2009 at 10:51 PM, Bernd Fondermann There have been different opinions on this [moving code from Labs to subproject of TLP]. It has never been executed before. So this is the first try. If the code would have to go through Incubator (via an IP clearance vote) this wouldn't be a big thing, too. Would you mind starting a discussion over a labs about this? I'll join the list and follow along. /niklas I started a thread about it [1]. Re-reading what was previously said about this topic, all concerns are about a lab wanting to become TLP. There are no concerns AFAIS about a lab going to an existing TLP as subproject. But we will see. No response yet. Bernd [1] http://mail-archives.apache.org/mod_mbox/labs-labs/200904.mbox/%3c49e3148a.9000...@brainlounge.de%3e
Re: TODOs for moving Vysper
On Tue, Apr 14, 2009 at 07:30, Ashish paliwalash...@gmail.com wrote:
Vysper has it's own naive pull parser implementation. See packages
o.a.vysper.mina
o.a.vysper.mina.codec
o.a.vysper.xmpp.decoder
o.a.vysper.xmpp.fragment
No third party lib I looked at in 2007 worked for me.
Have seen that. Infact, my first XML decoder was very similar.
Check out this thread
http://www.nabble.com/Continuous-XML-document-processing-td20802789.html#a20802789
Openfire has similar implementation.
Thinking about multiple implementations of XML Decoders, basically
using different parsers.
have it for XPP3, woodstox shall be ready guess by today (if time
permits). Then we can try with
JiBX, XStream etc
:-) Well, I can understand that. As soon as you take a closer look,
though, that's actually an advantage of XMPP: Being very modular on
the spec side, too.
The RFCs are big, but the XEPs are usually pretty handy.
Well now you understand XMPP, so will take your help on this :-)
One biggest TODO, is to migrate the code from MINA 1.1.0 to MINA 2.0
A lot has changed since then.
I you or anybody else is happy to dive into it, go ahead. Every ASF
committer has Labs commit access... ;-)
Couple of test cases related to Presence are failing.
Yes, see JIRA LABS-340. In progress.
Regarding Spec package, was able to generate the report :-)
Changed this apt-classpath
path id=apt-classpath
path refid=classpath /
pathelement location=${vysper.output.dir} /
pathelement location=${java.home}/lib/ /
/path
and here is the modified target
target name=generate-compliance-doc description=generates the
compliance document
apt
factory=org.apache.vysper.compliance.reporting.DocumentSpecCompliantAnnotationFactory
debug=false verbose=true
preprocessdir=${basedir}/build/ant/apidocs
compile=false
classpath refid=apt-classpath /
src refid=sourcepath/
/apt
/target
See if it works for you.
Great! Now it works! Thanks.
Is this contributed, ASL-licensed code? ;-)
For the compliance package, my expectation shall be a little
different. We need to generate a summary report, which states what all
we comply to, like a simple pdf. Users can pick it up and can see the
compliance easily, rather than browsing all javadocs. Javadocs shall
still retain this information.
+1. That'd be a goal for improvement. The current idea is to have an
easy pointer where in code to find the implementation(s) for a
specific part of the spec (you already mentioned it, the RFCs are big
:-). Some section you'd probably never implement, sometimes you have
to go down to paragraph- or bullet point-level granularity.
I guess turning them into JIRA will make things more manageable and we
can get a better picture of tasks at hand.
Ok, I'll take that todo.
Bernd
Re: TODOs for moving Vysper
On Tue, Apr 14, 2009 at 09:44, Ashish paliwalash...@gmail.com wrote: One biggest TODO, is to migrate the code from MINA 1.1.0 to MINA 2.0 A lot has changed since then. I you or anybody else is happy to dive into it, go ahead. Every ASF committer has Labs commit access... ;-) Is it?? Never knew that :-) Or we may freeze the development for a while, till the code is moved to sandbox, and then take care of all this. At some point, we need a freeze. Please let me know when you start IP due dilligence. For the time being, I'd like to continue committing. Any suggestions ?? If you need a branch at Labs, I'll re-balance the trunk. Great! Now it works! Thanks. Is this contributed, ASL-licensed code? ;-) Yup It is :-) You'd like to commit it? That'd be great. Otherwise I will do later today. For the compliance package, my expectation shall be a little different. We need to generate a summary report, which states what all we comply to, like a simple pdf. Users can pick it up and can see the compliance easily, rather than browsing all javadocs. Javadocs shall still retain this information. +1. That'd be a goal for improvement. The current idea is to have an easy pointer where in code to find the implementation(s) for a specific part of the spec (you already mentioned it, the RFCs are big :-). Some section you'd probably never implement, sometimes you have to go down to paragraph- or bullet point-level granularity. Leave this to me, will take care of it. ok. I guess turning them into JIRA will make things more manageable and we can get a better picture of tasks at hand. What's the Lab JIRA URL? https://issues.apache.org/jira/browse/LABS select component 'Vysper' Bernd
Re: TODOs for moving Vysper
On Tue, Apr 14, 2009 at 10:01, Ashish paliwalash...@gmail.com wrote: For the time being, I'd like to continue committing. Which file are you working with. If I get into the code today, shall take care of file headers as well. Please don't adopt to MINA conventions for now! We're still in Labs. Let's do that _after_ the move to MINA sandbox, when the whole MINA community can participate and provide oversight. Thank you. Great! Now it works! Thanks. Is this contributed, ASL-licensed code? ;-) Yup It is :-) You'd like to commit it? That'd be great. Otherwise I will do later today. Will do it. Low in energy today, but trying to regain my strength :-) Bernd
Re: TODOs for moving Vysper
On Tue, Apr 14, 2009 at 10:32, Niklas Gustavsson nik...@protocol7.com wrote: On Tue, Apr 14, 2009 at 7:03 AM, Bernd Fondermann bernd.fonderm...@googlemail.com wrote: Should I turn them into JIRAs, so we can track them better? I think this can wait until after the vote has passed successfully so that we know we should move at all. /niklas Ok, fine. Bernd
Re: TODOs for moving Vysper
On Tue, Apr 14, 2009 at 11:47, Ashish paliwalash...@gmail.com wrote: Updated the build file. Please have a look and verify that it doesn't break anything. Have tested the execution on my machine. Works great, thanks. Bernd PS: Vysper dev discussion takes place at l...@labs.apache.org until the move.
Re: Moving over Vysper
On Thu, Apr 16, 2009 at 11:00, Niklas Gustavsson nik...@protocol7.com wrote: On Thu, Apr 16, 2009 at 10:48 AM, Julien Vermillard jvermill...@archean.fr wrote: Let's start the move :) Okay, down to the practicals then. Bernd, to you feel comfortable with the (limited) outcome of the discussion over at Labs? Yes and no. I'm satisfied with Bertrand's response but not with the number of participants. I've sent an update to labs@ a few minutes ago. I will start a vote now at labs@ to move Vysper here. We have to involve the Labs PMC, because it is the 'owner' of the Vysper code. Will take a few more days to complete, but no hurry. ;-) Also, could you now create JIRA issues for the move according to the list you provided earlier? Should I proceed now or wait till the labs vote has passed? I'm fine with both options. I've created a component in the MINA JIRA project for a XMPP protocol. Let's use that for now and then create a separate JIRA project for Vysper as we have for the other subprojects. Ok, great. Thanks. In addition, please note that there is a GSoC applicant for Vysper this year, Michael Jakl. He proposed to implement PubSub within Vysper, an important extension to XMPP ( http://xmpp.org/extensions/xep-0060.html ). Whether or not he will be accepted we will not know until Sun 20th at 1900 UTC. Bernd
Re: Moving over Vysper
On Thu, Apr 16, 2009 at 13:25, Bernd Fondermann bernd.fonderm...@googlemail.com wrote: On Thu, Apr 16, 2009 at 11:00, Niklas Gustavsson nik...@protocol7.com wrote: On Thu, Apr 16, 2009 at 10:48 AM, Julien Vermillard jvermill...@archean.fr wrote: Let's start the move :) Okay, down to the practicals then. Bernd, to you feel comfortable with the (limited) outcome of the discussion over at Labs? Yes and no. I'm satisfied with Bertrand's response but not with the number of participants. I've sent an update to labs@ a few minutes ago. I will start a vote now at labs@ to move Vysper here. We have to involve the Labs PMC, because it is the 'owner' of the Vysper code. Will take a few more days to complete, but no hurry. ;-) The vote has been started. Bernd
Re: TODOs for moving Vysper
Modifying and adding a few todos before adding the to JIRA: On Sun, Apr 12, 2009 at 22:32, Bernd Fondermann bernd.fonderm...@googlemail.com wrote: Hi, this is a probably incomplete list of things to do to move Vysper over here. MOVE PROJECTS + DONE: ratify reception of code (MINA) + ratify Vysper lab completion on Labs side (vote, pending) + (optional) do additional steps as required to move from Labs to MINA, for example moving through Incubator IP CLEARANCE + check dependencies, NOTICE, LICENSE etc. + provide a list of contributors and contributions to Vysper INFRA + move LABS/Vysper JIRAs + move Vysper svn + move Vysper's cwiki pages + create Vysper mailing list vysper-...@mina.apache.org + setup continuous integration? CODE (after svn move) + adjust code to MINA conventions (headers etc.) + use maven for build KARMA + grant berndf committer karma for Vysper Bernd
Re: TODOs for moving Vysper
On Thu, Apr 16, 2009 at 20:56, Niklas Gustavsson nik...@protocol7.com wrote: On Thu, Apr 16, 2009 at 1:43 PM, Bernd Fondermann bernd.fonderm...@googlemail.com wrote: INFRA + move LABS/Vysper JIRAs In this task, let's include setting up a new JIRA project for Vysper. + move Vysper's cwiki pages In this task, let's include setting up a new Confluence space for Vysper. ok. + create Vysper mailing list vysper-...@mina.apache.org For the other subprojects, we user dev@mina.apache.org for developer discussions. I believe the primary reason is to get all developers cooperating on the various subprojects. We do however have a separate user list for FtpServer. Wow, that should make me feel like labs then ;-) Ok, then I guess we will stick with d...@mina.a.o. In future, we could still fork a ML for Vysper (or any other subproject) when traffic permanently gets too high for a single list (this is a best practice from other projects). Bernd
Re: TODOs for moving Vysper
On Fri, Apr 17, 2009 at 02:54, Ashish paliwalash...@gmail.com wrote: + move Vysper's cwiki pages In this task, let's include setting up a new Confluence space for Vysper. May be we can think of a logo for Vysper and probably since we shall be setting up new space, having a brief site map shall be a plus. Will help keep things organized. +1 Bernd
Vysper Logo [WAS: Re: TODOs for moving Vysper]
Ashish wrote: In this task, let's include setting up a new Confluence space for Vysper. May be we can think of a logo for Vysper and probably since we shall be setting up new space, having a brief site map shall be a plus. Will help keep things organized. +1 Could workout only Text Logo's :-( I am bad at drawing, too... Used this site http://cooltext.com/, for creating Logos Images are attached. Attachements get stripped (or you missed to attach them). Do you have a link (you could upload them to your people.a.o home in a subdir called public_html)? Or We can have a logo which can depicts the XMPP theme That was my first thought, too. Maybe taking the XMPP logo[1] rainbows and make something feathery out of them. [1] http://xmpp.org/images/xmpp.png Bernd
Re: Vysper Logo [WAS: Re: TODOs for moving Vysper]
Ashish wrote: Attachements get stripped (or you missed to attach them). Do you have a link (you could upload them to your people.a.o home in a subdir called public_html)? Here is the page http://cwiki.apache.org/confluence/display/MINA/MINA+Theme Please don't get Alarmed at MINA logo's :-) I am working on them too. Trying to complete my homework before starting the thread with community. ok. I think MINA already has a pretty slick Logo. NOTE: Using MINA space temporarily till we get space for Vysper, That was my first thought, too. Maybe taking the XMPP logo[1] rainbows and make something feathery out of them. [1] http://xmpp.org/images/xmpp.png There is also http://xmpp.org/images/xmpp.svg which should be easier to inspect about colors etc. than the png. I saw this too. Infact, i thought to use colored V and the word Vysper Alright, V or y. But we cannot simply forge the xmpp X (I think that's what it is intended to be) into a V. That'd be a rip off. Trying to think about how to do this intelligently... Have been trying use some Logo creation tools, but need to work out a bit on them. Our Logo colors must be in sync with our site Color. ApacheDS is a real good example. Bernd
Re: Vysper Logo [WAS: Re: TODOs for moving Vysper]
Julien Vermillard wrote: Le Fri, 17 Apr 2009 10:33:00 +0200, Michael Jakl jakl.mich...@gmail.com a écrit : Hi! On Fri, Apr 17, 2009 at 08:37, Bernd Fondermann bf_...@brainlounge.de wrote: Or We can have a logo which can depicts the XMPP theme That was my first thought, too. Maybe taking the XMPP logo[1] rainbows and make something feathery out of them. I've been playing around with the logo-ideas, take a look here: http://stuff.interlinked.org/VysperLogos/ Some of them have a weird border (black or red), this is not intended and comes from Inkscape (I guess). I used Bitstream Vera Sans for the text and the feather comes from the Apache Wiki Logo [1]. What do you think? Cheers, Michael 1: http://people.apache.org/~nicolaken/whiteboard/apachelogos/ Hi, I was going to post my tries and I seen your mail ;) http://people.apache.org/~jvermillard/vysper.svg http://people.apache.org/~jvermillard/vysper.png Julien Wow, thanks for all your input! :-) I see what you mean by arranging the feathers like in the XMPP logo. Can we make it more clear that this is intended to be a play on the XMPP logo by chosing different colors or stylized feathers? Bernd
Re: Re : Re : Vysper Logo [WAS: Re: TODOs for moving Vysper]
Michael Jakl wrote: On Fri, Apr 17, 2009 at 14:21, Edouard De Oliveira doe_wan...@yahoo.fr wrote: i do agree if some remainder to mina is a wish maybe combining the V feathers with mina logo (replacing the mina text with Vysper) is the way Good point! Here a few ideas based on the Mina logo: http://stuff.interlinked.org/VysperLogos/mina_vysper.png (first try, click on your own risk :)) http://stuff.interlinked.org/VysperLogos/mina_vysper2.png http://stuff.interlinked.org/VysperLogos/mina_vysper3.png http://stuff.interlinked.org/VysperLogos/mina_vysper4.png (like 3 but with shadows) Cheers, Michael Hi Michael, concerning your contributions, could you please - if you don't mind - file a ICLA with the ASF? see http://www.apache.org/licenses/#clas Thanks, Bernd
Re: Re : Re : Re : Vysper Logo [WAS: Re: TODOs for moving Vysper]
Edouard De Oliveira wrote: IMHO the 4th is really cool ! exactly what i had i mind good job :) +1! Wow, that's a great one! Thanks Michael! Bernd Cordialement, Regards, -Edouard De Oliveira- Blog: http://tedorgwp.free.fr WebSite: http://tedorg.free.fr/en/main.php - Message d'origine De : Michael Jakl jakl.mich...@gmail.com À : dev@mina.apache.org Envoyé le : Vendredi, 17 Avril 2009, 14h55mn 57s Objet : Re: Re : Re : Vysper Logo [WAS: Re: TODOs for moving Vysper] On Fri, Apr 17, 2009 at 14:21, Edouard De Oliveira doe_wan...@yahoo.fr wrote: i do agree if some remainder to mina is a wish maybe combining the V feathers with mina logo (replacing the mina text with Vysper) is the way Good point! Here a few ideas based on the Mina logo: http://stuff.interlinked.org/VysperLogos/mina_vysper.png (first try, click on your own risk :)) http://stuff.interlinked.org/VysperLogos/mina_vysper2.png http://stuff.interlinked.org/VysperLogos/mina_vysper3.png http://stuff.interlinked.org/VysperLogos/mina_vysper4.png (like 3 but with shadows) Cheers, Michael
Re: Re : Re : Re : Vysper Logo [WAS: Re: TODOs for moving Vysper]
Michael Jakl wrote: Hi! On Sat, Apr 18, 2009 at 11:07, Emmanuel Lecharny elecha...@apache.org wrote: May I suggest all those logo to be stored into the MINA logo page, with a number, so when it will be a good timing for a vote, we can simply point to this page ? I would do so, but I don't have the right permissions (on the Mina-Artwork page[1]). If I prepare an archive for the source files and various logo-sizes could someone else do the upload? Yes, please open a JIRA and attach the files (check ASF license). Thanks, Bernd
Re: TODOs for moving Vysper
Updating the list... changed entries are starred* Should keep us busy a few days... ;-) On Thu, Apr 16, 2009 at 13:43, Bernd Fondermann bernd.fonderm...@googlemail.com wrote: this is a probably incomplete list of things to do to move Vysper over here. MOVE PROJECTS + DONE: ratify reception of code (MINA) + ratify Vysper lab completion on Labs side (vote, pending) + (optional) do additional steps as required to move from Labs to MINA, for example moving through Incubator IP CLEARANCE + check dependencies, NOTICE, LICENSE etc. + provide a list of contributors and contributions to Vysper + update the crypto notice for Vysper* INFRA + create Vysper JIRA project* + move LABS/Vysper JIRAs + move Vysper svn + create Vysper confluence space* + move Vysper's cwiki pages - DO NOT create Vysper mailing list vysper-...@mina.apache.org* + setup continuous integration? CODE (after svn move) + adjust code to MINA conventions (headers etc.) + use maven for build KARMA + grant berndf committer karma for Vysper + grant berndf editor karma for Vysper confluence space* Bernd
Re: Re : Re : Re : Vysper Logo [WAS: Re: TODOs for moving Vysper]
Emmanuel Lecharny wrote: Guys, there are a lot of god logos there... I like the one with the black rounded rectangle in the background. May I suggest all those logo to be stored into the MINA logo page, You mean this page? http://cwiki.apache.org/confluence/display/MINA/Artwork with a number, so when it will be a good timing for a vote, we can simply point to this page ? Michael uploaded his designs as https://issues.apache.org/jira/browse/LABS-349 I will add them as soon as I know where to put them exactly. Many thanks ! Seems like Vysper is on track to exit from labs :) Yes, we are on-track. In a few hours the final vote on Labs ends. :-) Bernd
[RESULT][VOTE][vysper] Compelete Vysper Lab and move code to Apache MINA
The vote *passes* with only +1 votes: binding: 5 (Santiago, Sander, Bertrand, Niall, Bernd) non-binding: 2 (Alexei, Ross) If I messed something up, please tell me. Thanks for voting! Bernd
Re: TODOs for moving Vysper
*done* creating the JIRAs. Bernd On Sat, Apr 18, 2009 at 16:22, Bernd Fondermann bernd.fonderm...@googlemail.com wrote: Updating the list... changed entries are starred* Should keep us busy a few days... ;-) On Thu, Apr 16, 2009 at 13:43, Bernd Fondermann bernd.fonderm...@googlemail.com wrote: this is a probably incomplete list of things to do to move Vysper over here. MOVE PROJECTS + DONE: ratify reception of code (MINA) + ratify Vysper lab completion on Labs side (vote, pending) + (optional) do additional steps as required to move from Labs to MINA, for example moving through Incubator IP CLEARANCE + check dependencies, NOTICE, LICENSE etc. + provide a list of contributors and contributions to Vysper + update the crypto notice for Vysper* INFRA + create Vysper JIRA project* + move LABS/Vysper JIRAs + move Vysper svn + create Vysper confluence space* + move Vysper's cwiki pages - DO NOT create Vysper mailing list vysper-...@mina.apache.org* + setup continuous integration? CODE (after svn move) + adjust code to MINA conventions (headers etc.) + use maven for build KARMA + grant berndf committer karma for Vysper + grant berndf editor karma for Vysper confluence space* Bernd
Re: TODOs for moving Vysper
AFAIK, cross-project svn copy is not working. But I'll give it a try. Bernd On Mon, Apr 20, 2009 at 13:30, Niklas Gustavsson nik...@protocol7.com wrote: On Mon, Apr 20, 2009 at 1:20 PM, Ashish paliwalash...@gmail.com wrote: When shall the code be available in MINA sandbox? As far as I can see, we could move it as soon as we like. I would prefer if Bernd could do the job as he would be the best to verify that all worked as expected. (and it's a good verification of Bernd access to the MINA svn). /niklas
Re: TODOs for moving Vysper
I was proved wrong. It worked. Do we want to have a trunk/ branches/ track/ construct under sandbox/vysper? Bernd On Mon, Apr 20, 2009 at 14:04, Bernd Fondermann bernd.fonderm...@googlemail.com wrote: AFAIK, cross-project svn copy is not working. But I'll give it a try. Bernd On Mon, Apr 20, 2009 at 13:30, Niklas Gustavsson nik...@protocol7.com wrote: On Mon, Apr 20, 2009 at 1:20 PM, Ashish paliwalash...@gmail.com wrote: When shall the code be available in MINA sandbox? As far as I can see, we could move it as soon as we like. I would prefer if Bernd could do the job as he would be the best to verify that all worked as expected. (and it's a good verification of Bernd access to the MINA svn). /niklas
Re: Bernd Fondermann is a new MINA commiter
Niklas Gustavsson wrote: All, as part of the move of Vysper from Apache Labs to MINA, the MINA PMC has voted Bernd Fondermann in as a MINA committer. Let's all welcome Bernd into the world of MINA! /niklas Thank you all for your trust. Bernd
Re: [Discuss] Is it ok to share other information(not related to project) with community?
On Mon, Apr 20, 2009 at 15:56, Ashish paliwalash...@gmail.com wrote: Folks, I received an offer mail from Atlassian. Its real good one and was confused whether I can share it here or not, as its a product sale offer from a company. Any suggestion on this? My apology for such a question. I'd consider such a fwd as off-topic and list spam. Bernd
Re: TODOs for moving Vysper
Niklas Gustavsson wrote: On Mon, Apr 20, 2009 at 11:18 PM, Guillaume Nodet gno...@gmail.com wrote: On Mon, Apr 13, 2009 at 10:55, Ashish paliwalash...@gmail.com wrote: 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). You mean some kind of TCK ? where would it come from ? There is none. The compliance package is only about documentation, not testing. However, there is infrastructure for interoperability testing at the XSF: http://xmpp.org/interop/ The spec compliance package is a set of annotations to mark classes on which part of a RFC the implement and to which degree. Here's an example from Vysper: @SpecCompliant(spec = RFC3920, section = A, status = ComplianceStatus.IN_PROGRESS) Using that, Bernd has created a script that produces an HTML report that details the compliance level of an implementation. For an example see here: http://people.apache.org/~berndf/projects/xmpp-server/vysper/apidocs_r757398/spec_compliance.html I find it's pretty useful and would like to investigate it for FtpServer (if we can break it out of Vysper into a standalone JAR and it's optional at runtime). +1 I'm open to extracting and completely redesigning the SpecCompliant code. Bernd
[Vysper][GSoC09] Michael's PubSub Proposal got accepted
Hi, Congrats to Michael Jakl. :-) He will be our MINA/Vysper Sommer of Code student for the next months[1]. Looking forward to your contributions, Michael, Have fun! Bernd [1] http://socghop.appspot.com/student_project/show/google/gsoc2009/asf/t124021715212
Re: TODOs for moving Vysper
Ashish wrote: There are couple of empty folders in Vysper source. Do we keep them? Bernd - Can you take a call on this probably not - which are they? Bernd
Re: TODOs for moving Vysper
Ashish wrote: On Tue, Apr 21, 2009 at 5:45 PM, Bernd Fondermann bf_...@brainlounge.de wrote: Ashish wrote: There are couple of empty folders in Vysper source. Do we keep them? Bernd - Can you take a call on this probably not - which are they? src\main\java\org\apache\vysper\xmpp\resourcebinding src\main\java\org\apache\vysper\xmpp\modules\core\jabber\handler src\main\java\org\apache\vysper\xmpp\modules\core\negotiation src\main\java\org\apache\vysper\xmpp\namespace From my point of view, they can go! Bernd
Re: [Vysper] Administrativa
Michael Jakl wrote: Hi! Since I do not have committer access, how would you suggest to get the big feature improvement into the code? Currently I would make JIRA tasks (as soon as JIRA has moved) and upload patches. This way Bernd can have a second look at the code. The idea is that everybody, not just me can have a look. Although, some folks might to choose to review only commits and speak up then (search for 'commit-then-review +site:apache.org'). I think the extension is mostly separate from the Vysper core, so a few bigger patches in the integration phase might also work. Unfortunately this way nobody else can have a look at the code until it is migrated... . -1, because of the reason you already give. This won't work. Personally I use git to track my work (and git-svn to communicate with the Vysper repository along with the stock subversion client). I think staying up to date and making coherent patches from many small changes should be no big problem. I'm sure you have some good ideas or suggestions how you would tackle this - please tell me ;) From my PoV, it is absolutely crucial to have small patches, as often as possible. The thing is, here at Apache, we have a very strict regime on code provenance. It must be absolutely trackable where the code comes from. That makes working with git problematic. ASF relies on its svn repository. It's our brain for everything. Everyone here knows svn from their hearts. This pretty much rules out introducing git for collaboration (at least for this summer). If you want to use git locally though, that's perfectly fine. So, I propose to attach patches to JIRA (more than one patch per JIRA, where appropriate) for the time being. At some point you may gain committership (that's not my call, but the MINA PMCs, so I can be open about that), but that's probably some month of work away. What do you think? Bernd
[Vysper] in the news
Hi, Vysper hit the main XMPP news today at http://blog.xmpp.org/index.php/2009/04/xmpp-roundup-8/ (which is fed by http://blog.xmpp.org/index.php/feed/ ) Bernd
Re: [Vysper] Publish/Subscribe timetable
Michael Jakl wrote: Hello! I'm reposting a slightly revised timetable how I plan to implement the XEP-060 (publish/subscribe) extension for Vysper. Please comment on it. Until 2009-05-23 my plan would be to continue to explore the current Vysper capabilities as well as to read the XEP-060 in detail. Since this is also the Community Bonding Period, do you have any idea how to get you out of your study and provide some feedback loops? The pubsub specification is quite large (170 printed pages), so I think a month is a good time frame. Maybe I will start coding earlier, though. Within the coming month I would also like to finalize a (rough) plan how to implement certain features. +1 I'd define two goals: Structure the spec for implementation (plan) and maybe summarize the parts to involve the rest of the community, so that they get an idea of what it's all about. For example I would like to clarify whether Vysper has (or should have) a general purpose extension mechanism. +1, please think aloud on-list. In the following Node stands for A virtual location to which information can be published and from which event notifications and/or payloads can be received (in other pubsub systems, this may be labelled a topic). Between 2009-05-23 and 2009-07-07 I plan to implement the following parts of the specification (including the chapter within the XEP-060 1.13rc1 spec): - Publish an Item to a Node (7.1) - Subscribe to a Node (6.1) - Affiliation to a Node (4.1) - Discover Node Information (5.3) These are the minimum requirements a XEP-060 implementation must fulfill to be conforming to the standard (see Chapter 3). Recommended features (creating and configuring a node for example) may also fit within this time frame. Chapter 10 of the XEP-060 gives an overview of the required, recommended and optional features. After the midterm evaluations I think it is best to concentrate on completing the extension with recommended features. And to integrate the new features cleanly into the Vysper server. In the end (around 2009-08-10) I'd like to have all the required and most of the recommended features of XEP-060 implemented and integrated into the Vysper server. After that we can complete the extension with the missing recommended and optional features and keep up with the draft-standard (since it is a moving target). In our proposal evaluation call we talked about implementing an examplary use case from the beginning. Can you factor this into your plan? Bernd
[vysper] committing new code?
Hi, should I wait with committing new stuff to Vysper sandbox? Bernd
[vysper] unit tests fixed
Please retry to run the unit tests. The stanzas are now fetched from the direct-to-session queue, not from the relaying queue. Bernd
Re: [vysper] unit tests fixed
Bernd Fondermann wrote: Ashish wrote: The stanzas are now fetched from the direct-to-session queue, not from the relaying queue. Bernd: Can you publish list of RFC's/XEP's in order to be read for XMPP? It shall help in ramping up for the protocol Sorry, hit send too early... I am replying in a new thread to the specific question. You will not find the answer there, what my commit message means though. This is an implementation specific thing. Please ask any questions you might have about that. Bernd
Recommended reading: XMPP specs
The stanzas are now fetched from the direct-to-session queue, not from the relaying queue. Bernd: Can you publish list of RFC's/XEP's in order to be read for XMPP? It shall help in ramping up for the protocol 1. RFC3920 - the core protocol. Crucial to understand the Vysper code. 2. RFC3921 - most of the IM part, especially roster and subscription. long but mostly canonical, as is the related implementation. 3. read 3920 again. 4. read 3921 again. 3. XEP-0030 - crucial to understand XMPPs extensibility mechanism. Save everything else for later. One more thing: Be sure not to read the _original_ RFCs. Read the latest bis version, see http://tools.ietf.org/html/draft-saintandre-rfc3920bis http://tools.ietf.org/html/draft-saintandre-rfc3921bis Have fun, Bernd
Re: [vysper] unit tests fixed
Ashish wrote: The stanzas are now fetched from the direct-to-session queue, not from the relaying queue. Bernd: Can you publish list of RFC's/XEP's in order to be read for XMPP? It shall help in ramping up for the protocol
Re: [vysper] unit tests fixed
On Fri, Apr 24, 2009 at 15:15, Michael Jakl jakl.mich...@gmail.com wrote: Hi! On Fri, Apr 24, 2009 at 13:29, Bernd Fondermann bf_...@brainlounge.de wrote: Please retry to run the unit tests. The new statistics for the code coverage (or test coverage): Exactly 70% of the server code gets executed when running all tests (and 83.2% of the test-code is run). Quite impressive :) You think so? I always felt that a lot of tests are missing, esp judging from what's in the spec. Bernd
Re: [vysper] unit tests fixed
Michael Jakl wrote:
Hi!
On Fri, Apr 24, 2009 at 16:25, Bernd Fondermann
bernd.fonderm...@googlemail.com wrote:
On Fri, Apr 24, 2009 at 15:15, Michael Jakl jakl.mich...@gmail.com wrote:
Exactly 70% of the server code gets executed when running all tests
(and 83.2% of the test-code is run).
Quite impressive :)
You think so? I always felt that a lot of tests are missing, esp
judging from what's in the spec.
Actually I haven't worked on a project with such a high coverage. This
makes it also a bit harder than expected to add more meaningful tests
for me since it'd require a more thorough understanding of the RFCs.
If you can think of untested parts of Vysper that you think I will
need during the implementation of the XEP, please give me a hint.
The whole presence subsription part is largely untested:
PresenceSubscriptionHandler
PresenceAvailabilityHandler
...That's most of 3921.
BTW, maybe we need to enhance SpecCompliant with a enum flag scope
having values {IMPLEMENTATION, TEST} to be able to annotate tests this
way, too.
Bernd
Re: [vysper] unit tests fixed
Michael Jakl wrote: Hi! On Fri, Apr 24, 2009 at 13:29, Bernd Fondermann bf_...@brainlounge.de wrote: The stanzas are now fetched from the direct-to-session queue, not from the relaying queue. Unit tests run through. Although I don't like the write(null) hack, why not introduce a new method and call it reset()? The comments also didn't match the method's behavior (write doesn't throw anything anymore). I've uploaded a patch so you can see exactly what I mean. +1, applied. Bernd
Re: [Vysper] Running example
Michael Jakl wrote: Hi! To implement the XEP-060, I'd like to have a running example which would also serve as a tool for evaluating the progress. Here are my notes for it, please comment on it. Bernd came up with something like Twitter. That would mean we have a node per person (for example mich...@vysper.tld/tweets) to which other people can subscribe. Whenever I publish a message on my pubsub node, every subscribed person is notified of my message (Publish an Item to a Node 7.1). Please be aware of XEP-0163 - Personal Eventing Protocol(*). Maybe you want to check that we don't implement anything contradicting it. (*) http://xmpp.org/extensions/xep-0163.html This basic setting includes many of the features defined in the XEP-060. We need the possibility to have an open node where everyone can subscribe without authorization, and we need some authorization mechanisms if users don't want to allow everyone per default (covers Affiliations 4.1 and Subscribing to a Node 6.1, and Unsubscribing 6.2). We need means of creating, configuring, and deleting nodes (covers important recommended features 8.1, 8.2, 8.4). The specification requires us to add discovery mechanisms (which features are supported - Discover Node Information 5.3). I think it makes most sense to start with a persistent, payload-included node. This means every subscriber can browse through old messages and a notification of a new message also includes the message. Note that this architecture ensures that everyone has control over his/her messages and downtimes of a single server don't affect others. Of course some features of Twitter won't be easily included. For example there is no way to share one's subscriptions with other people (at least not within XEP-060). Concerning tool support: I don't know many Jabber/XMPP clients that support XEP-060, but there is at least one node-management tool[1] available. Early versions of the extension will be more or less static configured. But let's get started with baby-steps. I'd like to have a request patched through to a mock object of the extension. I'll take my inspiration from the already included XEPs, but Bernd, if you have suggestions for an easier entry tell me ;) What do you think, overall: +1 Concerning tool support: that's a good point. Creating something with smack.jar would be my first idea, if everything else is not feasible. Michael 1: http://x60br.berlios.de/ Maybe xmpp4j (ruby) supports it, too. Bernd
Re: [Vysper] Running example
Michael Jakl wrote: Hi! On Fri, Apr 24, 2009 at 22:49, Bernd Fondermann bf_...@brainlounge.de wrote: Michael Jakl wrote: Please be aware of XEP-0163 - Personal Eventing Protocol(*). Maybe you want to check that we don't implement anything contradicting it. (*) http://xmpp.org/extensions/xep-0163.html Thanks for the suggestion, judging from this quote Note: Any use cases not described herein are described in XEP-0060. Also, this document does not show error flows related to the generic publish-subscribe use cases referenced herein, since they are exhaustively defined in XEP-0060. The reader is referred to XEP-0060 for all relevant protocol details related to the XMPP publish-subscribe extension. This document merely defines a subset or profile of XMPP publish-subscribe. /quote we should have no contradictions if we are XEP-060 compliant. Of course we could take the ideas of XEP-0163 about every account a pubsub service, yet I wouldn't want to reduce the pubsub implementation to personal publishing/eventing alone. It should be nothing more than one aspect which gets us going. Sure. Just wanted to make you aware of it. Bernd
Re: [Vysper] Running example
Ashish wrote: Thanks for the suggestion. Acutally, a tree-like structure would make sense since there are collection nodes (which I didn't plan to implement in the first round) and leaf nodes. We're also discussing persistence services of Vysper within the Labs JIRA (https://issues.apache.org/jira/browse/LABS-354). A node is nothing special, you could visualize it as a virtual user relaying messages sent to it, but of course it has to store a configuration etc. This reminds me of an interesting implementation. Its the infoq.com site implementation, and the site has a presentation on that (http://www.infoq.com/presentations/design-and-architecture-of-infoq) What they did was, they created a Hibernate like means POJO based layer for JCR (Jacrabbit). We can plan for a similar implementation. I don't recall the complete details. We may derive some good practices from it. Interesting. The current storage for Vysper is based on Jackrabbit, too. But it is not fixed to Jackrabbit. For example, you can just switch to in-memory storage for roster and user auth, which of course does not survive a restart. Vcard-temp storage is JCR only, but as soon as somebody adds another impl, you can change that, too. Bernd
Re: [Vysper] Running example
Michael Jakl wrote: Hi! snip/ Michael 1: http://x60br.berlios.de/ This might get interesting... http://thetofu.com/archive/pubsublog_20090307.html Bernd
Re: A new JIRA for VYSPER ?
Emmanuel Lecharny wrote: Wouldn't be better to create a JIRA for VYSPER instead of creating DIRMINA issues ? +1 we are only creating DIRMINAs for the transition. Niklas created a component for this, but I unfortunately failed to set it except for the master issue. I've no karma to create a JIRA project. Maybe infra needs to do that. Also, MINA jiraes are named DIRMINA for historic reasons. Can't we rename that to MINA (dropping the DIR). That would have the bad side effect of breaking archived links in mails. Bernd
Re: [vysper] JIRA
Emmanuel Lecharny wrote: There is already a VYSPER project in jira, I granted Bernd admin karma for it and attached the project to MINA. Thanks Emmanuel. Is there a way to migrate JIRAs - or - should we create a new parent JIRA for every LABS/Vysper JIRA and attach it the original one? Bernd
Re: [Vysper] Maven build
Niklas Gustavsson wrote: Hi I've committed a first draft of a pom.xml for Vysper. So far, it manages to compile and run the tests with Maven. However, there are several issues that needs fixing: * General review of the dependencies (scope, versions, exclusions) * Nekopull not available in Maven repositories. For now, I've uploaded it to people.a.o and sent an email to andyc to see if he knows if it is available in an existing repo. If not, I will have it uploaded to central. * APT report not working. Should be integrated with the apt plugin for Maven, haven't started on this * Release (e.g. licensing, uploading) stuff not at all tested We currently depend on jackrabbit-standalone which dependencies pulls down the entire internet: [INFO] +- org.apache.jackrabbit:jackrabbit-standalone:jar:1.5.3:compile [INFO] | +- javax.jcr:jcr:jar:1.0:compile [INFO] | +- org.apache.jackrabbit:jackrabbit-webapp:jar:1.5.3:compile [INFO] | | +- org.apache.jackrabbit:jackrabbit-core:jar:1.5.3:compile [INFO] | | | +- concurrent:concurrent:jar:1.3.4:compile [INFO] | | | +- commons-collections:commons-collections:jar:3.1:compile [INFO] | | | +- commons-io:commons-io:jar:1.4:compile [INFO] | | | +- org.apache.jackrabbit:jackrabbit-api:jar:1.5.0:compile [INFO] | | | +- org.apache.jackrabbit:jackrabbit-jcr-commons:jar:1.5.3:compile [INFO] | | | +- org.apache.jackrabbit:jackrabbit-spi-commons:jar:1.5.0:compile [INFO] | | | +- org.apache.jackrabbit:jackrabbit-spi:jar:1.5.0:compile [INFO] | | | +- org.apache.lucene:lucene-core:jar:2.3.2:compile [INFO] | | | \- org.apache.derby:derby:jar:10.2.1.6:compile [INFO] | | +- org.apache.jackrabbit:jackrabbit-jcr-server:jar:1.5.2:compile [INFO] | | | \- org.apache.jackrabbit:jackrabbit-webdav:jar:1.5.2:compile [INFO] | | | \- commons-httpclient:commons-httpclient:jar:3.0:compile [INFO] | | \- org.apache.jackrabbit:jackrabbit-jcr-rmi:jar:1.5.0:compile [INFO] | \- commons-cli:commons-cli:jar:1.1:compile What do we really need here? I refrained from pulling single jars in, so I don't know. But I removed the stuff we probably don't need ATM. Maybe we can just go with -core.jar, and maybe we need -jcr-server.jar, too Bernd
Re: [vysper] JIRA
Emmanuel Lecharny wrote: There is already a VYSPER project in jira, I granted Bernd admin karma for it and attached the project to MINA. I moved over all _open_ LABS/Vysper issues to VYSPER, but left closed ones behind. I think this is a balanced approach to have commit logs still referring to the right thing while having all issues we still work on in place here, although 'redirects' seem to work. Do others think otherwise? I also moved DIRMINA-689 to VYSPER. Bernd
Re: Recommended reading: XMPP specs
Emmanuel Lecharny wrote: Do we have a confluence page for VYSPER ? There is some basic note on this at the labs-cwiki-based doc at http://cwiki.apache.org/confluence/display/labs/vysper This content is to be moved to MINA to http://cwiki.apache.org/confluence/display/VYSPER/Index, (setup by Niklas, thanks!). If so, that would be great to mention those 'must read' document on it. Otherwise, a quick page should be added. +1 Patches are welcome! ;-) Bernd
Header stuff
Hi, Anyone from the experienced MINA crew who'd like to comment on http://issues.apache.org/jira/browse/VYSPER-2 Thanks, Bernd
Re: [Vysper] Publish/Subscribe timetable
Michael Jakl wrote: Hi! On Thu, Apr 23, 2009 at 11:54, Bernd Fondermann bf_...@brainlounge.de wrote: Michael Jakl wrote: Until 2009-05-23 my plan would be to continue to explore the current Vysper capabilities as well as to read the XEP-060 in detail. Since this is also the Community Bonding Period, do you have any idea how to get you out of your study and provide some feedback loops? I was thinking about that the last few days. Besides discussing implementation details and providing code-examples (like my first steps yesterday) I can't think of something. Of course, I participate in discussions on the list (at least where I can add something ;)). Do you have something on your mind? I'd define two goals: Structure the spec for implementation (plan) and maybe summarize the parts to involve the rest of the community, so that they get an idea of what it's all about. Creating documentation on confluence would be one possible approach. I'll do that. Currently I'm in the middle of RFC3920, which is (as you said it) absolutely essential for understanding Vysper/XMPP, after that I'll have to reread some parts of XEP-0060. At the coding-front I've set up the handler for the IQ stanzas within the pubsub namespace for normal pubsub stanzas and owner stanzas. Although I haven't yet managed to set up a good test-environment for me. For those not familiar with XMPP, at the top level are three types of stanzas namely presence, message and iq. A stanza is nothing more than a XML element exchanged between XMPP parties. The info/query stanzas are very general and can have different types (like set, get, error, and result). Publish/Subscribe operates within these iq-stanzas. The sub-elements of the iq-stanzas lie within a specific namespace, which can be used to route the stanzas. So far I've registered a handler for the iq-stanzas for the pubsub-extension. Cheers, Michael Bernd
Re: Recommended reading: XMPP specs
On Tue, Apr 28, 2009 at 10:36, Ashish paliwalash...@gmail.com wrote: +1 Patches are welcome! ;-) Will capture them in Wiki. Just trying to figure a way to start working with fresh wiki :-) Not for stopping you, but for your info: please be aware that there is already some cwiki doc at http://cwiki.apache.org/confluence/display/labs/vysper which still has to be moved. Bernd
JIRA notifications
Hi, VYSPER jira notification are not send out anywhere. Anyone have the required karma to set that up? (I haven't appearently.) Otherwise I'll go to infra. @Michael: I've commented on one or two of your issues. Bernd
Re: JIRA notifications
Michael Jakl wrote: Hi! On Tue, Apr 28, 2009 at 10:54, Bernd Fondermann bf_...@brainlounge.de wrote: @Michael: I've commented on one or two of your issues. Thanks. Is there a policy for JIRAs concerning closing/creating new ones? Like VYSPER-26[1], should I close it and make a new one like this Split existing pubsub handlers in smaller ones or should we close VYSPER-26 only when we are fully satisfied with the outcome? It depends. In this case we could reuse the JIRA. I propose you close issues as you see them fully covered and committed. Bernd
Re: [Vysper] Porting to MINA 2.0 M5
Ashish wrote: Work in a branch. It it works, fine. Maybe we can also tag the current version, and move to a new version from this tag. +1 to make the migration on a branch. I expect troubles which should not interfere with other work. Let's stabilize the MINA2.0 branch and then merge back. Should be not too much conflicting code. Hmm.. I think we shall release Vysper with latest MINA version? So tagging should be fine. I don't get what this tag is all about? Bernd: Want to take a call on this? I think I can't tag now, as I have coded on trunk :-( So if someone else can move the code to tag will be great. I don't understand that. If you have local changes you still could create a branch using URLs, couldn't you? I am fine on branch strategy as well. Since I now I know the changes, so it shall not be too much of a work :-) +1. On a similar note, April 2009 was the most active month for MINA community, since Nov 2007. We had a total of 861 messages on our ML's. That's good. But remember that people might get annoyed by increased off-topic ML traffic and might drop out (those interested only in MINA and not in Vysper). Make sure to monitor subscription figures, too and eventually fork lists. Bernd
Re: [Vysper] Porting to MINA 2.0 M5
Ashish wrote: Work in a branch. It it works, fine. Maybe we can also tag the current version, and move to a new version from this tag. Hmm.. I think we shall release Vysper with latest MINA version? So tagging should be fine. There is already a JIRA for it, VYSPER-23. Bernd
Re: [vysper] JIRA
Niklas Gustavsson wrote: On Mon, Apr 27, 2009 at 10:44 AM, Niklas Gustavsson nik...@protocol7.com wrote: On Mon, Apr 27, 2009 at 10:29 AM, Emmanuel Lecharny elecha...@apache.org wrote: Niklas Gustavsson wrote: Great! Should we set up the same authorizations as for the MINA and FTPSERVER project where the MINA PMC members has admin rights? I think so. Basically, we have a few person having admin rights on JIRA, including the chairman, the project owner and a couple of peeps. We should grant committers write access to the VYSPER jira. Yeah, I think we should copy the setup from the MINA project. Anyone with sufficient karma that have a time to do this? There is no 'setup' in a way that there is a group defined like 'mina-administrators' (like there is 'directory-administrators' for example). So copying is cumbersome and doesn't make much sense to me. I'd suggest MINA creates a JIRA admins group. Otherwise we'd have to single select every committer for every MINA-related JIRA project. I currently don't have any access to assign nor change the state of Vysper issues. That should have changed meanwhile. I added some people to the project as admins. Please anybody give me hint who's still missing karma. Bernd
Re: [Vysper] Porting to MINA 2.0 M5
Ashish wrote: Work in a branch. It it works, fine. Maybe we can also tag the current version, and move to a new version from this tag. +1 to make the migration on a branch. I expect troubles which should not interfere with other work. Let's stabilize the MINA2.0 branch and then merge back. Should be not too much conflicting code. Hmm.. I think we shall release Vysper with latest MINA version? So tagging should be fine. I don't get what this tag is all about? Bernd: Want to take a call on this? I think I can't tag now, as I have coded on trunk :-( So if someone else can move the code to tag will be great. I don't understand that. If you have local changes you still could create a branch using URLs, couldn't you? Got it. Not a master on SVN :-( community, since Nov 2007. We had a total of 861 messages on our ML's. That's good. But remember that people might get annoyed by increased off-topic ML traffic and might drop out (those interested only in MINA and not in Vysper). Make sure to monitor subscription figures, too and eventually fork lists. Can't monitor the Subscribers figures (don't have privileges). We need to wait for MINA Board report for these details. So you'd might be interested in tracking this page http://people.apache.org/~coar/mlists.html Either ways, having an active community is very important for an Open Source project. It forms one of the evaluation criteria for User's. Its an assurance that if there are any problem, they will be addressed. +1 From my POV, it's an input to COTS Usage Risk Analysis, that is being done before actually using the library. Bernd
Re: [Vysper] Porting to MINA 2.0 M5
Emmanuel Lecharny wrote: Can't monitor the Subscribers figures (don't have privileges). We need to wait for MINA Board report for these details. So you'd might be interested in tracking this page http://people.apache.org/~coar/mlists.html Sadly, it's not up to date... isn't it? then the date timestamp on top is wrong :-( Bernd
Re: Header stuff
On Tue, May 5, 2009 at 09:47, Julien Vermillard jvermill...@archean.fr wrote: Le Tue, 28 Apr 2009 14:04:32 +0530, Ashish paliwalash...@gmail.com a écrit : On Tue, Apr 28, 2009 at 1:53 PM, Bernd Fondermann bf_...@brainlounge.de wrote: Hi, Anyone from the experienced MINA crew who'd like to comment on http://issues.apache.org/jira/browse/VYSPER-2 These are same, its my SVN client (Tortoise SVN) that hasn't updated these tags. See this http://svnbook.red-bean.com/en/1.1/ch07s02.html I think I did put this up http://mina.markmail.org/message/rpucxhis34aaktz2?q=from:Ashish+date:200904+page=2 Any help is appreciated, to help me fix this issue with my SVN client. I start to dislike all those SVN code tags, it's just annoying to setup and not really useful for me. Perhaps we could drop them ? +1 from me, but I arrived here only recently - maybe when properly assimilated I will start to love them. But probably not. Bernd
Re: Logs in the chain ?
On Wed, May 6, 2009 at 19:41, Ashish paliwalash...@gmail.com wrote: as it seems that everybody want to get rid of the svn tags, I guess someone will go through all the files to remove them. Isn't it a perfect timing to propose another transverse addition ? I would like to add some log in all the filters It's always a PITA to debug an application with some filters, as we have no idea what's going on internally. What would be very helpful is to have a log trace containing the session ID for each method of each filter we have. Currently, if we except the LoggingFilter, we have nothing, nada, rien... wdyt ? Sounds like the need for AOP to me. Bernd
Re: [Vysper] Hudson builds now running
On Wed, May 6, 2009 at 22:56, Niklas Gustavsson nik...@protocol7.com wrote: Hi I've set up Vysper to build in the Hudson CI server using the Maven build: http://hudson.zones.apache.org/hudson/view/Vysper/ For now, it's building on Sun JDK 1.5 and 1.6 on Solaris and Ubuntu and IBM JDK 1.5 and 1.6 on Ubuntu. There is also Harmony JVM available but I did not set up a build for it as it currently doesn't work with MINA due to Harmony bugs in its NIO implementation. Let me know if you want any improvements to this set up. /niklas Great, many thanks, Niklas! Bernd
Re: Logs in the chain ?
On Thu, May 7, 2009 at 09:35, Emmanuel Lecharny elecha...@apache.org wrote: Bernd Fondermann wrote: On Wed, May 6, 2009 at 19:41, Ashish paliwalash...@gmail.com wrote: as it seems that everybody want to get rid of the svn tags, I guess someone will go through all the files to remove them. Isn't it a perfect timing to propose another transverse addition ? I would like to add some log in all the filters It's always a PITA to debug an application with some filters, as we have no idea what's going on internally. What would be very helpful is to have a log trace containing the session ID for each method of each filter we have. Currently, if we except the LoggingFilter, we have nothing, nada, rien... wdyt ? Sounds like the need for AOP to me. I didn't want to pronounce this evil buzz word ... Seriously, you are right, but having experienced some kind of AOP in Directory, I would not use it again even if someone pays me :) AOP : good ideas, crappy implementation + lots of complexity for just logging... ok, then I did every right by staying away from it all the time. :-) Bernd
Re: Got some error when compiling SSHd
Emmanuel Lecharny wrote: Hi guys, just before leaving for a long week-end, I tried to build all the MINA code. I get some error when compiling sshd. Can someone check ? Thanks ! mvn install works fine for me. What about a helpful error description! What do you do? What error do you get? Thanks, and: Have fun! Bernd
Re: Got some error when compiling SSHd
Hi Emmanuel, this is a known (at least to me) problem with mvn on wndws. Just make sure that the text file is deleted. HTH, Bernd Emmanuel Lecharny wrote: Sorry for the lack of information. I was in a hurry, didn't had time to copy/paste the log. Here is what I get on a slow windows machine : ... [ERROR] BUILD ERROR [INFO] [INFO] Failed to delete directory: C:\mina\sshd\sshd-core\target. Reason: Unable to delete file C:\mina\sshd\sshd-core\target\surefire-reports\org.apache.sshd.C lientTest.txt [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 10 seconds [INFO] Finished at: Thu May 07 15:48:20 CEST 2009 [INFO] Final Memory: 9M/17M [INFO] On Thu, May 7, 2009 at 12:33 PM, Guillaume Nodet gno...@gmail.com wrote: It works for me too. Please post some details. On Thu, May 7, 2009 at 12:20, Bernd Fondermann bf_...@brainlounge.de wrote: Emmanuel Lecharny wrote: Hi guys, just before leaving for a long week-end, I tried to build all the MINA code. I get some error when compiling sshd. Can someone check ? Thanks ! mvn install works fine for me. What about a helpful error description! What do you do? What error do you get? Thanks, and: Have fun! Bernd -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Header stuff
Emmanuel Lecharny wrote: Ashish wrote: Funny enough, you don't need network to do svn info pom.xml ;-) so +1 for removing Maarten +1 I have removed all the @version from MINA, SSHD and AsyncWeb. Still have to remove those from FtpServer. When it will be done, I will commit if nobody complains. Note : We also have to use the same @author tags everywhere. SSHd uses : @author a href=mailto:dev@mina.apache.org;Apache MINA SSHD Project/a FtpServer uses : @author The Apache MINA Project (dev@mina.apache.org) MINA uses : @author The Apache MINA Project (dev@mina.apache.org) AsyncWeb still have personal author's tags like : @author a href=mailto:adr...@ephox.com;Adrian Sutton/a In this case, we have to do three things : 1) check that those authors are Apache committers 2) check that the code was either committed as a part of the project or as a part of an ASL 2.0 compliant project 3) if they are external (ie, ASL 2.0 compliant license project), then we have to check that the notice.txt contains the correct attribution For 2) and 3), where the origin of the code is not at the ASF covered by and *CLA, my understanding is that there should be either an IP grant on file or a corresponding JIRA with a checked ASF-license box. Nevertheless, the author tags could be removed altogether, because they are not a copyright (the original author retains copyright anyway, it is irrevokable AFAIK) or a licensing statement. In any case, we should use the same tag formet (SSHd format ios probably more convenient, if we consider Javadoc). +1 Bernd
Re: Header stuff
Michael Jakl wrote: Hi! On Tue, May 12, 2009 at 08:54, Bernd Fondermann bf_...@brainlounge.de wrote: Emmanuel Lecharny wrote: Note : We also have to use the same @author tags everywhere. SSHd uses : @author a href=mailto:dev@mina.apache.org;Apache MINA SSHD Project/a FtpServer uses : @author The Apache MINA Project (dev@mina.apache.org) MINA uses : @author The Apache MINA Project (dev@mina.apache.org) AsyncWeb still have personal author's tags like : @author a href=mailto:adr...@ephox.com;Adrian Sutton/a In this case, we have to do three things : 1) check that those authors are Apache committers 2) check that the code was either committed as a part of the project or as a part of an ASL 2.0 compliant project 3) if they are external (ie, ASL 2.0 compliant license project), then we have to check that the notice.txt contains the correct attribution For 2) and 3), where the origin of the code is not at the ASF covered by and *CLA, my understanding is that there should be either an IP grant on file or a corresponding JIRA with a checked ASF-license box. Nevertheless, the author tags could be removed altogether, because they are not a copyright (the original author retains copyright anyway, it is irrevokable AFAIK) or a licensing statement. I was to support your suggestion, but after a second thought the author tag might have a benefit. Since everybody has the right to copy and use the code, it could be all over the internet, with the author tag it's clear where the code comes from (even if Google points to some class deep down the hierachy). Actually, it already _is_ all over the internet (at least for the MINA case :-). I intended to refer to _individual_ author tags, not the ML author tag, which I think is should stay. On the other hand, removing redundancies (since it's the same information everywhere) is also a good thing. In any case, we should use the same tag formet (SSHd format ios probably more convenient, if we consider Javadoc). +1 dev@mina.apache.org is a mailinglist, so it *might* not be the best address to add without further notice (how to subscribe to it for example). It isn't possible to send a mail to dev@mina.apache.org without subscribing, is it? It is possible, but the posting won't go through directly, it is subject to moderation. That's how most m...@asf work. I'd propose something like this: @author a href=http://mina.apache.org;Apache MINA Project/a At the homepage is everything one could possibly need (source, documentation, and contact information). I don't know if it's better to point to the subproject or not, though. Maybe there have already been extensive discussions about this in the past, but we should give that a second thought. The website will stay, while mailing lists for projects (sometimes) change, as projects grow and MLs are forked. Essentially, I am fine with both approaches. Bernd
Re: Got some error when compiling SSHd
On Tue, May 12, 2009 at 05:16, Emmanuel Lecharny elecha...@apache.org wrote: Guillaume Nodet wrote: It works for me too. Please post some details. On Thu, May 7, 2009 at 12:20, Bernd Fondermann bf_...@brainlounge.de wrote: Emmanuel Lecharny wrote: Hi guys, just before leaving for a long week-end, I tried to build all the MINA code. I get some error when compiling sshd. Can someone check ? Thanks ! mvn install works fine for me. Works now on linux... Strange :/ No, not at all. Linux has no file lock as Windows has, so the problem should not appear there. Bernd
Re: JIRA notifications
Ping? Should I go to Infra? Bernd Bernd Fondermann wrote: Hi, VYSPER jira notification are not send out anywhere. Anyone have the required karma to set that up? (I haven't appearently.) Otherwise I'll go to infra. @Michael: I've commented on one or two of your issues. Bernd
Re: JIRA notifications
On Wed, May 13, 2009 at 19:10, Emmanuel Lecharny elecha...@apache.org wrote: Bernd Fondermann wrote: Ping? Should I go to Infra? It's fixed now. Thanks! The resolve-notification for VYSPER-17 reached me, but not the list (at least until now). Maybe stuck in moderation? Out of curiosity, what did you have to do to make this happen? Bernd
Re: JIRA notifications
Bernd Fondermann wrote: On Wed, May 13, 2009 at 19:10, Emmanuel Lecharny elecha...@apache.org wrote: Bernd Fondermann wrote: Ping? Should I go to Infra? It's fixed now. Thanks! The resolve-notification for VYSPER-17 reached me, but not the list (at least until now). Maybe stuck in moderation? It arrived now! Bernd
Re: [Vysper] Running example
Michael Jakl wrote: Hi! On Fri, Apr 24, 2009 at 22:49, Bernd Fondermann bf_...@brainlounge.de wrote: Concerning tool support: that's a good point. Creating something with smack.jar would be my first idea, if everything else is not feasible. smack got pubusb support: http://www.igniterealtime.org/community/thread/38433 Cool! I've opened VYSPER-59 related to this. Bernd
Re: svn commit: r774819 - /mina/sandbox/vysper/trunk/src/test/java/org/apache/vysper/xmpp/xmldecoder/XMLParticleTestCase.java
Emmanuel Lecharny wrote:
IMO, it would be better to use \u notation in your String to avoid such
problems. I'm using UTF-8 encoding as a default on my IDE, and if one
developer is using something different (ie, ISO8859-1, for instance),
that will be a big problem.
In this case, the code should be :
assertFailureOpeningElementName(()\u00c2§$%/);
+1
Thanks for the suggestion.
In fact, thinking a little bit more about this, I lean towards looking
into the history of this line to see what was intented to be tested
here, exactly.
Bernd
ber...@apache.org wrote:
Author: berndf
Date: Thu May 14 15:22:39 2009
New Revision: 774819
URL: http://svn.apache.org/viewvc?rev=774819view=rev
Log:
[vysper] restore garbled chars from r774707
Modified:
mina/sandbox/vysper/trunk/src/test/java/org/apache/vysper/xmpp/xmldecoder/XMLParticleTestCase.java
Modified:
mina/sandbox/vysper/trunk/src/test/java/org/apache/vysper/xmpp/xmldecoder/XMLParticleTestCase.java
URL:
http://svn.apache.org/viewvc/mina/sandbox/vysper/trunk/src/test/java/org/apache/vysper/xmpp/xmldecoder/XMLParticleTestCase.java?rev=774819r1=774818r2=774819view=diff
==
---
mina/sandbox/vysper/trunk/src/test/java/org/apache/vysper/xmpp/xmldecoder/XMLParticleTestCase.java
(original)
+++
mina/sandbox/vysper/trunk/src/test/java/org/apache/vysper/xmpp/xmldecoder/XMLParticleTestCase.java
Thu May 14 15:22:39 2009
@@ -39,7 +39,7 @@
public void testWrongOpeningElementName() {
assertFailureOpeningElementName();
-assertFailureOpeningElementName(()�$%/);
+assertFailureOpeningElementName(()§$%/);
assertFailureOpeningElementName( space-prefixed /);
assertFailureOpeningElementName(-prefixed);
}
Re: [Vysper] Whole Server as Pubsub service
Michael Jakl wrote: Hi! I've started with the disco(very) implementation yesterday. There seem to be two possible ways of implementing disco, and the pubsub extension at large. The Pubsub Module is a subclass of DefaultDiscoAwareModule, which provides three method-stubs to deal with disco: - addInfoRequestListeners - addServerInfoRequestListeners - addItemRequestListeners The ServerInfoRequest is for server-features. The Pubsub module could identify the server addtionally as pubsub service. Meaning we have an additional identity and feature element (see XEP-0030 3.1[1] and XEP-0060 5.1[2]). This is the way to go. The InfoRequest returns the disco information for a particular node. The Pubsub module could be addressable by its own JID inside the server. pubsub.vysper.org or something. Not quite. 'pubsub.vysper.org' is a completely different /domain/ than 'vysper.org'! There is no inclusion relationship defined for xmpp domains related to domain names. so the pubsub.shakespeare.lit in the spec is equivalent to 'vysper.org'. The difference between ServerInfoRequest and InfoRequest is, that the server has either no to JID or no node associated (and the server-entity matches the to address). The ItemRequest (for completeness) returns either the associated nodes (service) or all items (node). The question thus is, should I enhance the server with the pubsub service, or provide an additional entity within the server? I tend towards the first option, but I'm not quite sure. What would you suggest? How would implementing the second option make the pubsub feature discoverable? There'd have to be a kind of redirect from vysper.org to pubsub.vysper.org, which doesn't exist, AFAIK. Is that answering your question? Bernd
Re: [Vysper] Whole Server as Pubsub service
Michael Jakl wrote:
Hi!
On Fri, May 15, 2009 at 14:26, Bernd Fondermann bf_...@brainlounge.de wrote:
Michael Jakl wrote:
The InfoRequest returns the disco information for a particular node.
The Pubsub module could be addressable by its own JID inside the
server. pubsub.vysper.org or something.
Not quite. 'pubsub.vysper.org' is a completely different /domain/ than
'vysper.org'! There is no inclusion relationship defined for xmpp
domains related to domain names. so the pubsub.shakespeare.lit in the
spec is equivalent to 'vysper.org'.
Seems I was wrong. See XEP0030/4.1/Example 12.
The answers comes from 'shakespeare.lit' but announces items at
'people|plays.shakespeare.lit'.
iq type='result'
from='shakespeare.lit'
to='ro...@montague.net/orchard'
id='items1'
query xmlns='http://jabber.org/protocol/disco#items'
item jid='people.shakespeare.lit'
name='Directory of Characters'/
item jid='plays.shakespeare.lit'
name='Play-Specific Chatrooms'/ ...
The pubsub service can also be addressed as pub...@shakespeare.lit
instead of pubsub.shakespeare.lit.
Initial discovery can only happen on the 'server node', like
'vysper.org', can't it? Otherwise, the client would have to guess.
So, now rereading some of XEP 30 + 60, the client would need to send a
info request to all nodes *.shakeskpeare.lit, to inspect if any has the
pubsub feature. If the domain itself announces pubsub as a feature,
maybe this will yield problems later, maybe not.
For now, I would go on with making it configurable which entity it
announces pubsub on (vysper.org, ${pubsub_identifier}.vysper.org or
${pubsub_identifi...@vysper.org). Don't know if we need more than one
announcement (for different or same pubsub service).
Hence I thought about a virtual
service within the vysper server. Using this addressing scheme
(pub...@shakespeare.lit), the server info request would be
problematic, wouldn't it?
Not as long as it'd yield an item 'pub...@shakespeare.lit'.
In my understanding, the server would have to report the virtual
pubsub service as node of category pubsub and type service during
discovery.
+1
I think it's up to us how we implement it, and since we agree, it will
be a feature of the server (hence, not a virtual service).
Is that answering your question?
Yes, thank you,
Michael
Bernd
Re: [jira] Updated: (VYSPER-51) Discovery for Leaf Nodes (XEP-0060 5.3)
Michael Jakl (JIRA) wrote: [ https://issues.apache.org/jira/browse/VYSPER-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jakl updated VYSPER-51: --- Attachment: VYSPER-51.1.patch The patch corrects the disc#info integration of the pubsub module. Applied. For pubsub, more disco listeners are needed, right? Have you thought about how to do this already? disco#items will be completed after the node-creation and storage tasks have been solved. This task will hence be postponed. I don't understand the last sentence. How does storage tasks play a role here? Bernd
[vysper] Pubsub code organization
Hi, For the pubsub module, I'd propose to + move the 'general' and 'owner' package to 'handler', or, alternatively, move the handler classes they contain to two new 'handler' sub-packages respectively. + rename test case classes to *TestCase or *Test so they are clearly identifyable as such by their name. If you use a view where all classes from one package are shown together even if they are on different dirs, this would be a big help. WDYT? Bernd
Re: [vysper] Pubsub code organization
Michael Jakl wrote: Hi! On Sat, May 16, 2009 at 22:52, Bernd Fondermann bf_...@brainlounge.de wrote: For the pubsub module, I'd propose to + move the 'general' and 'owner' package to 'handler', or, alternatively, move the handler classes they contain to two new 'handler' sub-packages respectively. +1, I wasn't happy with general anyways. What about .handler for the current general package and .handler.owner for the #owner namespace? +1 I can do it, if this proves to be too cumbersome to do in a patch. + rename test case classes to *TestCase or *Test so they are clearly identifyable as such by their name. If you use a view where all classes from one package are shown together even if they are on different dirs, this would be a big help. +1, the ant task will also profit from the right naming. Great, thanks. Bernd
Re: [jira] Updated: (VYSPER-51) Discovery for Leaf Nodes (XEP-0060 5.3)
Michael Jakl wrote: Hi! On Sat, May 16, 2009 at 22:44, Bernd Fondermann bf_...@brainlounge.de wrote: Michael Jakl (JIRA) wrote: The patch corrects the disc#info integration of the pubsub module. Applied. For pubsub, more disco listeners are needed, right? Have you thought about how to do this already? No, I haven't thought much of additional listeners. Currently the service reports the right identity and feature. The disco#info for nodes etc. is pending. disco#items will be completed after the node-creation and storage tasks have been solved. This task will hence be postponed. I don't understand the last sentence. How does storage tasks play a role here? Sorry, I was unclear. A disco#items request to the service returns all pubsub nodes associated with the service. For example the RSS-node for slashdot and my Twitter-like node are reported. How to retrieve the nodes and access them is not yet fixed so I'll postpone the discovery task until I have a good picture of how I access and retrieve node information. storage might be misleading here. I think it's time to plan and discuss about internal representation of items and all the other data held within the pusub module. Do some bottom up OO engineering. How that will be taken up by the handlers will later more or less fall into place. Bernd
Re: [vysper] Pubsub code organization
On Sat, May 16, 2009 at 23:09, Michael Jakl jakl.mich...@gmail.com wrote: Hi! On Sat, May 16, 2009 at 23:07, Bernd Fondermann bf_...@brainlounge.de wrote: Michael Jakl wrote: I can do it, if this proves to be too cumbersome to do in a patch. Done already. But Eclipse (Subversion?) doesn't recognize renamings and move operations so the patch is quite large :( r775668+9 contain changes equivalent to your patch. please check and report problems. maybe you need to revert your local changes to continue your work. Bernd
Re: svn commit: r771618 - /mina/sandbox/vysper/branches/MINA2.0/
All or most files have been changed. I'd recommend to re-create the branch to reduce merge efforts later. Bernd apali...@apache.org wrote: Author: apaliwal Date: Tue May 5 08:28:26 2009 New Revision: 771618 URL: http://svn.apache.org/viewvc?rev=771618view=rev Log: To port Vysper to MINA 2.0 Submitted By: Ashish Paliwal (apaliwal.at.apache.org) Added: mina/sandbox/vysper/branches/MINA2.0/ - copied from r771617, mina/sandbox/vysper/trunk/
Re: [vysper] Pubsub code organization
Michael Jakl wrote: Hi! On Sun, May 17, 2009 at 20:14, Bernd Fondermann bernd.fonderm...@googlemail.com wrote: r775668+9 contain changes equivalent to your patch. please check and report problems. maybe you need to revert your local changes to continue your work. Thanks for the notice, unfortunately I've already messed up my working copy (real bad). If you don't have too much pending work which is not stored anywhere else, I recommend removing the bad dirs and then do svn update. Bernd
Re: svn commit: r771618 - /mina/sandbox/vysper/branches/MINA2.0/
Ashish wrote: All or most files have been changed. I'd recommend to re-create the branch to reduce merge efforts later. Feel free to create one. I am yet to start work on it. Tied with my work right now. So, should I remove the branch and we'll create it again when somebody is actually going to work on it, how does that sound? I see no point in an aging branch nobody is committing to. Bernd
Re: svn commit: r771618 - /mina/sandbox/vysper/branches/MINA2.0/
Emmanuel Lecharny wrote: Bernd Fondermann wrote: Ashish wrote: All or most files have been changed. I'd recommend to re-create the branch to reduce merge efforts later. Feel free to create one. I am yet to start work on it. Tied with my work right now. So, should I remove the branch and we'll create it again when somebody is actually going to work on it, how does that sound? I see no point in an aging branch nobody is committing to. Having done such a move (for Directory, 1.1.7 - 2.0.0), my experience is that it should be done in one shot, when you have time to do it. In my case, it took 2 months because I was quite busy and there were deadly bugs in MINA I had to fix. But as MINA has stabilized since then, my estimation of a move to MINA 2.0 is that it should take a couple of days, may be less if you know how MINA work. Probably less than a few hours too. So just do it in a branch *when* you are ready to do the migration (you = anyone feeling the mood and having the time to do the migration). The MINA code in Vysper is only a small portion of the code.Doing this as a side-project should not be as critical as refactoring over the whole codebase. Steady re-integration of TRUNK into the branch should help reducing pains, too. In the mean time, it's probably better to delete the branch. Dead wood is heavy to carry :) +1. done. Bernd
Re: [jira] Updated: (VYSPER-51) Discovery for Leaf Nodes (XEP-0060 5.3)
Michael Jakl wrote: Hi! On Sun, May 17, 2009 at 00:44, Bernd Fondermann bf_...@brainlounge.de wrote: I think it's time to plan and discuss about internal representation of items and all the other data held within the pusub module. Do some bottom up OO engineering. How that will be taken up by the handlers will later more or less fall into place. Essentially we have to deal with three types of objects: - Node - User - Message We have two types of nodes, a) CollectionNode and b) LeafNode. Collection nodes are optional, so I will omit them for now. A LeafNode contains its configuration and meta-data. This would be the name, type etc. The LeafNode also knows its owners, publishers, banned users and members as well as the pending, unconfigured, and subscribed users. The Node is responsible for serializing itself to the appropriate stanzas (info, items, subscriptions etc). A LeafNode comes in various types (like PersistentNode, TransientNode etc. see XEP-0060 4.3, Table 4). A User can have several roles in a Node. So I'd introduce a User class for storing the user-information and a NodeUser class (dynamically linked to the User) for inclusion within the nodes. The NodeUser has Owner, Publisher, Outcast, and Member subclasses defining the permissions of the user in association with the Node. The Message class simply stores a message. Class-hierarchy: Node LeafNode PersistentNotificationNode TransientNotificationNode PersistentPayloadNode TransientPayloadNode CollectionNode User NodeUser Owner Publisher Member Outcast Message Dynamic model (classes in squared brackets are collection types): Node: Name:String ...MetaData... LeafNode: [Owner] [Publisher] [Member] [Outcast] Pending:[NodeUser] Unconfigured:[NodeUser] Subscribed:[NodeUser] [Message] ...MetaData... CollectionNode: [Node] User: JID:Entity or String NodeUser User Owner Publisher Member Outcast Message Content:String or XMLElement I hope the textual explanation makes sense. I think this is a useful model and will fit nicely in the current handler model. I'm a bit uncertain with the redundant storage of the user-states and roles. On one hand, we could throw each type in the pending, unconfigured, and subscribed collections and search through the lists to check if some user has the right to publish to the node (or change it...). Another alternative is to store everything in the owner, publisher, member, and outcast collections and search through it to collect pending and unconfigured users. I've chosen the middle ground with storing both informations in their respective collections which might benefit the performance when a large number of users are subscribed. To check whether a user is one of the owners of a node, all I have to do is go through the owners list. To send a message to all subscribed users, I'd go through the subscribed list and trigger the, say, sendMessage (or so) method. I think explaining the interactions between the objects takes up more time than to implement it, but essentially each object is responsible to create the stanzas the handler requests. Some details surely will change when implementing it, but roughly this is how I'd do it right now. WDYT? From what I read in the spec so far this sounds good. Maybe I'd not model the user roles as subclassas but as an enum type, but this is already too implementation specific. What also needed are some higher level objects like a NodeRegistry and the like. I'll continue to read the spec and give feedback as you go. Bernd
Re: Incremental/dependent patches
Michael Jakl wrote: Hi! I've just uploaded a patch for some PubSub/Vysper feature. If I'd continue to work on the sources wouldn't I come into troubles creating the next patch? How do you deal with such a situation? Currently I just wait until the patch is applied and work on afterwards, but that won't work well when I've got more time for it. Incremental patches should work fine. If svn client encounters a local change which fits to the update delta (the patch coming in from the server) it is happy. If the local version has additional changes, there might be conflicts which can be merged automagically by svn (displaying a G instead of U for the file in the update log) or you have to resolve the conflict manually (C), which is also pretty nifty in IDEA. Is there a Subversion command to create a patch from some savepoint on? Not that I'm aware of. I use Intellij IDEA, which supports this poor- man's-git feature (called changelists). I don't know about Eclipse. Or should I create another full patch against HEAD? If you create a full, aggregated patch, I'm happy too. Bernd
Re: [jira] Commented: (VYSPER-52) Subscribe to a Node (XEP-0060 6.1)
Michael Jakl (JIRA) wrote: [ https://issues.apache.org/jira/browse/VYSPER-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12712012#action_12712012 ] Michael Jakl commented on VYSPER-52: Thanks for the hint, I'll consider this when I integrate the sotrage providers. I usually *try* to start with the easiest thing that could possibly work. Sure, I'll just drop in comments as I become aware of something, otherwise I forget it later. Bernd
Re: [jira] Commented: (VYSPER-52) Subscribe to a Node (XEP-0060 6.1)
Michael Jakl (JIRA) wrote: [ https://issues.apache.org/jira/browse/VYSPER-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12712014#action_12712014 ] Michael Jakl commented on VYSPER-52: You changed the order of the imports, is this on purpose, or some automatic IDEA thing? Sorry, this was not intended. I switched off 'optimize imports on the fly', so we don't run into unnecessary conflicts in the future. Thanks for the hint. Bernd Mine: import java.util.Map; import java.util.TreeMap; import org.apache.vysper.xmpp.addressing.Entity; Repo: import org.apache.vysper.xmpp.addressing.Entity; import java.util.Map; import java.util.TreeMap; Subscribe to a Node (XEP-0060 6.1) -- Key: VYSPER-52 URL: https://issues.apache.org/jira/browse/VYSPER-52 Project: VYSPER Issue Type: Sub-task Reporter: Michael Jakl Assignee: Michael Jakl Attachments: VYSPER-52.1.patch Example 30. Entity subscribes to a node iq type='set' from='franci...@denmark.lit/barracks' to='pubsub.shakespeare.lit' id='sub1' pubsub xmlns='http://jabber.org/protocol/pubsub' subscribe node='princely_musings' jid='franci...@denmark.lit'/ /pubsub /iq 6.1.2 Success Case If the subscription request is successfully processed, the server MUST inform the requesting entity that it is now subscribed (which MAY include a service-generated SubID). Example 31. Service replies with success iq type='result' from='pubsub.shakespeare.lit' to='franci...@denmark.lit/barracks' id='sub1' pubsub xmlns='http://jabber.org/protocol/pubsub' subscription node='princely_musings' jid='franci...@denmark.lit' subid='ba49252aaa4f5d320c24d3766f0bdcade78c78d3' subscription='subscribed'/ /pubsub /iq
Re: Incremental/dependent patches
Michael Jakl wrote: Hi! On Fri, May 22, 2009 at 07:36, Bernd Fondermann bf_...@brainlounge.de wrote: Michael Jakl wrote: I've just uploaded a patch for some PubSub/Vysper feature. If I'd continue to work on the sources wouldn't I come into troubles creating the next patch? How do you deal with such a situation? Currently I just wait until the patch is applied and work on afterwards, but that won't work well when I've got more time for it. Incremental patches should work fine. If svn client encounters a local change which fits to the update delta (the patch coming in from the server) it is happy. If the local version has additional changes, there might be conflicts which can be merged automagically by svn (displaying a G instead of U for the file in the update log) or you have to resolve the conflict manually (C), which is also pretty nifty in IDEA. Is there a Subversion command to create a patch from some savepoint on? Not that I'm aware of. I use Intellij IDEA, which supports this poor- man's-git feature (called changelists). I don't know about Eclipse. Or should I create another full patch against HEAD? If you create a full, aggregated patch, I'm happy too. Thanks for the explanation, I'm currently not eligible for a free IDEA license (and I'm very used to Eclipse). Well, maybe you are eligible :-) http://www.jetbrains.com/idea/buy/buy.jsp#openSource ASF committers definitively are. Thanks to Jetbrains, by the way! :-) Anyway, changing working environments can be a pain and should not be a precondition to providing patches. ;-) I'll see what I can do, maybe I just create a private mirror of the repository or something like that if things get too hairy. I'd think we won't get into this kind of hairy situation. Currently our work-cycle is working very well. +1 Bernd
[vysper] some handy utilities added
Hi, I've added two important utils to the server code, data forms (XEP-0004) and date time profile (XEP-0082) and en passant added support for XEP-0128. Both are used by many XEPs, and I came across them reading the PubSub spec. Data Forms provide a universal mechanism to communicate arbitrary 'data structures' between two entities (for example client/server) within a stanza. They are a mixture of HTML tables, HTML forms and XML-RPC parameter lists, at least sort of. XEP-0082 defines text formatting for dates and times. I factored out a utility class to handle that in a conformant way, so any impl can make use of it. Bernd
Re: [vysper] Any reason to still use an antic version of MINA?
Emmanuel Lecharny wrote: Hi guys, even if VYSPER is still based on 1.1 version instead of 2.0, can't we bump up the version from 1.1.0 to 1.1.7? +1, there you go... ;-) Bernd
Re: [Vysper] Moving to the Maven build
On Tue, May 26, 2009 at 11:57, Emmanuel Lecharny elecha...@apache.org wrote: Niklas Gustavsson wrote: Hi Should we drop the Vysper Ant build in favour of the Maven build? Right now we have two build systems to maintain, which will cause confusion and end up being out of sync. Do we need a vote for this, or should we just svn del build.xml? I don't think we need a vote, just an agreement from Bernd. I would favor a maven build and a removal of the ant build. It will allow us to remove the libs rom svn too. I'm not pro or con a specific build tool, but I think, for any Apache project, not having its libraries accessible in SVN somewhere near the code is bad. Libraries are hard dependencies, but tools like mvn (and others) treat them like soft dependencies. What if repos get lost? Or are compromised? Given the number of artifacts and their transient dependencies, this will happen sooner or later (or has already happened without getting noticed). mvn is much more easy to get a build up and running and add features like reporting, etc. that's a huge advantage over ant. Also, I work a lot without online Internet access. mvn is more of a pain then than it is normally. (Yes, I know about offline modes etc.) So while I don't oppose mvn as a tool, it doesn't free us from our reponsabilities to make our software available not only today, but also in the future. That said, I'm somewhere between -0 and +0 for the switch. Bernd
