Re: ASk for a feedback

[G.W.G.K.N. Udayanga]

Hello Bernard Sir,
Thank you very much for your support.I know that the time to discuss about
the project is now over.But if you can please consider about following
things.


You question:What would you want to remove? What would be unwanted stanzas?
What do you think is a stanza at all?

*Stanza is same as xml.(actually another name use in xmpp world).
*Here as the removable stanzas i mean xml tags such as ,
,   and so on which are used for initial  handshaking when
dealing with xmpp.

Another one that i didn't get answer from your reply.

Ajax clients send requests by using url encrypting also(other than the types
of xml document)But for the bosh protocol only xml is allowable as
payload.So do we need to process  url encryped requst of ajax client  as a
xml formatted one before using bosh protocol?

thank you,
G.W.G.K.N.Udayanga
Dept of Computer Science and Engineering
University of Moratuwa
Sri Lanka

>
>
>

Re: svn commit: r928769 - in /mina/ftpserver/trunk/core/src: main/java/org/apache/ftpserver/config/spring/ main/java/org/apache/ftpserver/ipfilter/ main/java/org/apache/ftpserver/listener/ main/java

[Sai Pullabhotla]

BTW, do you know why Hudson is complaining about the test failure on
trunk? I did not get that error locally.

Regards,
Sai Pullabhotla





On Mon, Mar 29, 2010 at 4:06 PM, Niklas Gustavsson  wrote:
> On Mon, Mar 29, 2010 at 9:39 PM, Emmanuel Lecharny  
> wrote:
>> Otherwise, if you think that the coding conventions don't fit, then we can
>> discuss openly here.
>
> I don't mind what coding conventions we use, as long as they are consistent 
> :-)
>
> /niklas
>

Re: svn commit: r928769 - in /mina/ftpserver/trunk/core/src: main/java/org/apache/ftpserver/config/spring/ main/java/org/apache/ftpserver/ipfilter/ main/java/org/apache/ftpserver/listener/ main/java

[Sai Pullabhotla]

