Re: [Standards] Council Minutes 2021-02-03

[drew . varner]

It’s similar to P1’s implementation, in that it will pattern match the head of 
the child element list and pop a known child off and parse it. It’s a common 
approach in functional languages.

https://github.com/processone/xmpp/blob/master/src/xep0004.erl#L152

Not sure how we’ll do it on the client yet.

- Drew

> On Feb 14, 2021, at 3:17 PM, Florian Schmaus  wrote:
> 
> On 2/11/21 7:09 PM, Drew Varner wrote:
>> First time caller, long time listener.
>> Some model-driven CODECs may not enforce nor detect order.
>> P1’s model-based XMPP CODEC (https://github.com/processone/xmpp) does not 
>> enforce nor care about the order of the elements.
>> ```
>> 2> ReportedFirst = <<"> type='result'>> type='text-single'/>> var='field-name-two'>field-value> var='field-name-three'>field-value">>.
>> <<"> var='field-name-one' label='description' type='text-single'/"...>>
>> 3> ReportedLast = <<"> var='field-name-two'>field-value> var='field-name-three'>field-value>  var='field-name-one' label='description' 
>> type='text-single'/>">>.
>> <<"> var='field-name-two'>field-value>
>> 4> xmpp:decode(fxml_stream:parse_element(ReportedFirst)) == 
>> xmpp:decode(fxml_stream:parse_element(ReportedLast)).
>> true
>> ```
>> There’s no way for them to detect the invalid order in the server code, 
>> because the CODEC hands them a record/struct. They do write it in the 
>> correct order because their implementation happened to use lists to element 
>> refs instead of maps.
> 
> What about the reading side: How does your CODEC assign field types to fields 
> of incoming data forms?
> 
> - Florian
> 
> 
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Minutes 2021-02-03

[Florian Schmaus]

On 2/11/21 7:09 PM, Drew Varner wrote:

First time caller, long time listener.

Some model-driven CODECs may not enforce nor detect order.

P1’s model-based XMPP CODEC (https://github.com/processone/xmpp) does not 
enforce nor care about the order of the elements.

```
2> ReportedFirst = <<"field-valuefield-value">>.
<<">
3> ReportedLast = <<"field-valuefield-value">>.
<<"field-value>
4> xmpp:decode(fxml_stream:parse_element(ReportedFirst)) == 
xmpp:decode(fxml_stream:parse_element(ReportedLast)).
true
```

There’s no way for them to detect the invalid order in the server code, because 
the CODEC hands them a record/struct. They do write it in the correct order 
because their implementation happened to use lists to element refs instead of 
maps.


What about the reading side: How does your CODEC assign field types to 
fields of incoming data forms?


- Florian




OpenPGP_signature
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Minutes 2021-02-03

[Florian Schmaus]

On 2/10/21 10:00 PM, Dave Cridland wrote:



On Wed, 10 Feb 2021 at 20:22, Florian Schmaus > wrote:


Since you asked: Smack relies on the ordering (in case a non-default
form field type is used), since Smack needs to see the 
first
to assign types to the field while parsing the following s.


Right, so you're parsing using a SAX-style parser and if  
comes after (or in between) the s, you'd need to use a two-pass 
parser, is that correct?


Not SAX but StAX, but not that this is relevant. I guess what is 
relevant is that I cannot rewind the parser (as, for example, a 
DOM-based would allow).


Furthermore, I do not strictly need two XML-parser passes: I could 
collect the information about the fields into a "pseudo-field" data 
structure and assemble the fields with the information found in 
 after I finished parsing the data form. Of course, this 
requires additional code and hence adds complexity.


I honestly did not expect this addition to the XEP to cause so much 
controversy. It appeared clear (to me) that the XEP intention is that 
 comes first, and then the s follow.


I understand that some languages may not come with a linked-map-like 
data structure. However, this appears to be a very commonly used data 
structure. Hence languages like Java and Python ship it as part of their 
runtime libraries. It should also be easy to add such a thing to your 
favorite language (likely it already exists as a library).


Eventually, this is a situation where we cannot avoid that somebody 
needs to change their code. We need to weigh in the effects of the three 
options:

  A: clearly state that the order is not guaranteed
  B: clearly state that the order is guaranteed
  C: state that it should be sent in order, but recipients must be able 
to process in any order


- Florian



OpenPGP_signature
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___