Re: Stream errors

[Brett Zamir]

(Making our discussions public)

Massimiliano Mirra wrote:

On Sun, Aug 24, 2008 at 12:09 PM, Brett Zamir <bre...@yahoo.com> wrote:
  

Hi,

I've got something working now for stream errors...

What kind of API would you want for the channel listener for stream errors?

As it is now, you can do something like this:

this.channel.on ({

  event : 'streamError',

  condition : 'bad-namespace-prefix'

},

function (err) {

  alert(err.condition); // Gives 'bad-namespace-prefix' (as above)

  alert(err.event); // Gives 'streamError' (as above)

  alert(err.msg); // Gives a string error message explaining
'bad-namespace-prefix' (since the specs say <text> can't solely be used, I
just used the definitions in 4.7.3:
http://www.xmpp.org/specs/rfc3920.html#streams-error
  alert(err.stanza.toXMLString()); // Shows the whole error stanza (can be
used to grab any <text> or other-namespaced error children)

});
\

I thought I'd tweak it the way you wanted it before sending a patch.
    

hmm, I'm thinking about this... what about a event: 'connector',
state: 'error', info: xmlErrorElement?  I'd like to fit what we can
into the existing structure if it makes sense.

  

Sure. But, there is already a connector-error of type "auth" and of type "badcert" which do not have any XML. Should I not include any "info" property on these at all, or set them to null/undefined?

Also, for stream errors, I'd like to make the whole error element and its contents available, since the <stream:error> not only contains the specific error element (whether XML-related, e.g., <restricted-xml/> or non-XML-related, e.g., <connection-timeout/>), but also can contain a human-readable <text> child (xml:lang-dependent) and/or proprietary XML content from the server related to the error. So the question is, do you want the specific error condition element also available directly as a property in addition to the full XML (I proposed "condition"), or do you want to let the user extract it (from the "info" XML which contains all of the <stream:error> content)? One advantage of making it available as a property is that they could more easily filter for just that condition if they wanted.