I apologize for the mess up. However, I do want you to know that I
tried all the possible things I could, but still was not able to
figure out how Eclipse manages to screw it up. I did not format any
existing sources. I even tried creating a brand new workspace, set the
new lines to UNIX style, instead of Windows. Not sure what's wrong,
but I gave up after struggling for a few hours (yes, was fighting with
it at 3am :(. May be if any one of you know a procedure on how not to
mess these things up, that would help. All I can offer at this time is
a tip in case if we can't figure this out -

Turn ON "ignore white space differences" in Eclipse preferences. This
would help when reviewing the changes as it does not show the white
space changes as spaces. This preference is available under General ->
Compare/Patch -> General tab. You may already know about this, but in
case.

Of course, a Source Code Formatter posted to the MINA web site would
definitely be a plus as I do want to format and still keep the
unchanged stuff as is.

Regards,
Sai Pullabhotla





On Mon, Mar 29, 2010 at 2:34 PM, Niklas Gustavsson  wrote:
> On Mon, Mar 29, 2010 at 2:31 PM,   wrote:
>> Author: sai
>> Date: Mon Mar 29 13:31:55 2010
>> New Revision: 928769
>>
>> URL: http://svn.apache.org/viewvc?rev=928769&view=rev
>> Log:
>> Implemented FTPSERVER-357
>
> Seems like there was a ton of whitespace changes included in this
> commit. Keeping the commits clean makes them much easier to review.
>
> /niklas
>

[jira] Created: (VYSPER-196) Merge nbxml-sax branch into trunk

[Niklas Gustavsson (JIRA)]

Merge nbxml-sax branch into trunk
-

 Key: VYSPER-196
 URL: https://issues.apache.org/jira/browse/VYSPER-196
 Project: VYSPER
  Issue Type: Task
  Components: core protocol
Affects Versions: 0.5
Reporter: Niklas Gustavsson
Assignee: Niklas Gustavsson
 Fix For: 0.6


The nbxml-sax branch is ready to be merged with trunk. However, it will require 
fixing quite a few cases of how namespaces are used in the core (and other 
downstream) modules. So, it will likely require some stabilization before ready 
to be released.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (VYSPER-194) Remove dependency on bouncy castle

[Niklas Gustavsson (JIRA)]

Remove dependency on bouncy castle
--

 Key: VYSPER-194
 URL: https://issues.apache.org/jira/browse/VYSPER-194
 Project: VYSPER
  Issue Type: Task
Affects Versions: 0.5
Reporter: Niklas Gustavsson
Assignee: Niklas Gustavsson
Priority: Minor
 Fix For: 0.6


We currently have an unused dependency on Bouncy castle security provider. We 
can probably remove it (including notice)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (VYSPER-195) Remove dependency on nekopull

[Niklas Gustavsson (JIRA)]

Remove dependency on nekopull
-

 Key: VYSPER-195
 URL: https://issues.apache.org/jira/browse/VYSPER-195
 Project: VYSPER
  Issue Type: Task
Affects Versions: 0.5
Reporter: Niklas Gustavsson
Assignee: Niklas Gustavsson
 Fix For: 0.6


We currently depend on nekopull, but only uses it in some no longer needed unit 
tests. Clean this up and remove the dependency.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [RESULT][VOTE] Release Apache Vysper 0.5, take 2

[Bernd Fondermann]

On Mon, Mar 29, 2010 at 22:11, Niklas Gustavsson  wrote:
> On Mon, Mar 22, 2010 at 10:20 PM, Niklas Gustavsson
>  wrote:
>> Bernd has updated the out-of-date text files and I've uploaded a new build.
>
> This vote passes with 5 binding +1 votes and one non-binding +1 vote.
> I'll release the artifacts and update the site.
>
> Thanks for voting!

Niklas, many many thanks for releasemanaging this (otherwise this
would be still unreleased software) and working hard on the code.
Thanks Emmanuel for the initial idea to bring this code over to MINA!

  Bernd

Re: svn commit: r928769 - in /mina/ftpserver/trunk/core/src: main/java/org/apache/ftpserver/config/spring/ main/java/org/apache/ftpserver/ipfilter/ main/java/org/apache/ftpserver/listener/ main/java

[Niklas Gustavsson]

On Mon, Mar 29, 2010 at 9:39 PM, Emmanuel Lecharny  wrote:
> Otherwise, if you think that the coding conventions don't fit, then we can
> discuss openly here.

I don't mind what coding conventions we use, as long as they are consistent :-)

/niklas

Re: svn commit: r928769 - in /mina/ftpserver/trunk/core/src: main/java/org/apache/ftpserver/config/spring/ main/java/org/apache/ftpserver/ipfilter/ main/java/org/apache/ftpserver/listener/ main/java

[Emmanuel Lecharny]

On 3/29/10 9:34 PM, Niklas Gustavsson wrote:

On Mon, Mar 29, 2010 at 2:31 PM,  wrote:
   

Author: sai
Date: Mon Mar 29 13:31:55 2010
New Revision: 928769

URL: http://svn.apache.org/viewvc?rev=928769&view=rev
Log:
Implemented FTPSERVER-357
 

Seems like there was a ton of whitespace changes included in this
commit. Keeping the commits clean makes them much easier to review.
   

A few hints :

I don't know what you guys are using as an IDE, but if most of you are 
using eclipse, then it would be a good idea to use a common formatter 
(strange enough, we have one defined a while back, but the link is 
broken on the web site)


Also there are a few rules that should be follow (here, rules = habits) :
- use spaces, no tabs,
- when you are modifying some existing code, try not to reformat it to 
fit your taste : adapt your taste instead.
- if you don't know what are the coding convention in use, ask on the 
mailing list.


Otherwise, if you think that the coding conventions don't fit, then we 
can discuss openly here.


Hope it helps...

--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com

[RESULT][VOTE] Release Apache Vysper 0.5, take 2

[Niklas Gustavsson]

On Mon, Mar 22, 2010 at 10:20 PM, Niklas Gustavsson
 wrote:
> Bernd has updated the out-of-date text files and I've uploaded a new build.

This vote passes with 5 binding +1 votes and one non-binding +1 vote.
I'll release the artifacts and update the site.

Thanks for voting!

/niklas

Re: svn commit: r928769 - in /mina/ftpserver/trunk/core/src: main/java/org/apache/ftpserver/config/spring/ main/java/org/apache/ftpserver/ipfilter/ main/java/org/apache/ftpserver/listener/ main/java

[Niklas Gustavsson]

On Mon, Mar 29, 2010 at 2:31 PM,   wrote:
> Author: sai
> Date: Mon Mar 29 13:31:55 2010
> New Revision: 928769
>
> URL: http://svn.apache.org/viewvc?rev=928769&view=rev
> Log:
> Implemented FTPSERVER-357

Seems like there was a ton of whitespace changes included in this
commit. Keeping the commits clean makes them much easier to review.

/niklas

[jira] Resolved: (VYSPER-191) roster javadoc

[Bernd Fondermann (JIRA)]

 [ 
https://issues.apache.org/jira/browse/VYSPER-191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bernd Fondermann resolved VYSPER-191.
-

Resolution: Fixed

javadoc added, please feel free to re-open for anything still missing

> roster javadoc
> --
>
> Key: VYSPER-191
> URL: https://issues.apache.org/jira/browse/VYSPER-191
> Project: VYSPER
>  Issue Type: Improvement
>  Components: roster and subscription
>Reporter: Julien Vermillard
>Assignee: Bernd Fondermann
>Priority: Blocker
>
> javadoc on roster is thin :
> http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/modules/roster/RosterGroup.java
> http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/modules/roster/RosterStanzaUtils.java

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [Vysper] Moving out of sandbox - Todos

[Emmanuel Lecharny]

On 3/29/10 2:50 PM, Niklas Gustavsson wrote:

On Mon, Mar 29, 2010 at 12:23 PM, Bernd Fondermann
  wrote:
   

We collected that the following stuff has to be done *before* moving out
of sandbox, right?
 

I do not think we need to do anything before moving out of the
sandbox. All those things that needs fixing might just as well be done
afterwards as they need to be done anyways.
   

I agree with Niklas here.

We know what we have to do after you move out of sandbox, we now have 
JIRA for the Javadoc, the website has been started, the documentation 
will come, I think we are golden so far.



--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com

Re: [Vysper] Dependency on BC provider

[Jean-Sebastien Delfino]

Bernd Fondermann wrote:

Niklas Gustavsson wrote:

Hi

VYSPER-190 (typo in NOTICE.txt) lead me to look further into the
dependency on the Bouncy castle provider. Do we actually still need
it? I removed the dependency and the unit tests and the server runs
just fine. Now, this is on JDK 1.6 so there might be issue on some
other Java version.


If it works w/o bc, I'm +1 to remove it.

  Bernd


Works for me too without Bouncy Castle on Ubuntu 9.10 with OpenJDK, SUN 
and IBM JDKs 1.6. I've not tried with JDK 1.5.


--
Jean-Sebastien

Hudson build became unstable: ftpserver-trunk-jdk1.5-solaris #343

[Apache Hudson Server]

See 

Hudson build became unstable: ftpserver-trun k-jdk1.5-solaris » Apache FtpServer Core #343

[Apache Hudson Server]

See 

[jira] Commented: (FTPSERVER-323) Add a new configuration option for enabling/disabling IP check when accepting passive data connections

[Sai Pullabhotla (JIRA)]

[ 
https://issues.apache.org/jira/browse/FTPSERVER-323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850909#action_12850909
 ] 

Sai Pullabhotla commented on FTPSERVER-323:
---

Looks like this feature is not checked into the 1.0.x branch. Could some one 
look into it and see if it should be in the branch? 

Thanks. 

> Add a new configuration option for enabling/disabling IP check when accepting 
> passive data connections
> --
>
> Key: FTPSERVER-323
> URL: https://issues.apache.org/jira/browse/FTPSERVER-323
> Project: FtpServer
>  Issue Type: New Feature
>  Components: Core
>Affects Versions: 1.0.2
>Reporter: Sai Pullabhotla
> Fix For: 1.1.0
>
> Attachments: FTPSERVER-323.patch
>
>
> In the current version it is possible for a hacker to connect to any passive 
> port that is currently waiting for a connection and read/write data off that 
> connection. We should implement a check in place to make sure the IP address 
> of the remote host is same as the one we are expecting, if not, close the 
> data connection right way. After closing the data connection we can do one of 
> the following: 
> 1. Wait for incoming connection again so the original client can connect 
> 2. just quit and send a reply back to the client that the data connection is 
> closed. We need to figure out what reply we want to send in this case. 
> What do you guys think we should do? 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [Vysper] Moving out of sandbox - Todos

[Niklas Gustavsson]

On Mon, Mar 29, 2010 at 12:23 PM, Bernd Fondermann
 wrote:
> We collected that the following stuff has to be done *before* moving out
> of sandbox, right?

I do not think we need to do anything before moving out of the
sandbox. All those things that needs fixing might just as well be done
afterwards as they need to be done anyways.

/niklas

Re: [Vysper] Moving out of sandbox - Todos

[Rick Bullotta]

That's awesome news. 

I think that expanded examples and an active wiki which included architectural 
discussion, usage tips, examples, etc. would be valuable/essential 
post-sandbox. 


--Original Message--
From: Bernd Fondermann
To: dev@mina.apache.org
ReplyTo: dev@mina.apache.org
Subject: [Vysper] Moving out of sandbox - Todos
Sent: Mar 29, 2010 12:57 AM

Hi everone,

Just wanted to start collecting thoughts from everyone what we need to
do before moving Vysper out of sandbox?

I think a proper website would be needed, anything else?

  Bernd


 

Re: [Vysper] Moving out of sandbox - Todos

[Bernd Fondermann]

Bernd Fondermann wrote:
> Niklas Gustavsson wrote:
>> On Mon, Mar 29, 2010 at 5:57 AM, Bernd Fondermann
>>  wrote:
>>> Just wanted to start collecting thoughts from everyone what we need to
>>> do before moving Vysper out of sandbox?
>> I think we're ready to just move it.
> 
> I guess we would want to ratify with a vote.
> I'll start one.

But wait a minute, I'm jumping the gun.

We collected that the following stuff has to be done *before* moving out
of sandbox, right?

* Documentation
* Website
* Javadoc

  Bernd

Re: [Vysper] Moving out of sandbox - Todos

[Bernd Fondermann]

Niklas Gustavsson wrote:
> On Mon, Mar 29, 2010 at 5:57 AM, Bernd Fondermann
>  wrote:
>> Just wanted to start collecting thoughts from everyone what we need to
>> do before moving Vysper out of sandbox?
> 
> I think we're ready to just move it.

I guess we would want to ratify with a vote.
I'll start one.

  Bernd

Re: [Vysper] Moving out of sandbox - Todos

[Bernd Fondermann]

Emmanuel Lecharny wrote:
> On 3/29/10 10:37 AM, Niklas Gustavsson wrote:
>> On Mon, Mar 29, 2010 at 8:36 AM, Julien Vermillard
>>   wrote:
>>   
>>> IMO some class miss javadoc, there is room for improvement.
>>> Randomly pciked examples :
>>>  
>> I perfectly agree that Vysper needs a lot more documentation in
>> general. However, I do not think this is a blocker for moving out of
>> sandbox.
>>
> It's certainly not a blocker. As suggested by Bernd, we have to create
> JIRAs for that.
> 
> Bernd, if you need to help with the Web Site, i'll be around until the
> ned of this week, then I'll be off for 2 weeks. I'm not sure we can
> modify the main site lokk, but we certainly can link to the Vysper site.

Actually, bad enough, I will be very busy in April facing a couple of
deadlines on different fronts.
I'll have to limit my Vysper-time, unfortunately.

Right now I'm concentrating on mailing list and open issues, esp. the
javadoc one's where I have a working (:-)) patch available, which I will
commit as soon as I'm on the relevant network.

No spare cycles for the website ATM, sorry. And no holiday either ;-)

  Bernd

[jira] Commented: (FTPSERVER-361) Provide more information on command execution to Ftplets - especially file created in STOU

[Richard Evans (JIRA)]

[ 
https://issues.apache.org/jira/browse/FTPSERVER-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850872#action_12850872
 ] 

Richard Evans commented on FTPSERVER-361:
-

I see - the reply would indicate the file that was stored, etc.

Can I suggest a new methods on DefaultFtpLet which are called with the reply 
object cast to the correct class for the command?

eg. 

public FtpletResult onUploadEnd(FtpSession session, FtpRequest request, 
DataTransferFtpReply reply)

put I guess this would fail if the reply indicated some failure?

> Provide more information on command execution to Ftplets - especially file 
> created in STOU
> --
>
> Key: FTPSERVER-361
> URL: https://issues.apache.org/jira/browse/FTPSERVER-361
> Project: FtpServer
>  Issue Type: Improvement
>  Components: Ftplets
>Affects Versions: 1.0.4
>Reporter: Richard Evans
>
> To monitor file uploads, I can configure an Ftplet and override onUploadEnd 
> and onUploadUniqueEnd in DefaultFtplet.  However I cannot find a way to 
> determine the real file that was written in the upload.  
> For a non-unique upload I can get the argument and resolve it against the 
> working directory in the file system view; but this seems unnecessarily 
> complex and does not for for unique uploads (STOU) because the random file 
> name is not available.
> Browsing the code I can see the file observer stuff, but these are non-public 
> APIs and there can be only one observer at a time whilst I can have many 
> independent Ftplets implementing the onUpload APIs.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [Vysper] Dependency on BC provider

[Bernd Fondermann]

Niklas Gustavsson wrote:
> Hi
> 
> VYSPER-190 (typo in NOTICE.txt) lead me to look further into the
> dependency on the Bouncy castle provider. Do we actually still need
> it? I removed the dependency and the unit tests and the server runs
> just fine. Now, this is on JDK 1.6 so there might be issue on some
> other Java version.

If it works w/o bc, I'm +1 to remove it.

  Bernd

[jira] Commented: (FTPSERVER-361) Provide more information on command execution to Ftplets - especially file created in STOU

[Niklas Gustavsson (JIRA)]

[ 
https://issues.apache.org/jira/browse/FTPSERVER-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850867#action_12850867
 ] 

Niklas Gustavsson commented on FTPSERVER-361:
-

I think we have solved this in trunk (which will become 1.1.0) already. Have a 
look at the FileActionFtpReply class in particular. 

> Provide more information on command execution to Ftplets - especially file 
> created in STOU
> --
>
> Key: FTPSERVER-361
> URL: https://issues.apache.org/jira/browse/FTPSERVER-361
> Project: FtpServer
>  Issue Type: Improvement
>  Components: Ftplets
>Affects Versions: 1.0.4
>Reporter: Richard Evans
>
> To monitor file uploads, I can configure an Ftplet and override onUploadEnd 
> and onUploadUniqueEnd in DefaultFtplet.  However I cannot find a way to 
> determine the real file that was written in the upload.  
> For a non-unique upload I can get the argument and resolve it against the 
> working directory in the file system view; but this seems unnecessarily 
> complex and does not for for unique uploads (STOU) because the random file 
> name is not available.
> Browsing the code I can see the file observer stuff, but these are non-public 
> APIs and there can be only one observer at a time whilst I can have many 
> independent Ftplets implementing the onUpload APIs.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [jira] Created: (FTPSERVER-361) Provide more information on command execution to Ftplets - especially file created in STOU

[Sai Pullabhotla]

I think this should have been taken care of with the
https://issues.apache.org/jira/browse/FTPSERVER-222. You might want to
try building from the trunk and see if this works out better.

Regards,
Sai Pullabhotla





On Mon, Mar 29, 2010 at 4:56 AM, Richard Evans (JIRA)  wrote:
> Provide more information on command execution to Ftplets - especially file 
> created in STOU
> --
>
>                 Key: FTPSERVER-361
>                 URL: https://issues.apache.org/jira/browse/FTPSERVER-361
>             Project: FtpServer
>          Issue Type: Improvement
>          Components: Ftplets
>    Affects Versions: 1.0.4
>            Reporter: Richard Evans
>
>
> To monitor file uploads, I can configure an Ftplet and override onUploadEnd 
> and onUploadUniqueEnd in DefaultFtplet.  However I cannot find a way to 
> determine the real file that was written in the upload.
>
> For a non-unique upload I can get the argument and resolve it against the 
> working directory in the file system view; but this seems unnecessarily 
> complex and does not for for unique uploads (STOU) because the random file 
> name is not available.
>
> Browsing the code I can see the file observer stuff, but these are non-public 
> APIs and there can be only one observer at a time whilst I can have many 
> independent Ftplets implementing the onUpload APIs.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>

[jira] Created: (FTPSERVER-361) Provide more information on command execution to Ftplets - especially file created in STOU

[Richard Evans (JIRA)]

Provide more information on command execution to Ftplets - especially file 
created in STOU
--

 Key: FTPSERVER-361
 URL: https://issues.apache.org/jira/browse/FTPSERVER-361
 Project: FtpServer
  Issue Type: Improvement
  Components: Ftplets
Affects Versions: 1.0.4
Reporter: Richard Evans


To monitor file uploads, I can configure an Ftplet and override onUploadEnd and 
onUploadUniqueEnd in DefaultFtplet.  However I cannot find a way to determine 
the real file that was written in the upload.  

For a non-unique upload I can get the argument and resolve it against the 
working directory in the file system view; but this seems unnecessarily complex 
and does not for for unique uploads (STOU) because the random file name is not 
available.

Browsing the code I can see the file observer stuff, but these are non-public 
APIs and there can be only one observer at a time whilst I can have many 
independent Ftplets implementing the onUpload APIs.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [Vysper] Merge new XML parser into trunk

[Niklas Gustavsson]

On Mon, Mar 29, 2010 at 7:10 AM, Niklas Gustavsson  wrote:
> But it turned out I had a bug in my benchmark. New numbers coming up
> later today.

Bugs fixed, here's the new numbers:

Tests performed (1 rounds):
Single level XML ()
Existing parser ~700ms
New parser ~800ms

About the same as before

Nested XML ()
Existing parser ~1000ms
New parser ~850ms

As you see, more even than before, but I'm still comfortable with the results.

/niklas

Re: [Vysper] Moving out of sandbox - Todos

[Julien Vermillard]

Le Mon, 29 Mar 2010 09:53:24 +0100,
Niklas Gustavsson  a écrit :

> On Mon, Mar 29, 2010 at 9:50 AM, Julien Vermillard
>  wrote:
> > No but I hope it's not going to be a usage here to being rude when
> > we talk about lack of code documentation nor expecting others to do
> > the peon work.
> 
> I fully agree, and I don't think there was ever any intention to be
> rude. None the less, this seems to be an orthogonal issue to Vysper
> being moved out of the sandbox :-)
> 
> /niklas

Personally I don't mind much until commits are following the minimum
rule : javadoc on every interface/class/public methods.

-- 
Julien Vermillard

Archean Technologies
http://www.archean.fr


signature.asc
Description: PGP signature

[jira] Assigned: (VYSPER-191) roster javadoc

[Bernd Fondermann (JIRA)]

 [ 
https://issues.apache.org/jira/browse/VYSPER-191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bernd Fondermann reassigned VYSPER-191:
---

Assignee: Bernd Fondermann

> roster javadoc
> --
>
> Key: VYSPER-191
> URL: https://issues.apache.org/jira/browse/VYSPER-191
> Project: VYSPER
>  Issue Type: Improvement
>  Components: roster and subscription
>Reporter: Julien Vermillard
>Assignee: Bernd Fondermann
>Priority: Blocker
>
> javadoc on roster is thin :
> http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/modules/roster/RosterGroup.java
> http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/modules/roster/RosterStanzaUtils.java

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [Vysper] Moving out of sandbox - Todos

[Niklas Gustavsson]

On Mon, Mar 29, 2010 at 10:01 AM, Emmanuel Lecharny  wrote:
> Sadly, we can't come back to a time where french was the Lingua Franca, or
> even Latin

Uhm, yeah sure ;-)

/niklas

Re: [Vysper] Moving out of sandbox - Todos

[Emmanuel Lecharny]

On 3/29/10 10:53 AM, Niklas Gustavsson wrote:

On Mon, Mar 29, 2010 at 9:50 AM, Julien Vermillard
  wrote:
   

No but I hope it's not going to be a usage here to being rude when we
talk about lack of code documentation nor expecting others to do the
peon work.
 

I fully agree, and I don't think there was ever any intention to be
rude. None the less, this seems to be an orthogonal issue to Vysper
being moved out of the sandbox :-)
   
