On 19.02.2017 22:49, Matthew Wild wrote:
An example implementation of storage de-duplication, let's say you
have two users: userA and userB.
userA sends a message to userB, which the server archives, because
both of them have archiving enabled. When processing the message from
userA, the server
On 2/20/17 2:20 AM, Jonas Wielicki wrote:
> I feel that using BIND2 resources---albeit this is likely to become the new
> standard---harms readability a lot. However, I can also see that using
> examples which do not fit the current standards lead to developers
> implementing the wrong things,
On 2/20/17 4:28 AM, Florian Schmaus wrote:
> On 20.02.2017 10:36, Georg Lukas wrote:
>> * Jonas Wielicki [2017-02-20 10:20]:
>>> I feel that using BIND2 resources---albeit this is likely to become the new
>>> standard---harms readability a lot. However, I can also see that using
>>> examples whi
On 20 Feb 2017, at 16:12, Steve Kille wrote:
>> Clients are going to need to use a consistent approach to globally unique
>> naming. If they’re not unique then you’ll get collisions and all the
>> benefits are
>> lost. (And if they’re not consistent then they’ll be fingerprintable, which
>> seems
> Clients are going to need to use a consistent approach to globally unique
> naming. If they’re not unique then you’ll get collisions and all the benefits
> are
> lost. (And if they’re not consistent then they’ll be fingerprintable, which
> seems like a sensible thing to avoid while we’ve got t
On 20.02.2017 14:12, Kevin Smith wrote:
>
>> On 20 Feb 2017, at 12:42, Florian Schmaus wrote:
>>
>> On 20.02.2017 12:54, Kevin Smith wrote:
>>> Hi Flow,
>>>
>>> On 20 Feb 2017, at 11:28, Florian Schmaus wrote:
On 20.02.2017 10:36, Georg Lukas wrote:
> * Jonas Wielicki [2017-02-20
> On 20 Feb 2017, at 12:42, Florian Schmaus wrote:
>
> On 20.02.2017 12:54, Kevin Smith wrote:
>> Hi Flow,
>>
>> On 20 Feb 2017, at 11:28, Florian Schmaus wrote:
>>>
>>> On 20.02.2017 10:36, Georg Lukas wrote:
* Jonas Wielicki [2017-02-20 10:20]:
> I feel that using BIND2 resources-
On 20.02.2017 12:54, Kevin Smith wrote:
> Hi Flow,
>
> On 20 Feb 2017, at 11:28, Florian Schmaus wrote:
>>
>> On 20.02.2017 10:36, Georg Lukas wrote:
>>> * Jonas Wielicki [2017-02-20 10:20]:
I feel that using BIND2 resources---albeit this is likely to become the
new
standard---h
Hi Flow,
On 20 Feb 2017, at 11:28, Florian Schmaus wrote:
>
> On 20.02.2017 10:36, Georg Lukas wrote:
>> * Jonas Wielicki [2017-02-20 10:20]:
>>> I feel that using BIND2 resources---albeit this is likely to become the new
>>> standard---harms readability a lot. However, I can also see that usi
On 20.02.2017 10:36, Georg Lukas wrote:
> * Jonas Wielicki [2017-02-20 10:20]:
>> I feel that using BIND2 resources---albeit this is likely to become the new
>> standard---harms readability a lot. However, I can also see that using
>> examples which do not fit the current standards lead to devel
Mon, 20 Feb 2017 10:36:07 +0100
Georg Lukas wrote:
> I think that we need readable examples in the XEPs over anything else.
> My suggestion would be to use human-readable, short resource
> identifiers, both in the client case and in the auto-generated proxy
> case. It is possible to convey the sa
* Jonas Wielicki [2017-02-20 10:20]:
> I feel that using BIND2 resources---albeit this is likely to become the new
> standard---harms readability a lot. However, I can also see that using
> examples which do not fit the current standards lead to developers
> implementing the wrong things, such
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hey list,
On Montag, 20. Februar 2017 02:00:49 CET Steve Kille wrote:
> > * Steve Kille [2017-02-13 12:55]:
> > > 8. Use example JIDs aligned to anticipated BIND2 format. These are
> > > long!
> >
> > I think it's a bad idea to do this in examples
Hi,
first of all thank you Matt for the update.
> In the case of non-anonymous rooms or if the recipient of the MUC archive has
> the right to access the sender real JID at the time of the query, the archive
> message will use extended message information in an element qualified by
> the 'htt
14 matches
Mail list logo