Also, what do you think of what I proposed as a "msg" property? This is a localizable message based verbatim on the RFC3920 explanations of the errors. For example, if the user gets a "connection-timeout" stream error (assuming your code isn't already catching these somehow), the msg property would be "the entity has not generated any traffic over the stream for some period of time (configurable according to a local service policy)." I think having such messages available would be convenient so that the xmpp4moz developer wouldn't have to write their own text messages for every possible stream error at section 4.7.3 of http://www.xmpp.org/specs/rfc3920.html#streams-error , especially during debugging. They could just set up a generic connection error listener and say put the message in an alert. I already have the code working for this, including the localizable messages--it'd just be a question of what property name to use on the returned event object, if you're open to it.

(btw, if I remember correctly, only message/presence/iq are called
'stanzas' in xmpp, all the rest are just elements...)

  

Yeah, you're right. I have to get over my bad habit of trying to hijack terms to enforce consistency. :)

If you don't mind, I have also started making xmpp4moz localizable.
    

I don't mind, quite the contrary!

  

Ok, cool... Let me know if you're open to the error messages, as mentioned above. If so, I think a very simple getter and setter (property or function) for xml:lang would also make sense here (getter for the xml:lang returned by the server). It really shouldn't add much code at all I think.
(Don't mean to be a nag on this...) :)

best wishes,
Brett

[Massimiliano Mirra]

On Wed, Sep 3, 2008 at 3:45 AM, Brett Zamir <bre...@yahoo.com> wrote:
>> hmm, I'm thinking about this... what about a event: 'connector',
>> state: 'error', info: xmlErrorElement? I'd like to fit what we can
>> into the existing structure if it makes sense.
> Sure. But, there is already a connector-error of type "auth" and of type
> "badcert" which do not have any XML. Should I not include any "info"
> property on these at all, or set them to null/undefined?

You can simply omit it.

> Also, for stream errors, I'd like to make the whole error element and its
> contents available, since the <stream:error> not only contains the specific
> error element (whether XML-related, e.g., <restricted-xml/> or
> non-XML-related, e.g., <connection-timeout/>), but also can contain a
> human-readable <text> child (xml:lang-dependent) and/or proprietary XML
> content from the server related to the error. So the question is, do you
> want the specific error condition element also available directly as a
> property in addition to the full XML (I proposed "condition"), or do you
> want to let the user extract it (from the "info" XML which contains all of
> the <stream:error> content)? One advantage of making it available as a
> property is that they could more easily filter for just that condition if
> they wanted.

Let's make just the error element available now, and see how it goes.
If we miss the condition property, we can add it later.

> Also, what do you think of what I proposed as a "msg" property? This is a
> localizable message based verbatim on the RFC3920 explanations of the
> errors. For example, if the user gets a "connection-timeout" stream error
> (assuming your code isn't already catching these somehow), the msg property
> would be "the entity has not generated any traffic over the stream for some
> period of time (configurable according to a local service policy)." I think
> having such messages available would be convenient so that the xmpp4moz
> developer wouldn't have to write their own text messages for every possible
> stream error at section 4.7.3 of
> http://www.xmpp.org/specs/rfc3920.html#streams-error , especially during
> debugging. They could just set up a generic connection error listener and
> say put the message in an alert. I already have the code working for this,
> including the localizable messages--it'd just be a question of what property
> name to use on the returned event object, if you're open to it.

Hmm. I think a way to do this would be to have a .properties file
with the condition->message mapping, so that the client can loop up
the (localized) message at runtime. Something like:

errors.properties:
conncetion-timeout=The entity has not generated ...

Then you may have a utility function:

alert(errorStringBundle.getString(XMPP.getCondition(xmlErrorElement)))

Creating the <stringbundle/> element would still be the responsibility
of the end-developer.

> Yeah, you're right. I have to get over my bad habit of trying to hijack
> terms to enforce consistency. :)

I sympathize. :)

> Ok, cool... Let me know if you're open to the error messages, as mentioned
> above. If so, I think a very simple getter and setter (property or function)
> for xml:lang would also make sense here (getter for the xml:lang returned by
> the server). It really shouldn't add much code at all I think.
> (Don't mean to be a nag on this...) :)

The above scheme would of properties+stringbundle seems to follow more
closely the grain of the platform, I'd prefer to try with that. The
properties file can still be shipped with xmpp4moz so all can benefit.

[Brett Zamir]

Massimiliano Mirra wrote:

On Wed, Sep 3, 2008 at 3:45 AM, Brett Zamir <bre...@yahoo.com> wrote:
  

hmm, I'm thinking about this... what about a event: 'connector',
state: 'error', info: xmlErrorElement?  I'd like to fit what we can
into the existing structure if it makes sense.
      

Sure. But, there is already a connector-error of type "auth" and of type
"badcert" which do not have any XML. Should I not include any "info"
property on these at all, or set them to null/undefined?
    

You can simply omit it.

  

Ok.

Also, for stream errors, I'd like to make the whole error element and its
contents available, since the <stream:error> not only contains the specific
error element (whether XML-related, e.g., <restricted-xml/> or
non-XML-related, e.g., <connection-timeout/>), but also can contain a
human-readable <text> child (xml:lang-dependent) and/or proprietary XML
content from the server related to the error. So the question is, do you
want the specific error condition element also available directly as a
property in addition to the full XML (I proposed "condition"), or do you
want to let the user extract it (from the "info" XML which contains all of
the <stream:error> content)? One advantage of making it available as a
property is that they could more easily filter for just that condition if
they wanted.
    

Let's make just the error element available now, and see how it goes.
If we miss the condition property, we can add it later.

  

Ok.

Also, what do you think of what I proposed as a "msg" property? This is a
localizable message based verbatim on the RFC3920 explanations of the
errors. For example, if the user gets a "connection-timeout" stream error
(assuming your code isn't already catching these somehow), the msg property
would be "the entity has not generated any traffic over the stream for some
period of time (configurable according to a local service policy)." I think
having such messages available would be convenient so that the xmpp4moz
developer wouldn't have to write their own text messages for every possible
stream error at section 4.7.3 of
http://www.xmpp.org/specs/rfc3920.html#streams-error , especially during
debugging. They could just set up a generic connection error listener and
say put the message in an alert. I already have the code working for this,
including the localizable messages--it'd just be a question of what property
name to use on the returned event object, if you're open to it.
    

Hmm.  I think a way to do this would be to have a .properties file
with the condition->message mapping, so that the client can loop up
the (localized) message at runtime.  Something like:

errors.properties:
    conncetion-timeout=The entity has not generated ...

  

Yup, already done.

Then you may have a utility function:

    alert(errorStringBundle.getString(XMPP.getCondition(xmlErrorElement)))

Creating the <stringbundle/> element would still be the responsibility
of the end-developer.

  

Ok. So you wouldn't be open to a utility that wraps up all of the above (including the string bundle XPCOM service which can be used in place of <stringbundle/>)?

Ok, cool... Let me know if you're open to the error messages, as mentioned
above. If so, I think a very simple getter and setter (property or function)
for xml:lang would also make sense here (getter for the xml:lang returned by
the server). It really shouldn't add much code at all I think.
(Don't mean to be a nag on this...) :)
    

The above scheme would of properties+stringbundle seems to follow more
closely the grain of the platform, I'd prefer to try with that.  The
properties file can still be shipped with xmpp4moz so all can benefit.
  

Ok, well then to comply with the RFC3920 spec with this approach, we should still supply the relevant xml:lang per the locale, so that the server doesn't choose its own xml:lang (which might contradict the user's locale).

But one question that arises for me is that if the user can't specify the xml:lang on the stream element, they'll not only get error messages in their own locale (if the server provides any <text/> children of the <stream:error>), but will also be indicating that all of the messages and iq they are sending (unless they specifically include their own xml:lang), are from that locale. There'd be no "quick fix" mode.

best,
Brett

[Massimiliano Mirra]

On Fri, Sep 5, 2008 at 2:53 AM, Brett Zamir <bre...@gmail.com> wrote:
>> Then you may have a utility function:
>>
>> alert(errorStringBundle.getString(XMPP.getCondition(xmlErrorElement)))
>>
>> Creating the <stringbundle/> element would still be the responsibility
>> of the end-developer.
>>
> Ok. So you wouldn't be open to a utility that wraps up all of the above
> (including the string bundle XPCOM service which can be used in place of
> <stringbundle/>)?

In general I think that XMPP utilities should make common XMPP tasks
easier, not generic XUL/XPCOM tasks easier. If getting a localized
XMPP-related string proves to be a recurring and otherwise cumbersome
task, however, I'm open to such a utility.

>> The above scheme would of properties+stringbundle seems to follow more
>> closely the grain of the platform, I'd prefer to try with that. The
>> properties file can still be shipped with xmpp4moz so all can benefit.
>
> Ok, well then to comply with the RFC3920 spec with this approach, we should
> still supply the relevant xml:lang per the locale, so that the server
> doesn't choose its own xml:lang (which might contradict the user's locale).

Ok.

> But one question that arises for me is that if the user can't specify the
> xml:lang on the stream element, they'll not only get error messages in their
> own locale (if the server provides any <text/> children of the
> <stream:error>), but will also be indicating that all of the messages and iq
> they are sending (unless they specifically include their own xml:lang), are
> from that locale.

Yes. Still, I don't see any way around that. Rather than
"application locale" vs. "user-configurable XMPP locale", to me the
problem seems like "single default locale" vs. "user sending messages
in multiple languages". Unless user is requested to set the language
attribute for every message he sends out, the best thing we can do is
sticking to the default locale and assuming it'll be correct in the
majority of cases.

Whether the default locale should come from the application or from a
preference setting, then, is another matter. I suggest keeping things
simple and use the application locale for now.

> There'd be no "quick fix" mode.

Uhm... what is a quick fix mode? :)

[Brett Zamir]

Massimiliano Mirra wrote:

On Fri, Sep 5, 2008 at 2:53 AM, Brett Zamir <bre...@gmail.com> wrote:
  

But one question that arises for me is that if the user can't specify the
xml:lang on the stream element, they'll not only get error messages in their
own locale (if the server provides any <text/> children of the
<stream:error>), but will also be indicating that all of the messages and iq
they are sending (unless they specifically include their own xml:lang), are
from that locale.
    

Yes.  Still, I don't see any way around that.  Rather than
"application locale" vs. "user-configurable XMPP locale", to me the
problem seems like "single default locale" vs. "user sending messages
in multiple languages".  

Yes, in the latter case, the user would probably still want to keep the default behavior, so that errors were returned in the default language. (It would take up somewhat more bandwidth though with xml:lang="" all over the place.)

There is the case, however, of multiple users using a computer--whether at home in a bilingual family or at a public place. Granted, there are apparently extensions which let you change the whole locale of Firefox, but I still feel that for a core component like xmpp4moz, it would be ideal to just give full control to the developers.

Unless user is requested to set the language
attribute for every message he sends out, the best thing we can do is
sticking to the default locale and assuming it'll be correct in the
majority of cases.

  

That could be determined automatically by a language switching interface.

Whether the default locale should come from the application or from a
preference setting, then, is another matter.  I suggest keeping things
simple and use the application locale for now.

  

I've already done the underlying work for it (besides updating xpidl/xpt files), though I don't know what names you'd be open to. This wouldn't break any existing applications. My own code so far was to add an extra argument to connector.init() (as called by XMPP.open()) which would use any "xmllang" argument on the passed in opts (accounts-based) object, or if none were present, just use a variable with the system's default locale by default (potentially over-ridable by a prior setter call in JSAPI (including being able to set it to null in order to send no xml:lang at all and find the server's default)--I was thinking something like "XMPP.client_stream_xml_lang" to distinguish it from the server stream's xml:lang that would be returned by the server).