We have to keep in mind that english is not our native language, and 
that a sentence may have been written without the intention to be rude, 
even if it's what some may feel. That's a sad reality we have to deal it.


Sadly, we can't come back to a time where french was the Lingua Franca, 
or even Latin (well, I bet it's probably better for all of us ;)


Let's get Vysper out of the sandbox !!!

--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com

Re: [Vysper] Moving out of sandbox - Todos

[Emmanuel Lecharny]

On 3/29/10 10:37 AM, Niklas Gustavsson wrote:

On Mon, Mar 29, 2010 at 8:36 AM, Julien Vermillard
  wrote:
   

IMO some class miss javadoc, there is room for improvement.
Randomly pciked examples :
 

I perfectly agree that Vysper needs a lot more documentation in
general. However, I do not think this is a blocker for moving out of
sandbox.
   
It's certainly not a blocker. As suggested by Bernd, we have to create 
JIRAs for that.


Bernd, if you need to help with the Web Site, i'll be around until the 
ned of this week, then I'll be off for 2 weeks. I'm not sure we can 
modify the main site lokk, but we certainly can link to the Vysper site.


--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com

[jira] Created: (VYSPER-193) javadoc on exception classes

[Julien Vermillard (JIRA)]

javadoc on exception classes


 Key: VYSPER-193
 URL: https://issues.apache.org/jira/browse/VYSPER-193
 Project: VYSPER
  Issue Type: Improvement
Reporter: Julien Vermillard
Priority: Minor


On all the exceptions class there is no javadoc.
Example :
http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/authorization/AccountCreationException.java

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (VYSPER-192) javadoc on org/apache/vysper/xmpp/delivery

[Julien Vermillard (JIRA)]

javadoc on org/apache/vysper/xmpp/delivery
--

 Key: VYSPER-192
 URL: https://issues.apache.org/jira/browse/VYSPER-192
 Project: VYSPER
  Issue Type: Improvement
Reporter: Julien Vermillard
Priority: Blocker


Thin javadoc here :
http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/delivery/LocalDeliveryUtils.java
http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/delivery/StanzaRelayBroker.java
http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/delivery/failure/ServiceNotAvailableException.java
http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/delivery/StanzaReceiverRelay.java

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [Vysper] Moving out of sandbox - Todos

[Niklas Gustavsson]

On Mon, Mar 29, 2010 at 9:50 AM, Julien Vermillard
 wrote:
> No but I hope it's not going to be a usage here to being rude when we
> talk about lack of code documentation nor expecting others to do the
> peon work.

I fully agree, and I don't think there was ever any intention to be
rude. None the less, this seems to be an orthogonal issue to Vysper
being moved out of the sandbox :-)

