Hi, I think I miss some features here:
1. fetching messages by giving a set of ids, also similar like xep-013
Fetching message by id(s) is needed for example when i have a custom push
notification with a given message id(s) and client needs to get that one
message asap and show it in the chat.
e features were kind of existent back
in 2005 in xep-0013. Now we removed those features, why?
Thanks
On Sun, Mar 4, 2018 at 4:36 PM, Matthew Wild wrote:
> Hi Lazar,
>
> On 3 Mar 2018 22:54, "Lazar Otasevic" wrote:
> >
> > Hi, I think I miss some features here:
ings (e.g. there is no requirement for them
> to be numeric, sequenced or GUIDs)
>
>
> 2018-03-03 23:53 GMT+01:00 Lazar Otasevic :
>
>> Hi, I think I miss some features here:
>>
>> 1. fetching messages by giving a set of ids, also similar like xep-013
>>
>
>
>
> > Matthew,
>
> I really don't understand this argument. Doing a MAM query is exactly
> like fetching a list of ids, except that you also get the content as
> well. As I mentioned, I see no case in which you would want the ids
> and not the content. Even if you get the ids, you will fetch the
See my answer to Mathew, maybe i clarified better. cu
On Sun, Mar 4, 2018 at 9:08 PM, Philipp Hörist wrote:
>
> 2018-03-04 18:37 GMT+01:00 Lazar Otasevic :
>
>> Phillip,
>>
>> I feel like we dont entirely understand each other. Are you sure you did
>> read and
On 4 Mar 2018, at 22:01, Lazar Otasevic wrote:
> >> I really don't understand this argument. Doing a MAM query is exactly
> >> like fetching a list of ids, except that you also get the content as
> >> well. As I mentioned, I see no case in which you would want the
Kevin says we can :) I asked him to clarify... we'll see.
On Mon, Mar 5, 2018 at 11:45 AM, Philipp Hörist wrote:
>
>>
>> You can already fill holes with the current spec, by specifying both
>> and on the RSM query can’t you? If that doesn’t
>> obviously follow from the text, that’s something w
because, why not. clients should be able to choose direction i guess. not
every needs to work the same?
On Mon, Mar 5, 2018 at 1:56 PM, Philipp Hörist wrote:
>
> 2018-03-05 13:42 GMT+01:00 Lazar :
>
>> yes we need explicit controll to request last 10 or first 10 results
>> then, i dont see it po
does response has to return count?
On Mon, Mar 5, 2018 at 2:06 PM, Lazar Otasevic wrote:
> because, why not. clients should be able to choose direction i guess. not
> every needs to work the same?
>
> On Mon, Mar 5, 2018 at 1:56 PM, Philipp Hörist
> wrote:
>
>>
>&
or the last 10 inside a
> timeframe
>
> 2018-03-05 14:06 GMT+01:00 Lazar Otasevic :
>
>> because, why not. clients should be able to choose direction i guess. not
>> every needs to work the same?
>>
>> On Mon, Mar 5, 2018 at 1:56 PM, Philipp Hörist
>> wrot
@Philipp BTW, how do you handle own messages? how does client discover
archived id for newly sent message?
On Mon, Mar 5, 2018 at 4:48 PM, Lazar Otasevic wrote:
> Kevin suggested to use both (before..after) and i see no way to query
> first 10 or last 10, its a must have.
> I know
//xmpp.org/
> extensions/xep-0359.html
>
> if you request later the archive and discover a origin-id you can check
> your db if it is already present
>
>
>
> 2018-03-05 17:42 GMT+01:00 Lazar Otasevic :
>
>> @Philipp BTW, how do you handle own messages? how d
yes thats what i thought - carbon would be good
On Mon, Mar 5, 2018 at 6:14 PM, Kevin Smith wrote:
> On 5 Mar 2018, at 16:42, Lazar Otasevic wrote:
> > @Philipp BTW, how do you handle own messages? how does client discover
> archived id for newly sent message?
>
> It’s a thin
Conclusion:
1. it is not possible to iterate efficiently backwards by including both
& in the query because once is included in the query
then it iterates forwards. that means when iterating backwards client has
to omit and fetch entire pages and then the last page will mostly
overlap with some
if you set both it goes forwards (from old to new)? how to set direction
explicitly in such case?
On Tue, Mar 6, 2018 at 2:19 PM, Kevin Smith wrote:
> On 6 Mar 2018, at 13:14, Jonas Wielicki wrote:
> > I think it would be great to have a way to limit the MAM query to an
> end-ID
> > indeed. Mat
15 matches
Mail list logo
