Mon, 12 Oct 2015 09:48:07 -0300
Ben Langfeld wrote:
> I'm afraid they'd be mistaken in this belief.
Developers are bad, mmmkay. So what do you suggest? Teaching them to be
better? I bet that's not the goal of XSF. I think the solution is to
accept the fact developers do not want writing specs in
Mon, 12 Oct 2015 09:51:28 -0300
Ben Langfeld wrote:
> What else would you call it?
You can stop bugtracker for your project then. There are only trolls.
> Someone has to do this.
So XSF created a standardization process and now tells us: someone has
to do this.
> XMPP is not perfect. Nothing
Mon, 12 Oct 2015 08:45:29 -0300
Ben Langfeld wrote:
> If no-one is prepared to say why they won't do this but continues to
> complain about the absence of XEPs then the assumption has to be that
> they are trolling.
So, if I complain there is no feature X in software Y and I'm unwilling
to imple
Thu, 8 Oct 2015 14:05:04 +0200
Ralph Meijer wrote:
> Can you explain why people wanting to implement some feature couldn't
> (begin to) write a XEP?
I have some ideas why they don't do this. I know a lot of developers
from different projects who is unwilling to write XEPs. So my answer is
"I don
Thu, 8 Oct 2015 12:21:41 +0200
Ralph Meijer wrote:
> If nobody comes up with a new specification for
> functionality beyond XEP-0191, then my conclusion would be that there
> is no sufficient interest
No. The conclusion also might be that people who want this
functionality do not write XEPs.
Thi
Tue, 6 Oct 2015 11:35:58 -0500
Sam Whited wrote:
> and I doubt that
> anyone's going to try and come up with a new thing *unless* the old
> one is deprecated
The thing is nobody will come up even in the case the XEP is deprecated.
There were several attempts to write SPIM related XEPs. None of t
Tue, 6 Oct 2015 12:43:06 +0100
Kevin Smith wrote:
> On 5 Oct 2015, at 14:42, Matthew Wild wrote:
> > XEP-0191 is simple and efficient. It does one job, which is the one
> > that most users need and expect - blocking someone they not longer
> > want communication with. This operation is available
Tue, 29 Sep 2015 12:03:27 +0200
"Christian Schudt" wrote:
> Funny, I've brought up exactly these two problems, too:
> http://mail.jabber.org/pipermail/standards/2015-July/030049.html
Well I personally remember your comment :)
I would also like to add a problem with backward compatibility. I
unde
Tue, 29 Sep 2015 10:49:35 +0100
Dave Cridland wrote:
> Writing up use-cases for these things would be really interesting, by
> the way. In fact, writing up use-cases in general, and how to
> implement them with existing XEPs, would be interesting generally, I
> think. Maybe something to do on the
Tue, 29 Sep 2015 10:17:12 +0100
Tobias M wrote:
> Not ready in what capacity? It’s implemented by Conversations, Gajim,
> Swift and web clients (maybe, don’t remember for sure). Pidgin does
> not support it currently, there was a dev branch once but it’s likely
> outdated now.
Seems like I'm con
Tue, 29 Sep 2015 08:28:45 +0100
Dave Cridland wrote:
> File transfer, on the other hand, could very usefully be done via
> protocol translation. Converting SI to Jingle and back again - or
> even terminating Jingle in the server and translating to HTTP -
> really feels like it should be practical
Thu, 24 Sep 2015 13:10:44 +0300
PG Stath wrote:
> In general I think that XMPP might be missing developers not because
> features are missing but because of non compatible extensions lists
> and extension implementations among different libraries, servers and
> applications.
Totally agreed. As a
Mon, 21 Sep 2015 16:06:13 + (UTC)
XMPP Extensions Editor wrote:
> Version 0.4 of XEP-0313 (Message Archive Management) has been
> released.
>
> Abstract: This document defines a protocol to query and control an
> archive of messages stored on a server.
>
> Changelog: [See revision history]
Thu, 17 Sep 2015 21:49:04 +0200
Daniel Gultsch wrote:
> Hi,
>
> a couple of reason that speak against using the HTTP upload to create
> thumbnails. (In no particular order)
>
> - the service should be agnostic towards the files. I assume you are
> proposing to create thumbnails for images? What
Thu, 17 Sep 2015 13:51:41 +0100
Kevin Smith wrote:
> Hi folks,
>
> Council had a chat yesterday about how much review XEPs generally get
> outside those last-minute reviews required by Council at advancement
> points, and we generally agree that what happens is often
> insufficient; in an ideal
Thu, 3 Sep 2015 14:11:32 +0300
Evgeny Khramtsov wrote:
> It would be great if the protocol supports image thumbnails
> (optionally). A server could generate thumbnails during upload so a
> client don't need to convert image locally. This will reduce
> cpu/battery usage
Thu, 27 Aug 2015 16:10:18 + (UTC)
XMPP Extensions Editor wrote:
> Version 0.1 of XEP-0363 (HTTP File Upload) has been released.
>
> Abstract: This specification defines a protocol to request
> permissions from another entity to upload a file to a specific path
> on an HTTP server and at the
Thu, 27 Aug 2015 17:13:14 +0100
Dave Cridland wrote:
> The rest of these comments, though, I largely agree with - there's
> been talk of putting together both a new profile XEP, listing the
> things any "modern messaging app" should support, and also putting
> together a bunch of sensible tutoria
Wed, 26 Aug 2015 19:38:35 -0700
Lance Stout wrote:
> To that end, I submitted an update to XEP-0264 today to get it out of
> the Deferred state, allow it to use other URI types, and expand its
> scope to more than just file transfer thumbnails (for example,
> attaching a thumbnail preview to RTP
Wed, 26 Aug 2015 16:48:41 +0200
Kim Alvefur wrote:
> Didn't Jingle File Transfer support transfer of multiple files?
OK, probably it does. But it's still unclear how this will interact
with thumbnails. As I understand several files will be rejected at the
first step (only thumbnails are allowed)
Wed, 19 Aug 2015 15:44:30 + (UTC)
XMPP Extensions Editor wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Jingle HTTP Transport Method
>
> Abstract: This specification defines two Jingle transport methods for
> establishing HTTP connections for either up
Tue, 25 Aug 2015 22:03:14 +0200
Emmanuel Gil Peyrot wrote:
> Their current way is pretty terrible, they just put the URL in the
> body of the message, and the receiving client will download and
> display it if there is no other text than the URL.
This "terrible" way is easy to implement, which c
Sat, 1 Aug 2015 14:51:19 -0500
Sam Whited wrote:
> If Content-MD5 were to be supported in particular it would probably
> have to be something that clients supported, eg.
>
>
>
Another issue is how to pass this data to the file recipient. While
it looks obvious to pass an url, passing head
Thu, 30 Jul 2015 12:06:18 +0200
Goffi wrote:
> why wouldn't file transfer work offline or with MUC ? We just need a
> way to request a file with an uri.
We definitely need to transfer files with MUCs (think of lolcats in
chats). Regarding offline: sometimes I want to send a lolcat to my
offline
Thu, 30 Jul 2015 11:07:28 +0200
Goffi wrote:
> My point is that HTTP transfer is nothing more than a P2P transfer
> between server and requester(s) (and why would you not store the file
> ?), and while trying to make life easier it will result in either
> developers implementing both (so more
Mon, 27 Jul 2015 11:01:58 -0500
Sam Whited wrote:
> 2) Easily match signed requests; I did an example implementation where
> the server delegated storage to Amazon S3. The server would generate a
> pre-signed upload URL with a limited TTL, then the client would make a
> PUT to this URL. However,
Mon, 27 Jul 2015 17:20:16 +0200
Rick van Rein wrote:
> For my understanding, could you rephrase that in technical terms
> please?
Technically, you can count letters in the MSRP RFC and in HTTP-Upload
XEP :)
And to be serious, how do you see MSRP implemented in XMPP clients?
You need to get full
Mon, 27 Jul 2015 17:03:25 +0200
Rick van Rein wrote:
> I would like to point you to an alternative, namely MSRP
MSRP is scary as an atomic war :)
Mon, 27 Jul 2015 10:33:15 +0200
"Christian Schudt" wrote:
> 1) How to do offline file transfer? (see "HTTP Upload"-XEP)
> 2) How to send a file in a MUC room to all occupants/members?
> I think before moving JFT to Draft, the above two questions should be
> discussed.
HTTP upload is a really go
Mon, 27 Jul 2015 14:05:34 +0100
Kevin Smith wrote:
> Yes,
> “””
> 3.2 MUC archives
>
> A MUC service allowing MAM queries for a room MUST expose the MAM
> archive on the room's bare JID “””
This is still unclear. It's only said that a service allows MAM queries
for a room, but doesn't say wher
Mon, 27 Jul 2015 12:32:48 +0100
Kevin Smith wrote:
> To the room.
Will it be defined in the spec? Because it's not very obvious.
Thu, 27 Nov 2014 11:57:58 +
Kevin Smith wrote:
> Kev proposes using Trello for Agenda planning, with a board
> prepared at https://trello.com/b/ww7zWMlI/xmpp-council-agenda, and
> all agree. Kev asks for Council to let him know their Trello
> accounts so he can add them to the board.
So, we
Tue, 23 Sep 2014 14:43:07 +0100
kwaye kant wrote:
> I am installing the ejabberd and it seems not to be easy to
> configure.
What exactly do you have problems with?
Tue, 2 Sep 2014 10:58:38 +0100
Dave Cridland wrote:
> So your argument is that if the procedure doesn't fit the tool, we
> should change the procedure?
Sure, why not.
Tue, 2 Sep 2014 10:57:44 +0100
Dave Cridland wrote:
> Just because you disagree with the argument does not make it invalid.
Even though it's valid it doesn't mean it outweighs other arguments.
> I do follow the concept that a decentralized open protocol using a
> centralized proprietary tool is
Tue, 2 Sep 2014 09:17:05 +0100
Kevin Smith wrote:
> On Tue, Sep 2, 2014 at 7:54 AM, Cramer, E.R. (Eelco)
> wrote:
> > So it is very well possible to host a service with the same
> > features people love at github.
>
> There's an assumption running through a lot of posts in this thread
> that mo
Tue, 2 Sep 2014 09:17:05 +0100
Kevin Smith wrote:
> On the issue tracker front: Having an issue tracker is sensible, if
> people (both the submitters and the people who need to handle the
> issues) want one. We set one up years ago, and it fell into disuse so
> it's no longer running. I don't see
Tue, 02 Sep 2014 09:58:41 +0200
Goffi wrote:
> You can name and shame me if you want, 'cause I'm definitely in the
> against github-and-all-proprietary-trendy-shiny-things camp.
OK, you're the one. And a lot of people here want github.
And seems like the argument is still the same
"all-propriet
Mon, 1 Sep 2014 22:30:13 +0100
Dave Cridland wrote:
> You're implying that there is only one person.
>
> For the record, I have opposed outsourcing core XSF activities to
> github before, and will continue to do so.
Why? I still don't see reasonable arguments. From what I understood
because of
Mon, 1 Sep 2014 22:03:43 +0100
Dave Cridland wrote:
> See Kurt's comment as to one possible reason why.
>
> I use it for both work and pleasure; I'm more in the camp of wanting
> to avoid a proprietary outsourced lockin for a core concern. I don't
> mind a mirror on github, but then people expec
Mon, 01 Sep 2014 21:57:42 +0200
Florian Schmaus wrote:
> Using github's bug tracker could lead to a vendor lock-in. Especially
> for (hopefully) long living projects a self-hosted open-source bug
> tracker would be preferable in my eyes. Who knows if github still
> exists in 10 years? Who knows i
Mon, 1 Sep 2014 20:43:57 +0100
Dave Cridland wrote:
> Not all our contributors currently will use github.
Who will not? And why?
Mon, 1 Sep 2014 19:03:49 +0100
Steven Lloyd Watkin wrote:
> Whilst I agree with you entirely (we could also use Travis to test
> patches are valid and publish / updated the website) I believe there
> are some potential legal issues that have come up previously.
>
> I *think* the latest gitlab ha
Mon, 01 Sep 2014 21:57:42 +0200
Florian Schmaus wrote:
> On 01.09.2014 19:25, Evgeny Khramtsov wrote:
> > Mon, 1 Sep 2014 19:08:22 +0200
> > Christian Schudt wrote:
> >
> >> Hi,
> >>
> >> I appreciate the idea to introduce an issue tracker for
Mon, 1 Sep 2014 19:08:22 +0200
Christian Schudt wrote:
> Hi,
>
> I appreciate the idea to introduce an issue tracker for XEPs (like
> Jira).
It would be way much easier to move XEPs to github and use the
corresponding github's bug tracker.
Tue, 19 Aug 2014 10:21:42 -0700
Kurt Zeilenga wrote:
>
> On Aug 19, 2014, at 10:05 AM, Matthew Wild wrote:
>
> > On 19 August 2014 17:21, Evgeny Khramtsov
> > wrote:
> >> Tue, 19 Aug 2014 11:30:18 +0100
> >> Matthew Wild wrote:
> >
> > You
Tue, 19 Aug 2014 11:30:18 +0100
Matthew Wild wrote:
> There are so many different approaches and optimisations (as you just
> demonstrated in your message!). I don't feel this XEP is the right
> place to document them, I think there is a lot of room for
> experimentation. I want to leave implemen
Mon, 23 Jun 2014 15:23:40 +0200
Kim Alvefur wrote:
> When does this happen? Other clients should check with disco#info and
> caps if the client supports things before sending them.
This happens when a server doesn't cache caps.
> Presence de-duplication would be very interesting to implement.
Mon, 23 Jun 2014 12:11:35 +0100
Dave Cridland wrote:
> On 23 June 2014 11:44, Evgeny Khramtsov wrote:
>
> > 1) servers hold too much state
> >
>
> What state do you think they hold that they should not?
CAPs cache for example.
> > 2) clients receive too much d
Mon, 23 Jun 2014 12:01:21 +0200
Philipp Hancke wrote:
> Am 23.06.2014 09:41, schrieb Sergey Dobrov:
> > So guys, what are the exact concern around the XEP-0033
>
> None of us has ever seen 0033 deliver on "reducing the amount of s2s
> traffic". Even the authors of 0033 agreed to this in the rep
Wed, 18 Jun 2014 10:21:36 +0100
Kevin Smith wrote:
> The recipient-side filtering seems OKish, but could lead to situations
> where the publishing servers blindly send out to all possible
> recipient JIDs and let the recipients deal with whether to send to the
> clients or not - clearly not OK.
Sat, 19 Apr 2014 11:54:12 +0200
"Genghis Khan" wrote:
> Then write it down, again, if you may. I might incline to your
> opinion.
We should use ICE.
Sat, 19 Apr 2014 02:14:19 -0400
"Genghis Khan" wrote:
> On Sat, 19 Apr 2014 09:19:36 +0400
> Evgeny Khramtsov wrote:
> > There is trivial mod_sic module in ejabberd.
> > However, I still vote to Reject the XEP for the reason I did that
> > years ago.
>
&
Wed, 16 Apr 2014 17:56:07 -0600
Peter Saint-Andre wrote:
> XEP-0279 defines a simple XMPP extension that enables a client to
> discover its external IP address from its server. This feature can
> help a client discover if it's behind a NAT and thus trigger things
> like STUN lookups. I'd like to
Thu, 05 Dec 2013 03:04:28 +0100
Alexander Holler wrote:
> I wouldn't be so hard. It's a historical grown up protocol and it
> isn't that bad, It solved a lot of problems and is well described.
> There are much uglier things around.
That's a typical excuse. And developers don't need excuses, they
Thu, 05 Dec 2013 01:05:50 +0100
Alexander Holler wrote:
> Yes, they don't care, but a XMPP-server has to care about, as the
> server should refuse not-wellformed stanzas. So feeding it with the
> initial might result in a problem (not hard to avoid,
> but still ugly).
>
> Another ugly thing are
Wed, 4 Dec 2013 14:44:36 +
Dave Cridland wrote:
> XMPP is *not* a hard-schema protocol for the most part - we can and do
> cheerfully sling extra elements and attributes in all over the shop.
> Only the core is hard - that is, the stanzas and stream - the rest
> should be considered simply "c
Mon, 02 Dec 2013 17:03:55 -0800
Graham King wrote:
> We're a team of six, currently building a SIP and XMPP server in Go.
Yeah, I would say a team of six is a bare minimum to build a SIP
server :)
Mon, 02 Dec 2013 13:53:46 -0700
Peter Saint-Andre wrote:
> This document suggests some strategies for the combined use of the
> Session Initiation Protocol (SIP) and the Extensible Messaging and
> Presence Protocol (XMPP) both in user-oriented clients and in
> deployed servers.
Do we really need
301 - 359 of 359 matches
Mail list logo