/niklas

[jira] Created: (VYSPER-191) roster javadoc

[Julien Vermillard (JIRA)]

roster javadoc
--

 Key: VYSPER-191
 URL: https://issues.apache.org/jira/browse/VYSPER-191
 Project: VYSPER
  Issue Type: Improvement
  Components: roster and subscription
Reporter: Julien Vermillard
Priority: Blocker


javadoc on roster is thin :

http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/modules/roster/RosterGroup.java
http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/modules/roster/RosterStanzaUtils.java

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [Vysper] Moving out of sandbox - Todos

[Julien Vermillard]

Le Mon, 29 Mar 2010 09:37:13 +0100,
Niklas Gustavsson  a écrit :

> On Mon, Mar 29, 2010 at 8:36 AM, Julien Vermillard
>  wrote:
> > IMO some class miss javadoc, there is room for improvement.
> > Randomly pciked examples :
> 
> I perfectly agree that Vysper needs a lot more documentation in
> general. However, I do not think this is a blocker for moving out of
> sandbox.
> 
> /niklas

No but I hope it's not going to be a usage here to being rude when we
talk about lack of code documentation nor expecting others to do the
peon work.

-- 
Julien Vermillard

Archean Technologies
http://www.archean.fr


signature.asc
Description: PGP signature