There'd be no "quick fix" mode.
    

Uhm... what is a quick fix mode? :)

  

I just meant that with xml:lang on <stream:stream>, it quickly sets the default language so that one does not have to continually specify xml:lang on <message>, etc.

best,
Brett

[Massimiliano Mirra]

On Tue, Sep 16, 2008 at 2:42 AM, Brett Zamir <bre...@gmail.com> wrote:
> There is the case, however, of multiple users using a computer--whether at
> home in a bilingual family or at a public place.

That's a problem that should be solved at a platform level, not by a
subsystem and for the subsystem only.

> Granted, there are
> apparently extensions which let you change the whole locale of Firefox, but
> I still feel that for a core component like xmpp4moz, it would be ideal to
> just give full control to the developers.
>
>> Unless user is requested to set the language
>> attribute for every message he sends out, the best thing we can do is
>> sticking to the default locale and assuming it'll be correct in the
>> majority of cases.
>
> That could be determined automatically by a language switching interface.

Do you mean user interface? If it's automatic, you don't need user
intervention, thus neither user interface.

>> Whether the default locale should come from the application or from a
>> preference setting, then, is another matter. I suggest keeping things
>> simple and use the application locale for now.
>
> I've already done the underlying work for it (besides updating xpidl/xpt
> files), though I don't know what names you'd be open to. This wouldn't break
> any existing applications. My own code so far was to add an extra argument
> to connector.init() (as called by XMPP.open()) which would use any "xmllang"

See above. Adding arguments adds complexity. We can, but we need a
compelling case for it.