[Vysper] XML parser in a separate module?

2009-11-11 Thread Niklas Gustavsson
Hi

Since there has been some interest here on using XML decoders with
MINA, and the inherit problems with doing this with the standard XML
parsers out there, I'm thinking of breaking out the XML parser in
Vysper into a separate module (still within the Vysper subproject, but
with it's own JAR). Thus, it would have no dependencies on Vysper. In
the long run, we might also provide a way to remove the current
limitations on what XML features are supported. For example, XMPP does
not allow for comments and thus we throw an exception when finding
one. This, we might make into an optional behavior.

What do you all think? Would having a standalone XML decoder be useful?

/niklas


Re: [Vysper] XML parser in a separate module?

2009-11-11 Thread Emmanuel Lecharny

Niklas Gustavsson wrote:

Hi

Since there has been some interest here on using XML decoders with
MINA, and the inherit problems with doing this with the standard XML
parsers out there, I'm thinking of breaking out the XML parser in
Vysper into a separate module (still within the Vysper subproject, but
with it's own JAR). Thus, it would have no dependencies on Vysper. In
the long run, we might also provide a way to remove the current
limitations on what XML features are supported. For example, XMPP does
not allow for comments and thus we throw an exception when finding
one. This, we might make into an optional behavior.

What do you all think? Would having a standalone XML decoder be useful?
  
Definitively. Everyone wanting to use XML as a way to exchange data need 
to have a XML codec at some point. It has been a problem since day one, 
and it's not solved yet.


I pretty much see haw such a codec can be part of MINA codec's library.

My +1.


--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org




Re: [Vysper] XML parser in a separate module?

2009-11-11 Thread Ashish
+ 1 Much needed

On Thu, Nov 12, 2009 at 2:47 AM, Emmanuel Lecharny  wrote:
> Niklas Gustavsson wrote:
>>
>> Hi
>>
>> Since there has been some interest here on using XML decoders with
>> MINA, and the inherit problems with doing this with the standard XML
>> parsers out there, I'm thinking of breaking out the XML parser in
>> Vysper into a separate module (still within the Vysper subproject, but
>> with it's own JAR). Thus, it would have no dependencies on Vysper. In
>> the long run, we might also provide a way to remove the current
>> limitations on what XML features are supported. For example, XMPP does
>> not allow for comments and thus we throw an exception when finding
>> one. This, we might make into an optional behavior.
>>
>> What do you all think? Would having a standalone XML decoder be useful?
>>
>
> Definitively. Everyone wanting to use XML as a way to exchange data need to
> have a XML codec at some point. It has been a problem since day one, and
> it's not solved yet.
>
> I pretty much see haw such a codec can be part of MINA codec's library.
>
> My +1.
>
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>



-- 
thanks
ashish

Blog: http://www.ashishpaliwal.com/blog
My Photo Galleries: http://www.pbase.com/ashishpaliwal


Re: [Vysper] XML parser in a separate module?

2009-11-22 Thread Bernd Fondermann
Ashish wrote:
> + 1 Much needed
> 
> On Thu, Nov 12, 2009 at 2:47 AM, Emmanuel Lecharny  
> wrote:
>> Niklas Gustavsson wrote:
>>> Hi
>>>
>>> Since there has been some interest here on using XML decoders with
>>> MINA, and the inherit problems with doing this with the standard XML
>>> parsers out there, I'm thinking of breaking out the XML parser in
>>> Vysper into a separate module (still within the Vysper subproject, but
>>> with it's own JAR). Thus, it would have no dependencies on Vysper. In
>>> the long run, we might also provide a way to remove the current
>>> limitations on what XML features are supported. For example, XMPP does
>>> not allow for comments and thus we throw an exception when finding
>>> one. This, we might make into an optional behavior.
>>>
>>> What do you all think? Would having a standalone XML decoder be useful?
>>>
>> Definitively. Everyone wanting to use XML as a way to exchange data need to
>> have a XML codec at some point. It has been a problem since day one, and
>> it's not solved yet.

+1.

However, wearing my XMPP-shutter-glasses, I like to add that Vysper
itself would not profit from extending it to parse more XML. Vysper
needs fast fail, where any XML not supported by XMPP leads to an
immediate exception. Everything else only generates overhead, lost for
processing more XMPP stanzas.

  Bernd



Re: [Vysper] XML parser in a separate module?

2009-11-22 Thread Niklas Gustavsson
On Sun, Nov 22, 2009 at 2:57 PM, Bernd Fondermann  wrote:
> However, wearing my XMPP-shutter-glasses, I like to add that Vysper
> itself would not profit from extending it to parse more XML. Vysper
> needs fast fail, where any XML not supported by XMPP leads to an
> immediate exception. Everything else only generates overhead, lost for
> processing more XMPP stanzas.

Fully agreed. In fact, I think this requirement is shared by many
other XML-on-the-wire protocols, as things like DTD declarations,
comments and PIs makes very little sense in such protocols. Therefore,
I think we should make this configurable to be able to behave like it
does today.

I hope the vacation treated you well :-)

/niklas


Re: [Vysper] XML parser in a separate module?

2009-11-23 Thread Bernd Fondermann
Niklas Gustavsson wrote:
> On Sun, Nov 22, 2009 at 2:57 PM, Bernd Fondermann  
> wrote:
>> However, wearing my XMPP-shutter-glasses, I like to add that Vysper
>> itself would not profit from extending it to parse more XML. Vysper
>> needs fast fail, where any XML not supported by XMPP leads to an
>> immediate exception. Everything else only generates overhead, lost for
>> processing more XMPP stanzas.
> 
> Fully agreed. In fact, I think this requirement is shared by many
> other XML-on-the-wire protocols, as things like DTD declarations,
> comments and PIs makes very little sense in such protocols. Therefore,
> I think we should make this configurable to be able to behave like it
> does today.

Configurable at least, and we will see how much runtime-overhead this
produces.

  Bernd