Re: [Vysper] Moving out of sandbox - Todos

[Bernd Fondermann]

On Mon, Mar 29, 2010 at 10:36, Emmanuel Lécharny  wrote:
> On 3/29/10 10:25 AM, Bernd Fondermann wrote:
>>
>>> This is not exactly the kind of response we should expect here...
>>>
>>
>> Who is "we"? I don't want to step on anyones toes but cannot help that
>> I sometimes do not feel obliged to bind myself to other's
>> expectations.
>>
>
> "We", as in "Apache is all about community".
>
> Note that I'm not blaming you for the lack of Javadoc, I know that writing
> Javadoc wj-hile coding might not be the best solution, I'm just saying that
> when Julien mention that there are a lot of missing Javadoc missing, a more
> appropriate response like "Yeah, I'm aware of that, will work on it, or I
> wll appreciate some help" would be more appropriate.
>
> Just replying "patches welcomed" sounds a bit rude. My be it's just a
> perception problem on my side...

I apologize, it was not my intention to be rude.

  Bernd

Re: [Vysper] Moving out of sandbox - Todos

[Niklas Gustavsson]

On Mon, Mar 29, 2010 at 8:36 AM, Julien Vermillard
 wrote:
> IMO some class miss javadoc, there is room for improvement.
> Randomly pciked examples :

I perfectly agree that Vysper needs a lot more documentation in
general. However, I do not think this is a blocker for moving out of
sandbox.

/niklas

Re: [Vysper] Moving out of sandbox - Todos

[Emmanuel Lecharny]

On 3/29/10 10:30 AM, Bernd Fondermann wrote:

Remember, you was collecting thoughts ;)
 

ok, sure. Thank you.
So I would suggest to open JIRAs to record those classes missing
javadocs -  this thread was intended, as you say, to collect thoughts.
   


perfect ! Let's do that.


--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com

Re: [Vysper] Moving out of sandbox - Todos

[Emmanuel Lécharny]

On 3/29/10 10:25 AM, Bernd Fondermann wrote:



This is not exactly the kind of response we should expect here...
 

Who is "we"? I don't want to step on anyones toes but cannot help that
I sometimes do not feel obliged to bind myself to other's
expectations.
   

"We", as in "Apache is all about community".

Note that I'm not blaming you for the lack of Javadoc, I know that 
writing Javadoc wj-hile coding might not be the best solution, I'm just 
saying that when Julien mention that there are a lot of missing Javadoc 
missing, a more appropriate response like "Yeah, I'm aware of that, will 
work on it, or I wll appreciate some help" would be more appropriate.


Just replying "patches welcomed" sounds a bit rude. My be it's just a 
perception problem on my side...


Ok, let's move on !

--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com

Re: [Vysper] Moving out of sandbox - Todos

[Bernd Fondermann]

On Mon, Mar 29, 2010 at 09:43, Julien Vermillard  wrote:
> Le Mon, 29 Mar 2010 09:40:19 +0200,
> Bernd Fondermann  a écrit :
>
>> On Mon, Mar 29, 2010 at 09:36, Julien Vermillard
>>  wrote:
>> > Le Mon, 29 Mar 2010 07:27:02 +0200,
>> > Emmanuel Lecharny  a écrit :
>> >
>> >> On 3/29/10 6:57 AM, Bernd Fondermann wrote:
>> >> > Hi everone,
>> >> >
>> >> > Just wanted to start collecting thoughts from everyone what we
>> >> > need to do before moving Vysper out of sandbox?
>> >> >
>> >> > I think a proper website would be needed, anything else?
>> >> >
>> >> Already done ! http://mina.apache.org/vysper/
>> >>
>> >> Documentation ...
>> >>
>> >>
>> >
>> > IMO some class miss javadoc, there is room for improvement.
>> > Randomly pciked examples :
>> >
>> > http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/authorization/AccountCreationException.java
>> > http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/delivery/LocalDeliveryUtils.java
>> > http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/delivery/StanzaRelayBroker.java
>> > http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/delivery/failure/ServiceNotAvailableException.java
>> > http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/delivery/StanzaReceiverRelay.java
>> > http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/modules/roster/RosterGroup.java
>> > http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/modules/roster/RosterStanzaUtils.java
>> > http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/modules/extension/xep0092_software_version/SoftwareVersionModule.java
>>
>> patches, as always, are welcome! :-)
>>
>>   Bernd
>
> Remember, you was collecting thoughts ;)

ok, sure. Thank you.
So I would suggest to open JIRAs to record those classes missing
javadocs -  this thread was intended, as you say, to collect thoughts.

  Bernd

Re: [Vysper] Moving out of sandbox - Todos

[Bernd Fondermann]

On Mon, Mar 29, 2010 at 09:52, Emmanuel Lecharny  wrote:
> On 3/29/10 9:40 AM, Bernd Fondermann wrote:
>>
>> On Mon, Mar 29, 2010 at 09:36, Julien Vermillard
>>  wrote:
>>
>>>
>>> Le Mon, 29 Mar 2010 07:27:02 +0200,
>>> Emmanuel Lecharny  a écrit :
>>>
>>>

 On 3/29/10 6:57 AM, Bernd Fondermann wrote:

>
> Hi everone,
>
> Just wanted to start collecting thoughts from everyone what we need
> to do before moving Vysper out of sandbox?
>
> I think a proper website would be needed, anything else?
>
>

 Already done ! http://mina.apache.org/vysper/

 Documentation ...



>>>
>>> IMO some class miss javadoc, there is room for improvement.
>>> Randomly pciked examples :
>>>
>>>
>>> http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/authorization/AccountCreationException.java
>>>
>>> http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/delivery/LocalDeliveryUtils.java
>>>
>>> http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/delivery/StanzaRelayBroker.java
>>>
>>> http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/delivery/failure/ServiceNotAvailableException.java
>>>
>>> http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/delivery/StanzaReceiverRelay.java
>>>
>>> http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/modules/roster/RosterGroup.java
>>>
>>> http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/modules/roster/RosterStanzaUtils.java
>>>
>>> http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/modules/extension/xep0092_software_version/SoftwareVersionModule.java
>>>
>>
>> patches, as always, are welcome! :-)
>>
>
> This is not exactly the kind of response we should expect here...

Who is "we"? I don't want to step on anyones toes but cannot help that
I sometimes do not feel obliged to bind myself to other's
expectations.

> Sorry Bernd, but we suffered - and are still suffering - from the same exact
> problem in MINA care : lack of javadoc.

You don't have to apologize, no problem.

> I don't know who is in better position to inject Javadoc than the one who
> write the code.

The person actually having the time to review code and add anything
that's missing, functionality, javadoc etc.

> So I totally +1 Julien's position. We need more Javadoc,

+1. I totally agree.

> we don't need
> 'patches welcome' mails.

Who is "we" in this case? and What's the exact problem with those
mails? It's the everlasting truth in open source :-)

  Bernd

Re: [Vysper] Moving out of sandbox - Todos

[Emmanuel Lecharny]

On 3/29/10 9:40 AM, Bernd Fondermann wrote:

On Mon, Mar 29, 2010 at 09:36, Julien Vermillard  wrote:
   

Le Mon, 29 Mar 2010 07:27:02 +0200,
Emmanuel Lecharny  a écrit :

 

On 3/29/10 6:57 AM, Bernd Fondermann wrote:
   

Hi everone,

Just wanted to start collecting thoughts from everyone what we need
to do before moving Vysper out of sandbox?

I think a proper website would be needed, anything else?

 

Already done ! http://mina.apache.org/vysper/

Documentation ...


   

IMO some class miss javadoc, there is room for improvement.
Randomly pciked examples :

http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/authorization/AccountCreationException.java
http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/delivery/LocalDeliveryUtils.java
http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/delivery/StanzaRelayBroker.java
http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/delivery/failure/ServiceNotAvailableException.java
http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/delivery/StanzaReceiverRelay.java
http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/modules/roster/RosterGroup.java
http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/modules/roster/RosterStanzaUtils.java
http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/modules/extension/xep0092_software_version/SoftwareVersionModule.java
 

patches, as always, are welcome! :-)
   

This is not exactly the kind of response we should expect here...

Sorry Bernd, but we suffered - and are still suffering - from the same 
exact problem in MINA care : lack of javadoc.


I don't know who is in better position to inject Javadoc than the one 
who write the code.


So I totally +1 Julien's position. We need more Javadoc, we don't need 
'patches welcome' mails.


--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com

Re: [Vysper] Moving out of sandbox - Todos

[Julien Vermillard]

Le Mon, 29 Mar 2010 09:40:19 +0200,
Bernd Fondermann  a écrit :

> On Mon, Mar 29, 2010 at 09:36, Julien Vermillard
>  wrote:
> > Le Mon, 29 Mar 2010 07:27:02 +0200,
> > Emmanuel Lecharny  a écrit :
> >
> >> On 3/29/10 6:57 AM, Bernd Fondermann wrote:
> >> > Hi everone,
> >> >
> >> > Just wanted to start collecting thoughts from everyone what we
> >> > need to do before moving Vysper out of sandbox?
> >> >
> >> > I think a proper website would be needed, anything else?
> >> >
> >> Already done ! http://mina.apache.org/vysper/
> >>
> >> Documentation ...
> >>
> >>
> >
> > IMO some class miss javadoc, there is room for improvement.
> > Randomly pciked examples :
> >
> > http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/authorization/AccountCreationException.java
> > http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/delivery/LocalDeliveryUtils.java
> > http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/delivery/StanzaRelayBroker.java
> > http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/delivery/failure/ServiceNotAvailableException.java
> > http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/delivery/StanzaReceiverRelay.java
> > http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/modules/roster/RosterGroup.java
> > http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/modules/roster/RosterStanzaUtils.java
> > http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/modules/extension/xep0092_software_version/SoftwareVersionModule.java
> 
> patches, as always, are welcome! :-)
> 
>   Bernd

Remember, you was collecting thoughts ;)

-- 
Julien Vermillard

Archean Technologies
http://www.archean.fr


signature.asc
Description: PGP signature

Re: [Vysper] Moving out of sandbox - Todos

[Bernd Fondermann]

On Mon, Mar 29, 2010 at 09:36, Julien Vermillard  wrote:
> Le Mon, 29 Mar 2010 07:27:02 +0200,
> Emmanuel Lecharny  a écrit :
>
>> On 3/29/10 6:57 AM, Bernd Fondermann wrote:
>> > Hi everone,
>> >
>> > Just wanted to start collecting thoughts from everyone what we need
>> > to do before moving Vysper out of sandbox?
>> >
>> > I think a proper website would be needed, anything else?
>> >
>> Already done ! http://mina.apache.org/vysper/
>>
>> Documentation ...
>>
>>
>
> IMO some class miss javadoc, there is room for improvement.
> Randomly pciked examples :
>
> http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/authorization/AccountCreationException.java
> http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/delivery/LocalDeliveryUtils.java
> http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/delivery/StanzaRelayBroker.java
> http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/delivery/failure/ServiceNotAvailableException.java
> http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/delivery/StanzaReceiverRelay.java
> http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/modules/roster/RosterGroup.java
> http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/modules/roster/RosterStanzaUtils.java
> http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/modules/extension/xep0092_software_version/SoftwareVersionModule.java

patches, as always, are welcome! :-)

  Bernd

Re: [Vysper] Moving out of sandbox - Todos

[Julien Vermillard]

Le Mon, 29 Mar 2010 07:27:02 +0200,
Emmanuel Lecharny  a écrit :

> On 3/29/10 6:57 AM, Bernd Fondermann wrote:
> > Hi everone,
> >
> > Just wanted to start collecting thoughts from everyone what we need
> > to do before moving Vysper out of sandbox?
> >
> > I think a proper website would be needed, anything else?
> >
> Already done ! http://mina.apache.org/vysper/
> 
> Documentation ...
> 
> 

IMO some class miss javadoc, there is room for improvement.
Randomly pciked examples :

http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/authorization/AccountCreationException.java
http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/delivery/LocalDeliveryUtils.java
http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/delivery/StanzaRelayBroker.java
http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/delivery/failure/ServiceNotAvailableException.java
http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/delivery/StanzaReceiverRelay.java
http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/modules/roster/RosterGroup.java
http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/modules/roster/RosterStanzaUtils.java
http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/modules/extension/xep0092_software_version/SoftwareVersionModule.java

-- 
Julien Vermillard

Archean Technologies
http://www.archean.fr


signature.asc
Description: PGP signature

Re: ASk for a feedback

[Bernd Fondermann]

On Mon, Mar 29, 2010 at 08:30, G.W.G.K.N. Udayanga
 wrote:
> Sir,
> Thank you for your great support(giving advices and made me aware) upto now.
> As the second step i started to read the referecences and examine the vysper
> codebase.
> This is the things what i understood upto now.Please give me a feedback.If
> It seems that i
> have understood the concept wrong, please correct me.
>
> *The Request parameters of a ajax client are included within a xml document
> as well as within a
> url.This encoding action is done by javascript.Then these requests are sent
> by using XMLHttpRequest.
> At there clients specify the format of the response in the form of XML,
> XHTML, HTML or JavaScript Object Notation (JSON).
> Normally bosh takes  XML payload.So is it need to implement the
> functionalities to convert url encoding to xml document
> format in the request and implement a translater which translates xml
> response document over bosh to xhtml or json if the xmlhttp
> request specify such a response format?

BOSH is only specified using XML, nothing else.

> *bosh sends xml payload encapsulates within http message body.

BOSH sends nothing. BOSH is a protocol spec, not an actor.
The actors in this spec are: Browser (HTTTP Agent), webserver
(HTTP/XMPP gateway), XMPP server.

> So with this
> we can implement xmpp stanzas.But to initiate and perform handshake
> we need xmpp streams.That puropose is achieved by extending the bosh
> functionalities as mentioned in the fourth reference mention
> by you.So the obtaing xml document from the ajax client's requst can be
> processed as a xmpp message and push on to the vyper.

It's Vysper, not vyper.

> Then the xmpp response messages from the xmpp server can be made as xml
> document

XMPP responses are always XML already, so, yes.

> which is suitable to pump as an ajax response by
> removing xml tags related to xmpp stream and some other unwanted stanzas.

What would you want to remove? What would be unwanted stanzas? What do
you think is a stanza at all?

> In the fourth reference it is said that "inclusion of tls negotiationw is
> not allwed but not recommended" and in bosh protocol they are using
> sasl authentication.In xmpp also we can use the sasl authentication.But by
> default vysper use ssl.
> So please make me clear about this.

Eh.. SASL is used for authentication, SSL/TLS is used for encryption.

> *Normally  these days tls is use and ssl is a predecessor of it.do you use
> tls specification
> at present(although it is  ssl by default)?

It's in the code :-)

> *Actually this project is developed as an extension.For vysper an extension
> is a module.To process stanzas from ajax clients
> we can use a stanzhandler which is connected to related module.
> Modules can be registered with the server calling
> ServerRuntimeContext.addModule(Module module).
> Using spring-config.xml, they are configured in bean 'server'. Simply add a
> new bean for the module to the config.
> Then add a bean reference to property 'modules' list in 'server'. On server
> startup, these modules are loaded and activated.

No, I don't think you can add BOSH as an module.
A suitable extension point would be AbstractSessionContext/SessionContext.

  Bernd

Re: Getting back into things

[Emmanuel Lecharny]

On 3/29/10 2:43 AM, Mark wrote:

I've been away for a while (yeah yeah) working on many things not java
nor networking-based.  I want to get started back up with some MINA
work.  Has there been a 3.0 branch started?  Or should we work on some
improvements from JIRA in a sandbox copy?

Thanks,
Mark

   

Welcome back !

A quick Status on MINA :
- we have started discussion on MINA 3, there is a branch with some cod, 
but it's the very beginning
- we still have to release 2.0-GA, actually we launched a vote but have 
cancelled it, because we have some issues on the windows platform
- we also have started to migrate the web site to a new layout (see 
http://mina.apache.org/mina2/)


Sadly, most of us are totally swamped with work, and we didn't had time 
to get back to the code base to see what's going on. I personally didn't 
had any time in the last past weeks to touch MINA at all (spending my 
spare time on Apache DS 1.5.6 release). And as i'll be off 2 weeks in 
april, I'm afraid I won't be able to look at the MINA 2 problem.


I don't hink we are far from a release, maybe one more week...

--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com